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.""
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...
is that it's not dependent on Blu-Ray.
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.
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.
I respect Richard Grimes' writing, as a .NET programmer. However, I cant figure out his rants on .NET's directions.
.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'.
This issue is largely irrelevant;
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
Read this blog posting by Dan Fernandez:
"...For those of you that refuse to believe, here's an estimate of the lines of managed code in Microsoft applications that I got permission to blog about:
The Online Slang Dictionary
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?
Are supposed to run like glacially slow dogs, which have just been fed a tranquiliser overdose?
Deleted
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.
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.
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
Grammar tip: "Effect" is a verb. "Affect" is a noun.
I know this is entirely off-topic, but I feel I must comment. Frankly, you're wrong. "Affect" and "effect" are both nouns and both verbs.
You can read the verb and noun definitions of affect here. You can read about those of effect here, if you want to learn more.
Anyway, please change your sig. It's bad to spread misinformation.
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
I see nothing in that EULA that prohibits benchmarks against Java.
.NET Framework component of the Software to any third party without Microsoft's prior written approval. The foregoing does not, however, apply to the Server Software for Windows Server or Exchange Server.
= /library/en-us/dnnetdep/html/redisteula.asp
.NET Framework component of the OS Components (".NET Component"). You may disclose the results of any benchmark test of the .NET Component, provided that you comply with the following terms: (1)
Bullshit, and this pisses me off to no end.
My link and several others: http://www.msdnaa.net/EULA/EMEA/English.aspx
2.6 Benchmark Testing. You may not disclose the results of any benchmark test of Server Software (as defined below in Section 4.1) or the
Your Link has stipulations:
http://msdn.microsoft.com/library/default.asp?url
*You may conduct internal benchmark testing of the
Go read the compliance of terms.
Enjoy,
It's just the normal noises in here.
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. .NET, but because these apps desperately need updating. There are already 3rd party .NET replacements for these, but MS needs to jump on it. However, you can't be farther from the truth with regards to .NET being replaced in 3-5 years just because notepad isn't written in .NET. Important enterprise applications like Biztalk Server and CMS have at least in part been ported to the .NET platform. Media Center is written in .NET. Parts of Visual Studio and Visual Studio Team System is written in .NET. This is all fairly public information - if I were internal at Microsoft I could probably list a lot more. So while I agree that MS needs to rewrite a lot of tooling in their OS (whether or not using .NET), I do not think that the lack of Vista .NET applications points to Microsoft not having a huge commitment with .NET and looking to replace it with Yet Another Platform to sell to everyone in a few years.
You are absolutely right in that MS should rewrite the "basics" like notepad and mspaint. Not because of
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
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.
I don't think anyone is expecting MS to rewrite the kernel in C# or managed C++.
Interestingly the people at MS research are expecting just that - they are writing Singularity in what is essentially C# with extensions (extensions mostly in the form of formal specification semantics to allow more complete static checking). The upside to doing this is that, when combined with a better ground up approach to security as is being used in Singularity, you get a remarkably robust and secure kernel for an operating system.
Of course this is a project at MS research - I wouldn't expect it to ever see the light of day in an actual product released by MS. It's nice to know that some people set their expectations suitably high though.
Jedidiah.
Craft Beer Programming T-shirts
We had someone out to interview last month who is currently at Microsoft working on Windows. He said that the major reason that Vista is so late is that they had to rollback all of the development to remove all of the managed code because performance had gone to hell. Every thing that had been done in managed code had to be reimplemented from scratch. Ouch.
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
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
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.
Dude, you've never heard of static linking?
It's amazingly simple to determine if MFC is being used statically in an application. Look for the teltale signs in the Windows classes with Spy++ or dump the executables and find the symbols.
Ok, just fired up spy++ and took a look at Outlook and guess what? One of the windows under the root window is AfxWndW, MFC finger prints right there.
If you need web hosting, you could do worse than here
It's easy to decompile and analyze .NET bytecode, all the way to method and variable names.
.NET expert.
See Reflector: http://www.aisto.com/roeder/dotnet/
OK, now shoot me. I'm not a
I'm sorry if I haven't offended anyone
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.
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.
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.
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.
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.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
You're right. Win2k uses a microkernel architecture. The kernel is kept tiny and streamlined, but upon receiving events it passes execution off to a userland service, which does all the work of addressing that event.
Uh? NT "microkernel" stopped being a real microkernel long time ago (just like mac os x). The TCP/IP stack, drivers (IDE/SCSI/SATA controllers, graphic/sound drivers etc), the filesystem, the VFS...EVERYTHING is in the kernel. In practice, windows and mac os x have the same disadvantages than monolithic kernels, except they were designed from scratch to be modular (in practice, monolithic kernels have evolved and become quite modular aswell, which is why these days monolithic kernels can continue adding features without rewriting the whole kernel and maintaining it despite of all the complexity hardware has today)
So, where exactly win2k "passes execution off to a userland service") As far as I know they implement in the kernel everything that a monolithic kernel implements, plus the graphics subsystem + window manager, plus software audio mixing, plus some parts of some codecs....
You can't get the thing off until you unbuckle the 0th clasp.