Whats the Deal with Visual C++.Net?

  • Thread starter Thread starter Paul Tremblay
  • Start date Start date
P

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.
 
Paul said:
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?
Click to expand...

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?
Click to expand...

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 "managedextensionsspec.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?
Click to expand...

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.
 
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?.
Click to expand...

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/d...ols/html/cpgrfNativeImageGeneratorNgenexe.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
 
Lastly, but not the least, is the apparant casual nature with which
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/d...ols/html/cpgrfNativeImageGeneratorNgenexe.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.
Click to expand...

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
 
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.
Click to expand...

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\assembly\NativeImages1_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/
 
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
 
Paul Tremblay said:
[...] 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?.
Click to expand...

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. [...]
Click to expand...

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 [...]
Click to expand...

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
[...]
Click to expand...


Schobi

--
(e-mail address removed) 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
 
Paul said:
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.
Click to expand...

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).
Click to expand...

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?.
Click to expand...

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.
Click to expand...

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
Click to expand...

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)
Click to expand...

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
Click to expand...

-cd
 
Jochen said:
It does *not* make the disassembly process more difficult!
The managed assembly stays untouched! Therefor you can still use some
tools like ".NET Refelector"...
Click to expand...

Worse, in .NET 1.0 and 1.1, when you've ngen'd an assdembly, you'll end up
with BOTH the native AND the managed assembly loaded into your address
space - the native assembly doesn't have the meta-data, so the CLR has to
load both, filling your address space with IL code you don't need. There
are also circumstances where the CLR actually won't use the ngen'd assembly
and will JIT your assembly anyway (these have to do with assemblies shared
across app domains and other esoterica). Fortunately, this whole situation
is much improved in .NET 2.0.

-cd
 
Jochen Kalmbach said:
Just one example: Salamander .NET protector
http://www.remotesoft.com/salamander/protector.html
Click to expand...

It looks good to me.

I guess it is because I am not an internals kind of guy that I just don't
get it. I didn't see the meta-data issue that Carl has already pointed out,
and call me old-fashioned, but I just can't get my head around why shipping
more than machine code ought to be such a problem.

Regards,
Will
 
Hi William!
It looks good to me.

I guess it is because I am not an internals kind of guy that I just don't
get it. I didn't see the meta-data issue that Carl has already pointed out,
and call me old-fashioned, but I just can't get my head around why shipping
more than machine code ought to be such a problem.
Click to expand...

The main reason for shipping IL-code is the goal of making *real*
platform independecy. .NET-Assemblies can be shipped on x86 and x64 /
IA64 without recompiling.

But from my point of view:
Most developers could accept to deliver two (or more) native-compiled
assemblies...

So I hope this will become a "high-priority" feature in the .NET-team...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Olaf said:
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.
Click to expand...

The real value of a code is *not* in it's WINAPI calls, nor in it's use of
the standard C++ functions : it's in the internal algorithms, and that is
much more difficult to revese-engineer (that is, make it understandable).

Arnaud
MVP - VC
 
Paul said:
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?.
Click to expand...

So any non-commercial app is by definition "not serious" : nice for Firefox,
Apache, Linux and the like...

However, WTL is a *really* very good product : personnaly, I can't
understand why it's still flaged as Beta under SourceForge, given the time
it has been around. However, if you are affraid of MFC learning curve, you
may find WTL too much to handle. On the default side, the WTL documentation
is alas still terribly poor...

Arnaud
MVP - VC
 
Jochen Kalmbach said:
[...]
The main reason for shipping IL-code is the goal of making *real*
platform independecy.
Click to expand...

IIUC, ironically Mono, a OSS initiative, is the
only reason.NET is indeed somewhat platform
independent, because...
.NET-Assemblies can be shipped on x86 and x64 /
IA64 without recompiling.
Click to expand...

...I think the same holds true for Win32 PE
executables. (I migh tbe wrong, tough, as I
haven't looked into 64bit yet.)
But from my point of view:
Most developers could accept to deliver two (or more) native-compiled
assemblies...
Click to expand...

We're shipping most of our SW for Windows,
MacOS X, Linux, and Darwin. Some even on
more platforms.
[...]
Click to expand...


Schobi

--
(e-mail address removed) 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
 
Hendrik said:
Jochen Kalmbach [MVP] <[email protected]> wrote:
Click to expand...
.NET-Assemblies can be shipped on x86 and x64 /
...I think the same holds true for Win32 PE
executables. (I migh tbe wrong, tough, as I
haven't looked into 64bit yet.)
Click to expand...

True, but only through emulation or other second-class citizen support. A
..NET app is in effect a native app on any of those platforms.

-cd
 
Hi Hendrik!
IIUC, ironically Mono, a OSS initiative, is the
only reason.NET is indeed somewhat platform
independent, because...
Click to expand...

And also MS implementation of the CLI on FreeBSD (so called "rotor").
But with this alternative platforms you do not need to recompile your
source. Just execute your assembly.

And here is an (incomplete) list of alternatives CLI implementations:

Mono
http://www.mono-project.com/

DotGNU
http://www.dotgnu.org/

The Microsoft Shared Source CLI Implementation (Rotor)
http://msdn.microsoft.com/library/en-us/Dndotnet/html/mssharsourcecli.asp

OCL (Open CLI Library)
http://sourceforge.net/projects/ocl/

...I think the same holds true for Win32 PE
executables. (I migh tbe wrong, tough, as I
haven't looked into 64bit yet.)
Click to expand...

No. win32-apps will be executed as win32-apps and not as win64 apps...
On IA64 architecture you will see a huge performance degrease...

--
Greetings
Jochen

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

There are some excellent .Net code obfuscators out there. True, some care
must be taken to ensure that code flow or performance aren't tampered with,
but they can generally foil disassemblers, and even the simple obfuscation
stuff (mangling variable and function names) can make strides towards making
the code harder to unravel. Not impossible, mind you, but as it's already
been pointed out, even binary-compiled code can be decrypted by a determined
effort.
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).
Click to expand...

My understanding is that the SQL 2000 version of SQL Reporting Services was
written entirely in C# and C++.Net. Is this correct? It's true that this is
bundled into SQL 2005, but at the moment it's considered to be a separate
add-on product.

Erik J Sawyer
CFT Programmer
Appro Systems
 
Back
Top