why migrate from VC++ win32 to C++.NET windows applications?

[John]

My friend told me that his company will migrate the VC++ win32
applications
to C++ .NET windows applications. I don't understand why since
currently
Microsoft only supports .NET on windows platforms. If Win32
applications
and .NET application both will run on windows only, what's the
advantages
for the migration? Or maybe this type of migration is not common in
practice?

please dicuss and advise.

thanks!!
John.

 

[Barry Kelly]

My friend told me that his company will migrate the VC++ win32
applications to C++ .NET windows applications. I don't understand why
since currently Microsoft only supports .NET on windows platforms.

Microsoft also only supports VC++ Win32 applications on Windows
platforms, AFAIK, so I don't see your distinction.

If
Win32 applications and .NET application both will run on windows only,
what's the advantages for the migration? Or maybe this type of
migration is not common in practice?

The value available in the current .NET space, in terms of libraries
(e.g. ASP.NET, WinForms) and platform support like rich reflection, GC,
efficient generics, dynamic code generation etc., is one advantage.

-- Barry

 

[William DePalo [MVP VC++]]

My friend told me that his company will migrate the VC++ win32
applications to C++ .NET windows applications. I don't understand
why since currently Microsoft only supports .NET on windows platforms.
If Win32 applications and .NET application both will run on windows only,
what's the advantages for the migration?

I can't speak for your friend's company but developing for the .Net platform
is significantly easier than is build a ntive application to the Win32 API
or even MFC.

Or maybe this type of migration
is not common in practice?

I have no knowledge of the statictics.

Regards,
Will

 

[Marcus Heege]

Hi John,

My friend told me that his company will migrate the VC++ win32
applications
to C++ .NET windows applications. I don't understand why since
currently
Microsoft only supports .NET on windows platforms. If Win32
applications
and .NET application both will run on windows only, what's the
advantages
for the migration? Or maybe this type of migration is not common in
practice?

please dicuss and advise.

thanks!!
John.

in addition to the reasons mentioned already, I must also be mentioned that
many future APIs will be native .NET APIs. Think of WPF, WCF, WWF, ...

 

[Bruno van Dooren]

in addition to the reasons mentioned already, I must also be mentioned

that many future APIs will be native .NET APIs. Think of WPF, WCF, WWF,
...

I have been wondering about this.
How can an API be a pure .NET API?

I agree that a lot of API logic can be made in managed as well as unmanaged
environment,
but sooner or later you will have to make system calls to communicate with
either device drivers or
the windows subsystem itself.

This means that you are always going to have an unmanaged core on which a
managed API is built.
correct?

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Cor Ligthert [MVP]]

Bruno,

That is what you call an API. I have the idea that some persons calls
everything an API. But a Win32 is complete different from what they call a
Net programming interface. As we follow that line than is even the Bios an
API.

Just my thought,

Cor

 

[David Wilkinson]

I have been wondering about this.
How can an API be a pure .NET API?

I agree that a lot of API logic can be made in managed as well as unmanaged
environment,
but sooner or later you will have to make system calls to communicate with
either device drivers or
the windows subsystem itself.

This means that you are always going to have an unmanaged core on which a
managed API is built.
correct?

Bruno:

Might it not be that although these .NET GUI features are implemented in
native code under the hood, that functionality is not exposed in either
the PSDK or (I wish) in MFC?

David Wilkinson

 

[Arnaud Debaene]

I have been wondering about this.
How can an API be a pure .NET API?

I agree that a lot of API logic can be made in managed as well as
unmanaged environment,
but sooner or later you will have to make system calls to communicate with
either device drivers or
the windows subsystem itself.

This means that you are always going to have an unmanaged core on which a
managed API is built.
correct?

Yes, but as you said, the bulk of the API can be written in .NET. For
example, concerning WPF (Avalon), it relies on native DirectX for primitives
drawing, but all the controls logic, the XAML parser, the event handling
logic, the renderer, etc... are pure .NET.

Arnaud
MVP - VC

 

[Bruno van Dooren]

Might it not be that although these .NET GUI features are implemented in

native code under the hood, that functionality is not exposed in either
the PSDK or (I wish) in MFC?

My guess:
if an API is considered to be a native .NET API, I would expect it to be
implemented in managed code, except for syscalls and driver interfacing.
this means it will not be implemented as a win32 wrapper. otherwise you
would not be able to call it a pure .NET API.

