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

Well DUH

[Anonymous Coward]

I mean, an operating system IS supposed to be as efficient and speedy as possible. .NET may be easy to develop, but it isn't as fast as native code. As the trolls would say, "Move along, nothing to see here".

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.

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

[jbplou]

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.

Re:Well DUH

[Albinofrenchy]

Holy crap, run-on sentence!

You worry too much. Unless you are doing something real damn special, you don't need to call WINAPI code alot, and alot of the unmanaged libraries are being/have been replaced with managed versions. Not saying it will be free of bugs, and completely secure, nothing is, but it will have fewer bugs, and fewer holes.

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]

I don't think that's an entirely fair assessment. I use several applications on Linux that are written in Mono on a daily basis, none of them seem remotely sluggish. f-spot, for example, performs very well. The only Java application that I use on a somewhat regular basis is Eclipse and it certainly is slow. In fact, when I played around with Monodevelop the one thing that really surprised me was how quickly it started up and how well it performed once started (especially compared to Eclipse). Now, I realize that Monodevelop isn't nearly the program that Eclipse is, but it's still a pretty useful tool and it started several orders of magnitude faster than Eclipse.

Now, assuming that Microsoft's .NET isn't considerably worse than Mono you would think that Microsoft would have included some visible new feature written in .NET. Heck, how about replacing notepad.exe, for instance. I mean, seriously, how much would that cost?

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:Well DUH

[Bacon Bits]

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

Re:Well DUH

[tshak]

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.
You are absolutely right in that MS should rewrite the "basics" like notepad and mspaint. Not because of .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.

Re:Well DUH

[Tyr_7BE]

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.

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:Well DUH

[Anonymous Coward]

I've given up on trying to get developers to write "the code properly in the first place."

Humans make mistakes. Don't fight it. It's not the pretty or perfect solution. But reality says that developers will screw up. Now pick the system that addresses reality and not what you wish to be true. What if thinking leads to communism and failure.

Re:Well DUH

[Coryoth]

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.

Re:Well DUH

[2nd Post!]

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

On the other hand Vista has NEW products, such as the new Explorer and IE; if .NET really is as powerful as Microsoft claims, why not write them in .NET?

To use an example, analogous (but not the same) to .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

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.

Re:Well DUH

[m50d]

People are only human, and they make mistakes. It's all well and good to say "don't make the mistakes", but it's better to have a setup where a typical mistake doesn't compromise the system.

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.

Re:Well DUH

[diegocgteleline.es]

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.

Re:Well DUH

[diegocgteleline.es]

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

Re:Well DUH

[MickDownUnder]

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.

The purpose of .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.

Basically a service running on an OS is never going to run in a reduced security context, in .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.

I think Microsoft's vision for .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.

I can hear you all saying... but Java and Flash are cross platform. Like Java and Flash, .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.

At the end of the day it will all be about content, and what technology that content leverages.... So the developer will decide.

Re:Well DUH

[plague3106]

From what I read, eventually all kernel calls will be through .Net managed code. Think of the .Net framework today as Win32s; the API which was backported to Win3.x so that developers could target Win95 and still have them run on Win3.x. Such a stragegy supports people migrating off of Win3.1, and thats the stragegy here.

Re:Well DUH

[plague3106]

This article is a good summary: http://www.ondotnet.com/pub/a/dotnet/2003/11/24/lo nghorn_01.htm?page=last&x-maxdepth=0

It was written 3 years ago though, but seems to make sense still.

Re:Well DUH

[yerfatma]

You can't get the thing off until you unbuckle the 0th clasp.

Re:Well DUH

[techno-vampire]

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.

So, it's better to put everything possible in a sandbox, so that code monkeys can be lazy and sloppy? That's OK during development, because you expect problems. Properly written production code shouldn't need that. Yes, errors will slip by at times, but things like buffer overflows are so easy to prevent that there's no excuse for them.

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

[djradon]

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

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.

So....

[Anonymous Coward]

So what... We donot use JVM as an OS. Every tool has a purpose. ".Net" is not created to be able to write an OS from scratch.

Re:So....

[Evers]

True, you don't want the really low level stuff (e.g. kernel) to be coded in .Net but I fail to see why some of the services couldn't be coded in it if Microsfot now really wants to promote the stuff.

the only good news I've heard about Vista...

[Anonymous Coward]

