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

The proof is not OS services

[BadAnalogyGuy]

The proof is in their application layer. Office, Visual Studio, and their other user applications.

People like to complain about MFC, but fail to realize that Visual Studio, from its humble beginnings up through VS6, was based on MFC.

Besides that, the value of a tool is not determined by what the toolmakers do with it, but with what you can do with it. When you see proved over and over that .Net provides many more facilities to the underlying operating system than most other runtime packages that came before it, and that it does so in a way that makes programming in that environment a pleasure, then you see the value of .Net.

Microsoft deciding to keep OS components in native code is not indicative of anything.

Reflection!

[bencvt]

Other than the obvious execution speed issue, there's a second factor involved that's nearer and dearer to Microsoft's heart: protection of their IP.

.NET has excellent reflection support. Consequently, .NET assemblies are easily decompiled. And there are numerous freely available tools to do this.

Sure, there's obfuscation. Doubtlessly, MS already uses obfuscation extensively in every one of its published .NET assemblies.

But obfuscation will only get you so far. Your garden-variety reverse engineer will have an easier time working with obfuscated .NET code than traditional assemblies.

Easy: you don't start over unless you have to

[xiphoris]

Why not a C# notepad, mspaint, explorer.exe, taskmgr, regedit etc?

Why waste time re-implementing something that already works fine? Also, explorer.exe doesn't really qualify as userland. Sure, it's not the kernel, but it's as close as you get in userland.

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.

Again, it seems you're expecting Microsoft to instantly rewrite all their software from scratch. A lot of software that's going into Vista, and indeed Vista itself, have been in the work as long as .NET or longer. Consider Office. That's been around forever.

You're saying they should just throw away everything and do it all over again in .NET? Personally, I think notepad and regedit are fine the way they are. If .NET needs to prove itself, it will not be through clones of tools as simple as those.

Re:Easy: you don't start over unless you have to

[bigman2003]

So how *should* they work? I've never had Notepad crash. It has always done for me exactly what it should do.

If I want a program to do more, I use something else. But for what it is designed to do, Notepad is great.

Re:Easy: you don't start over unless you have to

[R3d M3rcury]

"Why waste time re-implementing something that already works fine?"

From a coding perspective? Agreed. If it ain't broke, etc., etc. Politically, though, there is quite a bit to be gained.

I am not a Windows Developer and I'm pretty ignorant about .Net. But, as a Mac developer, I know Apple gets a lot of credit for "eating their own dog food." When Apple announced Carbon, many Mac developers had this whole "Carbon is going away, it will never be as fully supported as Cocoa, Apple is going to screw us, etc." attitude. This is one reason the Finder is a Carbon application. Apple would have a hard time getting rid of the Carbon APIs and rewriting the Finder in Cocoa at this point.

Another good reason to do this is to show what .Net can do. Again, I'm ignorant of it, so I don't know what it can do. But, to use Apple as the example, Apple's applications like iPhoto, iWeb, etc. are written with Cocoa. That certainly makes me feel more confident that problems with Cocoa will be found and fixed, that Apple will continue to support and improve it, etc. It's a better way to sell developers on using it than having some VP of Development stand up at a conference and say, "Hey you guys, you should really use Cocoa. It's cool."

Third, and this is a variation of "eating your own dog food," but if Microsoft is making all these claims about how great .Net is, why aren't they using it? If it supports rapid application development, then it shouldn't be that monumental a task to rewrite Notepad, MSPaint, RegEdit, etc. with it. And if it is a monumental task to do this, maybe Microsoft needs to figure out why this is so and solve the problem. If rewriting a simple application in .Net is so difficult, why should I use .Net to write my applications?

Re:Well DUH

[Nataku564]

Not much, but why rewrite something? The net result is just a notepad that runs about the same as the original, with no physical difference. Joe End User is not impressed. Rewriting things in the latest and greatest programming language of the day always sounds cool from a geek perspective, but from a business standpoint (and just plain old efficiency standpoint) its wasteful.

Now if they wanted to write some new app in .Net that would be cool. But just as with VB, you will notice Microsoft stays away from their own tools. They know their business strategy, and they know that the current cool buzzword be obsoleted for the next flavor of the month tech that they want to sell to their users.

Re:Can't blame them

[GreggBz]

Uhh.. I call shenanigans.
I write games also in, get this... VB.NET. (Which turns into the same CLR code as any other managed language)
Fairly complex stuff, not commercial quality, but impressive none the less. Commercial quality of 4-5 years ago maybe. My current project has about 180 pages of source and that compiles in about 15 seconds on my 2.5Ghz machine. I'm using DirectX 9.0 SDK summer update 2005. You're aware that Quake II was ported to .NET and runs just fine? http://www.vertigosoftware.com/Quake2.htm Compiling that took about 90 seconds on my machine. I noticed approximately 80-90% the performance level of the original C / Assembly version. Maybe there is something wrong with your code, or design.

My development experience in VB.NET has been a pleasure. I write bash/perl shell scrips at work all day so this is polar opposites. The brain dead IDE and syntax makes things nice and easy, and I can focus on problem solving and complex algorithms. Also the speed penalty is more than acceptable, unless you are writing some very serious games.

Re:Well DUH

[Onan]

Hm, I'm not quite sure I agree with your assessment which one of those is the "real" solution and which is the bandaid.

If the past three decades of computer science have taught us a single thing, it's that intelligent, conscientious, meticulous coders will still write code that has simple vulnerabilities like buffer overflows. Now, I'm not suggesting that we just give up on trying to write good code. But it's hard to argue that it's anything other than a win to reduce the damage of such errors when they--inevitably--occur.

Writing unexploitable code is great, but it needs to be executed perfectly by every single developer, writing every single line of code, forever. Every time you find and fix one bug, you've only fixed that one, but haven't done anything about future ones; that seems like the epitome of bandaidness. A single centralized sandbox api could conceivably address such bugs categorically, in a finite amount of code.

I don't actually know anything about .net, so I can't speak to how well it accomplishes this goal. But generally approaching the problem in this way seems sound. An actually-existing approach that seems analogous is the privsep model of recent years' opensshd.

Missing the point

[nobodyman]

You're missing the point(s). Let's recap:

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....[snip]

This scenario is pure fantasy. The vast majority of apps nowadays are IO limited, and spend most of their time idling whilst they wait for on the hard drive/network for more data, or (more commonly) waiting for the user to type something or click a button. I doubt you'd realise these types speed gains you talk about - most of the time the user him/herself is the weak link in the throughput chain.

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

Well, you've left out those 60 people who are twiddling their thumbs for 100 hours because the "super-speedy C version" of their app doesn't exist yet. That's 60 people * 100 hours of thumb-twiddling * $8.00/h = $48,000 of money that is lost as users eagerly await the software that is going to save them $4,160 per year.

In your world, they'll break even in around 12 years. Funny, you haven't convinced that development time isn't the leading factor in the cost equation.

Re:Well DUH

[PhrostyMcByte]

Is Microsoft supposed to completely rewrite all of their already working software? Maybe I was the only one that expects _new_ things to be in .NET.

Re:Well DUH

[Eivind Eklund]

I'd say relying on each and every one of hundreds of thousands of buffer operations being right is the bandaid, and that using "least privilege" is the systematic, proper approach. Of course, pros do both. It's known under various terms, a common one being "defense in depth".

I was sort of worried that MS was going to take over for open source, by actually taking the job of fixing their security model and creating really secure and stable system. Don't look like the chose to.

Eivind.