Slashdot Mirror
Analysis of .NET Use in Longhorn and Vista
smallstepforman writes "In a classic example of "Do as I say, not as I do", Richard Grimes analyses the ratio of native to managed code in Microsoft's upcoming Vista Operating System. According to the analysis at Microsoft Vista and .NET, "Microsoft appears to have concentrated their development effort in Vista on native code development. Vista has no services implemented in .NET and Windows Explorer does not host the runtime, which means that the Vista desktop shell is not based on the .NET runtime. The only conclusion that can be made from these results is that between PDC 2003 and the release of Vista Beta 1 Microsoft has decided that it is better to use native code for the operating system, than to use the .NET framework.""
As far as the kernel goes, you are right. However, with windows we are talking about a whole suite of applications included with the OS. None of them are all that complex, and could probably run quite quickly under the .Net platform. I've often wondered how much more secure our computers would be if we ran web browsers, mail clients, and other web facing applications in a sandbox like the JVM, I think .net has some of the same capabilities. I'm sure attacks would still be possible, but at least we wouldn't have to worry about buffer overflows causing problems.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I spent a year developing games (yes, believe it or not) in C# under "managed" DirectX. Keeping up with the various versions of the runtimes required (D3DX) was difficult... and just to test our game, it took over 3 minutes to recompile and get it to come up under the just-in-time compiler. That was for each tweak-code/recompile/test-to-see-how-it-looks iteration -- talk about killing my productivity! The first opportunity I got to take a job back in the C++ "non managed code" games world, I took it! Good riddance. I see why they don't want to use it either. Just more bloat from the kings of overkilled Fronkenschtinian solutions.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
He's not ranting. His expectation was that many of the peripheral services in Vista would be built in .NET, as was the case with the PDC 2003 release of Longhorn. However, if you track through the links to various articles about Microsoft and the Longhorn 'reboot', you find that .NET was pulled from this OS role due to the lateness of .NET 2.0 and the fact that machines that would run .NET services at a reasonable speed are 6 years (now 3 years) down the road.
.NET. This is probably good, since I've sinced switched to objective-C and Cocoa for my personal development needs. This is great since Apple doesn't pull the same crap as MS does about supplying a crappy UI library, then using a much better one in it's own products. e.g. any Office 2003 app etc etc.
This has all the hallmarks of the ass-kickings that Bill Gates handed out during NT development. The ass-kickings that pushed the graphics code into the kernel spring to mind here.
All this is kinda interesting, since my job has kept me in VC6, and I've mostly missed out on using
-- "It's not stalking if you're married!" My Wife.
Actually, I believe microsoft is still committed to developing using the .Net framework. I think they've been hurt by the same problem that rest of the developers faced- back when development for vista started, .Net was a buggy framework and .Net 2.0 was still under heavy development- I think the people in charge of windows didn't want to have a dependency on .Net, since waiting for the new stable version of .net 2.0 would have delayed vista further, and that would never have been acceptable to allchin and co.
This has been leaked several times. It'll probably be leaked again and ignored again. Here it goes.
.NET almost entirely. Avalon, Indigo, WinFS, tons of other application and API layers were built on .NET tech. Yes, you heard me - the new graphics layer was going to be a .NET system, primarily. Older systems were being ported to .NET. Any new features were to be written in .NET. It was a huge initiative.
.NET handled versioning. This wouldn't be complete until the next iteration of .NET - past VS 2005 (Whidbey). This was considered a pretty risky thing - to depend on this way to deal with versioning that hadn't even come out yet. In the middle of 2004 it was discovered or hashed out that the versioning story was just not going to work.
.NET assembly that depends on the 1.1 framework. You've got another that needs the 2.0 framework. Both of these need to be accessible via the same process, potentially - otherwise you're in a worse version of DLL hell. Note that this is impossible to do currently via Java; having multiple packages that need different versions of Java to run can not run in the same package without recompilation. Microsoft's original answer was to have a sort of virtual-VM that would allow this to run, but for whatever reason it was scrapped.
.NET parts of Longhorn/Vista would be cut except under really extreme situations. This is why Avalon, Indigo, Monad and a host of other features that were going to be part of Vista natively will now be addons - because they were deemed too dangerous to ship with.
.NET - and it looked like they were going to be able to do it too. These were all cut because of the versioning issue, not the performance issue.
Vista had been built around
One of the things this initiative depended on was the way that
An aside: what do I mean by versioning? For instance, let's say you've got a
When this versioning problem came up, it was decided by the higher ups that ALL
Long story short - MS had every intent of having performance-critical APIs, applications and big parts of the OS be in
Microsoft's inability or disinterest in leveraging their .Net API to rapidly build new applications and system utilities stands in stark contrast to Apple use of Cocoa, the API they're selling to their developers.
.Net 2.0 - more than 1/2 a decade.
Apple uses Cocoa not only to rapidly build new freestanding apps like iPhoto, but has rebuilt bundled apps like Mail with it, as well as pretty much everything that isn't Java or a standing legacy codebase (like iTunes or the Finder, which was ported from OS 9 in Carbon). Apple is very much eating their own dog food, so that the direction they sell to developers is actually being put into practice at home, and actively being developed by its owner (and premier user).
The difference:
- Cocoa isn't a flavor of the month. It has functional origins back into the 1989 release of NeXTSTEP, making it over 15 years old.
- Apple moved decisively to Cocoa after revealing their strategy for Mac OS X around 2000.
- The work to modernize the NeXT APIs into today's Tiger Cocoa (yum) is comparable to delivering
- Cocoa has incrementally absorbed an increasing role in Mac OS X as it expands to encompass new functions that were only available procedurally before in Mac OS X.
So Apple has a strategy that they are decisively using, while Microsoft takes wild stabs at various things, few of which ever get to mature before a new stab is announced.
Microsoft 2006 sounds a lot like Apple 1996. The difference: there isn't another NeXT for Microsoft to buy.