is that it's not dependent on Blu-Ray.

Uh...

[Anonymous Coward]

Isn't it impossible to do that anyway? .Net (or C# rather) is an interpreted language, and it needs an interpreter to be running in a host operating system. That interpreter needs to be run somewhere, but I don't think between the processor and the kernel is an especially good place for it.

Not suprising.

[rfernand79]

This is not surprising. Performance-sensitive applications (just as the shell, explorer or whatever they call it) would suffer from not being built with optimised, native code. Just remember the OS X Finder (pre-10.2). It was not multi-threaded and made using the UI practically impossible.

Re:Not suprising.

[bphant]

.NET code is JITed -- it _is_ native and compiled code. And it can be multithreaded. You would not notice a performance difference in a program like the shell (which isn't a performance-oriented program at all).

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.

Re:The proof is not OS services

[nickos]

"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

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.

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:Can't blame them

[gbjbaanb]

You're aware that Quake II was ported to .NET and runs just fine?

Yes, I am aware of that - it was a great article. However. the 80-90% performance you see with the .net version is almost entire with an unchanged codebase. They just recompiled it with the new compiler and the /clr setting (and fixed the few compile issues there were). They didn't change the code to suddenly start using the managed heap insead of an unmanaged one, so the 85% performance compared to the native app is almost entirely due to the clr overhead. If they added in .net features (or coded it using .net techniques for memory and other API Calls) then you would see the performance drop much further. (yes, the added OHD isn't exactly a major performance hog)

Yes, I'm sure you love VB.NET compared to Perl. :-) MS does do good development tools.

The point here...

[Anonymous Coward]

.. not that an OS could be written in .NET, but Microsoft going back on their words. Having the OS based on .NET would be a nightmare with the runtime overhead and would slow down the OS too much.Windows would certainly lose ground to other OS due to demanding hardware requirements.

Should consider only new code

[Anonymous Coward]

When looking at the ratio of .net vs. native, it would make more sense to consider only new code as opposed to all code. It is unrealistic to expect the existing codebase (like explorer) to be rewritten.

Re:Should consider only new code

[RobertLTux]

actually the reason that vista launch is what 7 quarter this year? is supposedly THE WHOLE THING WAS REWRITTEN FROM EXPLORER ON UP and one of the things that was marketed is that major chunks were rewritten to use the .Net runtime (for "safety reasons"

Re:When the baby came with instructions

[CastrTroy]

When was this? because I remember specifically having to download MFC42.dll when installing ICQ with windows 98. Are we talking about windows 3.1, because that wasn't really an OS, just an application that ran on DOS. I think Windows XP ships with .Net framework 1.1, but that OS is 4 years old, you can't expect every user to have .Net 2 when it didn't even exist back then. You can't force people to run the update wizard. And if you did, then people would complain that MS was forcing upgrades.

Consider the alternative...

[mattgreen]

If they had put .NET into Vista, then this article would be along the lines of "OMG MS PUTS INEFFICIENT CODE IN THEIR SHELL" and then blather endlessly on about how all real applications are written in [low-level-language]. Then we'd all sit around and wax about how wonderful it is that Gnome is pure C (and ignore the fact that Mono is associated with it because of cognitive dissonance).

Really, nobody can win when you sit there and pick apart everything someone does out of sheer spite. But I suppose it is far too unreasonable to ask for informed discussion these days...

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:Irrelevant

[caspper69]

Warning - offtopic. Sorry.

I agree with your post completely. This article is largely irrelevant. But it is interesting that you bring up the Singularity OS. It is quite a concept, having watched the Channel9 videos and read the whitepaper. Basically, the OS is written in a derivative of C# (which allows some of the things necessary for system level programming (int/trap/call gates, access to priviledged instructions like CLI/STI LGDT, LIDT, etc.)) and runs in a very lightweight .NET (if you can call it that at that point) VM. The really intriguing part of Singularity is that every process/thread/execution unit runs in kernel mode (ring0). The runtime is able to acheive security by analyzing the code prior to execution. Right now, this seems not only terribly inefficient, but brings up serious concerns about security and safety. But MS may be on to something....big. We all complain about the performance implications of managed/interpreted/byte/IL code, but what about when we suddenly have processing resources at the system level that were heretofore unimaginable in consumer level systems? I'm talking 4/8/16/32/+++ cores per die. Then where is the performance hit? Factor in that this new OS also completely eliminates context switching across protection rings. Quite frankly, with proper VM caching, code signing (at the VM layer; i.e. internal) and sound development practices, this type of operating system has the potential to be incredibly fast, and incredibly secure. Now the question is, who will release it first? (i) those trying to imitate MS with free software; (ii) a free software system who isn't hell bent on turning POSIX into a world dominating way of life; or (iii) Microsoft...

Why yes, I have designed and written an 32/64-bit protected mode, fully preemptive operating system from scratch (in C). It was hard.

No Duh

[NullProg]

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.

Why would Microsoft want to slow Windows down any further?
Ask Linus why he isn't using the JVM inside the kernel. Ask the KDE team why every call doesn't go through the JVM. Its a stupid assumption that any Vista program would run under the .Net runtime.

A better question would be to ask Microsoft why they won't allow anyone to publish program benchmarks for Java vs .Net runtimes.

Enjoy,

Re:No Duh

[0xdeadbeef]

http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnnetdep/html/redisteula.asp

I see nothing in that EULA that prohibits benchmarks against Java.

People are missing the point anyway. The purpose of managed code is to make DRM unbreakable. 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. If you want to see the future of "Trusted Computing", just look to the mobile space, already well on its way to that state of affairs.

Re:No Duh

[NullProg]

I see nothing in that EULA that prohibits benchmarks against Java.

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


Your Link has stipulations:
http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnnetdep/html/redisteula.asp

*You may conduct internal benchmark testing of the .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)


