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.""
The proof is in their application layer. Office, Visual Studio, and their other user applications.
.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.
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
Microsoft deciding to keep OS components in native code is not indicative of anything.
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.
Why not a C# notepad, mspaint, explorer.exe, taskmgr, regedit etc?
.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.
.NET or longer. Consider Office. That's been around forever.
.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.
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,
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
You're saying they should just throw away everything and do it all over again in
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.
.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.
Now if they wanted to write some new app in
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.