C++ Translator Yet?

[Louis Dascoulias]

I've answered this question myself on the asp.net ng a while back: (it was a
while back). I am faced with converting a large proprietary C++ app
(Proprietary DEFINED: the programmer was
1. too lazy to document, or 2. too protective to document)
Does anyone know of a tutorial, if not an app to convert C++ (VS 6) code to
C#?
As much as I'd like to ignore the existing code & just rewrite it from
scratch, I can't.
I have to at least mimic the code. It is a system that talks to hardware
devices in the field.

thanks,
Louis D. , JASE Group, Va

[Sin]

> I've answered this question myself on the asp.net ng a while back: (it was
a

while back). I am faced with converting a large proprietary C++ app
(Proprietary DEFINED: the programmer was
1. too lazy to document, or 2. too protective to document)
Does anyone know of a tutorial, if not an app to convert C++ (VS 6) code to C#?
As much as I'd like to ignore the existing code & just rewrite it from
scratch, I can't.
I have to at least mimic the code. It is a system that talks to hardware
devices in the field.

Uh... I don't think that'll ever happen. There's no other way than to
analyse and understand the code (as ugly as it can be) and then totally
re-write the code in the other language. This is the same with all other
languages... There's no magic... Blood and sweat... That's what we're payed
big salaries for...

Alex.

[Brandon Bray [MSFT]]

Louis Dascoulias wrote:

Does anyone know of a tutorial, if not an app to convert C++ (VS 6) code
to C#?

Hello Louis,

A conversion tool from C++ to C# is impossible. There are things that can be
expressed in C++ that cannot be expressed in C#.

As for manual guidance, unless you're referring to specific algorithms and
APIs, you won't find general guidance. The best way is to learn both
languages and have at it.

In general, I find a switch of this nature to be highly unproductive. Have
you considered other approaches such as keeping the existing C++ and using
C# in new areas? Or even better using C++ with the /clr switch? The CLR has
quite a few ways to do interop with existing code. Translating code from one
language to another is almost worse than throwing the code away.

Cheerio!

--
Brandon Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Louis Dascoulias]

Thanks Brandon. I really expected as much.
The biggest problem I have is that there is no software documentation that I
can find, and all the progammers were 'let go'.
I'll forward this to my manager. We have decided to do new development
in .Net but the new dev needs to at least mimic the old comm dll's done in
C++.

The app is a comm system that polls remote devices. I've started looking at
the
Real-time Communications (RTC) Client.. I'll search around for a .Net
library for comm.

thx again,
Louis D. , JASE Group
"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message
news:ee**************@TK2MSFTNGP11.phx.gbl...

Louis Dascoulias wrote:

Does anyone know of a tutorial, if not an app to convert C++ (VS 6) code
to C#?
Hello Louis,

A conversion tool from C++ to C# is impossible. There are things that can

be expressed in C++ that cannot be expressed in C#.

As for manual guidance, unless you're referring to specific algorithms and
APIs, you won't find general guidance. The best way is to learn both
languages and have at it.

In general, I find a switch of this nature to be highly unproductive. Have
you considered other approaches such as keeping the existing C++ and using
C# in new areas? Or even better using C++ with the /clr switch? The CLR has quite a few ways to do interop with existing code. Translating code from one language to another is almost worse than throwing the code away.

Cheerio!

--
Brandon Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Stephan Schaem]

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message news:ee**************@TK2MSFTNGP11.phx.gbl...

Louis Dascoulias wrote:

Does anyone know of a tutorial, if not an app to convert C++ (VS 6) code
to C#?
Hello Louis,

A conversion tool from C++ to C# is impossible. There are things that can be
expressed in C++ that cannot be expressed in C#.

Would it be possible to 'decompiler' MSIL to C# ?

If so, one would create a 'secure' managed assembly from the C++ code using the /clr, and decompile to C# ?

Or is this impossible because the resulting MSIL code still keep the C++ concepts that cant be expressed in C#?