Go read the compliance of terms.
Enjoy,

Re:No Duh

[panaceaa]

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.

Dogfood

[Doc Ruby]

When Microsoft took over Hotmail, it took them years and many failed efforts to switch it over from unix to Windows. I'm not actually convinced they ever fully pulled it off.

20 years of Windows, and the more expert we are in either/both Windows and unix (or Linux), the less likely we are to use Windows technology for our most important development. Especially stuff that's less than 10 years in the field.

Re:Dogfood

[Doc Ruby]

Not only is your vehement "no" merely the uncited denials of an Anonymous Coward, another poster has actual eyewitness accounts that contradict you. As did the very public downtimes during the failures to switch.

As well as your own "guarantee" that their OS has been substantially changed to accomodate that "new" app. An app that didn't seem to require upgrading unix to originally deploy. An OS that, by its name alone, shows the depths of the switchover fiasco: they started switching in the late 1990s; the 2003 OS is "more robust" as a result; the migration is "still ongoing" in 2006. Everything you say is a lie, or evidence Windows wasn't adequate to the major task, or both.

And you don't know what "guarantee" means.

Why are the Microsoft apologists indistinguishable from the Bush apologists? It's a monopoly thing, I just don't understand.

So?

[WalterGR]

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:

• Visual Studio 2005: 7.5 million lines
• SQL Server 2005: 3 million lines
• BizTalk Server: 2 million lines
• Visual Studio Team System: 1.7 million lines
• Windows Presentation Foundation: 900K lines
• Windows Sharepoint Services: 750K lines
• Expression Interactive Designer: 250K lines
• Sharepoint Portal Server: 200K lines
• Content Management Server: 100K lines

Re:So?

[Petrushka]

--
Grammar tip: "Effect" is a verb. "Affect" is a noun.

Your sig comes across as a bit affected -- it's a troubling effect.

Re:What is it anyway?

[TrappedByMyself]

What is this .NET framework anyway?

Sorry bub, that ole' free karma trick in the .NET threads don't work much any more.
Doesn't hurt to try though, I guess.

Whereas applications on the other hand...

[Colin Smith]

Are supposed to run like glacially slow dogs, which have just been fed a tranquiliser overdose?

Re:What is it anyway?

[Octorian]

You know, it's funny that you bring it up. Once upon a time, when MS was first talking about .NET, it seemed like people could sit through 2-hour MS presentations and still not know what .NET actually was. Essentially, it was some sort of all-encompassing FUD/vaporware vehicle to get everyone behind a name, without knowing what that name meant.

Of course today people do know what it is. Essentially, it is like the intermediary java byte-code and VM, with a somewhat language-independent front-end. So you can write .NET apps in multiple languages.

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.

This wouldn't be the first time

[Whatsmynickname]

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

