This article gets more than a smidge of its history wrong. For instance, it makes it seem as if WPF (nee Avalon) was written by DevDiv in isolation from Windows, where in reality the Avalon team was mostly made of the former IE team after its legal dismemberment. In fact, we moved my team (which was focused on developer tools on, for, and made with WPF) from DevDiv buildings into Windows buildings just so we could build apps and tools for Avalon to help test their platform.
But, it was a big effort. And even coming from inside of Windows, getting the rest of the shell to run on a whole new stack -- from drivers, through C++ layers, through managed -- was a challenge, especially with all of the other things going on in Longhorn. Sometimes, you bite off more than you can chew, especially when you make the dependency stack too deep.
Also, all of this happened long before Silverlight efforts started... XAML came out of the WPF work. Arguing Silverlight stole DevDiv focus from WPF during the Longhorn timeframe is temporally impossible. Certainly, you could argue DevDiv was being pulled in many directions with the concurrent efforts to placate the VB4 crowd, push out a new version of VS, figure out a new syntax for Managed C++, compete with the then-rapidly-expanding Java tools ecosystem, and support all of the internal and demanding partners (especially SQL and other Windows efforts). But a substantial portion of both the tools and .NET runtime team's efforts were spent making Avalon perform, and I don't think that even now anybody who was there would claim that more DevDiv resources could have made the "Windows Shell is now made from WPF" effort succeed in the desired schedule.
I sell a Windows application targeted toward business users. 57% of my site's visitors are still running XP. Of those who purchase, 50% are XP, 40% are Win 7, and 10% are Vista users. So forgive me for not getting excited about changes to any upcoming version of Windows because until the folks in Redmond design an OS that businesses are interested in, it's mostly moot.
As long as xp still works, it's impossible for microsoft to design an OS that businesses are interested in. migrating a large business to a new OS is a huge endeavour, and as long as there's any way to get away with not doing it, businesses are going to stick with XP.
the only way to get people off XP is to start writing applications that don't support XP.
I think cost is also a huge factor. But I would be interested to hear from some IT directors.
Right now volume licenses for Windows 7 just aren't that appealing cost-wise, especially when you consider that XP does still work. Home users have a similar dilemma: they can continue to use Windows XP for browsing the web and playing Farmville or they can spend $120 on a neutered Windows 7 Home Premium upgrade.
That's too much money for what is perceived to not be that much better. I think you'd see greater, faster adoption with a lower cost and one version (just Windows 8, not Windows 8 Starter, Home Premium, Professional and Ultimate) that has volume licensing for businesses.
I've only ever worked in a SMB contracting environment, so i can't speak for buying really large volumes, but in my experience it's not windows itself that is the big cost. it's the cost of man-hours to get everybody transferred over, the cost of training people on a new OS, and the cost of upgrading all the ancient tertiary systems that were built for 95 and somebody hacked into being compatible with XP.
Why should this change? Microsoft has invested billions in Vista and Windows 7. It's time to upgrade. Supporting all the legacy costs Microsoft money that can be better spent on future enhancements.
Technically that's the fault of the hardware vendor for not including a valid serial # in the device's EEPROM. Did they change the behavior in later Windows versions?
no, they didn't. vista and 7 still have exactly the same behaviour as XP for initializing a new device, they just do a better job of hiding it from the users.
The article plays on the ambiguity in the phrase "Windows is not based on .NET."
On the one hand, if "Windows" refers to the black box bits and pieces of code which make up the Windows operating system, then it is pretty much true that Windows is not based on .NET.
On the other hand, if "Windows" refers to the interfaces to the black box with which software developers typically interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects. Yes, there are exceptions - but from a practical standpoint, the working of the black box is irrelevant for most projects and it appears that Microsoft recognized this when Longhorn was shelved.
The speculation that the javascript/HTML5 model indicates a fundamental architectural shift in the Windows OS core seems to be unjustifed - the meaningful evidence for such an architectural shift being underway is the demonstrated ability of Windows 8 to run on diverse architectures.
Which is why the FUD being disseminated about the Javascript HTML model is so interesting. It is nothing new; merely another implementation of an idea Microsoft has been kicking around for years: i.e. HTA's (HTML Applications) have been a part of Windows for more than a decade.
In addition given that .NET can provide total control of the browser and that such a browser exists on the Windows platform in the form of IE, the whole javascript/html model Microsoft demonstrates can be seen as just another layer running on top of .NET.
refers to the interfaces to the black box with which software developers typically interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects
I agree that the vast majority of Windows thick client business projects developed in the last few years probably target .NET, but, looking at the start menu on my Vista laptop currently, apart from dev tools, PAINT.NET and Keepass 2.0 (which still maintains a 1.x Win32 release), every other end-user application installed on my machine does not run on .NET.
EDIT: In fact, I only run Keepass 2.0 for Mono compatibility on Ubuntu. I also would guess that a default Ubuntu desktop install has more dependencies on Mono, than a default Windows install does on .NET.
I'd imagine that that manager is Steve Balmer, or only 1 level below him.
The heads of WinDiv (http://www.microsoft.com/presspass/exec/ssinofsky/ ) and DevDiv (Not sure who that is - Scott Guthrie or his boss?) are pretty senior.
Has the infighting gotten worse since Bill Gates handed over?
Ok. Still, I get the feeling that Balmer should be sorting this out and setting direction. or making sure that someone does. Doing the "vision thing". Leading, basically.
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:
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.
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).
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.
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".
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.
But, it was a big effort. And even coming from inside of Windows, getting the rest of the shell to run on a whole new stack -- from drivers, through C++ layers, through managed -- was a challenge, especially with all of the other things going on in Longhorn. Sometimes, you bite off more than you can chew, especially when you make the dependency stack too deep.
Also, all of this happened long before Silverlight efforts started... XAML came out of the WPF work. Arguing Silverlight stole DevDiv focus from WPF during the Longhorn timeframe is temporally impossible. Certainly, you could argue DevDiv was being pulled in many directions with the concurrent efforts to placate the VB4 crowd, push out a new version of VS, figure out a new syntax for Managed C++, compete with the then-rapidly-expanding Java tools ecosystem, and support all of the internal and demanding partners (especially SQL and other Windows efforts). But a substantial portion of both the tools and .NET runtime team's efforts were spent making Avalon perform, and I don't think that even now anybody who was there would claim that more DevDiv resources could have made the "Windows Shell is now made from WPF" effort succeed in the desired schedule.