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.

[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
br************* *********@hotma il.com
Remove only "_nos_pam"

[Mark Miller]

"Bruno van Dooren" <br************ **********@hotm ail.com> wrote in message
news:eG******** ******@TK2MSFTN GP05.phx.gbl...

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
br************* *********@hotma il.com
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:

"Bruno van Dooren" <br************ **********@hotm ail.com> wrote in message
news:eG******** ******@TK2MSFTN GP05.phx.gbl...
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]

"Andre Kaufmann" <an************ ****@t-online.de> wrote in message
news:uG******** ******@TK2MSFTN GP02.phx.gbl...

Mark Miller wrote:

"Bruno van Dooren" <br************ **********@hotm ail.com> wrote in
message news:eG******** ******@TK2MSFTN GP05.phx.gbl...

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.

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 .

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

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.

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.

[...]

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.

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.

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.

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

---Mark

[Andre Kaufmann]

Mark Miller wrote:

"Andre Kaufmann" <an************ ****@t-online.de> wrote in message
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(embeddi ng) a WPF frame - or vice versa.
---Mark

Andre