this would also mean that the win32/win64 implementation of the same
functionality would be a separate implementation,
because to layer win64 on top of a .NET API would probably kill performance.

So there will be 2 implementations, rather than 1 and a wrapper.

I also fail to see why it is even relevant if an API is pure .NET or wrapped
winxx.
The application will have to make the managed / unmanaged switch anyway as
soon as you do
a syscall or driver call.

Unless of course the words 'pure .NETAPI' mean something different still and
I don't get it.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Andre Kaufmann]

Might it not be that although these .NET GUI features are implemented in
native code under the hood, that functionality is not exposed in either
the PSDK or (I wish) in MFC?

[...]

So there will be 2 implementations, rather than 1 and a wrapper.

I don't think so. Vista will have new Win32 functions, but IIRC e.g.
Windows Presentation Foundation (new 3D GUI) will have a .NET layer
only. It may be called pure .NET API, because AFAIK the top layer will
be only available for .NET languages. It will be a managed API sitting
on a x86 API. In the case of WPF (Windows Presentation Foundation) this
will be the DirectX API.

I also fail to see why it is even relevant if an API is pure .NET or wrapped
winxx.

If 50% of the code and logic is in the managed API wrapper itself, you
would have to (re)implement this managed code in native code, which you
hardly can't do by yourself and IMHO not in a 100% compatible way.
You could simply wrap the managed API, by wrapping the managed objects
by flat Win32 functions and Win32 handles, but IMHO that would be
nonsense since:

a) Win32 code would wrap managed code and call into managed code
which performance wise wouldn't be a good idea
(marshaling etc.)
b) You already can create managed objects and call their functions
from native code by using CLR-Hosting

I don't think Microsoft will implement 2 different API (managed /
native). I rather would expect them to enhance the .NET compilers to
emit native / more optimized code.

The application will have to make the managed / unmanaged switch anyway as
soon as you do
a syscall or driver call.

Sure. But where's the problem or difference if managed code does a
driver call or native code (besides marshaling perhaps).

Unless of course the words 'pure .NETAPI' mean something different still and
I don't get it.

Hope it's now somewhat more logical.
Andre

 

[Bruno van Dooren]

I don't think so. Vista will have new Win32 functions, but IIRC e.g.

Windows Presentation Foundation (new 3D GUI) will have a .NET layer only.
It may be called pure .NET API, because AFAIK the top layer will be only
available for .NET languages. It will be a managed API sitting on a x86
API. In the case of WPF (Windows Presentation Foundation) this will be the
DirectX API.

did't know that. I had always assumed -since win32 / win64 will coexist with
the .NET apis- that both would have equivalent functionality. If they don't,
then it would indeed be logical to create a pure-as-possible .NET API to
avoid marshalling.
Given that, the whole point of 'pure' .NET APIs starts to make sense.
there will still be dll calls (DirectX etc) underneath, but they will be as
low level as possible, with all implementation stuff in managed code, and no
worries about a winxx implementation.

thanks.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Mark Miller]

I have been wondering about this.
How can an API be a pure .NET API?

I agree that a lot of API logic can be made in managed as well as
unmanaged environment,
but sooner or later you will have to make system calls to communicate with
either device drivers or
the windows subsystem itself.

This means that you are always going to have an unmanaged core on which a
managed API is built.
correct?

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

You are correct. Ultimately you have to get down to something that runs in
machine code and can work with the underlying hardware.

There was a lot of confusion when Microsoft first started talking about
Vista having a managed API. People thought the whole OS was going to be
written in .Net (for some reason). Originally the plan was to write quite a
bit of the OS in .Net, as I understand, but that changed over time when they
realized the developers they had were more efficient coding in C++. Vista
will have both a managed and unmanaged API that developers can use. It's my
understanding that all of the newer technologies coming down the line like
WPF, WCF, etc. will have unmanaged APIs that can be accessed from C++, etc.
as well as managed APIs for .Net. It's just that these layers are being
*implemented* in .Net.

It's my understanding that what they're working towards is "universal"
access. All functions in the OS will be accessible both from native
applications (written in C/C++, etc.) and from apps. written in .Net. They
will hide the implementation using wrappers, so the programs using them
won't know any better. It'll just work.