Re:This wouldn't be the first time

[Joe U]

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.

That test won't work, as the developer has the option to compile MFC into their application and ditch the dlls. (This may have changed since VS6.0, but I vaguely remember seeing it as an option in VS.NET 2002)

Re:This wouldn't be the first time

[man_of_mr_e]

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.

Re:When the baby came with instructions

[drsmithy]

[OT, but this sort of misinformation annoys me.]

Are we talking about windows 3.1, because that wasn't really an OS, just an application that ran on DOS.

Given Windows 3.1 did just about everything from hardware interfacing to memory management, I'd say it was pretty damn close to an "OS" (and a hell of a lot more than "just an application").

Windows 1.0, and maybe 2.0 could be put into the "just an application" baskets, but from 3.x onwards Windows was providing most all OS functionality.

Re:.NET is for rapid app development

[Brandybuck]

.NET is for rapid app development

But that is NOT how Microsoft is promoting it. To read their ad copy, they make it sound like .NET should be for rapid development and long term carefully designed development, and very kind of development in between. It's for desktop applications, web applications, client/server applications, services, system software, device drivers (!), research, prototyping, production and anything else Microsoft can convince you to use .NET for. My own company is trashing a million lines of realtime embedded medical software because Microsoft has sold them on the .NET Kool-Aid.

Re:What?

[maelstrom]

No, and no one is saying it should be. I love how people fail to distinguish between kernel and userland. In fact, most of the GUI admin tools for Solaris ARE written in Java.

Re:When the baby came with instructions

[3770]

Deploy your applications with clickonce. Problem solved.

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

[jasondlee]

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.

Wait. Did you just say that notepad, mspaint, explorer, etc. work "just fine"?! Head. Spinning. Must. Lay. Down.

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

[jasondlee]

If I *have* to use Windows, I use gvim to edit text files. Notepad is an *extremely* basic, no frills, almost no functionality text "editor." Given its feature set, to use "good" to describe it boggles my mind.

jason

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

[miffo.swe]

But really, Windows is filled with pure userland tools all over. You would have thunk at leastsome of the new ones would be made in .net, like on linux perhaps?

Funny that, that Linux use more .net than Microsoft itself.

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:What is it anyway?

[xiphoris]

It's not meant to be a virtual machine, although that's what its bytecode instruction set represents. A fundamental difference between .NET and Java is that .NET was designed from the beginning to be fully compiled natively before any execution. There is no .NET VM that interprets applications; they're always compiled natively.

Java is doing this now, too, but that was not the Java design from the beginning. Java actually was interpreted in a VM; .NET never has been.

Yes, yes, the .NET bytecode represents a VM. It has a stack and instruction and such things. But nothing actually ever executes that. It's only ever translated to native.

Your sig is a lie

[xiphoris]

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.

Re:Your sig is a lie

[sik0fewl]

Of course, in they way they are most often [mis]used, affect is a verb and effect is a noun.

Re:Your sig is a lie

[uradu]

You've got it exactly backwards, but there's probably no convincing you.

(Dictionary.com: effect, affect)

Re:Your sig is a lie

[Tim C]

Anyway, please change your sig. It's bad to spread misinformation.

If you feel like that, how can you stand to read slashdot?

It seems to me that Java is another example.

[Futurepower(R)]

Companies like Microsoft and Sun have always provided easily de-compiled languages for others to use, and not used them themselves.

(The links provided are just the first listed for the searches ".NET De-compile" and "Java De-compile". There are many de-compilers, and the ones linked are not necessarily the best.)

--
Movie claims overthrow of the U.S. government: Loose Change, 2nd Edition.

bad PR but good SE

[penguin-collective]

It's bad PR that Microsoft isn't using it .NET more aggressively in Vista, but it's also good software engineering: it doesn't make sense to rewrite large amounts of mostly working code, in particular when a company is already years behind on its schedule. Still, it would make sense for them to start moving some services over to .NET, like personal web server, FTP, and a few others, not just to spread .NET, but also to make them more robust and secure.

None of this has any bearing on whether it's a good idea to use .NET for new services or applications--it is.

The primary market for .NET will initially be custom software development, where it has big advantages. That's the place where software like Cocoa started as well; it takes many years for a platform to become mainstream after such beginnings.

so i've heard

[Anonymous Coward]