Just curious...

Stephan

As for manual guidance, unless you're referring to specific algorithms and
APIs, you won't find general guidance. The best way is to learn both
languages and have at it.

In general, I find a switch of this nature to be highly unproductive. Have
you considered other approaches such as keeping the existing C++ and using
C# in new areas? Or even better using C++ with the /clr switch? The CLR has
quite a few ways to do interop with existing code. Translating code from one
language to another is almost worse than throwing the code away.

Cheerio!

--
Brandon Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Brandon Bray [MSFT]]

Hello Stephan!

Stephan Schaem wrote:

Would it be possible to 'decompiler' MSIL to C# ?
Sure (mostly). It would not necessarily make the code any more readable.
Because structure about the original program is inevitably lost during
compilation, a decompile would look more like the MSIL than code that you
would actually write in C#. For example, a for loop is translated into a
series of basic blocks with appropriate jumps, which when translated back to
C# is closest to labels and jumps. Some intelligence can be done to
reconstitute a for-loop, but any optimizations to the MSIL (like loop
unrolling, induction variables, etc.) would make that harder.
If so, one would create a 'secure' managed assembly from the C++ code
using the /clr, and decompile to C# ?
One can certainly create a 'secure' managed assembly from C++. The Everett
(VC2003) compiler had a "cookbook" for being able to do this. The next
release of Visual C++ will have the '/clr:safe' switch will force the
assembly to verifiable.

Again, the decompiled program probably would not look anything like a normal
C# program. Nor would it look anything like a normal C++ program.
Or is this impossible because the resulting MSIL code still keep the C++
concepts that cant be expressed in C#?

There are some C++ semantics that C# does not understand. For instance,
there are some MSIL instructions that the C# compiler does not generate.
These are usually in correlation to V-Tables for C++ native classes.

Cheerio!

--
Brandon Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Stephan Schaem]

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello Stephan!

Stephan Schaem wrote:

Would it be possible to 'decompiler' MSIL to C# ?
Sure (mostly). It would not necessarily make the code any more readable.
Because structure about the original program is inevitably lost during
compilation, a decompile would look more like the MSIL than code that you
would actually write in C#. For example, a for loop is translated into a
series of basic blocks with appropriate jumps, which when translated back to
C# is closest to labels and jumps. Some intelligence can be done to
reconstitute a for-loop, but any optimizations to the MSIL (like loop
unrolling, induction variables, etc.) would make that harder.

If so, one would create a 'secure' managed assembly from the C++ code
using the /clr, and decompile to C# ?

One can certainly create a 'secure' managed assembly from C++. The Everett
(VC2003) compiler had a "cookbook" for being able to do this. The next
release of Visual C++ will have the '/clr:safe' switch will force the
assembly to verifiable.

Again, the decompiled program probably would not look anything like a normal
C# program. Nor would it look anything like a normal C++ program.

Or is this impossible because the resulting MSIL code still keep the C++
concepts that cant be expressed in C#?

There are some C++ semantics that C# does not understand. For instance,
there are some MSIL instructions that the C# compiler does not generate.
These are usually in correlation to V-Tables for C++ native classes.

Cheerio!

Thanks you for your explaination and taking the time to answer these type of questions.

One more, related to the subject of MSIL code generation: I would like to understand when and if the C++ team
will be able to integrate the current intrinsic functions (exposing SIMD functionality) into future MSIL revision?
I'm asking to see if it will be possible to, at some point, migrate to 100% managed app.
Specially of interest if this is planned in Longhorn timeframe...

Do you recommand any links for futher reading on just MSIL?

Thanks again,

Stephan


--
Brandon Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Kalafiorczyk]

Hello Brandon!

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote:

The Everett
(VC2003) compiler had a "cookbook" for being able to do this.

Can you point me to an example of C++ code (for Everett)
that uses any integer type and passes "pverify" check?

