[artmageddon]

In my opinion, it's very misleading because the .Net framework relies on the Win32 API to interact with the operating system. Without Win32, there's no .Net, so if Microsoft plans to make upgrades/updates to the OS, how can it do so when Win32 is "frozen and static?" While it's clear that they will eventually(hopefully) rewrite the main applications(Explorer, Calculator, etc) to use .Net, that last part didn't seem to make sense given the dependency of .Net on Win32.

Edit: Please correct me if I'm wrong, as I'm looking to make sure I understand. I based my comment off of David Morton / nobugz's comments in the following thread:

http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/a...

[bad_user]

The problem with .NET is that nobody knows what it is.

     .Net framework relies on the Win32 API to 
     interact with the operating system

You're saying it as if Java and Java Swing do not interact with Windows.

It is true that (e.g.) Windows Forms is built with Win32 in mind and is using native widgets, but on the other hand nothing prevents you from porting it and you can check out the Mono implementation, which is functional and runs on Linux and OS X.

Of course, Java Swing is a much more portable implementation of a GUI toolkit, but even Java Swing makes Win32 calls and it is also cursed with the common-denominator problem.

    the dependency of .Net on Win32

Other than a couple of instances where you can clearly see that the design of Windows had a clear influence on .NET, Win32 is certainly not a dependency of .NET

Sure, most .NET apps won't run on Linux or OS X, but that's mostly because their developers have been interacting with native code that isn't easily portable, but P/Invoke is so kick-ass that writing new managed bindings to native modules is a piece of cake, so devs are inclined to do that when it makes sense for them, instead of (say) search for a portable alternative.

[rahoulb]

As I remember it (and it is a long time ago), one of the key promises of Longhorn was it was to make .Net a peer of Win32.

At the time (Win2K, WinXP time) there were a few ways to write apps that ran on Windows - Win32 was the preferred way (using a C api), but there was also a much neglected POSIX layer, the DOS API and Win16 (the last two using what they called "virtualization" though I don't know exactly how it worked).

COM, MFC, .NET (and Delphi) built layers over the top of Win32 - so if it wasn't in Win32 it couldn't be done.

The promise of Longhorn was that .Net would become a peer to Win32, not a layer over the top of it, so it could become the foundation for moving the core of Windows forwards (as the parent says, freezing Win32 and adding stuff to .NET).

And then the security issues over XP and the ever increasing delays to Longhorn prompted the "Longhorn reset" (in about 2003?), which threw this away (making Vista a shinier version of XP with an annoying security model, rather than a fundamental rethinking of the internals of Windows).

[kenjackson]

As I remember it (and it is a long time ago), one of the key promises of Longhorn was it was to make .Net a peer of Win32.

I don't recall that, and I don't think it would make sense (although I'm not saying it wasn't the case). Win32 provides so many services it would be foolish to reimplement them. And .NET and Win32 come from the same company. If there was a feature that the .NET team needed exposed, it would probably be easier to get them from the Windows team than to plumb it themselves in a subsystem.

[rahoulb]

Well one thing i definitely do remember about Microsoft at that time was their "white papers" that were little more than made-up visions of a utopian future (which when implemented fell a long way short).

My favourite (from a bit earlier - mid 90s I think) was the "zero-configuration PC" - no matter which PC you logged into it would know all your settings, programmes and documents - which eventually materialised as a "synchronised My Documents folder".

[contextfree]

It depends what you mean by "Win32" - the legacy Win32 API includes calls for 2D graphics (GDI32) and UI (USER32). The graphics and UI toolkits in the original release of .NET (System.Drawing, System.Windows.Forms) were just wrappers around those, but WPF (and now Jupiter/DirectUI/WinRTUI?) was a separate framework built on Direct3D (does Direct3D count as part of "Win32"?) I don't think there was ever any plan to somehow replace the threading primitives and stuff (KERNEL32).

Or, put another way, you could say the legacy Win32 API contains lower-level and higher-level functions, and the higher-level stuff is what was/is being replaced - with new frameworks built on the lower-level functions.