I've heard a few rumors that MS has already gotten pretty far with the .Net successor. We will see a V3 .net, but after that something different. Rumor also is that efforts that would be going into Vista .Net is being put into the successor. If you look at history, it took a while for MS to really fully embrace com as part of the OS, but when they did, it was fairly complete. Here we are in V2 of .Net and there are several huge missing pieces (WIA, full DirectX, still poor web app dev support etc) so you kind of have to assume it (.Net) is a stop gap. At least that is what I'm hearing.

Re:.NET is for rapid app development

[SeeMyNuts!]

Sorry, but .NET is not a RAD language. Lisp is a RAD language.

I used to work with a couple of Lisp developers, and their productivity was probably 10 times mine.

Power is cheap, time is expensive.

[daemonenwind]

Why would someone sacrifice application performance for ease of development?

Here's a reality check for you:
Suppose you have a semi-large development task ahead of your team. In .net, you can create the code and have it working with 1200 developer hours, with standard C code it can be done in about 1400.

Those extra 200 hours are charged to your department at $45/hour internally. Which means that the extra development time necessary to extend/create new libraries and start "from scratch" instead of using the .net framework is $9000. That's a pretty decent server to handle the extra load.

Quite simply, hardware is cheaper than developer time. That's the driver - overall cost to create and maintain your application. NOT overall performance, unless the difference is so significant that the hardware cost to make up the difference would be astronomical.

You want to understand the allure of .net? It's right there.

One more thing...I stole the following shamelessly from MS's .net website:
Microsoft .NET is the Microsoft strategy for connecting systems, information, and devices through Web services so people can collaborate and communicate more effectively.

So...you want to write an OS as a web service? Here's a question for you: What are you going to run your OS service on? I guess that means you want Microsoft to have an OS for their OS!

Duh indeed.

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.

actually, I rather like notepad

[Phil Urich]

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.

And sure, Microsoft should be working on some snazzier looking basic apps, and writing them to showcase .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.

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.

Re:actually, I rather like notepad

[Jason Earl]

I don't mind that notepad.exe is a pure text editor. What I mind is that it is the stupidest text editor ever. For example, at the very least it could deal with UNIX and Mac style text files intelligently. I mean seriously, how much is that to ask?

Re:actually, I rather like notepad

[st1d]

Quite a lot from a company that's desperate to kill off both. I think the parent was referring to the fact that notepad hasn't progressed much from the days when gui-based copy/paste was the new great idea. Other editors are nearly as small as, if not smaller than notepad, yet include editing features that make using them so much more efficient. Granted, I can't see too many MS users fondly glossing over an MS version of vi, but MS could do better, and I agree with the poster that suggested MS could probably just ask for someone to donate one, and somebody probably would happily offer it up, costing MS nothing.

The only upside for MS for not doing so might be that leaving users with a painful editor discourages them from making changes to text/config files, saving MS from potential support problems, and more importantly, keeping Windows users clueless about how computers work. You know, like other "improvements" they've made, hiding the shell, reducing shell functionality, removing command line tools, etc.

You could say MS likes to keep it's users uneducated, barefoot and pregnant. That way they won't stray. :)

Re:actually, I rather like notepad

[Jason Earl]

That almost makes sense. Microsoft has a crappy text editor because they don't want people to actually edit text.

they did have managed code, but pulled it out

[owenomalley]

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.

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.

the obsession with the V in front of the M

[Hooya]

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

Re:the obsession with the V in front of the M

[esme]

first, in todays day and age, what is not facing the web?

it's not that there are a lot of apps that don't use the web, it's that they should be isolated from each other. my web browser generally only needs to write files in one or two directories (cache, downloads). ditto for my email client. my browser shouldn't be able to delete my email. my email client shouldn't be able to wipe my whole home dir. etc.

people like to say that linux and macosx are inherently more secure than windows because of user separation. but all of the data i care about is owned by my user account and could be deleted by my browser or email client (given the right vulnerability), because they both have uneccessary access to the filesystem.

-esme

Re:the obsession with the V in front of the M

[ultranova]

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.