No matter what I've tried as soon as I declared any
integer variable my code would fail to pass "pverify"
with an error:

[IL]: Error: Unverifiable PE Header/native stub.

The code is really simple and included below.

I have a feeling that you know what you are talking about
"cookbook". Can you share that secret ingredient?

Thanks,

Sylvester
-------------------------------------------------------
#ifdef _MANAGED
#using <mscorlib.dll>
using namespace System::Security::Permissions;
[assembly:SecurityPermissionAttribute(
SecurityAction::RequestMinimum,SkipVerification=fa lse)];
#define puts System::Console::WriteLine
#define S(x) S##x
#else
#include <cstdio>
#define S(x) x
#endif
int main()
{
int i(1); // this is the problem
puts(S("Hello, C++ world!"));
return 0;
}
--------------------------------------------------------
@echo off
cl /clr:initialAppDomain /Od h.cpp /Fohm /Fehm /Fahm nochkclr.obj /link /entry:main /fixed:no /opt:ref
if errorlevel 1 goto end
rem permview hm.exe
silo -s hm.exe
peverify hm.exe
: end
--------------------------------------------------------

[Ronald Laeremans [MSFT]]

2 books have great info on IL (Amazon site used for convenience, not as an
endorsement):
<http://www.amazon.com/exec/obidos/tg...1069445818/sr=
1-4/ref=sr_1_4/002-3697507-1194409?v=glance&s=books>

<http://www.amazon.com/exec/obidos/tg...1069445880/sr=
1-1/ref=sr_1_1/002-3697507-1194409?v=glance&s=books>

We have been discussing SIMD intrinsics support for MSIL. It definitely will
not be available in the Whidbey release, but is still under consideration
for the Orcas / Longhorn release.

Ronald Laeremans
Visual C++ team

"Stephan Schaem" <ss*****@seriousmagic.com> wrote in message
news:uW**************@TK2MSFTNGP10.phx.gbl...

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello Stephan!

Stephan Schaem wrote:

Would it be possible to 'decompiler' MSIL to C# ?

Sure (mostly). It would not necessarily make the code any more readable.
Because structure about the original program is inevitably lost during
compilation, a decompile would look more like the MSIL than code that you would actually write in C#. For example, a for loop is translated into a
series of basic blocks with appropriate jumps, which when translated back to C# is closest to labels and jumps. Some intelligence can be done to
reconstitute a for-loop, but any optimizations to the MSIL (like loop
unrolling, induction variables, etc.) would make that harder.

If so, one would create a 'secure' managed assembly from the C++ code
using the /clr, and decompile to C# ?

One can certainly create a 'secure' managed assembly from C++. The Everett (VC2003) compiler had a "cookbook" for being able to do this. The next
release of Visual C++ will have the '/clr:safe' switch will force the
assembly to verifiable.

Again, the decompiled program probably would not look anything like a normal C# program. Nor would it look anything like a normal C++ program.

Or is this impossible because the resulting MSIL code still keep the C++ concepts that cant be expressed in C#?

There are some C++ semantics that C# does not understand. For instance,
there are some MSIL instructions that the C# compiler does not generate.
These are usually in correlation to V-Tables for C++ native classes.

Cheerio!

Thanks you for your explaination and taking the time to answer these type

of questions.
One more, related to the subject of MSIL code generation: I would like to understand when and if the C++ team will be able to integrate the current intrinsic functions (exposing SIMD functionality) into future MSIL revision? I'm asking to see if it will be possible to, at some point, migrate to 100% managed app. Specially of interest if this is planned in Longhorn timeframe...

Do you recommand any links for futher reading on just MSIL?

Thanks again,

Stephan

--
Brandon Bray http://blogs.gotdotnet.com/branbray/ This posting is provided AS IS with no warranties, and confers no rights.

[Stephan Schaem]

Thanks for the reference... the reviews look great, should be some very productive reading.

