Whats the Deal with Visual C++.Net?

[Paul Tremblay]

Hi All,

I am a veteran C/C++ programmer (Unix background) and I want to get to
speed with Visual Studio .Net

I have legacy C/C++ code that I want to use in my application. However,
I'm not sure how to call my native C++ functions from my C++ DLLs. The
confusion is this: I currently have Visual Studio 2003 it is not clear
whether I should use managed extensions or C++/Interop?

I have had a look at some sample code from the MSDN site. The syntax
looks wierd - nothing like C++.

For example, I saw a variable declared of type: String ^
what the ...?

What does this mean?. I thought this was the most ISO C++ compatable
C+++ that MS has ever produced. Am I missing something here?

Lastly, but not the least, is the apparant casual nature with which
everyone (Microsoft included), is treating the fact that the IL code is
easily reversed. Is anyone out there actually building applications
using .Net and delivering to clients?. How do they ensure that their IP
is protected?. It seems (AFAIK) that even forms (i.e. all your
presentation logic) are compiled to IL, which can easily be reverse
engineered. Does MS eat its own dog food? Does anyone know of any
commercial MS application actual written in .Net and compiled as IL?

I will be very interested in hearing your comments.

PS: I know that even native C binaries can be reverse engineered by a
persistent enough hacker - but that level of security afforded by native
binaries is sufficient to me. I'll take my chances with that.

[Carl Daniel [VC++ MVP]]

Paul Tremblay wrote:

Hi All,

I am a veteran C/C++ programmer (Unix background) and I want to get to
speed with Visual Studio .Net

I have legacy C/C++ code that I want to use in my application.
However, I'm not sure how to call my native C++ functions from my C++
DLLs. The confusion is this: I currently have Visual Studio 2003 it
is not clear whether I should use managed extensions or C++/Interop?
Why not just keep everything native? You're not required to use .NET at
all, despite the .NET in the product name. You can still build native user
interfaces using MFC or WTL or any library of your choice.

If you do want to interop with native code, you have three choices:

1. Managed C++ IJW (It Just Works). Managed C++ can simply call unmanaged
C++.
2. P/Invoke (Platform Invoke) services can be used to call native code from
any .NET language.
3. COM Interop services can be used to call native code from any .NET
language.

Of these, IJW is the fastest and COM interop is the slowest.
I have had a look at some sample code from the MSDN site. The syntax
looks wierd - nothing like C++.

For example, I saw a variable declared of type: String ^
what the ...?