I'm not sure how the unmanaged API will be constructed. I know for example
that when .Net 1.0 came out 4 years ago, Microsoft also released GDI+ as a
separate C++ library. As I recall it was not an add-on to MFC, since it
didn't use MFC objects, but it did use objects/object inheritance, etc. So
it wasn't a C API like Microsoft typically released in the past. GDI+ was a
new technology supported by .Net, and is supported by underlying technology
in WinXP. I don't remember if GDI+ was already supported in XP, and
programmers just downloaded the SDK for it, or whether the download was an
upgrade to XP, plus the API. Anyway, this is an example where Microsoft
released both a managed and unmanaged API that offered the same access to
functionality.

I agree with the comments made earlier. It's much easier dealing with the
..Net API than it is dealing with Win32/MFC. I am a bit surprised to hear
though that C++ projects are moving to C++/CLI. I always thought that
projects that had been written in C++ had performance as a major concern. I
know we're not supposed to talk about unpublished benchmarks, but I can say
just because C++/CLI runs through the .Net runtime that it's not going to
run as efficiently as a native C++-implemented app. I guess PCs have gotten
to the point, though, where they're speedy enough that running a managed
app. isn't a big deal.

I don't know if Microsoft will be adding access features to MFC that make it
easy to access the new feature layers. I've been out of that loop (C++) for
a while. I went to a Microsoft DevDays event back when they were talking
about .Net 1.0 and I talked to a Microsoft developer there. I was asking him
questions about if there was anything new in MFC in the new version of VS.
He didn't know and he didn't care. As far as he was concerned MFC was legacy
technology and didn't care for it. Nevertheless when VS.Net came out, they
had added some features to MFC, such as web services capability, a new
CHtmlDialog class, etc. So it's possible they'll add more.

---Mark

 

[Andre Kaufmann]

Mark Miller wrote:

Hi,

[...]
written in .Net (for some reason). Originally the plan was to write quite a
bit of the OS in .Net, as I understand, but that changed over time when they
realized the developers they had were more efficient coding in C++.

There is a Microsoft research OS called Singularity, which is completely
written in managed code (compiled to native one) with a few bits of
assembly code.

Vista will have both a managed and unmanaged API that developers can use. It's my
understanding that all of the newer technologies coming down the line like
WPF, WCF, etc. will have unmanaged APIs that can be accessed from C++, etc.
as well as managed APIs for .Net. It's just that these layers are being
*implemented* in .Net.

You can access all .NET objects from standard C++ by using CLR Hosting.
But IMHO this won't be simple and straightforward.

It's my understanding that what they're working towards is "universal"
access. All functions in the OS will be accessible both from native
applications (written in C/C++, etc.) and from apps. written in .Net. They
will hide the implementation using wrappers, so the programs using them
won't know any better. It'll just work.

AFAIK there won't be any wrappers for the (AFAIK now called) .NET 3.0
framework, which has been formerly named WinFX. Perhaps this new name
makes it more clear that IMHO there won't be any simple wrappers for
native languages, at least I haven't found a native WinFX API.

I'm not sure how the unmanaged API will be constructed. I know for example
that when .Net 1.0 came out 4 years ago, Microsoft also released GDI+ as a
separate C++ library. As I recall it was not an add-on to MFC, since it
didn't use MFC objects, but it did use objects/object inheritance, etc. So
it wasn't a C API like Microsoft typically released in the past. GDI+ was a
new technology supported by .Net, and is supported by underlying technology
in WinXP. I don't remember if GDI+ was already supported in XP, and
programmers just downloaded the SDK for it, or whether the download was an
upgrade to XP, plus the API. Anyway, this is an example where Microsoft
released both a managed and unmanaged API that offered the same access to
functionality.

GDI+ is a simple DLL which you can use even on Win2K. It's a DLL
exporting the same flat functions as any Win32 DLL. .NET is using GDI+,
and it wraps it. GDI+ C++ classes are "simple" wrapper classes, wrapping
the flat functions. IMHO it's way harder to wrap a .NET library, than
wrapping flat DLL functions for managed and native languages.
If it would be that simple then Microsoft wouldn't perhaps have needed
to design and implement managed extensions for C++.

