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...
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
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?
I think your forgeting about all the hype put out by Microsoft, that .NET would result in a more secure OS because buffer overflows would be a thing of the past.
While, a few years ago, Microsoft was pushing the MS koolaid drinking developers towards MFC (which I used for some projects), MS used WTL (Windows Template Library) for projects such as Office! Think I'm smoking crack? At one point, I renamed all the MFC DLLs in my system and then proceeded to try all the apps in my system to see which ones were dependant on MFC. Guess which ones weren't? That's right, Microsoft products, such as Office, weren't (use Dependancy checker to verify)! Don't know what they're using for Office now, though...
Although MS never really officially supported WTL too much (was on MSDN CDs at one point if you knew where to look), it had a great fan base. I used it for a few apps, and it produced some of the tightest GUI code I've ever seen! With no DLL dependancies either! MS apparently dropped support, but now it's on Sourceforge, so it's still available.
Great, just when they finally got me to drink the forking .NET koolaid, they have to switch it on developers AGAIN! Just how much crap will MS developers take?!?!?! You know, I do like the .NET forms library and the way it's cross language compatible, but couldn't this have been done WITHOUT putting all this on a virtual machine?!? Virtual machines make working on real world apps a pain to develop, IMHO, with having to interface with legacy libraries and the performance issues wrapped around those interfaces...
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.
I agree. Even looking at Windows XP, the following applications could be written with managed code:
IE (considering IE 6's security "model", this would be a really good idea)
Outlook Express (ditto)
Media Player (yeah, ditto again)
WordPad
Movie Maker
Paint
Image & Fax Viewer
Solitare and every other game
The road to tyranny has always been paved with claims of necessity.
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. Perhaps there's a very good reason why these services can't be written with managed code, unfortunately I don't know what it is.
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.
Well, then, isn't that the same reason for 3rd party developers to not use .NET? If there is no physical difference, why use .NET over known existing toolkits and libraries? Using .NET chains developers to MS, while at the same time MS is NOT constrained by .NET
.NET really is as powerful as Microsoft claims, why not write them in .NET?
.NET in Mac OS X is Cocoa, the modern development environment on OS X, while Carbon is their modern equivalent to Win32 that is also compatible with the now deprecated Mac OS 9. Apple implements their modern products (Safari, iPhoto, Mail, Aperture, iChat) in Cocoa and their transition products in Carbon (Finder, iTunes). The term, I think, is "eat their own dog food" in terms of promoting these development environments. .NET replaces Win32
On the other hand Vista has NEW products, such as the new Explorer and IE; if
To use an example, analogous (but not the same) to
GPL Deconstructed
I'm quite content that notepad has remained almost entirely unchanged since Win95, actually. It's nice to be able to open up a *pure* text editor, no frills whatsoever, when I want. You have a point that they should include a better text editor, but then again that's already taken over by wordpad; not that wordpad doesn't suck, but I don't see why notepad is getting all the hate here. It's just a edit-plain-text-period editor, and that's fine with me. But avoiding being too pedantic here, yeah, wordpad isn't really anything more than support for some font formatting and the like, it's not much improvement especially compared to the kinds of little neat things that other 3rd party text editors have been doing since Win95.
.NET might be a good move . . . but it's not going to happen for text editors. For Windows the idea is notepad as a legacy plaintext editor (which I respect), then wordpad as a sucky slightly higher-level app so that people can barely read word documents and get suckered into buying Office. Yes, I realize that there is a difference between a text editor and a word processor, but Microsoft wants you to use Word and the other Office apps for everything, so they're not going to give you any apps that even so much as remind people that there are more choices other than either absurdly-basic (notepad/wordpad) and full-office-suite (Office, naturally). It's in their interests to maintain this binary picture of text apps in the mind of Windows users.
And sure, Microsoft should be working on some snazzier looking basic apps, and writing them to showcase
Okay, so that doesn't work for ya (and I often myself, if I'm doing plaintext editing on Windows for one reason or another, use something other than notepad). But hey, not to give in to the rampant bashing of Microsoft here on Slashdot but there are some pretty good reasons why people abbreviate it M$, right? Maybe I'm just driving out in Conspiracy Land here, but it seems to me that it's actually a business strategy for Microsoft not to have any better default editors.
I remember sigs. Oh, a simpler time!
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.
(this is apart from portability concerns -- which is a whole another discussion).
i am failing to see why people are so afraid of the M that we need the V. maybe on large multiuser mainframe-style system, you'd want some V. we are talking about PCs. if you need 'em, just get a bunch of 'em. those are your VMs.
if the argument is that if the app crashes or malfunctions -- for whatever reason -- you don't want the V to go down with it, well, if my app crashes, i couldn't care less about the machine staying up.
> 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
first, in todays day and age, what is not facing the web?
second, doesn't that make the JVM an extension (of the OS) whose sole purpose is to run the apps?
wasn't that what the OS itself is designed to do in the first place? so now, OS isn't something that runs apps but something that runs the VM to run the app? so shouldn't the VM be a standard part of the OS? but it is. it is the OS itself. but the OS isn't secure! so the VM on top of that very same OS is?
it almost sounds like packing on some cake-ey layers of makeup on top of wrinkled up skin and expecting it to fix the wrinkles. if it does show thru the layers, what next, another layer?
anyhow, i cringe when i see JVM. or any other VM for that matter. just give me the freakin M.
Someday soon you will need explicit permission to generate machine code, enforced through the PKI mechanism they already have in place. To flip that "unsafe" switch you'll need a signed certificate, which Microsoft will only sign when you agree to their terms.
While this is technically possible, if Microsoft made it very difficult or expensive to develop applications for Windows, less applications would be developed for Windows. The value of the Windows platform would drop significantly. Users, without modern applications, would switch to Linux and OSX in hordes, especially now that many important applications are web applications that run great in Firefox on any major operating system.
my blog
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
Any programmer that used a VM based language knows that is B.S.
// C with size bigstring>smallbuffer >> buffer overflow // Java with bigstring>smallbuffer : no overflow, smallbuffer garbage collected. // C# with bigstring > smallbuffer : no overflow, smallbuffer garbage collected.
Compare:
strcpy(smallbuffer,bigstring);
smallbuffer = bigstring;
smallbuffer = bigstring;
smallbuffer = bigstring # Python with pretty much the same... no overflow
The main point is garbage collection. One misplaced malloc() with no matching free() in the kernel can cause a memory hole that will keep on growing into infinity. Anyhow, if you do a ps v -A | cut -b "54-" on any linux machine you will see that the big culprits is not the kernel based components, but the gui based components.
Not all programmers are top notch, and sooner or later everybody slips up. VM's enable you to be sloppy and cleans up messes quite nicely.
Other than that, "putting your applications in a sandbox" is pretty much what is done with the Internet / Intranet split using firewalls. It is the default deny principle in working.
Sandboxing==Segregation==Layer of perimiter security. The more layers, the more security.
Why is Java a higher level language than C++?
My way of thinking is the higher level the language, the less code you need to write and I've found Java to be more verbose than C++. Java is also missing paradigms that C++ has, like operator overloading and (proper) generic programming.
I don't think JVM's are the way to have decent security anymore. Things like SELinux allows you to run code natively (in any language) AND at the same time have sandbox-like security.
All the advantages, without any of the disadvantages. Why "virtual machines" exit at all? I already have a machine, a real one! Give me an operative system with a MAC framework, I'll leave others the overengineered abstractions.
Well I know quite a bit about .NET. I've been developing in C# since 2001. It does not surprise me at all that Microsoft's implementation of the Vista kernel and services do not run on .NET. I would actually be surprised if Vista shipped without a single app running on the framework, this is definitely not the case with beta's of Vista.
.NET is to provide a sandboxed environment in which the services and resources of the hosting OS are exposed. When an application is run in the .NET framework, the context in which the application runs affects what api and resources that are available. When an application running in a reduced security context attempts to execute an priveleged api an exception occurs, protecting the operating system. For example if your ran a Microsoft Winform .NET application on your local machine from a server on the internet, unless you have granted that domain special privileges it will run in a reduced security context, if that application attempted to delete or modify files on your machine it would throw an exception.
.NET's sandboxed environment it's always going to run with full access, hence the only reason you would have for implementing it in .NET would be to reduce the cost of development, when your budget for R&D is $4 billion a year, this obviously wouldn't be a motivating factor, as the original post said, you wouldn't do it for performance reasons.
.NET is not just a new highly productive development platform, its part of a larger strategy which aims to see a decline of a html based applications on the internet, in favour of Microsoft .NET applications, which is probably quite similiar to Sun's vision of client side Java, and Macromedia's vision of flash. I think it's only a few years away and you'll come across web sites which may at first glance look like like old school html with a bit of flash, but are in fact XAML... a windows application.
.NET to some is going to increasingly become more cross platform, it's been designed that way from the outset. But at the end of the day you can bet it will always be more fully functioned on Windows than it will ever be on Linux or Mac or some other OS. For Microsoft I think they'll be hoping this will lead to a continuing dominance the desktop market.
The purpose of
Basically a service running on an OS is never going to run in a reduced security context, in
I think Microsoft's vision for
I can hear you all saying... but Java and Flash are cross platform. Like Java and Flash,
At the end of the day it will all be about content, and what technology that content leverages.... So the developer will decide.
"The vision of MFC: Let's saddle people with the extra intellectual mass of C++, but ignore the language's most powerful features; instead we'll fill in the gaps with a bunch of C preprocessor macros. Then we'll throw in a bunch of wizards to encourage people to automatically generate spaghetti boilerplate by the megabyte."
LOL - spot on! You can really see that MFC was made by people who didn't really get C++, but I suppose that's partially excusable since it was developed back at a time when the language was still relatively new and many coders frowned upon OO.
I've been playing a bit with Ultimate++ recently, and I think that it really shows how well a GUI toolkit can be written in C++. Check out these nice comparisons with Qt, Java/Swing and wxWidgets