What does this mean?. I thought this was the most ISO C++ compatable
C+++ that MS has ever produced. Am I missing something here?
Yes. You're looking at documentation for VC++ 2005, which implements a new
language in addition to ISO C++. That new language is called C++/CLI. For
VC++ 2003, you need to look at "Managed Extensions for C++". There should
be a Word document in your .../Microsoft Visual Studio .NET 2003/vc7 folder
called "managedextensi onsspec.doc" that tells you all about it. It's
painful, although not nearly as bad as writing JNI interface code for Java.
Lastly, but not the least, is the apparant casual nature with which
everyone (Microsoft included), is treating the fact that the IL code
is easily reversed. Is anyone out there actually building applications
using .Net and delivering to clients?. How do they ensure that their
IP is protected?. It seems (AFAIK) that even forms (i.e. all your
presentation logic) are compiled to IL, which can easily be reverse
engineered. Does MS eat its own dog food? Does anyone know of any
commercial MS application actual written in .Net and compiled as IL?
No entire applications (that I'm aware of), but large parts of Visual Studio
2005 (and to a lesser extent, 2003 and 2002) are written in managed code
(mostly either the older Managed C++ or the new C++/CLI).

There are commercial applications shipping that are pure .NET. For example,
SourceGear Vault, a source code control program, is pure IL code.

You're not alone in this concern. It'll be interesting to see how it plays
out over the next few years. Note that Java has the same problem - bytecode
can be easily and mechanically reverse-engineered into compilable source
code.

I will be very interested in hearing your comments.

PS: I know that even native C binaries can be reverse engineered by a
persistent enough hacker - but that level of security afforded by
native binaries is sufficient to me. I'll take my chances with that.

[William DePalo [MVP VC++]]

"Paul Tremblay" <pt*******@hotm ail.com> wrote in message
news:d8******** **@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...
Lastly, but not the least, is the apparant casual nature with which

everyone (Microsoft included), is treating the fact that the IL code is
easily reversed. Is anyone out there actually building applications using
.Net and delivering to clients?. How do they ensure that their IP is
protected?.

That's a good question for which I wish I have ever heard a satisfying
answer. :-(

Just by the way, do you know about the Native Image Generator - ngen?

http://msdn.microsoft.com/library/de...torNgenexe.asp

It is used to pre-jit (compile in advance of use) the IL to native code. On
the plus-side it ought to make the disassembly process more difficult. On
the down-side it is something that is supposed to be done on each end-user's
system.

Regards,
Will

[Olaf Baeyens]

> Lastly, but not the least, is the apparant casual nature with which

everyone (Microsoft included), is treating the fact that the IL code is
easily reversed. Is anyone out there actually building applications using .Net and delivering to clients?. How do they ensure that their IP is
protected?.
That's a good question for which I wish I have ever heard a satisfying
answer. :-(

Just by the way, do you know about the Native Image Generator - ngen?

http://msdn.microsoft.com/library/de...torNgenexe.asp
It is used to pre-jit (compile in advance of use) the IL to native code. On the plus-side it ought to make the disassembly process more difficult. On
the down-side it is something that is supposed to be done on each end-user's system.

Don't get fooled that unmanaged code is impossible te reverse engineer.
It is a little harder, but it is not worth the effort to lose time in
protecting your code.

Unmanaged code can with the current tools be reversed engineered in days if
not hours if someone really wants to.
Use the time that you would put in your protection for new functionality to
make your product even better than the competition.

Reverse enginering of unmanaged code can be easily done because professional
disasemblers look at patterns in the executable code to determin what
standard C++ function you have used. Unless you write all your C++ code like
file handling, string handling yourself, it can be easily disassembled in a
very readabel form. The weak point is still the WINAPI calls, if you use one
of those calls, then the disassembler makes this a readable statment.

Just look at this IDA Pro disassmebler:
http://www.datarescue.com/idabase/index.htm

[Jochen Kalmbach [MVP]]

Hi William!

Just by the way, do you know about the Native Image Generator - ngen?

It is used to pre-jit (compile in advance of use) the IL to native code. On
the plus-side it ought to make the disassembly process more difficult.

The only "plus-side" is that the jit is not needed on every startup of
the app.

It does *not* make the disassembly process more difficult!
The managed assembly stays untouched! Therefor you can still use some
tools like ".NET Refelector"...

The native image is just cached in an native-image-cache.

You can vies the native-image-cache only via command-line, because the
Explorer has some extension to display some "special" list.

Just go to "C:\WINDOWS\ass embly\NativeIma ges1_v1.1.4322" and you will
see some subdirs and then some files...

But the original assemblies in the GAC (or whereever stored) are not
touched by ngen.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Paul Tremblay]

Hello Carl,

Thanks for the info. The only reason I am considering using .Net is
because of its GUI productivity tools - i.e., for developing fast and
great looking apps (XP feel etc) on the client side.

I like the concept of Windows Forms, and the ease with which quite
complex GUIs can be created with relative ease. Had it not been because
of the GUI tools, I would probably not be considering Visual Studio .Net
at all (if it works, don't fix it ... and all that).

The problem is that (AFAICT), if I (or anyone for that matter) put
effort in developing a nice flashy GUI in .Net, the code produced is IL
- and therefore I am more or less giving away the source code to my
custom presentation tier logic (please say it isn't so - or there is a
way around this).

You mentioned that I don't have to use .Net - Ah, but life is often not
that simple. .Net seems to have the GUI development tools I want, but
that comes with the (unacceptably) high price of opening up my
application GUI code to the entire world (this is not a serious option
for any ISV - and probably explains why MS themselves are not doing
this). The only option then is to use either WTL or MFC as you
suggested. I had never heard of WTL, so I did a google search and read
up on it. It is an extension to ATL, not supported by MS, and currently
only at beta phase. You're not seriously suggesting that I build a
serious (commercial) application with that are you?.

So the only option left seems to be MFC. Well there is apparently a
problem with this route as well as MFC is gradually going to be phased
out by MS (not to mention the ridiculously steep learning curve and lack
of good, intuitive WYSWIG GUI building tools compared to .Net). It is
not very prudent to develop a new application with technology that is
being phased out. So it seems I am stuck between a rock and a very hard
place.

Is there another alternative that I am missing?. Basically, all I'm
looking for is this: a WYSIWYG GUI builder that is capable of building
screens of the same quality as that built by .Net (XP look and feel, RAD
development etc) but then either generates pure ISO C++, or builds a
native binary which I can interface to my C++ native libraries. If only
I could build native binaries from a WinForm, then I could design a nice
GUI in .Net, create a native binary from that and "nail" that GUI end to
my native C++ libraries. I would not have though that was too much to ask.

To summarize, it looks like MFC is the only route to create native GUI
applications (please say it isn't so!). I don't want to use MFC because
of these facts (I stand to be corrected on any of these)

1). Steep learning curve
2). Its a technology being phased out by MS
3). I'm not sure how many GUI components there are out there for MFC,
compared to .Net (i.e. I believe that .Net produces flashier and nicer GUIs)

I hope you or someone else can help answer these questions

Thanks

Paul

Carl Daniel [VC++ MVP] wrote:

Paul Tremblay wrote:

Hi All,

I am a veteran C/C++ programmer (Unix background) and I want to get to
speed with Visual Studio .Net

I have legacy C/C++ code that I want to use in my application.
However, I'm not sure how to call my native C++ functions from my C++
DLLs. The confusion is this: I currently have Visual Studio 2003 it
is not clear whether I should use managed extensions or C++/Interop?

Why not just keep everything native? You're not required to use .NET at
all, despite the .NET in the product name. You can still build native user
interfaces using MFC or WTL or any library of your choice.

If you do want to interop with native code, you have three choices:

1. Managed C++ IJW (It Just Works). Managed C++ can simply call unmanaged
C++.
2. P/Invoke (Platform Invoke) services can be used to call native code from
any .NET language.
3. COM Interop services can be used to call native code from any .NET
language.

Of these, IJW is the fastest and COM interop is the slowest.

I have had a look at some sample code from the MSDN site. The syntax
looks wierd - nothing like C++.

For example, I saw a variable declared of type: String ^
what the ...?

What does this mean?. I thought this was the most ISO C++ compatable
C+++ that MS has ever produced. Am I missing something here?

Yes. You're looking at documentation for VC++ 2005, which implements a new
language in addition to ISO C++. That new language is called C++/CLI. For
VC++ 2003, you need to look at "Managed Extensions for C++". There should
be a Word document in your .../Microsoft Visual Studio .NET 2003/vc7 folder
called "managedextensi onsspec.doc" that tells you all about it. It's
painful, although not nearly as bad as writing JNI interface code for Java.

Lastly, but not the least, is the apparant casual nature with which
everyone (Microsoft included), is treating the fact that the IL code
is easily reversed. Is anyone out there actually building applications
using .Net and delivering to clients?. How do they ensure that their
IP is protected?. It seems (AFAIK) that even forms (i.e. all your
presentatio n logic) are compiled to IL, which can easily be reverse
engineered. Does MS eat its own dog food? Does anyone know of any
commercial MS application actual written in .Net and compiled as IL?

No entire applications (that I'm aware of), but large parts of Visual Studio
2005 (and to a lesser extent, 2003 and 2002) are written in managed code
(mostly either the older Managed C++ or the new C++/CLI).

There are commercial applications shipping that are pure .NET. For example,
SourceGear Vault, a source code control program, is pure IL code.

You're not alone in this concern. It'll be interesting to see how it plays
out over the next few years. Note that Java has the same problem - bytecode
can be easily and mechanically reverse-engineered into compilable source
code.

I will be very interested in hearing your comments.

PS: I know that even native C binaries can be reverse engineered by a
persistent enough hacker - but that level of security afforded by
native binaries is sufficient to me. I'll take my chances with that.

[Hendrik Schober]

Paul Tremblay <pt*******@hotm ail.com> wrote:

[...] I had never heard of WTL, so I did a google search and read
up on it. It is an extension to ATL, not supported by MS, and currently
only at beta phase. You're not seriously suggesting that I build a
serious (commercial) application with that are you?.
I have never used or even looked at WTL, but
you might be painting it too black here.
So the only option left seems to be MFC. [...]
Have you looked at www.wxWidgets.org?
Is there another alternative that I am missing?. Basically, all I'm
looking for is this: a WYSIWYG GUI builder [...]
Why don't you consider to implement all your
logic in native C++ and only do the pure GUI
(that is: no logic at all) in whatever you
like for a GUI builder? If you do this, you
are free to do the GUI in whatever you want,
as long as you can interface it. Heck, with
COM, .NET etc. and all this, you can create
your GUI in any language you like, even Delphi,
if you cabn wrap yourself around Pascal!
And -- the less logic you put into your GUI,
the easier it would be to replace it.
[...]
Paul
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Coming back to where you started is not the same as never leaving"
Terry Pratchett

[Duane Hebert]

"Hendrik Schober" <Sp******@gmx.d e> wrote in message
news:en******** ******@TK2MSFTN GP10.phx.gbl...

Have you looked at www.wxWidgets.org?

or www.trolltech.com

[Carl Daniel [VC++ MVP]]

Paul Tremblay wrote:

Hello Carl,

Thanks for the info. The only reason I am considering using .Net is
because of its GUI productivity tools - i.e., for developing fast and
great looking apps (XP feel etc) on the client side.
I think you'd be disappointed with the look & feel of a Winforms UI using VS
2003. I think that's one reason why there aren't many shipping apps with
Winforms front-ends: the sophistication just isn't there yet. This
situation changes a lot with VS2005 with the addition of a pile of new UI
elements to WinForms so you really can make a flashy UI with ease.
The problem is that (AFAICT), if I (or anyone for that matter) put
effort in developing a nice flashy GUI in .Net, the code produced is
IL - and therefore I am more or less giving away the source code to my
custom presentation tier logic (please say it isn't so - or there is a
way around this).
It's a concern. I won't comment any more since I haven't really wrestled
with the pros and cons of that issue myself (yet).

You mentioned that I don't have to use .Net - Ah, but life is often
not that simple. .Net seems to have the GUI development tools I want, but
that comes with the (unacceptably) high price of opening up my
application GUI code to the entire world (this is not a serious option
for any ISV - and probably explains why MS themselves are not doing
this). The only option then is to use either WTL or MFC as you
suggested. I had never heard of WTL, so I did a google search and read
up on it. It is an extension to ATL, not supported by MS, and
currently only at beta phase. You're not seriously suggesting that I build
a
serious (commercial) application with that are you?.
Yes, I am. WTL is widely used and has a strong following and good support.
It was originally developed by the creators of ATL as an extension and then
released as a sample. Recently, MS released it as an open source project,
and it has an active support community on source forge
(http://sourceforge.net/projects/wtl/), which includes the original
developer.

So the only option left seems to be MFC. Well there is apparently a
problem with this route as well as MFC is gradually going to be phased
out by MS (not to mention the ridiculously steep learning curve and
lack of good, intuitive WYSWIG GUI building tools compared to .Net). It is
not very prudent to develop a new application with technology that is
being phased out. So it seems I am stuck between a rock and a very
hard place.
MFC does have a steep learning curve, and it more or less forces a number of
architecture decisions on you that you might not agree with. But it does
work, has lots of support and 3rd party add-ons, and will be supported by MS
for many years to come. VS 2005 has some significant additions to MFC,
including the ability to host Winforms forms inside MFC views, so you can
mix and match technologies as you see fit.
Is there another alternative that I am missing?. Basically, all I'm
looking for is this: a WYSIWYG GUI builder that is capable of building
screens of the same quality as that built by .Net (XP look and feel,
RAD development etc) but then either generates pure ISO C++, or
builds a native binary which I can interface to my C++ native libraries.
If
only I could build native binaries from a WinForm, then I could design a
nice GUI in .Net, create a native binary from that and "nail" that GUI end
to my native C++ libraries. I would not have though that was too much to
ask.
To summarize, it looks like MFC is the only route to create native GUI
applications (please say it isn't so!). I don't want to use MFC
because of these facts (I stand to be corrected on any of these)

1). Steep learning curve
True.
2). Its a technology being phased out by MS
I think de-emphasized would be more accurate. It won't be phased out for
many years, if ever.
3). I'm not sure how many GUI components there are out there for MFC,
compared to .Net (i.e. I believe that .Net produces flashier and
nicer GUIs)
Lots. Many (Most?) of the UI components out there are available in COM or
..NET flavors. All of the COM (ActiveX) components are usable from MFC. I
believe that most hard-core GUI developers would argue that MFC produces
flashier and nicers GUIs, albeit with more work.

I hope you or someone else can help answer these questions

-cd

[William DePalo [MVP VC++]]

"Jochen Kalmbach [MVP]" <no************ ********@holzma .de> wrote in message
news:Oy******** ******@TK2MSFTN GP12.phx.gbl...

But the original assemblies in the GAC (or whereever stored) are not
touched by ngen.

Well, that sucks. :-)

Regards,
Will