Are Win32 functions be rewritten for .NET or simply wrapped?

[Peter Olcott]

http://en.wikipedia.org/wiki/Windows_Communication_Foundation

..NET Framework 3.0 (formerly called WinFX) - the new .NET Windows API to succeed
Win32 with the release of Windows Vista.

The above quote is from the link above it. It seems to be saying that the .NET
Framework 3.0 will replace and supercede Win32. Does this mean that the
underlying Win32 functions have been rewritten for .NET or is this new framework
simply a wrapper around the pre-existing Win32 API?

 

[Cowboy \(Gregory A. Beamer\)]

I have not looked at the bits lately, but the last time I dove into the
bits, it was a mixed bag: part wrapper, part rewrite.

The best wa to answer the question is to download the 3.0 bits and use a
tool like Reflector to "reverse engineer". You can then see if any items are
wrapped.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************

 

[ThunderMusic]

I'd like to have the answer to that question too, so if you (or someone
else) can post the results, it will be very appreciated...

thanks

ThunderMusic

 

[Carl Daniel [VC++ MVP]]

http://en.wikipedia.org/wiki/Windows_Communication_Foundation

.NET Framework 3.0 (formerly called WinFX) - the new .NET Windows API
to succeed Win32 with the release of Windows Vista.

The above quote is from the link above it. It seems to be saying that
the .NET Framework 3.0 will replace and supercede Win32. Does this
mean that the underlying Win32 functions have been rewritten for .NET
or is this new framework simply a wrapper around the pre-existing
Win32 API?

Marketing messaging to the contrary, the fact is that .NET 3.0 (aka WinFX)
is, like all the rest of the .NET platform, a wrapper over Win32. It's an
application framework that puts an easier to use, managed veneer over the
native Win32 APIs. It does not make use of any interfaces into the core OS
that aren't available to every Win32 program.

WPF (aka Avalon) applications are managed, but their user interface is
rendered by a new Win32 service process that's largely native code via
Direct-3D. While Direct-3D has a managed interface, internally it's all
native code.

WCF (aka Indigo) applications are managed, but WCF is nothing more than a
large, complex, sophisticated library that makes use of the existing
System.Net facilities, which in turn make use of the OS/Kernel-supplied
networking facilities (e.g. sockets, IO completion ports, etc).

WWF (workflow) is completely new and completely managed - this is one area
where WinFX isn't just a wrapper over Win32 - there's actually some entirely
new functionality here.

As for Vista, nearly 100% of the new features in Vista are native code.
There are extensive additions to the kernel, to User32 (and by extension,
the Win32 API). The new "Aero" UI is 100% native code, implemented by 100's
of new Win32 controls and styles.

One place where .NET 3.0 might be considered a "replacement" for Win32 is in
the focus of development tools - considerably more resources are involved in
driving developers towards writing managed code than are supporting
development of native code. The message is clear: for new projects, use
managed code. At some point, unmanaged code will "go away", but that point
is many years down the road still.

There's still a fundamental schism between Win32 and .NET: Win32 is the API
of an Operating System, while .NET is an application framework that's
largely OS agnostic (and could be implemented for nearly any modern
operating system).

HTH

-cd

 

[Mike Lowery]

There's still a fundamental schism between Win32 and .NET: Win32 is the API
of an Operating System, while .NET is an application framework that's largely
OS agnostic (and could be implemented for nearly any modern operating system).

Or at least that's what Microsoft hopes will happen. But so far I haven't seen
much progress. Mono can do a lot, but it's lacking support for VB and Framework
2.0 (among other things.) Microsoft would do well to port this framework to
other OS's themselves because nobody else is going to be interested in doing
that, especially when it's already been done for competing languages like Java.

 

[Patrice]

First, my understanding is that .NET 3.0 is not a replacement but rather a
complement to 2.0. Because this is quite a massive addition is is called 3.0
but AFAIK what 2.0 offers at this time will remain untouched.

IMO what they mean by "supercede" it that the whole goal of .NET is to
astract the underlying Win32 API capabilities into a nice object oriented
layer so that YOU don't have to call any more this API. It doesn't mean that
MS drops the Win32 API or even spends much time to rewrite what is already
available since years in Win32 and simply doing something like showing a
form obviously results in dozens of Win32 API calls...

Then when most code won't contain direct calls to the Win32 API they could
eventually write an OS with native support for Managed Code but this won't
be likely anytime soon...

 

[William Stacey [MVP]]

True. If or until the OS is managed, any library (which is what .Net is -
just a bunch of dlls) will eventually always need to call Win32.
Singularity (a fully managed OS) is making progress however. It is still
just a research OS with no current plans to make it a product. However,
does would not require Win32. In fact, it would be the reverse. A Win32
compat layer would need to call into managed code instead of visa-versa.
They have some very interesting work going on their. They allow both
software issolated processes (SIPs) and traditional hardware issolated
processes. Naturally talking between SIPs is factors faster as you don't
pay the huge tax for moving between hardware boundaries. Check out the
latest Channel9 vids on it.

--
William Stacey [MVP]

| First, my understanding is that .NET 3.0 is not a replacement but rather a
| complement to 2.0. Because this is quite a massive addition is is called
3.0
| but AFAIK what 2.0 offers at this time will remain untouched.
|
| IMO what they mean by "supercede" it that the whole goal of .NET is to
| astract the underlying Win32 API capabilities into a nice object oriented
| layer so that YOU don't have to call any more this API. It doesn't mean
that
| MS drops the Win32 API or even spends much time to rewrite what is already
| available since years in Win32 and simply doing something like showing a
| form obviously results in dozens of Win32 API calls...
|
| Then when most code won't contain direct calls to the Win32 API they could
| eventually write an OS with native support for Managed Code but this won't
| be likely anytime soon...
|
| --
| Patrice
|
| "Peter Olcott" <[email protected]> a écrit dans le message de | IEAJg.8481$Tl4.4940@dukeread06...
| > http://en.wikipedia.org/wiki/Windows_Communication_Foundation
| >
| > .NET Framework 3.0 (formerly called WinFX) - the new .NET Windows API to
| > succeed Win32 with the release of Windows Vista.
| >
| > The above quote is from the link above it. It seems to be saying that
the
| > .NET Framework 3.0 will replace and supercede Win32. Does this mean that
| > the underlying Win32 functions have been rewritten for .NET or is this
new
| > framework simply a wrapper around the pre-existing Win32 API?
| >
|
|

 

[Chris Mullins]

Or at least that's what Microsoft hopes will happen. But so far I haven't
seen much progress. Mono can do a lot, but it's lacking support for VB
and Framework 2.0 (among other things.)

Lack of VB support in Mono is partly due to the fact that C# is a
standardized language with a formally approved spec, and Visual Basic isn't.
Even with that said, Mono does have some level of VB support.

If I were Miguel, and had to choose between the two, choosing C# is a very
easy decision based on that fact alone.

The .Net 2.0 support is mostly there - the key stuff, like Generics, is
there. Most of the new APIs are there as well. It's still a bit spotty, but
really overally quite good.

Microsoft would do well to port this framework to other OS's themselves
because nobody else is going to be interested in doing that, especially
when it's already been done for competing languages like Java.

Microsoft has ported this framework to other OS's - Rotor is just that.