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.""

Comments

Mono

[zbyte64]

I wonder if the Mono project had any effect on their decision... Imagine porting windows apps to *nix via Mono. But maybe I'm just making a mountian out of a hill...

Re:Mono

[Zeinfeld]

This seems like a vote of no-confidence. You'd think the marketing people, at the very least, would've told someone "We have to include at least one hosted app or service in Vista, or people are going to think the CLR and .NET APIs are second-class environments."

Vista does not provide any new applications though. The main changes are deep in the O/S at the level where folk used to argue over high level language vs assembler. The user interface eye candy is expensive enough in cycles without using a set of relatively new compilers.

Longhorn has been in development for 6 years now. The last thing Microsoft needed to do was to introduce another delay for any reason.

Today managed code is slower than the best optimized C. It is on a par with average quality code. There was a time when the same was true of C code vs assembler. Today the number of coders who can produce code that is faster than compiler generated is pretty small and even they can't keep it up for very long. I don't think it will be long before the same is true of CLI code, particularly if the code is optimized for the platform at install time.

Unlike Java CLI code has exactly the same information available as the standard microsoft C++ compiler, plus it knows the exact target processor. The only thing that dings managed code performance wise is having the garbage collector running.

Re:Well DUH

[CastrTroy]

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.

Can't blame them

[electromaggot]

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.

Irrelevant

[popeyethesailor]

I respect Richard Grimes' writing, as a .NET programmer. However, I cant figure out his rants on .NET's directions.

This issue is largely irrelevant; .NET was never promoted as a systems programming environment - a few tasks such as network programming and higher-level services may have some benefits, but throwing out well-tested subsystems because of a new framework is asinine. There are tons of things MS is building with .NET - for example, I assume ASP.NET is a fairly large codebase, and it's completely built with .NET(no pedantic comments about ISAPI filters pls..) And their research team is building a C#-based OS called Singularity from the ground-up. I'd like a few more things to be .NETized, but my expectations are lesser than Mr.Grimes'.

Re:Irrelevant

[kabz]

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.

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 .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.

Re:Well DUH

[AstroDrabb]

an operating system IS supposed to be as efficient and speedy as possible

This isn't talking about an OS. It is referring to USER-LAND tools. I don't think anyone is expecting MS to rewrite the kernel in C# or managed C++. However, how can one be confident in .Net if MS won't port their USER-LAND tools to it? Why not a C# notepad, mspaint, explorer.exe, taskmgr, regedit etc? All of those would be great in .Net and would show MS's customers that MS is behind .Net 100%. As it looks to me, .Net is the "soup of the day" at MS. .Net will be replaced in 3-5 years with something else that will require MS customers to re-purchase their development tool chain.

an operating system IS supposed to be as efficient and speedy as possible

I think this could be said for *all* applications. I want the desktop apps I write to be "as efficient and speedy as possible". I want the web-apps I write to be "as efficient and speedy as possible". Going by your statment it sounds like I should not use .Net for anything. I mean who wants to use something that is not as speedy and efficient as possible?

As the trolls would say, "Move along, nothing to see here".

I think there is something to see here. Why doesn't MS port their non-OS apps to .Net? MS wants their customers to always port software to the latest and greatest MS language/environment of the year, so why doesn't MS do the same?

Re:Well DUH

[Jason Earl]

Exactly, Novell is perfectly happy to be building nearly all of its new tools with Mono, and some of my favorite Gnome applications have been written in C#. If .NET is so cool why isn't Microsoft doing something similar?

Re:Well DUH

[digitalinfinity]

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.

Re:Well DUH

[Jason Earl]

If there was ever an application that screamed out for replacing it is notepad.exe. Seriously, you can't throw a rock without hitting 10 better basic text editors for Windows, and yet for whatever reason Microsoft still relies on notepad.exe for this important niche. I mean seriously, how hard would it be to replace notepad.exe with a fancier .NET version that didn't suck so completely? I would bet that if Microsoft simply asked the developers there that they would find that they have half a dozen notepad.exe replacements written in .NET technologies. Not only would this mean that systems administrators like myself wouldn't have to include a decent text editor in our base images, but it would help showcase .NET.

I do agree that Microsoft seems to be mostly unimpressed by its own marketing machine, but its pretty clear that Microsoft is still trying to gain marketshare for .NET, and every little bit helps.

Re:Power is cheap, time is expensive.

[AstroDrabb]

Here's a reality check for you:

And another one right back at you. Developer time is not always the most important thing. It may be important for a *software* company, but for a company that makes their money from anything besides software, it usually is not. For example, where I work we have 150,000+ employees. A *very* small fraction of them are programmers. Here is an example for you: say I write a program in .Net that is used by 60 people to do some processing and that processing takes 10 minutes. The same application in C/Win32 does the same task in 8 minutes. That is 2 minutes per day times 60 people or 120 minutes/2 hours per day. We can use a very low wage of say $8.00/h * 2 hours = $16 a day; 5 days/week = $80/week; 52 weeks/year = $4,160 a year. Now say that application is used for 2 years we come to $8,320 in lost productivitiy. Even if it took me an extra 100 hours to write the app in C/Win32 at $50/h that would only be $5,000. Still less than the 2 years of lost productivity. If you add more workers into the mix, things only get worse.

I think your "reality" is a little narrow. There is a lot more complexity to figuring out ROI then what the MS marketing machine has convinced you of. Even my example leaves out a lot of details like the added cost of migrating to a newer toolset to support .Net, etc.

The real story

[Anonymous Coward]

This has been leaked several times. It'll probably be leaked again and ignored again. Here it goes.

Vista had been built around .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.

One of the things this initiative depended on was the way that .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.

An aside: what do I mean by versioning? For instance, let's say you've got a .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.

When this versioning problem came up, it was decided by the higher ups that ALL .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.

Long story short - MS had every intent of having performance-critical APIs, applications and big parts of the OS be in .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.

Forget Sun... is Apple using Cocoa?

[DECS]

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.

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 .Net 2.0 - more than 1/2 a decade.
- 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.

Because .NET is effectively open source

[upside]

It's easy to decompile and analyze .NET bytecode, all the way to method and variable names.

See Reflector: http://www.aisto.com/roeder/dotnet/

OK, now shoot me. I'm not a .NET expert.