What would actually make SIMD intrisinc support be at the 'top' of the todo list?
Anyway to influence MS considerations on this?

Stephan

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message news:uh**************@tk2msftngp13.phx.gbl...

2 books have great info on IL (Amazon site used for convenience, not as an
endorsement):
<http://www.amazon.com/exec/obidos/tg...1069445818/sr=
1-4/ref=sr_1_4/002-3697507-1194409?v=glance&s=books>

<http://www.amazon.com/exec/obidos/tg...1069445880/sr=
1-1/ref=sr_1_1/002-3697507-1194409?v=glance&s=books>

We have been discussing SIMD intrinsics support for MSIL. It definitely will
not be available in the Whidbey release, but is still under consideration
for the Orcas / Longhorn release.

Ronald Laeremans
Visual C++ team

"Stephan Schaem" <ss*****@seriousmagic.com> wrote in message
news:uW**************@TK2MSFTNGP10.phx.gbl...

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message

news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello Stephan!

Stephan Schaem wrote:
> Would it be possible to 'decompiler' MSIL to C# ?

Sure (mostly). It would not necessarily make the code any more readable.
Because structure about the original program is inevitably lost during
compilation, a decompile would look more like the MSIL than code that you would actually write in C#. For example, a for loop is translated into a
series of basic blocks with appropriate jumps, which when translated back to C# is closest to labels and jumps. Some intelligence can be done to
reconstitute a for-loop, but any optimizations to the MSIL (like loop
unrolling, induction variables, etc.) would make that harder.

> If so, one would create a 'secure' managed assembly from the C++ code
> using the /clr, and decompile to C# ?

One can certainly create a 'secure' managed assembly from C++. The Everett (VC2003) compiler had a "cookbook" for being able to do this. The next
release of Visual C++ will have the '/clr:safe' switch will force the
assembly to verifiable.

Again, the decompiled program probably would not look anything like a normal C# program. Nor would it look anything like a normal C++ program.

> Or is this impossible because the resulting MSIL code still keep the C++ > concepts that cant be expressed in C#?

There are some C++ semantics that C# does not understand. For instance,
there are some MSIL instructions that the C# compiler does not generate.
These are usually in correlation to V-Tables for C++ native classes.

Cheerio!

Thanks you for your explaination and taking the time to answer these type

of questions.

One more, related to the subject of MSIL code generation: I would like to

understand when and if the C++ team

will be able to integrate the current intrinsic functions (exposing SIMD

functionality) into future MSIL revision?

I'm asking to see if it will be possible to, at some point, migrate to

100% managed app.

Specially of interest if this is planned in Longhorn timeframe...

Do you recommand any links for futher reading on just MSIL?

Thanks again,

Stephan

--
Brandon Bray http://blogs.gotdotnet.com/branbray/ This posting is provided AS IS with no warranties, and confers no rights.

[Ronald Laeremans [MSFT]]

You are already speaking to the team that has part of the responsibility for
this part of the product. To make sure you have the other half's ear as
well, you should post a question about this on the CLR newsgroup.

If the applications you are working on are a significant revenue driver for
Microsoft, make sure you express your concerns to your TAM or other primary
Microsoft contact.

Ronald

"Stephan Schaem" <ss*****@seriousmagic.com> wrote in message
news:O5**************@tk2msftngp13.phx.gbl...

Thanks for the reference... the reviews look great, should be some very productive reading.
What would actually make SIMD intrisinc support be at the 'top' of the todo list? Anyway to influence MS considerations on this?

Stephan

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message

news:uh**************@tk2msftngp13.phx.gbl...

2 books have great info on IL (Amazon site used for convenience, not as an endorsement):
<http://www.amazon.com/exec/obidos/tg...1069445818/sr= 1-4/ref=sr_1_4/002-3697507-1194409?v=glance&s=books>

<http://www.amazon.com/exec/obidos/tg...1069445880/sr= 1-1/ref=sr_1_1/002-3697507-1194409?v=glance&s=books>

