Windows 8 for software developers: the Longhorn dream reborn?
arstechnica.com
arstechnica.com
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.
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.
[http://en.wikipedia.org/wiki/HTML_Application]
[http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%2...]
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.
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.
the only way to get people off XP is to start writing applications that don't support XP.
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.
Microsoft has invested billions in Vista and Windows 7.
It's time to upgrade
You can buy support for legacy versions of VMS, Unix and OS/2.
Supporting all the legacy costs Microsoft money that
can be better spent on future enhancements.
The reason for withdrawing XP support are strategic, not cost-oriented (nor customer-oriented!!)
Surely there must be a manager somewhere that looks over both teams and makes sure they aren't trying to shaft each other.
Has the infighting gotten worse since Bill Gates handed over?
OMG, Another non-technical person trying to write about technology again <sigh>
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...
.Net framework relies on the Win32 API to
interact with the operating system
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
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.
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).
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.
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".
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.