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]

"John" <ja*****@gmail. com> wrote:

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

--
http://barrkel.blogspot.com/

[William DePalo [MVP VC++]]

"John" <ja*****@gmail. com> wrote in message
news:11******** **************@ i40g2000cwc.goo glegroups.com.. .

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,

"John" <ja*****@gmail. com> wrote in message
news:11******** **************@ i40g2000cwc.goo glegroups.com.. .

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

"Bruno van Dooren" <br************ **********@hotm ail.com> schreef in bericht
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"

[David Wilkinson]

Bruno van Dooren wrote:

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?

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]

"Bruno van Dooren" <br************ **********@hotm ail.com> a écrit dans le
message de news: eG************* *@TK2MSFTNGP05. 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?

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

[Andre Kaufmann]

Bruno van Dooren wrote:

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