We have been discussing SIMD intrinsics support for MSIL. It definitely will not be available in the Whidbey release, but is still under consideration for the Orcas / Longhorn release.

Ronald Laeremans
Visual C++ team

"Stephan Schaem" <ss*****@seriousmagic.com> wrote in message
news:uW**************@TK2MSFTNGP10.phx.gbl...

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message

news:ex**************@TK2MSFTNGP09.phx.gbl...

> Hello Stephan!
>
> Stephan Schaem wrote:
> > Would it be possible to 'decompiler' MSIL to C# ?
>
> Sure (mostly). It would not necessarily make the code any more readable. > Because structure about the original program is inevitably lost during > compilation, a decompile would look more like the MSIL than code that

you

> would actually write in C#. For example, a for loop is translated

into a > series of basic blocks with appropriate jumps, which when translated

back to

> C# is closest to labels and jumps. Some intelligence can be done to
> reconstitute a for-loop, but any optimizations to the MSIL (like loop > unrolling, induction variables, etc.) would make that harder.
>
> > If so, one would create a 'secure' managed assembly from the C++ code > > using the /clr, and decompile to C# ?
>
> One can certainly create a 'secure' managed assembly from C++. The

Everett

> (VC2003) compiler had a "cookbook" for being able to do this. The next > release of Visual C++ will have the '/clr:safe' switch will force the > assembly to verifiable.
>
> Again, the decompiled program probably would not look anything like a normal

> C# program. Nor would it look anything like a normal C++ program.
>
> > Or is this impossible because the resulting MSIL code still keep

the C++

> > concepts that cant be expressed in C#?
>
> There are some C++ semantics that C# does not understand. For

instance, > there are some MSIL instructions that the C# compiler does not generate. > These are usually in correlation to V-Tables for C++ native classes.
>
> Cheerio!

Thanks you for your explaination and taking the time to answer these

type of questions.

One more, related to the subject of MSIL code generation: I would like

to understand when and if the C++ team

will be able to integrate the current intrinsic functions (exposing

SIMD functionality) into future MSIL revision?

I'm asking to see if it will be possible to, at some point, migrate to

100% managed app.

Specially of interest if this is planned in Longhorn timeframe...

Do you recommand any links for futher reading on just MSIL?

Thanks again,

Stephan
>
> --
> Brandon Bray

http://blogs.gotdotnet.com/branbray/

> This posting is provided AS IS with no warranties, and confers no

rights.

>
>

[Ira Baxter]

"Louis Dascoulias" <lo**************@jasegroup.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

I've answered this question myself on the asp.net ng a while back: (it was a while back). I am faced with converting a large proprietary C++ app
(Proprietary DEFINED: the programmer was
1. too lazy to document, or 2. too protective to document)
Does anyone know of a tutorial, if not an app to convert C++ (VS 6) code to C#?
As much as I'd like to ignore the existing code & just rewrite it from
scratch, I can't.
I have to at least mimic the code. It is a system that talks to hardware
devices in the field.

You might consider using the DMS Software Reengineering Toolkit.
This is generalized compiler technology used to parse/analyze/transform
source programs. DMS has a full C++ front end available,
and a C# frontend also (which can double as a backend in a translation).
We have not implemented a translator from C++ to C#,
but DMS can accept translation rules (usually several thousand
to translate languages of this complexity) to carry this out.

Others have rightfully pointed out that there are some C++
constructs that may be hard or impossible to translate directly.
On the other hand, your code may not use these constructs,
may not used them extensively, or may use them in idiomatic
ways that makes it possible to translate them anyway.
(Finally you can fall back on hand-patching, which
in the worst case, for the untranslatable items, cannot
reeally be any worse than recoding that stuff from scratch).
C++ and C# share enough so that I'd expect quite a lot
would translate relatively nicely.

See http://www.semdesigns.com/Products/S...Migration.html
for more details.
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com