I agree with the comments made earlier. It's much easier dealing with the
.Net API than it is dealing with Win32/MFC. I am a bit surprised to hear
though that C++ projects are moving to C++/CLI. I always thought that
projects that had been written in C++ had performance as a major concern. I
know we're not supposed to talk about unpublished benchmarks, but I can say
just because C++/CLI runs through the .Net runtime that it's not going to
run as efficiently as a native C++-implemented app.

Why ? The C++ compiler can compile mixed assemblies holding managed and
native code. For the GUI part you normally don't need "full"
performance. If you compile your native C++ code to native x86 code in a
mixed assembly, why should it be that slower ? It will be just the same
code. The GUI part of .NET is rather slow, because it extensively uses
GDI+, which doesn't (can't?) use hardware acceleration.

And not each C++ standard library is quite performant, iostreams for
example are IMHO not.

I guess PCs have gotten to the point, though, where they're speedy enough
that running a managed app. isn't a big deal.

I don't know if Microsoft will be adding access features to MFC that make it
easy to access the new feature layers.

Since both are base on completely different technologies, I strongly
doubt that a WinFX-MFC will be available. Perhaps other compiler vendors
will wrap WinFX technology for their native languages. Though I don't
think they can do it without language extensions. E.g. I doubt that
other compiler vendors will have such a wrapper for native C++.

I've been out of that loop (C++) for
a while. I went to a Microsoft DevDays event back when they were talking
about .Net 1.0 and I talked to a Microsoft developer there. I was asking him
questions about if there was anything new in MFC in the new version of VS.
He didn't know and he didn't care. As far as he was concerned MFC was legacy
technology and didn't care for it. Nevertheless when VS.Net came out, they
had added some features to MFC, such as web services capability, a new
CHtmlDialog class, etc. So it's possible they'll add more.

The problem is that they would have to "reinvent the wheel" and IMHO
only could wrap a subset of the WinFX / .NET 3.0 API. The WinFX API is
already available, if there would be any native API it should already
have been documented. But yet I haven't found any.

---Mark

Andre

 

[Mark Miller]

Mark Miller wrote:

message
Hi,

Hi.

[...]
written in .Net (for some reason). Originally the plan was to write quite
a bit of the OS in .Net, as I understand, but that changed over time when
they realized the developers they had were more efficient coding in C++.

There is a Microsoft research OS called Singularity, which is completely
written in managed code (compiled to native one) with a few bits of
assembly code.

I know about this. I was talking about Vista though. Some people were under
the misimpression that it was going to be written totally in .Net. How they
imagined that I don't know. Microsoft wouldn't be that dumb. They know what
..Net is capable of and they know which side their bread is buttered on. What
some imagined is that they were going to make Vista totally incompatible
with native apps.

You can access all .NET objects from standard C++ by using CLR Hosting.
But IMHO this won't be simple and straightforward.

Yeah. I just read up a little bit on it. It sounds complicated.

AFAIK there won't be any wrappers for the (AFAIK now called) .NET 3.0
framework, which has been formerly named WinFX. Perhaps this new name
makes it more clear that IMHO there won't be any simple wrappers for
native languages, at least I haven't found a native WinFX API.

What I heard from a couple Microsoft reps. a year or two ago was that they
were going to provide universal access, but perhaps what they meant was that
they would provide native APIs to all features of the OS below the WinFX
layer. I'm not sure, but I imagine they've used .Net elsewhere in the OS
besides WinFX. It was around this time that people were getting the
misimpression about Vista being totally written in .Net. They were trying to
answer that.

[...]

Why ? The C++ compiler can compile mixed assemblies holding managed and
native code. For the GUI part you normally don't need "full" performance.
If you compile your native C++ code to native x86 code in a mixed
assembly, why should it be that slower ? It will be just the same code.
The GUI part of .NET is rather slow, because it extensively uses GDI+,
which doesn't (can't?) use hardware acceleration.

And not each C++ standard library is quite performant, iostreams for
example are IMHO not.

You are right. The only time I had heard about a mixed assembly being
created was for a native-accessible managed DLL, where you could have the
compiler create a DLL with a native stub that native apps. could link to. I
read a little further into a book I got on managed extensions and it talks
about the #pragma unmanaged directive, which causes the compiler to emit x86
code into the assembly. What I'm unclear on is how it bridges the gap
between native and managed code. I thought the way it enabled unmanaged and
managed code to get along was to compile everything to MSIL and just enable
hard pointers to system memory. That way unmanaged code could still have its
pointers, and you could have objects on the managed heap, and the runtime
could keep track of everything that's happening.