Some of us use multitasking. It would be annoying to have the whole machine crash every time Nautilus hiccups over something ;(. Besides, it is much faster to just restart the app rather than the whole machine.

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.

Re:Because .NET is effectively open source

[DrXym]

It's easy to decompile HTML, JavaScript, Java, Python, Ruby, Perl etc. too. I've even browsed through code MS used for their "Active" desktop around IE4.0 because it was all HTML, JS & VBS.

Anyway, source for some user-land tools such as Wordpad & Notepad (two candidates for replacement) are already available and part of MS Developer Studio sample code. So I hardly see the harm from being able to decompile a .NET app equivalent. Besides, if you or they were absolutely paranoid about people decompiling your code, you run it through an obfuscator first. Then all of the property names, symbols, code etc. get scrambled around and given random names making it pretty much impossible to follow what is going on.

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.

Reasons I can think of

[rikkus-x]

1. Large parts of Vista are built on existing code. If something's not broken, you don't rewrite it from scratch just so that you can say that you're using the latest and greatest technology. Not if you're smart, anyway.
2. Windows Forms applications feel slightly sluggish and start slower than native - even for very simple applications.

Re:Of Course!

[Profound]

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.

Re:Do as I say, not as I do?

[soulhuntre]

Or could you just not resist yet another cheap, meaningless shot?

You must be new here :)

Disappointing. I think we deserve better.

[appdev]

There are some very legitimate reasons for us to look to Microsoft to use .Net extensively in their own products, including parts of the OS.

Readers here have seen the "dogfooding" idea, and have seen lots of arguments for why this makes sense in terms of getting requirements and design right. For a framework as sweeping and critical as .Net, that means real use in real apps by Microsoft. Now.

I don't think there are too many people who would expect low-level code to be written in .Net (kernel, drivers, etc.). But lots of stuff in a modern OS distribution is really bundled applications. As "JSD" pointed out, components like Outlook Express are bundled applications, not core OS components. Survey 1000 people and ask if they'd rather have sucure, bug-free browsing and email or have Outlook Express run 2% faster. Anyone have any doubt at all about the results?

Besides, the argument that unmanaged code is faster than managed code falls pretty flat on me. I completely agree that a good coder should be able to beat .Net with C++, but one of the reasons for a framework like .Net is that you want to make most apps perform very well, rather than just a few apps perform exceptionally well, and the rest run like crap or never get finished at all. A reasonably competent developer should be able to pick up a framework like .Net and use objects and data structures that are already developed, tested, and optimized. The reult may not be as fast as recoding the exact right algorithm in a native language, but for most developers and most development, they're going to end up with a better app than if they'd written it from scratch. That's why we use high-level languages, folks.

I think what this really points to is a combination of two factors, both of which are a little unsettling.

First, Microsoft is subject to the same product planning dynamics as the rest of us. For existing code and existing apps, virtually any incremental change will be more economical and less risky when built on an existing code base. Even the iffy cases will *appear* less risky when built on an existing code base. In order to undertake an architectural change, you have to have a pretty compelling reason to do so, and a good bit of courage to shelve the old stuff and move forward. This hasn't happened in a meaningful way in Vista.

Why is this disturbing? Simple. This points to the depth of reengineering that's going into making the OS and apps more stable and more secure. Very often, the right thing to do when fixing a bug is to find the specific pinprick in the code and patch it. Sometimes, however, when you start to accumulate enough bugs in one place, you have to consider whether there's a systemic problem in that area. In those cases, the only way to stop the bugs for good is to fix them systemically -- ie, to re-engineer that part of the app. If this is happening anywhere in the Vista code base, why wouldn't it be happening on .Net?

Which brings me to disturbing point #2. The release date for .Net 1.0 was what - 2002? And it's not like it snuck up on anyone. Let's give MS the benefit of the doubt and say that they all knew about it in 2000 / 2001, so it's been five years, easy. That's plenty of time to work out the bugs in a framework that they expect the rest of the world to build apps with. We've had the .1 releases, and we've had the hotfixes and service packs. It's got to be production-ready now, right? So why isn't it showing up in more of MS's own distributions?

It's either because any MS OS release is really a bunch of pretty small changes scattered across a staggering number of individual files and components such that MS can't justify rewriting any of the components, or because MS has, as Grimes concludes, lost confidence in .Net.

I'm a fan of .Net. I'd like to see it succeed. One of the critical factors for its success is for it to reach a critical mass. It's time for MS to step up and help .Net hit that critical mass.

Notepad *has* changed

[DrSkwid]

It no longer has a 64k file size restriction and now lets you have extensions that are not .txt.