I knew you could have __nogc classes and __gc classes, in VC 2002/2003. I
assume you can have them in code that's compiled completely into MSIL, no? I
don't imagine it would be the most optimal way to run. The thing that amazes
me about managed C++ is the flexibility it gives you.

Since both are base on completely different technologies, I strongly doubt
that a WinFX-MFC will be available. Perhaps other compiler vendors will
wrap WinFX technology for their native languages. Though I don't think
they can do it without language extensions. E.g. I doubt that other
compiler vendors will have such a wrapper for native C++.


The problem is that they would have to "reinvent the wheel" and IMHO only
could wrap a subset of the WinFX / .NET 3.0 API. The WinFX API is already
available, if there would be any native API it should already have been
documented. But yet I haven't found any.

I'll take you're word for it. You're farther along in this than I am. Thanks
for the info.

---Mark

 

[Andre Kaufmann]

Hi,

[...]

I know about this. I was talking about Vista though. Some people were under
the misimpression that it was going to be written totally in .Net. How they
imagined that I don't know. Microsoft wouldn't be that dumb. They know what
.Net is capable of and they know which side their bread is buttered on. What
some imagined is that they were going to make Vista totally incompatible
with native apps.

You are totally right in this regard. Would be plain dumb by Microsoft
to drop all native apps support and rewrite the whole system in .NET.
And AFAIK most of the Vista code is still native code.

What I heard from a couple Microsoft reps. a year or two ago was that they
were going to provide universal access, but perhaps what they meant was that
they would provide native APIs to all features of the OS below the WinFX
layer. I'm not sure, but I imagine they've used .Net elsewhere in the OS
besides WinFX.

Yes. You may be right. IIRC there has been used more .NET code, before
some Vista parts have been recoded - but I don't know for sure.

You are right. The only time I had heard about a mixed assembly being
created was for a native-accessible managed DLL, where you could have the
compiler create a DLL with a native stub that native apps. could link to. I
read a little further into a book I got on managed extensions and it talks
about the #pragma unmanaged directive, which causes the compiler to emit x86
code into the assembly. What I'm unclear on is how it bridges the gap
between native and managed code. I thought the way it enabled unmanaged and
managed code to get along was to compile everything to MSIL and just enable
hard pointers to system memory. That way unmanaged code could still have its
pointers, and you could have objects on the managed heap, and the runtime
could keep track of everything that's happening.

You can do both. Compile C++ code to MSIL or to x86 code. I had a look
at how a managed function calls a native one. (My interpretation) For
the native one a PInvoke function frame is generated and the x86 code is
embedded into this frame. The managed code simply calls the PInvoke(d)
function. IIRC mixed assemblies are generating more efficient code, than
managed code which is using PInvoke (directly) / COM Interop to call
into native code.

Perhaps you can compare it with a managed application calling into a
native DLL. Why shouldn't this be possible in a single application ?

I knew you could have __nogc classes and __gc classes, in VC 2002/2003. I
assume you can have them in code that's compiled completely into MSIL, no? I
don't imagine it would be the most optimal way to run. The thing that amazes
me about managed C++ is the flexibility it gives you.

Yes. It's cool to simply compile a complete C++ application (using
iostreams / stl etc.) to MSIL code. ;-)

[...]

The problem is that they would have to "reinvent the wheel" and IMHO only
could wrap a subset of the WinFX / .NET 3.0 API. The WinFX API is already
available, if there would be any native API it should already have been
documented. But yet I haven't found any.

I'll take you're word for it. You're farther along in this than I am. Thanks
for the info.

Please. I read only some articles about the internals of .NET 3.0
(WinFX) and got the impression that it uses intensely .NET technology,
which cannot be easily made available for native applications. At least
not regarding the interaction (events, objects) between native and
managed code.

Though there might be native frameworks from other compiler vendors
which may also support native code access to .NET 3.0 technology.
We'll see. What Microsoft supports is mixing native code and .NET 3.0
(WinFX). E.g. MFC Window hosting(embedding) a WPF frame - or vice versa.

---Mark

Andre