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

[DarkOx]

The thing is you probably would still have to worry about stuff like that. DotNet, JVM, type sandboxes as well as purely interpreted stuff like dialect, python, ruby, etc... only provide protection against that type of thing provided you don't go calling unmanaged code or still worse passing data back and forth with unmanaged code. One little call to WINAPI and it might be all over. Now you have throw often goofy pointer handeling/emulation of these enviornments into the mix along with the syscalls its almost as dangerouse as it ever was. Sure most of the code is mannaged and you have fewer points of entry for attack but when you write mannaged code you don't check the bonds on that array because you should not have to but what if something got changed when things were not managed no nobody is even looking most likely not the code and certainly not the managed enviornment.

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

[this great guy]

<<
an operating system is supposed to be as efficient and speedy as possible.
>>

What do you mean by "is supposed to" ? Oh... you mean "has to". What OS are you using again ?

Re:Well DUH

[Anonymous Coward]

Replace .Net with Java and you're little 12 year old fanboy brain can figure it out...

VM code: Slow but speedy development
Native code: Fast but slow development

Sometimes you just need a solution that works, and sometimes you need the fastest and most compact execution possible.

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

[Anonymous Coward]

Replace .Net with Java and you're [sic] little 12 year old fanboy brain can figure it out...

Who said anything about Java?

Sometimes you just need a solution that works, and sometimes you need the fastest and most compact execution possible.

So you're saying that since neither the kernel nor userland apps were written in .Net, then the framework is not useful for any of those cases?

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

[Anonymous Coward]

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?

Same reason their web site relied on Unix for hosting for soooo long. M$ makes crap and then expects you to use it, but they are smart enough to use something else that works! .Net is crap! SO, move along, nothing to see here!! heh

Re:Well DUH

[yabos]

They can't even get the OS out in time, they shouldn't be expected to port all their apps to .NET as well, especially because they don't gain anything by doing it.

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

[techno-vampire]

I'm sure attacks would still be possible, but at least we wouldn't have to worry about buffer overflows causing problems.

Putting your applications in a sandbox to protect against buffer overflows is a bandaid approach. The way you protect against buffer overflows is by writing the code properly in the first place, instead of hard-coding the buffer sizes in so that skript kiddies can send longer and longer strings into them until they overflow.

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

[ZenShadow]

Array Bondage?

Is this some new fetish thing that I'm unaware of?

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

[CtlAtlDelete]

I'll stipulate your point - it doesn't make sense to rewrite existing apps just to showcase the technologies you want your customers to use. But how about writing some of the newer apps using .Net? MS Antispyware and MS Defender were good candidates as these are recent add-ons developed by MS. I'd be more likely to use these tools if I thought that MS had enough trust in them to use .Net in it's own software.

Re:Well DUH

[NitsujTPU]

You can find out for yourself. That's essentially what a microkernel operating system does.

There are exceptions, understand this, I don't need a bunch of "no, it's called a microkernel because it has a small kernel," replies.

Anyway, in general, the design philosphy on a microkernel OS has been to provide as much separation as possible between programs running on the OS. A quick run thorugh of the literature will show you this design philosophy, and point you to plenty of operating systems that follow it.

Re:Well DUH

[NitsujTPU]

I should caveat that what I meant is that a microkernel OS provides that separation, not that it (necessarily) involves running managed code.

Re:Well DUH

[Anonymous Coward]

The phrase "a lot" is two words, not one!

Re:Well DUH

[fupeg]

This is a good point. Concurrent development of a framework and apps that run on that framework is extremely difficult and can cause a lot of internal frustrations.

Re:Well DUH

[plover]

There are different levels of .NET safety. Only "pure" code is considered safe, and that's code that is 100% MSIL. Calling the Win32 API via any mechanism other than through the framework class libraries, or linking any native x86 code will result in your assembly not being compilable as pure. Any "back and forth" between MSIL and x86 or "unsafe" practices such as pointer math is verboten.

The deal with MSIL is that they run it through a verifier. Only things that have appropriate permissions can do restricted stuff -- your company might want a policy that prohibits you from writing to any folder other than "My Documents", for example, and they may prohibit any code existing in "My Documents" from being executed. No more spyware, no more browser-based attacks. Assuming it's all verified .NET code, that is.

[ warning: descending into speculative anti-MS, anti-.NET rant here ]

Once enough of the business world has their code ported to .NET, MS intends for Info Security groups to swoop through corporations turning on all these wonderous restrictions that will keep the corporate computers safe. [ *cough* ]

Well, that's their plan, anyway. It goes hand-in-glove with the TCPA and unTrustworthy Computing. Ultimately only pure code will get signed, and only signed code will be allowed to run. Oh, and while they're at it, only official, currently-licensed copies of Word, Excel, Office, Outlook, etc., will be permitted to run. Have you tithed Bill this month? Well, let's just check the records before we let you go running Word now, shall we? Hmm... that copy of Access looks like it's about to expire. You might want to have your boss pay the license bills a little quicker next month.

Re:Well DUH

[Major Wedgie]

So you really would expect that MS would take the time (aka spend the money) to rewrite already-working applications, such as notepad, paint, and regedit, just because you want to see .Net in action?

Re:Well DUH

[Skreems]

For the record, SQL 2005 lets you run C# code across your DBs. Used in the right context (processing one entry at a time), it's light years faster than standard queries. So there are already some things that it's being used for, and quite well too.

Re:Well DUH

[accident]

They have never shiped any substantial application in VB either, and its been around over a decade!

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

[Onan]

VM code: Slow but speedy development
Native code: Fast but slow development

Sometimes you just need a solution that works, and sometimes you need the fastest and most compact execution possible.

So you're asserting that Microsoft's big problem with Visthorn is that they have too much developer time on their hands and not enough to accomplish, so they choose to burn extra work on making a super-speedy Notepad.exe?

Having a hard time buying it. I think that the case here is that writing to .net is not as easy and fast as Microsoft has been billing it as being. And in an attempt to actually ship something ever, they've given up on going through the contortions necessary to use it, and have fallen back to actually just writing bare code, which they feel they know how to do. (Despite evidence to the contrary.)

Re:Well DUH

[zyte]

In the triage meeting:
"So it seems there's this bug in terminal services where it's listening on port 80 for anything that feel like connecting and it will allow a malicious user to take full control of the computer. this is a priority 1, severity 1 bug."
"What about notepad though? we bitch at our customers to rewrite crap in .net, why don't we do it ourselves!"
"Oh shit guys! I forgot about that! Let's drop all this stupid security shit and get on rewriting notepad right now!"

Re:Well DUH

[st1d]

You might have just answered your own question. MS wanted developers to jump to .NET, and many did, but a fair number of developers are using Mono, which is something MS probably wasn't anticipating. It's probably a little simplistic, but maybe MS no longer wants to bank it's future on .NET because of the risk that it might actually make it easier for developers to move to Linux in the future. While the .NET/C# move seemed like a good way to push developers away from common "standards" like C/C++/Java, Mono short circuited the attempt by providing developers a way to develop for .NET without being entirely locked into MS's tool set or platform.

Re:Well DUH

[z4pp4]

Any programmer that used a VM based language knows that is B.S.

Compare:

strcpy(smallbuffer,bigstring); // C with size bigstring>smallbuffer >> buffer overflow
smallbuffer = bigstring; // Java with bigstring>smallbuffer : no overflow, smallbuffer garbage collected.
smallbuffer = bigstring; // C# with bigstring > smallbuffer : no overflow, smallbuffer garbage collected.
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.

Re:Well DUH

[nobodyman]

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.

I know this was more a bash of MS execs than the research department, but more stuff comes out of MS research than you might think. Microsoft spends a greater percentage of their funds on research than IBM, Sun, or Apple . Of the top of my head: there's .NET, C#, and matchmaking and TrueSkill systems used for Xbox Live.

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

[Xyde]

You're right, but actually the term "eating our own dogfood" was used in reference to Carbon, not Cocoa.

They built the Finder from scratch in Carbon, using no code from OS 9 to show that it was possible to write good apps with it and to encourage software vendors to port things from OS 9 to OS X. Ironically the Finder is probably one of the worst OS X apps to come from Apple at the moment, and desperately needs updating (although iTunes is an example of an excellent Carbon port.)

Re:Well DUH

[Anonymous Coward]

GNOME: More MicroSoft than MicroSoft (TM)

Re:Well DUH

[Jason Earl]

I suppose that's possible. However, it's pretty safe to say that Windows developers that don't work for Microsoft are already using .NET in large numbers. Unless Microsoft is worried that Novell is going to poach Microsoft employees it should simply use the best Microsoft tool for the job at hand. It's not like Microsoft employees are likely to wake up one day with a overpowering desire to port to Mono.

The folks using Mono think that it's a huge advantage over writing applications in C, and they should know, many of them have extensive C experience including the development of complex C applications like Evolution or Gnumeric. So why is it that Microsoft appears to be unconvinced?

Re:Well DUH

[Com2Kid]

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

Because the second you tried to loadup a C# notepad, mspaint, explorer.exe, taskmgr and regedit all at once, your computer would become too slow to use!

A minimum of 20 megs of ram per app, assuming that they are not actually DOING anything. If they actually do something, crud, heh, plan on a few hundred at least.

You know what? If I plopped down the cash for a gig of memory, I want to use it for something like video or photo editing, playing games, or SOMETHING that deserves to require memory.

As it is right now, Firefox eats up over 300MB (with page caching turned down to a hard limit of 5 pages total, still 300megs, wtf..), Eclipse apparently thinks that 70MB or so is ok, and VS.NET 2005 likes eating up a few hundred.

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

[jlarocco]

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?

Probably because most of their user-land apps are already written in C or C++ and working fine. It'd take months and tons of money to rewrite and retest all of Window's userland apps for .NET. What's the point?

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

[Boronx]

Am I the only nerd in the world that's gets annoyed when someone uses "win" for "good idea"?

Re:Well DUH

[pimpimpim]

You could make it a microkernel, and put all the device drivers outside of this, with very restricted and controlled functionality:
see: http://www.minix3.org/reliability.htm

There's other stuff out there, like eternal loop-catching etc. I just bounced into this a few days ago, and it looks interesting.

Re:Well DUH

[WillerZ]

Your VM-code is not equivalent to your C code. The C code attempts to make a copy of one string into another buffer, while your VM code copies a pointer.

The closest equivalent C to your VM examples is probably:

{
    void *tmpptr = smallbuffer;
    smallbuffer = bigstring;
    free (smallbuffer);
}

Although if *smallbuffer is statically allocated or other components have references to it the equivalent is:

    smallbuffer = bigstring;

Don't dis. what you don't understand.

Re:Well DUH

[Anonymous Coward]

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 We can't be sure of course, but the VB6 experience shows that we should be very wary of committing to Microsoft's technologies. The company I work for is faced with the huge cost of re-writing some big VB6 applications because of Microsoft's lack of commitment it's users. If you are developing in Visual Studio 2003/5, don't think that you will be able to just switch to Mono if Microsoft dumps it all. With regards to things being dumped, Java seems like a safer bet.

Re:Well DUH

[msobkow]

I think people need to remember that J2EE and .NET are designed for network-aware distributed applications with web, desktop, and peer clients. There is a lot of overhead that can come into play if you use the wrong features to solve a problem, and performance will be horrible.

Native code gets a bad run because a lot of vendors use do-it-all APIs that rely on void pointers or anonymous handles/ids and request numbers instead of using a lightweight code wrapper so programmers are dealing with a type-safe readable API. Other native code products have the same issue. The result is too many opportunities for a typo to creep in to the code.

If you don't require a distributed environment, need to maximize performance, and have the time to do extra code reviews and debugging, then native code is a better option.

Unfortunately most of Microsoft's desktop applications are network-enabled, even if they're not distributed. If native code used a sandboxed network API instead of the existing/older OS APIs, the attack opportunities might be reduced. Or the various OS and native library producers could just finally get around to removing the old APIs that didn't include buffer sizes (it's been over a decade since the issue was recognized -- plenty of time to have upgraded the cruft in old applications.)

Re:Well DUH

[Anonymous Coward]

Exactly. While ideal-case performance of Java and .NET applications is not much worse than C/C++, the worst-case performance (mainly caused by humongous memory usage) can be really bad.

So can startup time.

I remember testing C# ZipLib. It was about twice as slow (without startup time) than cygwin gzip (including it's startup time). Test file about 3MB.

Re:Well DUH

[chhupa_rustam]

Probably because all that code is already in place. Rewriting the kernel and basic system libraries/tools was the goal for Vista, for reasons of security and to add new features. There was no need to touch apps like notepad and paint, because their functionality/interfaces have not changed -- it would be silly to port them to .NET simply for the sake of porting them.

Re:Well DUH

[iGN97]

As others have pointed out, rewriting just for the sake of rewriting isn't good business. New applications from MS do use .NET; look at Sparkle, which is IMHO the coolest application they've released in recent years.

Re:Well DUH

[shrykk]

Am I the only nerd in the world that's gets annoyed when someone uses "win" for "good idea"?

Well, it's traditional, to the point that the (hilarious) GNU coding standards quoth:
Please don't use "win" as an abbreviation for Microsoft Windows in GNU software or documentation. In hacker terminology, calling something a "win" is a form of praise. If you wish to praise Microsoft Windows when speaking on your own, by all means do so, but not in GNU software. Usually we write the name "Windows" in full, but when brevity is very important (as in file names and sometimes symbol names), we abbreviate it to "w". For instance, the files and functions in Emacs that deal with Windows start with 'w32'.

Re:Well DUH

[Anonymous Coward]

Plus, MS have X programmers. Now, they can put all X programmers to work on issues which are hurting them at the moment (did anyone say security?), or they can take a percentage of X away to work on rewriting applications that people rarely use / don't care about / can easily replace with something better for the sake of...what? Proving their development environment. Sure, you'll earn some brownie points with a limited number of developers (yes, that's right, developers, not general users). But at the end of the day, who cares? (I would suggest very few people).

And don't forget, everything has an opportunity cost. They can't rewrite crappy applications in .Net without giving up on something else they could be spending their money on (and yes, that even applies if they increase their budget). Get over it. As the parent posst says "move along, nothing to see here".

Re:Well DUH

[Kanasta]

It just proves that porting is a pain even for rich giant co.s
Who has ever seen any major app ported from C++ to a modern language anyway?

The test is for NEW MS apps. These should popup soon enuf.

Re:Well DUH

[Sfing_ter]

They did, but then before they could release vista, the msdn came out with .Net2, and their previously finished coded projects would longer work... :) ... DOH!

Re:Well DUH

[gbjbaanb]

Your argument made me think of qmail. The author wanted it to be more secure than sendmail, and designed it to be secure. I think he has a large cash reward to anyone who finds a bug in it. And to date, no-one has ever found a security bug in it.

Similarly, Dovecot is a replacement pop3/imap server, similarly designed to be secure and it too has a monetary reward for anyone who can find a security bug.

So, the argument that even the best, most conscientious and meticulous coder will inadvertently introduce a security bug like a buffer overflow is just wrong. People have written code without these bugs (and these are publicly network-connected apps, written in C or C++) without security issues.

I think the problem is about design of the code - if you make it modular, you can better audit the smaller chunks to see how it works and where the flaws may be,m then you use better libraries to wrap around the parts you know may be problematic. You also handle data input and output with more care and you have a secure system even if you write it in the most low-level language.

Also, writing code in .NET just prevents *some* security errors like buffer-overflows. Other issues are not fixable (eg. if you don't secure your user-input data, someone will try to inject code)

Re:Well DUH

[DrXym]

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?

The simple answer is because .NET's performance is inferior to compiled code. .NET may be faster than VB6 but its performance is roughly the same as Java's. This equates to mediocre performance in client side application code. You probably wouldn't feel it in some dumb database query viewer, or in some moderately static UI, but you sure as hell would if you tried to implement a browser with it. MS could cheat of course and simply wrap an C++ coded browser engine in .NET but from my experience, that would give you the worst of two worlds - the overhead of .NET, and the instability / exploitability of C++. If you're going to use C++ in any substantial way you may as well stick with it throughout.

Personally I have no problems with client apps coded in .NET & Java but it's a case of the best tool for the job. Java & .NET work better in high latency environments (e.g. servers) where code execution time is dwarfed by network / database latency and the return in terms of stability more than pays for itself.

Re:Well DUH

[palndron]

I would have thought .net come more from visual j++ and thier java efforts morphing into thier own managed environment with the one-upper of having more than one language produce the IL.

Which would mean that it was SUN that did the r n d, and MS doing the "next step".

Guess I'm wrong.

Re:Well DUH

[z4pp4]

:) no dissing intended. I know the difference between pointer re-allocation and new object creation. What I intended to demonstrate was the different approaches one would take to achieve the same ends.. with a very specific demonstration. Of course if you want to nitpick, a another correct example of the equivalent C code to the Java code is:

char* bigstring = new char[256];
char* smallbuffer = new char[20];
delete smallbuffer;
smallbuffer = bigstring;
// .. and eventually
delete bigstring;

Although, some unexperienced programmers would simply use
strcpy(bigstring,smallbuffer);
What your response so eloquently also illustrates is that there are multiple interpretations to C code, where the interpretation variety to VM code is less.
To be quite honest, I've not programmed in C for a while..so it tends to be a bit rusty. My worst memory of C: Plugging a memory leak in the windows compilation of libnet.

Re:Well DUH

[callistra.moonshadow]

As a C/C++ as well as .NET developer I agree to a certain point. My larger area for concern comes from the fact that use of native code will add potential for speed, but what about use of poorly defined memory management in the unmanaged codebase? This is an over-simplification, yet many of the security flaws in the Windows operating systems in the past were due in no little part to the use of "unmanaged code." M$ is trying to make a more secure OS (at least that is the marketing line here) yet may be seen as treading the same path as they have done in prior versions of Windoze.

Re:Well DUH

[Alioth]

You sound just like the GNU libc developers who are arguing against including the BSD strl* functions. Their argument basically goes "Well, developers should write perfect code instead".

In the real world this DOES NOT happen. That's why OpenBSD has implemented things like W^X and compiled everything with ProPolice, have built a much safer malloc()/free() implementation and continue to audit their code time and time again. They recognise that they are not perfect, and make mistakes - so therefore having a defence against the inevitable mistakes is better than leaving their users vulnerable.

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

[ultranova]

Only things that have appropriate permissions can do restricted stuff -- your company might want a policy that prohibits you from writing to any folder other than "My Documents", for example, and they may prohibit any code existing in "My Documents" from being executed. No more spyware, no more browser-based attacks. Assuming it's all verified .NET code, that is.

And assuming that you turn all of the computers off for night. Because being unable to write files does not stop memory-resident programs, and if even one machine is on at all times, it can re-infect the others as soon as they are turned back on and log into the network.

Besides, a macro exploit (or simply a suitably malformed document to insert code to the program that opens it) can easily reside in "My Documents", even if it can officially contain no executable code.

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

[diegocgteleline.es]

If .NET is so cool why isn't Microsoft doing something similar?

Because Microsoft already has a lot of tools written in C++, and it'd be stupid to rewrite them just to "switch languages".

I'd expect that future developments will be done in C#, but why would Microsoft rewrite the whole OS in a new language for fun? Is that going to provide any new feature at all, except LOTS of work and new bugs?

Re:Well DUH

[LexMan]

The way for faster/efficient code (both application and OS) is through better algorithms, not by implementing the same algorithm more efficient.
The way for more reliable code is not by manually inserting numerous checks at every level, but to have a system that is reliable in it's foundations. These foundations are the place to do these checks always and efficient.
How fast is this efficient OS with all the malware software (anti-virus, anti-spyware, multi-level firewalls, other anti-X stuff to come) using cycles and memory?

Cutting corners doesn't speed anything up:
Not the development cycle, not the execution of code.
Taking the off-road shortcut makes your trip shorter, not faster, hell, not even shorter 'cause you need more trips to the repair shop.

Using a system of sandbox/managed code makes (should make) programmers more productive, having more time to think up better algortihms.

Not using .NET shows that:

• MS holds the same opinions as the parent
• The framework is not as good as promised
• It was only ment for luring away Java people
• (insert your favourite conspiracy theory here)

Re:Well DUH

[ultranova]

The closest equivalent C to your VM examples is probably:

{
void *tmpptr = smallbuffer;
smallbuffer = bigstring;
free (smallbuffer);
}

No. In Java, Strings aren't mutable. In C, arrays (C string is just a char array) are mutable. This means that, in Java, you can just assign the same String reference to a new variable, and be assured that it won't be changed by anyon; but in C, you cannot, you must allocate a new char array and copy the contents of the old one to it - after counting its lengt, of course. Oh, and even if you are certain that no one will alter bigstring, who is going to free it ?

C is inherently unsafe when using heap memory, there's just no way to get over it. Sure, you can make bug-free programs, but it takes more skill and carefull planning than doing them in Java, and that is pretty hard to do when deadline is nearing.

Re:Well DUH

[Anonymous Coward]

Uhm.

Try using ATI Control Panel made in .NET, then compare it to the normal .cpl control panel.

Which takes less resources? .NET is a resource hog and I'd rather see nothing at all using it.

It may look cool on your resume ".NET Developer" but until they get some performance out of it, hell no.

Re:Well DUH

[RalphSleigh]

I like notepad, you can use it to write text in, paste text you want to keep from other apps and edit html in a pinch. If you are feeling really fancy you can edit config files or view apache logs. -Ralph

Re:Well DUH

[swordfish666]

Exactly!!
You can build some kick-arse apps with .NET.
You can also build some kick-arse apps with JAVA.
But basing an OS on either of these on technologies is foolish!
Sure JavaOS was a good idea 4 years ago but it's never going to do the job C/C++ and the same goes for .NET and Miscrsoft knows that.

Re:Well DUH

[Anonymous Coward]

Posted anonymously because... well... I know stuff :)

This is exactly the reason. It impacted a lot of the business software teams (both Office and the enterprise business system groups) even more because they had code ready to ship before the framework was. .NET 2.0 was such a huge change over 1.x, it took them a while to get it out. The products they have available to users early at this point are not representative of how much it will be used in a year.

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

[Anonymous Coward]

The way you protect against buffer overflows is by writing the code properly in the first place

And be sure to look for the next installment of my "In The First Place" series, "The way to protect against automobile accidents is by not crashing into things in the first place."

Re:Well DUH

[yerfatma]

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

Re:Well DUH

[RetiredMidn]

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.

As a counter-example, I offer OS X's "Stickies" application, which has been around a long time but remains current with the OS X APIs.

Stuff like Notepad and Stickies serve multiple purposes; they have some genuine utility, but they can also showcase the platform and provide developers and users with ideas about the possibilities. IMHO, it's significant that Microsoft is slow to embrace the technologies that they present to the developers on the platform.

Back in the 80's, some Lotus 1-2-3 developers analyzed Excel and found it not to be using the very APIs that the Lotus developers were being encouraged to use. As Scotty said: "Fool me once, shame on you. Fool me twice, shame on me." Or something like that.

Re:Well DUH

[rbanffy]

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, I couldn't resist to say that Singularity sucks.

Re:Well DUH

[moro_666]

well checking your applications with valgrind never hurt anyone ...

i found valgrind extremely useful for tracking down memory allocation issues, some applications that are considered safe are not so safe at all when you "valgrind" them ...

look it up on google, i can't even remember the link since it's a packaga on debian/ubuntu just from the repository.

and you can use memory pools from which you allocate instead of manually mallocing all the time.

makepool;

do stuff;
allocate A through the pool;
do stuff;
allocate B through the pool;
do stuff;
free A;
do stuff

freepool;
# ditto we forgot to free B , but the pool knows it's
# allocated and free it for us ... ofcourse this creates a
# danger by itself if B's pointer travelled somewhere else
# outside the scope of this block ... but it's still usually
# better no free at all.

and C is always safe to use if it's used the right way, the user/programmer is the unsafe element :)

Re:Well DUH

[pla]

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.

...With apologies to Douglas Hofstadter,

Great Solution! In one fell swoop you've managed to eliminate all bugs that directly exploit vulnerabilities in the OS. This seems like such a wonderful accomplishment, it needs a name... How about Mu?

In the past, we've only had the ability to attack one bug at a time... B1, B2, B3, and so on. Sure, we've gotten better, and can now attack whole classes of bugs at once such as buffer overflows, RPC vulnerabilities and the like - Let's call those fixing B^2, B^3, and so on.

But this idea, why allow bugs to touch the OS at all? Keep 'em in a sandbox where they can't do any harm. Of course, eventually, someone will find a way to get this particular sandbox - Sorry, Mu - to execute arbitrary code (remember, "intelligent, conscientious, meticulous coders will still write code that has simple vulnerabilities"), which can then in turn exploit flaws in the underlying OS. But no doubt we can build a better sandbox, Mu-2, then Mu-3, and so on. Perhaps we can even sandbox whole schemas of attack, such as debuggers and DLL-injection. So we'll need Mu^2, Mu^3, Mu^4...

Hey, I have a great idea - Let's run the whole OS in a sandbox! I'll name this new Solution E(psilon). Certainly, no one could ever defeat so glorious a solution as E! Hmm, "E!", now that entirely coincidental bit of typography really makes me think...



Sandboxing reduces to an instance of the halting problem. No solution exists for the halting problem (Cantor's diagonal argument provides a fairly elegant proof of that).

Re:Well DUH

[MickDownUnder]

Well you really are speculating here. Garbage collection and memory mangement are entirely possible to implement in C++, what do you think .NET is developed in ? Or perhaps they have another VM (not .NET) on which they are developing Vista.... There are very few people around who could talk on this subject with absolute authority, and they would be architects working for Microsoft on vista.

Anyhow... Microsoft .NET is totally inappropriate for the task of implementing components within an OS. If you think otherwise you really don't understand it, or the strategy behind it... Try reading my other comment in this discussion.... That's my take on it.

Re:Well DUH

[High Hat]

And assuming that you turn all of the computers off for night. Because being unable to write files does not stop memory-resident programs, and if even one machine is on at all times, it can re-infect the others as soon as they are turned back on and log into the network.

But this would also require an OS-level exploit somewhere in the network stack or in the services (RPC comes to mind :)). Putting bigger parts of the system services into managed code would probably also reduce the number of bugs in those - it is much harder to make buffer-offerflow-type mistakes when you have mandatory bounds checking.

Besides, a macro exploit (or simply a suitably malformed document to insert code to the program that opens it) can easily reside in "My Documents", even if it can officially contain no executable code.

This is of course true, but then what kind of damage can the macro exploit, which will most probably still be running on the VM cause? If you don't stack multiple exploits you won't be able to do much damage to the system, only to the user's files. There's backups for that. No hooking into the registry, no starting automatically at boot and no modifying of other installed Programs.

This makes it much easier to get rid of malware, simply reboot and run a removal tool before opening any documents.

Re:Well DUH

[RingDev]

Simple, those apps already work, and work well. Why would MS invest hundreds of thousands of dollars to re-write MSPaint in .Net when 1) the unmanaged version has worked fine for years, 2) the demand for MSPaint is tiny, 3) they are working on a full fledge image editing suit.

Using the same logic, have you replaced the engine in your aging vehicle to a new hydrogen engine?

-Rick

Re:Well DUH

[Hosiah]

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"

Aye, there's the nut of the matter. The development tools that they give to their users should be just as good as the ones that they use themselves! But once again we have the Microsoft feifdom: "You're not good enough to use *real* tools. You're a stupid ape! We're going to keep you in a box and feed you scraps!" - they might as well print it right on the box.

Re:Well DUH

[Jason Earl]

If you read the article it would be pretty clear that early versions of Vista contained *more* .NET assemblies than the ones that Microsoft has released later. In fact, it would appear that Microsoft is rewriting new software that was originally written in .NET in "unmanaged" code.

I can understand not wanting to rewrite stuff that works, but apparently Microsoft actually attempted to write some new stuff in .NET and backed off.

Re:Well DUH

[Eivind Eklund]

I just read it, and my impression is that you don't understand security contexts and security design. I do OS development, I've worked as a security consultant doing similar things, I've studied the literature, etc.

One would DEFINATELY want OS components to run in a reduced security context. It's the POINT in least privilege - you run as close to everything as possible in a context with access reduced as far as possible. I don't know if the access control .NET use is detailed enough to make the restrictions that's possible really useful, as I've fairly much ignored .NET due to time constraints.

Also, "garbage collection and memory management" has little to do with this - the issue close to this in C++ etc is the naked pointer support, and the ease of creating various forms of security errors (buffer overflows) using that. A virtualized system that's designed for security will avoid that problem. It will also be able to restrict other types of privilege, such as reading from files the user haven't opened in a system dialog box or drag-dropped onto a suitable graphical area.

While many other privilege restrictions could theoretically be done in C++, it would require removing the old APIs and creating new ones. I don't believe MS has done that, nor do I believe they've created *yet another* virtual machine when they have a decent one already.

Eivind.

Re:Well DUH

[MickDownUnder]

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?

Well... They're currently implementing Office using .NET...

I've also seen a MSDN .NET show where one of the developers confirmed this. Office has been and will be for some time to come their #1 cash cow... I'd say that's commitment enough.

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.

As for .NET being replaced in a few years... I really doubt that, a few years from now .NET 3.0 is going to be released, I know this as I was in a meeting where they were presenting the new features that are going to be added to it. I can also say as a MS.NET developer, that Microsoft .NET is hugely popular and well liked by anyone who has spent time on it. I've yet to meet anyone who was negative on this architecture who has actually used it. There's nothing wrong with it, architecturely it's very well thought out. So I think basically you're talking totally on emotional grounds here with little or nothing to back it up.

I'm really quite amazed how highly such a stupid comment can be modded here simply because it's anti-Microsoft.

Re:Well DUH

[ckaminski]

You're solving the problem with the wrong solution. An OS should be able to implement sandboxes natively, we shouldn't need to rely on a VM to do it for us. Unix started this with chroot(), and has evolved into the capabilities model of SeLinux and Solaris Zones.

Re:Well DUH

[ultranova]

But this would also require an OS-level exploit somewhere in the network stack or in the services (RPC comes to mind :)).

Or it could be something as simple as a way to keep javascript/activex running after leaving the Web page - perhaps you could open the page in a hidden window or something ? Then simply read the address book and send spam to everyone in it. Make sure that those spam messages will also contain the neccessary HTML to keep the chain reaction going.

There's plenty of ways to abuse simple interoperability and integration without having to resort to buffer overflows.

This is of course true, but then what kind of damage can the macro exploit, which will most probably still be running on the VM cause?

Depends. Is there any way to send e-mail with the macro language ? Is there some common file server for shared documents that have read/write access ?

Neither VM nor programming skill can protect you from design flaws in programs. Microsoft has a tendency to integrate everything into a big mess, and as a result the possible interactions between the programs are endless - and because there are endless interactions, it is simply impossible for the designers to think of all the ways the system might be abused.

Re:Well DUH

[MickDownUnder]

You haven't ever developed applications using .NET have you ?

1.0 .NET is astoundingly bug free, it's well documented, things actually work the way they say they'll work, even the Beta's were pretty good, I was astounded to begin with. Anyhow .NET 2.0 has been out since december, I've only heard good things about the framework. Also I know for a fact .NET 2.0 was never linked to Vista in any way. .NET 3.0 will be released shortly after vista which shall incorporate many things into the framework that are currently seperate SDK's (on .NET 2.0)...

Anyhow yet another completely ignorant, highly modded comment on Slashdot...

Re:Well DUH

[bburdette]

What about Notepad? that piece of junk has been included with every version of windows since forever, and it hasn't improved one iota. Can microsoft really not spare five minutes for somebody to make a better version of notepad?

Re:Well DUH

[baadger]

I can hear you all saying... but Java and Flash are cross platform.

Yeah except there isn't 64-bit build of Flash to be found and Java on FreeBSD Java is a mess.

Re:Well DUH

[mmeister]

Is Microsoft supposed to completely rewrite all of their already working software?

Not ALL, but at least SOME applications!

Outlook Express was a major rewrite, but apparently is not using .NET. To me, that says that Microsoft is unwilling to eat its own dog food, period. They had an application that was essentially retooled and they chose not use the tools they claim make it faster to develop and more secure. I'm sure there are other examples.

I compare this with Apple, which pushes Cocoa/Obj-C and does use it for many of their applications, including Pages, Keynote, iPhoto, iMovie, iWeb, iDVD, Apple Mail, and Address Book -- just to name a few.

Re:Well DUH

[Alef]

What you want is an operating system that employs the principle of least privilege, something most operating systems have been lacking far too long by now (imho). That combined with a tiny and extremely closely analysed micro-kernel would yield a very secure OS.

In fact, this is what the Coyotos project aims at. I'm sure there are others as well. What is interesting with Coyotos however is that they are implementing the kernel in a programming language (BitC) that allows them to formally verify security and correctness properties.

Re:Well DUH

[MickDownUnder]

as I've fairly much ignored .NET due to time constraints

OK so you admit you don't know what you're talking about.

Well I can tell you didn't read my comment, so I'll repeat some of it for you.... I know .NET, it is for application development. It exposes the OS resources and services in a sandboxed environment, to allow untrusted applications to run without full trust and full access to the operating system. Basically it's the gateway / conduit for applications running on windows to the outside world.

Also, "garbage collection and memory management" has little to do with this - the issue close to this in C++ etc is the naked pointer support, and the ease of creating various forms of security errors (buffer overflows) using that.

*Cough* Ummm you smoking crack or something ? What else does garbage collection and memory management have to do with other than eliminating the use of naked pointers, and eliminating buffer overflows ? Anyhow my point was that people have been working with C++ libraries out that do garbage collection and memory management in C++ for years specifically to remove the use of naked pointrs and buffer overflows from their code. I would actually bet that Microsoft is actually doing this in their C++ development..... Any C++ developer out their with half a clue knows about this stuff.

Re:Well DUH

[tau-lepton]

It's called "eating your own dogfood" - See 'Inside Windows NT'. David Cutler, genius and madman, insisted that NT developers start using the alpha versions of NT as their development environment; thousands of bugs were found and fixed. Having developed with .Net 1.1 and 2.0, I can tell you that there are many bugs and much missing functionality in the framework. It is virtually impossible to write a non-trivial .Net application without resorting to un-managed code. If Microsoft had to implement Excel or Word in .Net then many of the bugs and missing functionality in .Net would probably be found and fixed quickly. Organizations that don't develop with the same tools that they provide have little credibility in my mind.

Re:Well DUH

[sfontain]

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.

That's funny; this is exactly what a lot of people said about .Net four years ago when it was released...

Re:Well DUH

[MickDownUnder]

I think Java is all but buried as a client side technology, and Microsoft is currently handing out the spades to bury flash.

And I say bring it on... I've always hated flash and always will.... Microsoft's Expression suite will totally kick ass over flash, hooking in the power of Direct-X and C#, into an idiot proof suite of tools.

Re:Well DUH

[TheOtherChimeraTwin]

Is Microsoft supposed to completely rewrite all of their already working software?

Good point, Solitaire and Notepad are good to go.

Re:Well DUH

[Anonymous Coward]

It's funny though. Microsoft has a history of sticking stubburnly by some of their bad decisions, and the original decision to use .NET sounds like the kind of thing they would be stubburn about since they just love telling us how wonderful it is and why we should stop using alternatives immediately.

Re:Well DUH

[techno-vampire]

Writing unexploitable code is great, but it needs to be executed perfectly by every single developer, writing every single line of code, forever.

Writing code that's not vulnerable to buffer overflows is trivial. Either you check the input size before allocating your buffer, or you have a fixed buffer, and throw away anything that doesn't fit. Hard-coding the buffer size in, especially after it's been proven time and again to be bad coding is just plain stupid.

Re:Well DUH

[Eivind Eklund]

I don't do C++, it's 10 years since I last had to use that language for anything serious. The point of GC and memory management is in general a few things: (A) decreasing programmer load, (B) allowing the design of reasonable APIs (as Meyer says, a language without GC isn't an OO language, and I halfway agree with him), (C) Increased performance (depending on what kind of memory management we're talking about). Avoiding buffer overflows is an almost completely separate issue. I don't doubt there are libraries that does this for C++ and they may use GC as an enabling technology, yet these are still very separate issues. Are you smoking crack or something?

And I read your comment, and the point I was making (which you jumped across) was LEAST PRIVILEGE. Read again: LEAST PRIVILEGE. And again: LEAST PRIVILEGE. This means RESTRICTING ALL PROGRAMS AS MUCH AS POSSIBLE. I'm uppercasing so you can see this through the crack smoke. In LEAST PRIVILEGE, ALL APPLICATIONS ARE UNTRUSTED. Yes, that is it: All Applications Are UNTRUSTED. They get only as much access as they have to have. They are ALL sandboxed as much as possible. That means that to be implemented as LEAST PRIVILEGE, all applications that CAN be managed SHOULD be managed. It also means that those that can run with a more restrictive security policy run with a more restrictive security policy. This would fit fairly nicely with the "Evidence based security" that MS is talking about, and it would include not giving evidence of higher trust than is absolutely needed for each piece.

Eivind.

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.

Re:Well DUH

[Anonymous Coward]

damn, you're dumb

why am I still reading slashdot?

Re:Well DUH

[techno-vampire]

What if thinking leads to communism and failure.

What nonsense! "What if" thinking leads you to find ways people can misuse your code, either with malice or from simple error, and helps you protect it. Refusual to do this is the "in a perfect world..." syndrome that refuses to check for errors because people shouldn't be making them. Properly written code validates input, including length, if you're accepting a string, and avoids foolish things like buffer overflows.

Re:Well DUH

[techno-vampire]

How hard would it be for MicroSith to have somebody write a function that accepts input and returns it in a buffer, properly sized? How hard would it be for MicroSith to include a spec that each buffer so allocated is released when not needed? How hard would it be for everybody to use that function? BANG! Buffer overflows go away. No need for everybody to write perfect code, just everybody using the same, well-tested function instead of rolling their own and getting it wrong time after time. Buffer overflows are easy to avoid, if you do it right. Clearly, MicroSith code monkeys do it the easy way, not the right way, so let's make it easy for them to get it right!

Re:Well DUH

[Verity_Crux]

And, yeah, MS Paint. There's a beauty of a program. Whatever you do, don't rewrite that one! I like the Windows 3.0 look and feel of it.

Re:Well DUH

[dzfoo]

>> What if thinking leads to communism and failure.

Then successful stupidity leads to democracy.

        -dZ.

Re:Well DUH

[dzfoo]

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

Perhaps for the same reasons why they don't push VB as the development platform for *every* Windows application developer: It has its purpose and its place in the development tools universe, but I cannot imagine MS asking game developers and system tools developers to switch to, say, VB.NET from VisualC++, just because it is their new fangled thang.

That said, I do agree that it seems like Microsoft is not "eating its own dog food", yet I fail to see this particular argument as proof of it.

        -dZ.

Re:Well DUH

[jauren]

In Vista, sound and graphic drivers are moving out of the kernel.

Re:Well DUH

[AstroDrabb]

The simple answer is because .NET's performance is inferior to compiled code.

Maybe in pure number crunching. However I find Mono/.Net to be fast and the memory foot print is not bad. Subjectively I think the apps I run with Mono are faster than equivelent Java apps and non-subjectively they use a whole lot less memory.

I use Linux for my desktop at home and use Mono for some apps. I develop C#/.Net on MS Windows at work. When I fire up F-Spot with Mono on Linux it starts up in about 2 seconds tops.

Re:Well DUH

[Richard Steiner]

They didn't improve COMMAND.COM in MS-DOS in over a decade...so why are you surprised that the pattern continues with Windows? Only potential profit centers receive attention.

Re:Well DUH

[Coryoth]

I'm very impressed with MS research - they have some great people there doing amazing things. I'm depressed by MS corporate which, like a great many corporate divisions of companies, seems to fail to actually listen to the research department have to say. Sure you'll see them grab onto various bits and pieces of research work, but often the intent will get destroyed in the product development phase, or the item piked will be some small minr easily implementable thing. In the meantime the big, useful, significant ideas simply get ignored as inconvenient.

This is not a problem of MS, this is a problem generally - a lot of companies have a big well funded research team because it's good PR, but fail to really listen to anything that team has to say because it would mean (1) learning enough to understand some of their more complicated points (2) re-evaluating various key products.

Jedidiah.

Re:Well DUH

[Slime-dogg]

Funny, how Novell is writing a ton of stuff for .NET... They are so chained to Windows!

Re:Well DUH

[DrSkwid]

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

At first glance these will not look like old school html to me, they will look like a big square with "download plugin" or some such in the middle.

> I can hear you all saying... but Java and Flash are cross platform.

They are cross platform round here, blank squares are easy to draw.

> Like Java and Flash, .NET to some is going to increasingly become more cross platform, it's been designed that way from the outset.

When is the plan9 version slated for release ?

Re:Well DUH

[plover]

I certainly am not arguing that Microsoft has created swiss cheese in the past. Their track record is long and ugly.

What they're doing with .NET is making the sandbox completely policy driven. Let's say that a trojan in a Word document sends a bunch of spam emails. The administrator can specifically turn off the permission to "send email from application X" or "send email from any application other than Outlook" or "require human confirmation before sending email from any application other than Outlook."

So that's the rose-colored glasses view that they're selling to companies.

Reality is likely to be a bit different. The Microsoft people I've talked to have shown no ability to differentiate between "security policies" and "computer security". They run around and say "if you change John's logon to prevent him from using DCOM to sending emails he can't get a spammer worm." That's a policy. The worm, of course, isn't going to care about DCOM. It doesn't stop the worm from opening a socket to the local SMTP server and writing "from: spammer@cheapdrugs.com / to: spammee@unlucky.net".

This is an attempt by the more security-wise OS teams to impose restrictions on the security-unwise application teams. It certainly can help reduce the problem -- if it's adopted. But the adoption will come with a price. DRM gets to be a policy, just like security. I'm saying "no" to Vista until I see what can be turned off.

Re:Well DUH

[DrSkwid]

What's wrong with edit.com ?

Re:Well DUH

[z4pp4]

How many overworked and underpaid programmers are there out there that wouldn't give a sh1t if their code conforms to security measures just as long as their pay comes in and they stay out of trouble?
How many of those programmers to you trust to code for your system, people you have never met?
Yes, sloppy programming is bad, but in a commercial context with non-open source software this cannot be always monitored and controlled.
VM's are like the airbags in your car. You hardly notice them. But you are glad that they are around when the fit hits the shan.
Even MS-win and Ubuntu had vulns that were only recently discovered that has been around for a while. 90% of these Vulns were exploited because of simple buffer overflows caused by sloppy C programming.
Not all org's can afford top notch programmers, so the best approach is to implement systems that limits the amount of damage that they can do. Hence VM's.
Buffer overflows are only easy to prevent in C if you know the difference between strcpy() and strncpy() and a whole bunch of other functions. In Java and C# you do not even have to bother.
C'mon, remember the article on the Internet along the lines of Real men use Fortran, sissies use Pascal? Standards have indeed dropped and are dropping every day. It is not the people but the systems that are in control.

Re:Well DUH

[Alioth]

Unfortunately it isn't that simple. If you did that, the programmer could still write buggy code that can overflow the returned buffer. Additionally, it would have a vast impact on performance since you'd no longer be passing things by reference (instead copying whole buffers around, and you can still get buffer sizes wrong).

A better approach for Microsoft would be to take the approach the OpenBSD developers take - build the operating system with something similar to W^X and ProPolice, have a safer malloc/free implementation - and effectively neuter buffer overflows. They can still happen but instead of allowing code injection, just cause the program with the bug to crash (so the machine doesn't get compromised).

Also if the Microsoft C compiler and associated tools gave warnings every time someone used one of the rather naive C functions (like strcpy) which don't do any bounds checking, it might help.

Re:Well DUH

[Anonymous Coward]

Sandboxing reduces to an instance of the halting problem.

No it doesn't. You can, in theory, prove that a particular sandbox running on a particular OS is secure. And then the sandbox can run arbitrary code securely.

Yes, this would be hard, but that doesn't mean it's impossible.

Re:Well DUH

[Onan]

Your argument made me think of qmail. The author wanted it to be more secure than sendmail, and designed it to be secure. I think he has a large cash reward to anyone who finds a bug in it. And to date, no-one has ever found a security bug in it.

qmail is an interesting case. Yes, djb's code can be at least arguably described as bug-free. (That's at least partially because he's refused to add any new features, which results in many people applying third-party patches to it, which then introduce bugs.)

But one of the big architectural decisions of qmail was to use compartmentalization very aggressively. The actual parts that run with elevated privileges are quite tiny. This seems like another example of the model I was advocating: centralize most of your security risk in a relatively small amount of code, which you then have a shot at auditing comprehensively.

Doing this at the application layer not only has all the usual downsides of doing anything at the application layer, but is antithetical to the whole model. eg, djb has written his own security compartmentalization, openssh has written their own privsep, and so on. So it seems like a reasonable next step that this should be a service provided by the platform, thus reducing the total quantity of extra-critical code even further.

Re:Well DUH

[pla]

You can, in theory, prove that a particular sandbox running on a particular OS is secure.

Cantor's diagonal argument doesn't reduce the problem to a proof-by-divine-intervention. Humans do not have a magical exemption from the halting problem, just that we currently have better hardware for solving certain classes of "hard" problems. We can make better (meta^x)schemas than today's computers can. But problems still exist that we not only cannot solve, but we can't tell if we can ever solve them... Amusingly enough, you can consider this the halting problem applied to human problem-solving - For example, will an infinite number of mathematicians working for an infinite amount of time ever find a perfect prime-generating algorithm? If someone finds one tomorrow, we'll have a good solid answer of "yes". If we still don't have one a billion years from now, we'll still only have a solid "I don't know".


Extending this to sandboxing gets tricky, in that you need to decide what exactly you want the sandbox to protect you from (and even the "you" counts as an assumption, in the sense that DRM uses a form of sandboxing to protects itself from the user). You can indeed construct a proveably secure sandbox - It throws away all inputs and has no internal state. For anything "useful", in the sense that it allows almost all of the functionality of a modern computer while preventing anything "bad" from happening, you just can't do it - This situation reduces to requiring a telepathic interface to know whether or not the user intended to perform foo. This situation describes one of the basic flaws of DRM, in trying to allow all legal uses of protected content while block all illegal ones: If I make a copy of a non-protected CD as a backup, I have acted within my legal rights; If I perform the exact same steps but then sell the original, I have infringed the copyright on that CD.


Now, all of the above doesn't make sandboxing useless... I use it myself in a number of common situations (my web browser, for example, runs under a virtual machine). But when you start to trust the security of your sandbox as more than a mere convenience, you will eventually find a bullet-shaped hole in your foot, you just won't see the gun anywhere.

Re:Well DUH

[techno-vampire]

One way or another, we both agree that something needs to be done about buffer overflows and that if it's done right, a sandbox isn't needed. (I think we agree on that last.) As far as the programmer carelessly going past the end of buffer, that's just as true now, and not (as far as I know) a vector for malicious code. It's also something much more likely to be caught during testing, rather than in production. I wonder how much all this trouble comes from "we've always done it this way" being more important than "let's find the best way to do it."

Re:Well DUH

[FrostedChaos]

>> You can, in theory, prove that a particular sandbox running on a particular OS is secure.

> Cantor's diagonal argument doesn't reduce the problem to a proof-by-divine-intervention.
> Humans do not have a magical exemption from the halting problem, just that we currently
> have better hardware for solving certain classes of "hard" problems. We can make better
> (meta^x)schemas than today's computers can. But problems still exist that we not only
> cannot solve, but we can't tell if we can ever solve them...

Don't confuse the halting problem with the statement that "proving code correct is impossible." There's a large amount of code that has been proven correct. There's even a project at Carnegie Mellon to construct a provably correct TCP/IP stack...

Also, as developers move away from older languages like C and C++, and towards more abstract languages like Java and C#, certain classes of careless errors become impossible to make. Buffer overflows and other memory corruptions are the most high-profile, but there's a lot of more obscure errors like failing to include a virtual destructor in a virtual class in C++.

There is also a growing acknowledgement of the importance of having a good security model.
There's been a lot of research in the field of operating systems on this topic.
The basic idea is that the operating system should use "capabilities" rather than "permissions."
With "permissions," a given user runs code, and the code gets to do whatever actions that user has permission to do. So if he is root, or Administrator, he can wipe the hard disk, send emails, etc. With "capabilities," the user chooses which abilities to give to the code he runs. Then, this code can call other code with either the same or reduced permissions, etc.

The basic idea is to have separation of power. For example, a rogue email application may be able to send out rogue emails, but it shouldn't be able to modify the hard disk. Since that is not required for its normal operation, it should never get that capability in the first place. In fact, it may not even be aware of whether there is a hard disk or not. Information and abilities should be on a "need to know" basis.

Unfortunately, to a large extent, the current model is that you are either the "super user"-- in which case you can do anything-- or else you are a regular user, and you have all the regular user permissions. Think of how coarse-grained "chmod" is.

So it doesn't make sense to say "this new sandbox is just like the old sandbox-- we haven't gained anything."
If Microsoft uses this chance to improve their security model, and their development models, they have indeed gained a lot. I hope linux and the other free operating systems can change their infrastructure to keep up.

Re:Well DUH

[Anonymous Coward]

For anything "useful", in the sense that it allows almost all of the functionality of a modern computer while preventing anything "bad" from happening, you just can't do it - This situation reduces to requiring a telepathic interface to know whether or not the user intended to perform foo.

Fair enough. Sandboxes are redundant in principle; any security measure provided by a sandbox could just as well be provided by the OS.

And I understand how the halting problem relates to partial decidability and the implications this has for mathematics. I still don't understand what this has to do with sandboxes.

Re:Well DUH

[pla]

I still don't understand what this has to do with sandboxes.

First, think of a computer as a really impressively complex Turing machine. Modern PCs have made huge leaps ahead of that model in terms of performance, but in terms of computational power, you can consider them isomorphic. It helps to think of this in terms of pure memory-mapped I/O.

Now, in the simplest model of malicious code, you might have a program that says "go to the beginning of the tape and write zeros until the end of the tape". A tad mindlessly destructive, but it will work as our model of a "bad" program.

To make the idea of a sandbox meaningful, we need to implement some form of privilege isolation - At its simplest form, consider a Turing machine emulating X Turing machines, checking the tape-extent bounds on each emulated turing machine.

For that level of complexity, you could "prove" correctness. I wouldn't personally want to have to do it, but it lies within the realm of possibility.

But what about within each of those emulated Turing machines? A malicious program could easily wipe our the entire emulated memory. So we don't just want virtualization as our sandbox - It works, and damn well... As I mentioned, I use it for my web browser. Barring a flaw in the VM I use, my worst-case scenario for a browser-based exploit requires me to replace the VM image with the backed up original. Consider, though, that you could say the exact same thing about a PC itself - Barring some hardware flaw (such as a BIOS writing vulnerability), the absolute worst-case scenario of attack requires nothing more than reinstalling an OS and restoring from a backup. In the case of a VM, I consider my running image disposeable; In the case of a whole machine, reinstalling requires more time and effort than just copying one large file, but these amount to the same situation, logically.

Sandboxing, therefore, amounts to a way to limit damage to the most specific context possible. On a 'nix system, we don't run as root because the worst damage a normal user can do, assuming no OS flaws and sane FS permission, requires resetting that user's account to a new-user state.

We don't want that, however, and whether or not the OS survives, most of us would consider such damage-limitation as frustratingly useless if our dissertation or tax forms or the like vanished while the OS stays just fine-n'-dandy.

So, we really want a sandbox that "knows" what we should and shouldn't do. We run a web browser, it might even save the occasional file, but we don't expect our web browser to format the HDD. Same idea applies to email clients. To media players. To the shell itself.

The problem then turns into a situations of how much you want to make your sandbox to protect you from. If you don't mind reinstalling your OS and restoring from a nonvolatile offline backup, hell, don't even bother using an antivirus program! I personally wouldn't go that far, but I think nothing of wiping XP on my SO's machine and restoring from a backed-up preconfigured state I have stored on a DVD for just that purpose. It takes a couple of hours, but only about 10 minutes of my interactive time.



And there we run into the problem, and why the halting problem has relevance to the idea of sandboxing. The more complex you make your sandbox, the less you can analytically call it "secure". At some point, you can only call it "probably secure". And at some point, it has attained a level of complexity where we can't even say that much, we literally cannot say more than "it works, and hasn't crashed on any known inputs".

Mathematically, that last situation would require a truly infinite input space (though the halting problem technically does not). But in practice? A mere 4KB(=32Kb) RSA key would, on modern hardware, take far longer than the current age of the universe to crack. How many programs have you seen lately that take up more than 4K

Re:Well DUH

[MickDownUnder]

There are thousands of libraries out there that specifically deal with either mitgating the risk over buffer overflows or detecting them such as this one and this one . Anyhow my point was that you can accomplish adequet protection against buffer overflow in C++ with the right code, and a consistent approach. Buffer overflows needn't be a factor in your choice of development language. I'm sure those architecting Vista are well aware of these issues and would have some very sophisticated C++ libraries and tools that do the job alot better than any freeware product you'll find on the net.

My original point was that you actually have no clue as to the architectural choices that have been made, and the approach taken by the developers of Vista and that your original post was based on complete speculation.

This would fit fairly nicely with the "Evidence based security" that MS is talking about, and it would include not giving evidence of higher trust than is absolutely needed for each piece.

As for your imaginings about the suitability of using .NET Code Access Security to deal with your least privilege mantra. As I have been repeatedly trying to say with little success, I understand it quite well, and NO IT DOES NOT FIT NICELY at all.... It's evidence based security that MS talks about is specifically designed to deal with the problem of how to allow untrusted applications loaded FROM A LOCATION OTHER THAN YOUR LOCAL COMPUTER, to run in a partially trusted context. It simply doesn't do what you imagine it might do.... it has no constructs that could be utilised to accomplish what you're talking about, which is the segmentation of an OS's internal components.

I will pre-empt your reply, which most undoubtedly will be... oh well then... what a hopeless job of security they've done in .NET then....

It is simplistic for a very good reason, it's purpose is singular and that is to quote my original comment...

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

So basically you should really avoid critizing someone for not using a tool that you have no understanding of to tackle an objective within an architecture that no-one except those who would be bound by non-disclosure agreements would have an authority to talk about.

In short... cut the crap.

Re:Well DUH

[Anonymous Coward]

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

Indeed. Notepad and mspaint keep crashing on me, and my whole production backbone depends on them.

Re:Well DUH

[Nataku564]

He never said .Net wasn't fast. Rather he claimed that .Net performance is inferior to an equivalent application written in C++ (or equivalent). Whether you think its fast and dont mind the extra memory is totally irrelevant to his point.

Throw enough hardware at a problem and it will (usually) be perceived as fast. Many financial industry applications operate under this ideology.

Re:Well DUH

[Anonymous Coward]

The complexity of proving a program secure isn't necessarily proportional to the number of possible inputs. For example, you could build a functional web browser that would run in a sandbox with only three system APIs: one to receive mouse and keyboard input, one to output a bitmap to the screen, and one to retrieve data from a URL. That's it. You only have to prove that the three APIs are correct; the mess of complexity involved in rendering a web page can be completely ignored.

Another example. The Java and C# code verifiers prove that byte code is safe before they JIT it. To correctly identify all safe programs would be to solve the halting problem, but the verifiers don't; they just recognize a subset of safe programs. Happily, that subset includes all code produced by Java and C# compilers, programs of arbitrary functional complexity.

I understand your point but I think that with appropriate layers of abstraction the theory is tractable. We may have to agree to differ!

Re:Well DUH

[MickDownUnder]

When is the plan9 version slated for release ?

Why don't you tell us... Perhaps you can start the implementation for Plan9.... ;) Anyhow it looks like the boys at Mono are on the job so why don't you ask them ?

XAML and Vista are a while off, but it's definitely coming within the next year, when it's ready Microsoft will submit it as an open standard. I think you will see more movement on .NET as a crossplatform framework when Microsoft releases their version Office built on .NET (which is also currently in development). At this point there will be some tangible incentives for Microsoft to supply a version of .NET running on Mac and Linux. Till then I think you'll have to content with the efforts groups such as the Mono group to provide support for non-Microsoft platforms.

Re:Well DUH

[slashdotwannabe]

A minimum of 20 megs of ram per app, assuming that they are not actually DOING anything. If they actually do something, crud, heh, plan on a few hundred at least.

ok troll, did you just pull this number out of your ass? You obviously aren't basing this on, say, real world applications you've written, 'cos if you were, you would not be making such a patently wrong statement.

I've got a solution with eleven different projects open, hundreds of pages, hundreds of classes, and VS 2005 is using 120meg after way to many compilations, and the web server using another 25.

Re:Well DUH

[z4pp4]

i found valgrind extremely useful for tracking down memory allocation issues, some applications that are considered safe are not so safe at all when you "valgrind" them ...

sweet, thanks for the heads up.. so it should be something along the lines of....

wget -r -O - cvs.sourceforge.net | valgrind > known_vulns.txt

:)

never too old to learn.

Re:Well DUH

[DrSkwid]

I think you miss my (snide) point.

Mono != .Net

Never will

Re:Well DUH

[JacobO]

They didn't improve COMMAND.COM in MS-DOS in over a decade

Are you referring to the years since Windows 95 or the years before Windows 95 when COMMAND.COM mattered?

Before MS-DOS was tossed out, COMMAND.COM had various incremental improvements. DOS 6.0 added the /C argument to DIR for example. Useful if you need it, I guess.

In Windows 95, COMMAND.COM was updated somewhat. Of course it has been all but replaced by CMD.EXE, which has many advantages. The useful FOR command for example.

I realize there's little point arguing any of this, but here I am doing it anyway. Bah.

Re:Well DUH

[cfuse]

Is Microsoft supposed to completely rewrite all of their already working software?

So I'm supposed to buy Vista just for the new chrome? I don't *bloody* think so!

Re:Well DUH

[Com2Kid]

ok troll, did you just pull this number out of your ass?

No, I got it from MY system resource usage stats.

Albiet this was Beta 2, but unless they fixed a 200MB memory leak...

Though admitedly I was working on a huge app that also had had some webapp components and a good sized SQL database it was working with.

Re:Well DUH

[Reziac]

One of my pet peeves is how developers no longer bother cleaning up the resource heap, because after all now WinXP can be expected to do it for you. Much the same principle -- XP's improved resource heap management lets coders be lazy and sloppy, so guess what, they are!!

As to preventing buffer overflows, I remember reading a couple years ago about how some compilers actually muck around with your code and *introduce* buffer overflows. Eeep!!

(BTW... hi Joe, didn't realise the nym was you til today!)

Re:Well DUH

[Richard Steiner]

I'm referring to the years from MS-DOS 1.0 through MS-DOS 6.0 (1981 through 1993).

Most of the heavy DOS users I know were in the days from MS-DOS 3.3 (32MB disk partitions) though MS-DOS 5.0 (the best one MS released, IMO), and a lot of us replaced COMMAND.COM with 4DOS.COM maaaany years before MS-DOS 6.0 was released. :-)

I had also moved to OS/2 by then, but it still had a COMMAND.COM in its VDMs (which I replaced almost immediately with 4DOS).

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

[kabz]

1. Create enormous hype over Windows Longhorn having a .NET UI
2. Wait for Gnome to start using .NET
3. .NET sucks for UI
4. ???
5. Profit!

Re:Mono

[aussie_a]

I'm personally glad a marketing department wasn't given such power. Allow developers to actually investigate for themselves whether it is better to use .NET, rather then force Microsoft to develop program X in .NET for no reason other then marketting.

Re:Mono

[Anonymous Coward]

Ummm.. You do know that Media Center is managed code, right?

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.

Re:Mono

[Anonymous Coward]

GNOME isn't using .NET, and it's not using Mono either. The Mono community has some strong ties to GNOME, and SuSE/Novell are doing some very neat things that depend on GNOME in Mono...

Re:Mono

[2nd Post!]

What's the point of upgrading to Vista if it doesn't provide new applications or features?

OS X has provided new applications with each release for the past five years:
Fontbook
Spotlight
Dashboard
Expose
Safari
iChat
iSync
AddressBook
Automator

They have all used Cocoa, the equivalent to .NET in Macland, to highlight the strengths of the Cocoa development environment.

In addition they have developed new applications in Cocoa, such as iPhoto, Aperture, and other for sale programs.

Re:Mono

[Anonymous Coward]

Probably not, .NET was developed so that applications written using it can be ported to other platforms, such as Unix, Linux, Mac etc... Which is why they published the specification for MSIL so that runtimes could be written on those platforms. Mono is an example.

No different than what java tried to accomplish except for one thing. Only the java language can generate java code for the java runtime. Any language can generate MSIL code for the .net runtime. C, C++, C#, Pascal, Fortran, Cobol, Basic....

Re:Mono

[misleb]

I don't think Mono is a big threat. I haven't checked up on its status in over a year, but last time I checked, there was absolutely no Windows GUI (Forms?) support in Mono. In fact, there is a pretty huge chunk of the API that will probably never be implemented. If you write GUI apps with Mono in Linux, it is done using gtk-sharp. If anything, it be easier to run Linux apps on Windows, not the other way around. When I was playing around with Mono, that is exactly what I did. Wrote a small program in LInux and it ran directly on Windows (with the GTK-sharp DLLs).

Frankly, I prefer it this way. I'd rather C# applications have a GTK (or Qt for you KDE geeks) look and feel. I don't want to try to emulate a Windows.

-matthew

Re:Mono

[ScottyH]

Cocoa and Cocoa applications are written in Objective-C. It is not garbage collected and is still very close to the metal.

It is only similar to .NET in the sense that it is the platform that Apple pushes its developers to use when writing applications.

Re:Mono

[R3d M3rcury]

"Vista does not provide any new applications though."

What about Windows Mail, Windows Calendar, and Windows Photo Gallery?

These seem like prime candidates to show off .Net to me...

Re:Mono

[jcr]

They have all used Cocoa, the equivalent to .NET in Macland

Hold on, there... Cocoa isn't perfect, but comparing it to MS's JavaVM knock-off is pretty harsh.

to highlight the strengths of the Cocoa development environment.

More like, Apple uses Cocoa to get their work done, since it's far and away the best development environment available to them. For any developer at Apple, their job is to ship their product, not to prove anything about Cocoa or any other development tools.

-jcr

Re:Mono

[anzev]

I'm sorry, I thought I heard you say that Vista does not provide any new applications. Well that's just plain wrong. How about the sidebar, sync center, photo gallery or even the calendar. Based on this link there will also be some new games.

And besides I don't think the problem with Microsoft not porting their software to .NET is the lack of trust into this platform. I think it is in lack of integration with Vista itself. I do not know who .NET is progressing with Vista style controls, buttons, lists, new interfaces and shell styles that are fairly new to the OS market. .NET is not yet equipped to handle them correctly, or its not tested. And besides, we know that Microsoft wants things to look nice. And the controls they developed for Office (p.s.: it's been changed!) or Vista are not developed in .NET and it takes considerable effort to replicate them convicingly (own experience).

IMHO, Microsoft believes firmly in .NET and among other things they have their corporate website to prove it. I also bet that they will develop more and more applications in it, but I also believe that they do not require to do any more convincing. They have a large user base, that's all they need -- the development will be pushed on by this user base.

Re:Mono

[Nurgled]

Well, I for one would prefer them to concentrate on improving the guts rather than piling more frills on top. The frills can come once the guts are good.

I also find it amusing that you're pointing at Safari as a cool new feature when Microsoft added a browser as a core Windows feature back in 1996 or so. Similarly iChat: Microsoft bundles Windows Messenger since WinXP. Windows has a system-wide addressbook app back when Microsoft's mail client was called "Internet Mail and News".

Something like Expose might be nice, but it's nothing that can't be added by a third party, and I don't keep stuff on my desktop anyway.

Re:Mono

[angulion]

I wish to disagree..
MSIL spcification was published only so that it could hold a candle against Java (being "open" and standard), when in practice .NET uses lots of Windows only libraries.

I'd say .NET is cross-platform only in MS understanding of the word - it runs on win2k, winxp etc.

I have yet to see a .NET app writen on windows that wouldn't look horrible on any other platform if able to run at all.

Re:Mono

[2nd Post!]

Yes, and Objective-C has a perceived performance hit as a message passing language, as compared to C++, that is analogous if not comparable to the performance hit that .NET has compared to Win32, as a managed code library. It isn't 100% analogous, but for the purpose of the comparison it has merits.

Re:Mono

[2nd Post!]

So you're saying that Microsoft has been resting on it's laurels since 2003? ;)

Still, I too would prefer that Microsoft improve it's guts, but I'm not sure that I see any evidence that they have. They haven't made their user-land applications such as Outlook, Addressbook, Windows Media Center, Windows Messenger, or Internet Explorer safer by using managed code (.NET), but they have instead focused a lot of effort on developing a new display system ala Quartz in their WPF/Avalon display technology, WinFX ala Cocoa as their new advanced development toolkit, and then there is Indigo, their web foundation that allows applications to act both locally and remotely. I hope they've done a good job with that, because that sounds like a sure recipe for remote exploits!

Apple had it easier though, since they bought NeXT, who had already developed an advanced display library and development toolkit. They were able to use that development toolkit to rapidly add to OS X what was necessary to catch up to XP, and then continue to add features such as Dashboard, Expose, and Spotlight to continue advancing past XP.

All info gathered from here: http://en.wikipedia.org/wiki/Windows_Vista#Core_te chnologies

Re:Mono

[Anonymous Coward]

" What's the point of upgrading to Vista if it doesn't provide new applications or features?"

Stability? Security?

Aren't people here always complaining that all Microsoft does is add new features/applications without addressing behind-the-scenes concerns? Probably this is why, too many people say why upgrade if there's no new easily visible features...

Re:Mono

[Zeinfeld]

I'm sorry, I thought I heard you say that Vista does not provide any new applications. Well that's just plain wrong. How about the sidebar, sync center, photo gallery or even the calendar. Based on this link there will also be some new games.

Those sound like they are revisions and repacakging of existing code rather than a completely new application. Microsoft has done plenty of side bars over the years. Sync center and photo gallery type tools have been distributed as part of the powertoy for years.

The point I was making was that I don't see any initiatives in Longhorn where I would expect the coding team to start off from a completely clean slate. If they had I am certain they would have used C#, thats what most Microsofties use as a matter of choice, they were writing C# code before the compilers were even available outside Microsoft.

With respect to the claim that .NET is a clone of the Java VM, that is completely untrue. Gosling did not invent the idea of a VM and would never make such a silly claim. The USCD p-system is well known to everyone in that field. The .NET model is not based on the Java VM, nor is it a clone of it, the .NET model is actually a different concept that also has a long line of prior art. The CLI code is actually based on the intermediate representation used by all the Microsoft compilers. This is a very common compiler architecture, GCC uses it and it was not the first by a long way.

The only 'innovation' in the .NET CLI is that it is designed to allow the final stage of the compilation to be performed at installation time or at run time. Again there are 20 year old precedents but this idea was really not a very practical one until relatively recently

The antecedents of .NET are really the work done at Digital in the late 80s when they were managing the transition from VAX to Alpha. This is not at all suprising given the number of ex-DEC people working in Redmond.

Unlike Java the CLI code is not directly executable (or at least not designed to be). A lot of the information is non-executable identity hints that is lost in a pure VM (as Java is re-engineered to optimize the just in time compilation mode it will look more like CLI). The result is that CLI code does not in theory suffer any penalty as a result of the CLI processing step. The 'inefficiency' in .NET comes from the use of implicit garbage collection rather than requiring the programmer to handle GC and the security mechanisms built in to make the code safe, prevent privillege boosting etc.

The Vista engineers have taken a slightly different tack. Intead of using .NET to provide fine grained security protections they worked out what they need most and implemnted that in the O/S core.

Re:Mono

[drinkypoo]

I don't think Mono is a big threat. I haven't checked up on its status in over a year, but last time I checked, there was absolutely no Windows GUI (Forms?) support in Mono.

It's called Windows.Forms and the vast majority of that functionality is present in WINE. It will be nontrivial but possible to extend Mono with Wine in order to provide that functionality in the future.

Re:Mono

[misleb]

It's called Windows.Forms and the vast majority of that functionality is present in WINE. It will be nontrivial but possible to extend Mono with Wine in order to provide that functionality in the future.

I'm sorry, but wine sucks as a general solution. If you can get your favorite app/game to work with wine (good luck!), great, but I would never count on it. The bottom line is that such emulation/immitation is a bandaid used in lieu of native apps.

And FYI, the Mono project has abandoned Windows.Forms through WINE. See: http://www.mono-project.com/WinForms They're currently trying to reimplement it all in System.Drawing. The first thing that comes to mind is Java/Swing. Ugh! Talk about slow (and ugly). This is Mono's third attempt at implenting Windows.Forms. I'm not holding my breath. GTK-Sharp is the way to go for graphical .NET apps with Mono. Trying to emulate Windows(.Forms) is a dead end.

-matthew

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.

Re:So....

[Comatose51]

Yeah seriously. Some people here will take every opportunity to bitch about MSFT and I'm not a fan of them either. However, let's be realistic here. Use the best tool for the job. .Net was never meant for writing an OS. Why the hell would MSFT want to do that anyways?! Let's just think about that one. MSFT promoting a set of tools to make writing an OS easier... No. .Net was created to run on top of Windows. As someone with experience in .Net and Windows application programming would tell you, quite a bit of .Net is not brand spanking new code but wrappers around existing code. .Net exists to make programming for Windows easier, thus further promoting MSFT.

It's like this: WMI and Active Directory both existed before .Net and are not implemented in .Net. However, using .Net makes it trivial to publish and pull data from WMI and read/write from AD.

There's a good chance that by the time Vista launches, a new version of .Net or an upgrade would follow shortly to tap into Vista. They won't be new implementations but would simply be there to make using the components of Vista easier.

Re:So....

[Overly Critical Guy]

Here's an idea. Read the fucking article. It's not about writing an "OS from scratch." It's comparing the amount of managed code that was used since the PDC 2003 build to today's builds. Back then, the shell was managed code, two services were managed code, and since then, native code has replaced nearly all of it, and WinFX isn't even installed by default anymore.

Clearly, Microsoft has abandoned its former strategy of using .NET for all that stuff, as they previously advertised that they would (again, read the fucking article).

Re:So....

[Overly Critical Guy]

Yeah seriously. Some people here will take every opportunity to bitch about MSFT and I'm not a fan of them either. However, let's be realistic here. Use the best tool for the job. .Net was never meant for writing an OS. Why the hell would MSFT want to do that anyways?!

Read the fucking article. It's not about writing an OS in .NET. It's about all the userland that was previously written in .NET code--like the freakin' Explorer shell--which has now been replaced with native code. Microsoft developers previously claimed Longhorn would be based on a lot of .NET code, and now they've quietly replaced it all with native. There were services that ran in .NET that are now native as well.

If I see another "they're not going to write an OS in .NET" commenter who has clearly not bothered clicking the damn link and reading the article, I'm going to scream.

Not a good basis for decision

[Anonymous Coward]

Writing bare-metal OS software vs. application programs is not a good comparison. DotNet was never sold on its principles of performance, but instead on its simplicity of development. That simplicity does not come at zero cost, so when writing base OS function, it is paramount to focus on features and performance, not ease-of-implementation.

Re:Not a good basis for decision

[vux984]

Ok. Given Windows Vista is probably around 10% bare-metal OS, and 90% user inferace, why is the .net to native code ratio of Vista 100% native? I mean sure, we don't expect it to be 10:90 out of the gate... but *why* wasn't the new version of Paint or Notepad written in .net? Why isn't the Add Printer Wizard .net? Or any of the other 200 bazillion wizards? What about some MMC panels? Policy Editor? Windows Update? The regional settings control panel? There is nothing "bare metal" about any of that crap.

We didn't even get a .net Solitaire or Minesweeper.

Nobody wants, or expects the kernel to be .net; but its striking that there is NOTHING whatsoever in .net expecially in an OS that is so loaded with utilties and wizards and tools.

Imagine Sun Solaris shipping without anything built in Java.

Re:Not a good basis for decision

[assassinator42]

They should put Reversi back in. Also, how well does .NET work with DirectX/Direct3D?

Re:Not a good basis for decision

[Anonymous Coward]

"Imagine Sun Solaris shipping without anything built in Java."

Not a great example, becuase Solaris is primarily a very highly polished UNIX--meaning C code and shell scripts. The default GUIs are GNOME and CDE. The kernel is in C. Most of the new features are in C. There are several utility programs, such as the Update Manager, which are Java, and they do work well, but they aren't a huge part of the system. Where Java shines in Sun's stack are the IDE tools, the J2EE stack, some of their system admin GUI tools, etc., but those are generally add-ons or are part of the larger install settings.

I still love Solaris, though, Java or not.

Re:Not a good basis for decision

[vux984]

Also, how well does .NET work with DirectX/Direct3D?

Not too badly at all... DirectX 9 includes "Managed DirectX"

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

[Anonymous Coward]

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

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

[Anonymous Coward]

The fact that you don't seem to understand that this (not using .net) is a plus in MS's case just shows how much of an amature you are spreading fud.

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.

Re:Uh...

[Anonymous Coward]

The interpreter caches the resulting machine code after JITting it the first time.

Re:Uh...

[benjymouse]

No, it's *not* an interpreted language. The C# compiler (or VB or J# or Eiffel or ...) will compile into Intermediate Language. This language was never intended to be interpreted. In fact, no interpreter exists for this language (well, not publicly from MS anyway). Upon first execution the IL is compiled to machine instructions on the target architecture. This code is then executed, and then kept in a private cache so that the next execution will not have to repeat the compilation

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

Re:Not suprising.

[Saint Stephen]

I've actually seen the source code for the shell. There are special hooks in the NTFS driver that update some internal tables that the shell reads. (Not the public journal notification functions you can use -- although they are related -- but the shell directly reads some NTFS tables in the kernel, sorta.)

It does this to efficiently display a directory with 60,000 files and do quick updates of deltas. It's highly performance sensative.

Re:Not suprising.

[bphant]

Performance sensitive code is the sort of code that spends 100% of its time calculating something -- like a rendering engine or something. Sitting around waiting for events to occur (whether from the user or the NTFS subsystem) does not require high-performance code. It's just a normal program. Have you noticed that the explorer doesn't sit in a tight loop using 100% of your CPU waiting for the filesystem to change? That's why those NTFS tables/notifications exist, to make the burden on the shell minimal. Anyone could write a shell that could display 60000 things efficiently in Javascript (for example) given the right notifications from the underlying systems.

Re:Not suprising.

[Nataku564]

Well, there is a really easy way to test your theory. Try creating a windows explorer clone in .Net. I dont think you will find it as efficient as you seem to think it will be. The native code version already hangs when listing directories with mere thousands of files. In addition to some added slowness, I predict you will most likely also notice a considerable memory bloat.

Re:Not suprising.

[bphant]

I can't believe I'm engaged in this conversation, or that there seem to be so many people who think that Windows Explorer is the most complex engineering problem anyone has ever attempted. I'm giving up on this. a) I wouldn't have access to the NTFS tables/notifications/whatever that Explorer does to get info about file changes -- so it would be at some level impossible at the moment; but ignoring that b) computers have been capable of dealing with lists of things for quite a while. When explorer hangs because there are more than a few, it's probably actually the UI controls. The Windows list-view etc _aren't_ efficient, and Explorer's reliance on them is probably the source of the problems. If it were inefficient, which it could well be (probably memory-wise), it would be a specific problem with a .NET implementation -- not doing escape analysis on variables (like Java 6) for example -- and it could be fixed. There's nothing wrong with the _concept_ of doing it in .NET, and if Microsoft actually tried, all the problems could be fixed up.

Re:Not suprising.

[Nataku564]

You do realize that a good number of .Net controls are just wrappers around the very same native code controls you are claiming are the cause of the problem, right?

While it is true that there is nothing wrong with the concept of doing it in .Net (there are filesystem explorers in Java too), you claimed you wouldn't notice a performance difference. I am refuting that claim. I say that instead of not noticing a difference, you would, in fact, notice a difference - in both speed and memory signature. While it may not be apparent on the newest of boxes, the performance difference would most likely be noticable on my parent's PC.

In addition, I also wonder exactly how you know that the windows tree-view/list-view/etc controls are not efficient. They are, after all, running in native code, and have been a part of windows for a very long time. Logic would dictate that they are some of the more efficient controls in the OS, since they were created when system resources were very much less than they were today.

Re:Not suprising.

[bphant]

I have programmed against all versions of Windows since 3.1, so yes, I realise quite a lot about the OS. Yes, the .NET controls are mostly wrappers around the Win32 ones. That is obvious, the APIs are so similar they haven't even fixed some of the obvious problems. I ask you (rhetorically, mainly) where would the speed difference come from? The native interop? What about if the controls were written purely in .NET? It's a JIT language -- by the time the code is running, it's been compiled to native code. The memory difference is correct, but that could certainly be minimized -- by caching the compiled stuff, mainly. There is nothing inherently inefficient about systems like .NET. If Microsoft wanted to use .NET more, they would fix these issues, they aren't fundamental problems with the platform, they're more just implementation issues in the current version. I know those controls (TreeView, ListView etc) aren't efficient because I've used them, and programmed using them. You can get around some of the issues, but it's pretty easy to stuff up. Native code or not -- it's irrelevant here; you're the one who thinks native code stuff is faster. Someone can program badly in any language, and the effect is pretty much the same.

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

[Anonymous Coward]

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

That's right. And it was just about the only Microsoft product that ever used MFC. Presumably that's because the developer tools UI department was close enough to the code framework department that their common boss could force them to use MFC, no matter how badly it sucked. The rest of the company went on their merry way, at least able to produce their mediocre goods without the burden of that byzantine beast around their necks.

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.

Re:The proof is not OS services

[killjoe]

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

So will visual studio and office be written in .NET?

Re:The proof is not OS services

[Anonymous Coward]

Core Office apps won't be -- they can't. You're talking about a 10+ year old codebase that isn't going to rewrite itself overnight. I can say that most of the Office test org uses a .Net based framework to do their testing ...

Re:The proof is not OS services

[Kjella]

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

Which may mean that MFC was designed to work with as that product needed, just like GTK is a good match for the GIMP. At least my experience with MFC was that whenever you strayed from the straight and narrow path of how it "should" be, MFC couldn't cope. I searched for solutions and came up only with other people that had the same problem and "it can't be done". That's one of the things I like about open source, it's been pulled in every direction so it's flexible and modular. MFC is probably fine if you follow one specific template, but for me it was frustrating to no end.

Re:The proof is not OS services

[gbjbaanb]

MFC is probably fine if you follow one specific template, but for me it was frustrating to no end.

The phrase about workmen and tools comes to mind ...

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

Re:The proof is not OS services

[hockpatooie]

That's not what I heard. I heard that Office and lots of other Microsoft internal development was done in WTL, because everybody knew that MFC was such an ugly hack.

.NET is for rapid app development

[sexyrexy]

...Not bottom-level performance systems. I love .NET, but no one in their right mind would write anything in it where performance is a key factor. Web applications and office productivity enhancers are not even in the same arena as, say, your network protocols implementation layer.

I'm not sure how realistic it is to even try to write OS-level stuff in .NET... the difficulties would completely negate any development speed gains.

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:.NET is for rapid app development

[vidalsasoon]

Download the latest DirectX SDK and see how fast managed code can run.

Re:.NET is for rapid app development

[killjoe]

Interesting. You are saying that if performance is important to your application then you should not use .NET.

If you are trying to sell your application though isn't performance a very important factor?

Re:.NET is for rapid app development

[Nataku564]

You do realize that Direct X is all native code, right?

I can make pretty geometry in Perl using OpenGL, but that doesn't mean Perl is particularly fast.

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.

Re:.NET is for rapid app development

[GPF(BSOD)]

Probably because they're 10x smarter than you. Sorry.

Re:.NET is for rapid app development

[smallguy78]

(I(dont't)be(l(ieve))that for a (second))

Re:.NET is for rapid app development

[Anonymous Coward]

Rapid Application Development is not about completing projects in a shorter time.

Re:.NET is for rapid app development

[Anonymous Coward]

A small mind for a small guy?

Re:.NET is for rapid app development

[Anonymous Coward]

my company is in a process of choosing java vs .net for medical software (not real time), so I am interested to know what language you used to replace the trashed code? was it scrapped because of performance?

Re:.NET is for rapid app development

[SeeMyNuts!]

That is at least half the reason :-(

Re:.NET is for rapid app development

[SeeMyNuts!]

I think a lot of their productivity had to do with a complete on-line debugging environment at all times. The instant a bug appeared, they would start crawling through the in-memory data right away. No core files, no post-mortem analysis, no edit-compile-test cycles. Not a bad deal, but there is so little incentive in workplaces to pursue Lisp that I never really picked it up. Also, there's that whole deal of using Emacs ;)

Re:.NET is for rapid app development

[Anonymous Coward]

Not to be a dick, but if you had really coded in LISP, it'd have been like this:-

not(believe I 1s)

Re:.NET is for rapid app development

[Anonymous Coward]

We will be using C# and Managed-C++. We scrapped the product itself because it is perceived by marketing as obsolete, even though it is the current industry leader in its field. For various reasons, Windows XP was chosen as the OS for the successor project. Among those reasons is the mandate to use a particular .NET medical software framework from another division. And so we're rewriting most of the working legacy code.

p.s. Rumour has it that the framework in question almost chose Java, but was ordered to use .NET instead by the company.

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

[jbplou]

it took over 3 minutes to recompile

Is this supposed to be a long time? I don't see that as a very long compile time.

Re:Can't blame them

[vosgienne]

Yah, for an entire game, consisting of thousands of line of spaghetti code, 3 minutes is impressive. But if you're too stupid to actually write code that works, and recompile with every other line you write, then well, YOU SUCK BALLS AS A CODER AND NO LANGUAGE CAN FIX STUPIDITY.

Re:Can't blame them

[Anonymous Coward]

It is when you're still in school and have no idea what it's like to write an actual application.

Re:Can't blame them

[electromaggot]

Three minutes is a r-e-a-l-l-y l-o-n-g time when you've only changed one source file! No, I wasn't rebuilding the whole solution/project each time in such instances... just making tiny tweaks to specific lines of code, initial values (positions, velocities, durations, etc.), state machine states, etc. It was well designed code too.

We started with a 3D engine written (under contract) in C++. When that "work for hire" contract ended, we didn't own it, so decided to write our new engine from scratch and in C#, to further distance us from the notion that any of the new engine was *derived* from the old.

Big mistake. We figured C#/.NET might make us more efficient... but we had no idea. My productivity nose dived. I'd spend longer days getting less done. L-o-t-s o-f t-i-m-e w-a-i-t-i-n-g f-o-r i-t t-o r-u-n.

I really hope C# doesn't take hold (I still don't think it has, but maybe I'm in denial). It's like training wheels. Like working in a Microsoft-imposed padded playpen. I really consider it to be Visual Basic made to look like C++... as others have suggested here. It's some kind of ugly malformed hybrid creature underneath with a real pretty face on top. I wish it would crawl away and die.

Yeah, that's how I really feel.

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

[Anonymous Coward]

Considering the other managed C# games being written which don't seem to have long compile times as a factor - I'm wondering if it was how the code/projects/solution was structured that caused the problem??

Re:Can't blame them

[Anonymous Coward]

You really suck balls man. What sort of stupid-ass programmer COMPILES A DYNAMIC LANGUAGE.

I mean, damn! Just click the "Run" button, and you can save yourself 3 minutes. Managed DirectX is nearly as fast as unmanaged DirectX, and unless you're trying to build something on the scale of Warhammer 40k, Doom3, or a MMO, you're not going to notice the difference in speed.

Learn to program, noob.

Re:Can't blame them

[Anonymous Coward]

So you think C# doesn't have to be compiled? Who's the noob?

Re:Can't blame them

[TimboJones]

just making tiny tweaks to specific lines of code, initial values (positions, velocities, durations, etc.), state machine states, etc. It was well designed code too.

A really good design would put at least initial values in data files. Ideally, you would have a command in-game to reload the data and start the scene over, but worst case you just quit and rerun the exe. You shouldn't need to touch the binaries to tune the game!

At Flying Lab only the devs and testers have VS installed. The content and art folks work on the data, programmers work on the binaries. Anything configurable is in Perforce as .ini or .xml.

Re:Can't blame them

[electromaggot]

I understand what you're saying and you raise good points. My issue is more with what happens *after* I build -- the amount of time the JIT compile process takes, the bigger-than-they-should-be size of my app and libraries, the time it takes to load those, tie in the CLR, whathaveyou. For a big, broad project, that can all take a lot of time. Way too much in my opinion.

...and it's not just me. I actually have extensive experience with the Reality Engine, which has a sizeable C# component. That can take forever to load too!

Oh, and some of the posts below are laughable. As if C# is a dynamic language! ...and I never argued the performance issues of managed vs. unmanaged. I assume it's all the same code inside the wrapper.

I just want my pointers back. (Although not having to dick with .h files was sure nice!)

Re:Can't blame them

[electromaggot]

I see your point, but... Then you're doing a disk access (or zillions) at runtime... perhaps well into the game... plus, if it's human readable (hence extensible like XML without re-coding everything), end-users can get in, edit, and monkey with your stuff!

In our C# work, we did have XML files that we compiled-in as resources. That was nice. ...but maybe that was part of the problem too!

I just figure it's 6-of-1/half-dozen-of-the-other... You gotta get those values in there somehow, and if they're not human readable, you gotta get 'em in there, well, somehow. Thus you might assume a compile/run might be possible in a reasonable time.

We commonly write package tools to accumulate all our assets into big data files (and simulate a filesystem therein), but too many little bits of initialization data for myriad game classes might become a maintenance nightmare, in my opinion. Then to generate the package becomes yet another part of the build! Our crunches are bad enough as it is. Sometimes ya just gotta do it and be done with it... so the perfect solution remains elusive. :-)



P.S. - Even for something like scripting that we hand off to the Designers to "tweak" gameplay... our best approach has always been to have 'em use a "script lib" of game-level functions, which they actually compile in C++! Thus we already have the benefit of a well-established debugger, etc...

Re:Can't blame them

[Anonymous Coward]

Christ you are dumb.

* Disk access is done while the application is starting. Populate your critical data structures on boot, not on demand.
* Use of XML seralization in the manner you describe results in code being generated and compiled dynamically at runtime and requires reading large quantities of data from your binary in probably the slowest manner I can imagine. This WAS your problem.
* When you run into a performance problem you don't understand, break out the profiling tools to see what is happening instead of scratching your ass like a monkey going "durrr...it no worky".
* Users can break out a hex editor to edit and monkey with things too. Oh, the horror. Whenever see yourself making this kind of argument, it's a sign that you're making excuses not to do something instead of coming up with valid reasons.
* Maintaining datafiles is just as difficult as maintaining source files. Except maintinance of datafiles can be done by non-devs. And it is easier (and safer) to write tools to manipulate data files than it is source code.

Re:Can't blame them

[I!heartU]

Just wanted to side with you electromaggot, I wrote a small client/server chatt app in mixed mode c++ using the .NET ui. Talk about fing slow to start the debugger, if I just ran the binary it was fast but specifclly getting it up in the debugger was slow. So if your app was mixed mode I see what your saying. Pure C# seems to be ok at least for websites and small tools. Native is super fast to debug, I dunno what kinda beast they're conjuring in mixed mode but it is a harsh one to debug.

Re:Can't blame them

[Anonymous Coward]

Whoah Timbo! You're a genius! No one else would've thought of any of that! (except the parts that are ill-conceived)

;-)

Re:Can't blame them

[Fulcrum of Evil]

end-users can get in, edit, and monkey with your stuff!

They can do that anyway. What's your problem with users messing with your stuff, anyway?

In our C# work, we did have XML files that we compiled-in as resources.

Sounds like something an intern came up with.

We commonly write package tools to accumulate all our assets into big data files (and simulate a filesystem therein), but too many little bits of initialization data for myriad game classes might become a maintenance nightmare, in my opinion. Then to generate the package becomes yet another part of the build!

So load the main file, then load whatever you're tweaking as an override. Simple.

P.S. - Even for something like scripting that we hand off to the Designers to "tweak" gameplay... our best approach has always been to have 'em use a "script lib" of game-level functions, which they actually compile in C++! Thus we already have the benefit of a well-established debugger, etc...

Beause something like Python doesn't have a debugger, right?

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.

Re:Can't blame them

[MickDownUnder]

I second your shenanigans, and expand it to half the comments posted here. I've read alot of them, it's been quite a while since I've seen such an eruption of bull$#!^ as I've witnessed in this slashdot discussion... George Bush should probably be recruiting from here.... there's some real talent in the disinformation department here.....

So guys.... maybe it would be better if you stuck to commenting about what you know, rather than just making stuff up.

Re:Can't blame them

[tau-lepton]

Crap, In three minutes I can refactor a PHP or Java class in a running application, including unit tests against it every 30 seconds or so... on a PIII 800 MHz server. So yes 3 minutes is a long time.

Re:Can't blame them

[Anonymous Coward]

15 seconds to compile "180 pages" of code is miserably slow.

180 pages = ~9000 lines? (50 lines per page)

Re:Can't blame them

[GreggBz]

I hit F5 a couple of times and your right. It's more like 2-5 seconds. I embelished a little. Regardless, my point was that managed code is a viable solution for game development. They have have a whole section devoted to .NET development at gamedev.net, the best game development community around.

Re:Can't blame them

[l3v1]

Geez, my eyes just popped out and rolled away in astonishment. I just measured, about 6000 lines of c++&mfc code in vs2k5 fully rebuilded in about 11s on a 2800+ sempron and 10s on a 2800+ barton. I also did anothet test, a c++/mfc project with around 28000 lines fully rebuilded in 8s in vs6 on a 2800+ barton, which is closer to your time (~8/3s), but it's vs6.

I didn't write large stuff in c# up to now, but when I wrote something in it, compile times seemed slower than c++ (in vs2k3 and vs2k5) even for simple apps. So how'd you manage to compile ~9000 lines of c# code on a 2.5ghz rig, I can't see.

Re:Can't blame them

[jbplou]

PHP isn't even in the same league as .NET, so your little crappy PHP script is of no concern here.

When the baby came with instructions

[Bucc5062]

and the winner is? wait, I'm sorry, I thought this was informative. As a long time MS developer (sigh, yes I can imagine the flames as I type) I really do not see the deep value of this article.

As it stands today, I have to deliver MS framework 1.x or 2.x or flipin x.x because it is not part of the basic OS. As a coporate developer I have to get our platform installers to push framework out so I dont have xx mg added to my installs. What would be the miracle would be that MS actually implemented an OS that had all the damn components in place (gasp) like it use to be, instead of today were I need to tell users to upgrade to FW then install the app. I try to stay within the envelope, it is MS that keeps changing the edges. How about getting back to basics where the OS, when released had it all.

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.

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:When the baby came with instructions

[3770]

Deploy your applications with clickonce. Problem solved.

Re:When the baby came with instructions

[edwdig]

Windows did its own memory management, but it avoided as much hardware interfacing as possible. You needed to load DOS drivers for any drives other than a floppy or a standard hard disk. Windows didn't do any disk caching on its own and required the DOS cache, Smartdrive, if you wanted any. SCSI and Ethernet cards needed DOS drivers loaded. Windows really only had its own sound and printer drivers, but so did every DOS application. I had very little experience with scanners back then, but I seem to remember the standard procedure was you'd load a DOS driver for your scanner which did the real work, and then install Windows TWAIN drivers which exposed the scanner functionality under a standarized API.

That said, I still consider Windows 3.x an OS. The competitors to Win 3.x did the same thing. Let DOS handle the drivers when there already was a standardized system in place, but do the rest yourself.

Re:When the baby came with instructions

[Anonymous Coward]

yeah 'cos it's not like to get any app running under linux you have to install perl,python,bison,gawk and about 50 other similar bizzaro dependancies, making sure you have the precise exact version of each number down to 3/4 decimal places. what do they do, randomly rename API functions with every relase?

At least with windows it's usually just .net (which is installed and upgraded automagically via MS update) or just the occasional VB dll. normal users just go with the built-in MS Java Runtime, i personally opt for the Sun one.

posting as A/C because i forgot my flameproof pants

Re:When the baby came with instructions

[drsmithy]

Windows did its own memory management, but it avoided as much hardware interfacing as possible. You needed to load DOS drivers for any drives other than a floppy or a standard hard disk.

Not really accurate. Windows 3.x didn't *require* its own drivers - it could access hardware via DOS drivers - but it could also load its own drivers for things like disk controllers (remember "32 bit disk access" ?).

Windows 95 functioned basically the same way, it just had more native drivers - it *could* use DOS to access the hardware, but could also use its own "native" drivers.

Windows didn't do any disk caching on its own and required the DOS cache, Smartdrive, if you wanted any.

Yes it did (it was added in Windows for Workgroups 3.11 - "32 bit file access").

SCSI and Ethernet cards needed DOS drivers loaded.

Ethernet cards didn't need DOS drivers.

Again, with things like SCSI, Windows could *either* use DOS _or_ its own "native" drivers (if they existed).

Now, a lot of this stuff is only in Windows for Workgroups 3.11 (particularly the networking and "32 bit" disk access/caching) and isn't in Windows 3.0, but certainly from 3.0 onwards, Windows was running the CPU in protected mode, doing its own hardware access, memory management, CPU scheduling, etc. All the stuff OSes do. It certainly required DOS to start, and would use DOS if it had to, but it also took over a lot of functionality from DOS if it could.

The short version is, from Windows 3.0 onwards, Windows was far closer to an OS than an "application". As it progressed, it took on more and more features of an OS, until it ended with Windows 9x

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.

Users embedding and extending the OS?

[BadAnalogyGuy]

If you code an object in .Net, you open the object up to reuse by external applications by default. This can be managed through certain programming practices, but the benefit of OO design is that the objects that you create can be reused in ways you hadn't imagined.

Now imagine that Microsoft's utility programs had a security vulnerability. In their managed code, you jokers.

Exporting objects that were fully reflective is asking for trouble. It's probably bad enough that you can tear apart binaries now with a good debugger and resource editor. It will be much worse if those programs actively advertised their services.

Re:Users embedding and extending the OS?

[chundo]

And this explains why Linux has so many security vulnerabilities, right? Because just allowing anyone to look at the source code would surely uncover many security holes to be exploited.

Attitudes like that encourage sloppy programming. Rather than thinking of a totally secure way of doing something, it encourages doing something "just secure enough", then crossing your fingers and hoping nobody figures out a way around it.

Security by obscurity is bullshit.

Re:Users embedding and extending the OS?

[CajunArson]

BadAnalogyGuy... an apt name for your bad analogy :)
  The problem with your logic is that you are assuming the security of the system is
really more based around not being able to figure out and access most system-level
services. The issue there is that if the OS is setup properly, the ACLs and other
security checks in place should catch attempts at manipulating files/network sockets/
registry keys/etc. I know that bashing Windows security is in vogue around here, but
to be perfectly blunt there is no real difference between the security services offered
by Windows and those offered by Linux*, namely that non-root users should get limited access and
superusers have the run of the machine. You can argue that Linux gets patches out faster when
bugs are found, but the basics of the models are not really different.
    If there really is a vulnerability in such a service, the existence of a convenient API will not
substantially reduce the security, as it stands now the blackhat community is more than capable of messing with things at the binary level like you mentioned. The existence of open API's to system
components could actually help security since a consistent set of interfaces would probably encourage better design and better testing, plus it would not allow the developers to pull stupid stunts that happen when they know nobody can interface with the program.

* SELinux, Apparmor, and even my master's thesis on mandatory access controls with Domain & Type
Enforcement do give Linux a big leg up, but unfortunately they are not as widely deployed as they should be.

Re:Users embedding and extending the OS?

[jbplou]

You know the classes can be secured. Just because it exists doesn't mean I can use it.

Re:Users embedding and extending the OS?

[BadAnalogyGuy]

I believe I mentioned that. If I didn't, I apologize.

However, this is Microsoft we're bashing here, so with enough mental contortions, you can probably figure out a way to show that they would be more than likely to leave critical components unsecured.

Re:Users embedding and extending the OS?

[Anonymous Coward]

Yes, Linux does have a lot of security issues, and yes people discover them by reading the code.

Re:Users embedding and extending the OS?

[Jussi K. Kojootti]

Rather than thinking of a totally secure way of doing something, it encourages doing something "just secure enough"

Get real, man. There are no totally secure solutions, there are only differing levels of "secure enough". If you think you've designed a totally secure system, you should probably think about it for a little longer...

In most cases I agree with your conclusion though.

Always knew it was a sucker bet

[jmorris42]

So if we project trends out a couple of years more of GNOME will be C#/.NET than Vista. Figures. So basically .NET was just something to slow down third party Windows devels (and the GNOMEs) and sow discord into the Java weenie camp.

Re:Always knew it was a sucker bet

[Anonymous Coward]

If only.

In ten years time GNOME will still be too busy agonising over another of its endlessly uselss variations of the file open dialogue and trying to foist the utterly worthless spatial browsing on people to have rewritten large parts in C#.

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:Should consider only new code

[jericho4.0]

MS has a market cap of 282 billion dollars, and 38,000+ employees. .NET is hyped as easy and fast to develop in. Why is it unreasonable to expect them to rewrite explorer?

Apple seems hugely more productive in comparision.

Re:Should consider only new code

[jcr]

Apple is much more productive, and based on my time there, I'm convinced that the reason for this is that Apple doesn't indulge in overstaffing, and more importantly, they don't load up with dozens of management levels. The biggest team I know of at Apple is Xcode, and those guys are very well organized into small groups for each major portion of the product: the compiler guys, the editor, the interface builder, the class modeller, etc.

Any of you who have been to Apple's WWDC and attended the "What's new in Cocoa" session, have probably seen the entire Cocoa development team on stage. Seriously, that's all of them.

-jcr

Re:Should consider only new code

[Jussi K. Kojootti]

What the hell does market cap have to do with the need to rewrite applications? If they have working code (which can of course be disputed, but you didn't), there's no reason to write it again.

Java Appliance

[kevlar]

This sort of ridiculousness reminds me of Sun's disasterous failure with their Java OS/Appliance shit they tried pushing about 6 yrs ago. Its stupid to base an OS on a virtual machine architecture. The entire purpose of an OS is to offer services efficiently so that apps don't have to implement their own functionality to control devices.

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

Re:Consider the alternative...

[UnrefinedLayman]

I believe it was Joseph Joubert who said, It is better to debate a question without deciding it than to decide it without debate. So while you may find this matter resolved simply because some people will say one thing and others will say another... I'd like to hear them out.

Re:Consider the alternative...

[natrius]

Then we'd all sit around and wax about how wonderful it is that Gnome is pure C.

Speak for yourself. Gnome is not pure C. Of the top of my head, at least deskbar-applet, sabayon and pessulus are written in python.

and ignore the fact that Mono is associated with it because of cognitive dissonance

None of the official Gnome modules use Mono.

But I suppose it is far too unreasonable to ask for informed discussion these days...

Judging by your comment, I guess you're right. Every other vendor that promotes a specific development environment uses that environment for their own code. Microsoft is the only exception. Whether you like it or not, this is a story.

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.

Re:Irrelevant

[Anonymous Coward]

Some of the things Microsoft had going with COM in the late '90s were pretty interesting, including ATL and COM+, and (later) WTL. But they are a famously paranoid company and, by all accounts, were panicking over the hype Java was receiving at the time. I wonder if they threw in the towel too quickly? Maybe they should've kept COM development going in parallel while they ramped up their Java killer, just to hedge their bets.

I remember when MSDN magazine (formerly MSJ) almost overnight changed over to a nearly 100% .Net editorial policy. I stopped subscribing after that, and haven't regretted it.

Re:Irrelevant

[killjoe]

"This issue is largely irrelevant; .NET was never promoted as a systems programming environment "

But he is not talking about systems programming. He is talking about userland applications.

Re:Irrelevant

[sheldon]

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.


Interesting supposed "fact", when you consider in this article, he does some benchmarks and basically comes to the conclusion that managed code is perhaps 2% slower than unmanaged code.

So Richard Grimes bust the myth of you claiming he said something as a fact. Take that! :-)

Re:Irrelevant

[IamTheRealMike]

Uh, why? As pointed out elsewhere, .NET is hardly "new" and many useful applications and utilities in the Linux world ARE being created using .NET: this includes OS components such as the updater service in SUSE 10.1

What is it anyway?

[ArkonChakravanti]

What is this .NET framework anyway?
Did a search for it and apart from some buzzworded texts and complaints about it I came up with nothing that actually said what it was...

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.

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.

Re:What is it anyway?

[ArkonChakravanti]

Thanks, at least that explains the lack of decent explanations...
And to the other guy saying thing about karma boosting tricks, thank you too, my faith in the goodwill of men was getting too high anyway...

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.

Re:What is it anyway?

[panaceaa]

It's still a confusing term. I'm on a couple email lists with C++ developers here at work, and when they talk about ".NET" they mean Visual Studio. Even though we've upgraded to Visual Studio 2005!! And these are relatively smart and well educated developers, but they're caught in a habit.

It's going to be a long time before ".NET" ever means anything specific, if ever. Instead I think people will use terms like CLR, or even C# (even though it's just one of many languages to develop managed code), to describe the managed code framework. Though I think the fully-qualified term ".NET framework" is pretty clear, even though GP's first impression was that it's a fluff term.

Re:What is it anyway?

[Octorian]

People who use MS products seem to have a habit of taking the most general and meaningless portion of the product name, and using that to refer to the product. This annoys the crap out of me, personally. So you worked with people who used "Visual Studio .Net" and just called it ".Net". This trend is made ever more annoying, as MS loves to use very generic terms in their product names. Heck, with Windows, they just mention the version name/number in complete isolation. So it's not "MS Windows XP". It's just XP, and be damned anything else that might be called XP. It's not "MS SQL Server", it's "SQL Server", and be damned any other database product that might actually be an "SQL Server". (most of 'em). So on and so forth. (At least I try to prefix MS product names with "MS" whenever I can, since I don't believe they get an automatic exception from products needing full identification.)

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

[Goalie_Ca]

KDE and Gnome have many applications making use of ruby, python, and mono. There are also many thousands of applications running on java. Bitorrent was in fact written in python. The underlying libraries are all done in c/c++. The graphical applications can be written in whatever makes the life of the developer easier without any "bloated" consequences. As is, almost all desktop applications (native or not) don't even come near taxing the CPU. They sit idly on various system queues and let the underlying libraries do the heavy lifting.

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

[Allador]

You should read your own links.

The first one is MSDN AA (Academic Alliance), and has absolutely nothing to do with this discussion. Unless you're a college/university, or a student receving MS software through the MSDN AA program, then this has absolutely nothing to do with this discussion.

The second one in no way stops you from publishing benchmarks, they just require full disclosure, so that it is reproducible.

Re:No Duh

[WhiteWolf666]

You mean, why don't Linux distributions litter userspace with Mono apps?

Like this: http://www.mono-project.com/Software ?

Oh, they do, that's right.

I would not be surprised to see OSS and Linux distro makers embrace Mono, C#, GTK#, and the like moreso than Microsoft pushes .NET

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.

Re:No Duh

[Anonymous Coward]

I don't care what you are saying, but no later than yesterday, windows update prompted me to install some .net framework update. I read the accompagning EULA, and it explicitely said that I could not publish benchmark without written acceptance from microsoft. I promptly clicked "Cancel"

Re:No Duh

[Anonymous Coward]

It was while installing MS GDI+ tool:

" * You may not disclose the results of any benchmark test of the .NET Framework component of the OS Components to any third party without Microsoft's prior written approval."

Well, no thanks.

Re:No Duh

[powerlord]

The second one in no way stops you from publishing benchmarks, they just require full disclosure, so that it is reproducible.

Not only do they want full disclosure, but if you are claiming a product's speed vs. .Net, they reserve the right to benchmark YOUR product. Gee ... I wonder what would happen?

Re:No Duh

[Surt]

This change wouldn't make it any harder to generate 99% of the applications that run on windows. Just the 1% that are dangerous to certain monopolies.

Re:No Duh

[NullProg]

You mean, why don't Linux distributions litter userspace with Mono apps?


I would not be surprised to see OSS and Linux distro makers embrace Mono, C#, GTK#, and the like moreso than Microsoft pushes .NET

I think I know what your saying, but I'm running SuSE 9.2, and I haven't even the mono runtimes. On my son's Ubuntu system, no mono either. Mono gets the crap beat out of it here: http://shootout.alioth.debian.org/ As a developer, there is still no reason for me not to choose Java over .Net. Java still has more cross-platform support with runtimes for AIX/WIN32/4690/zSeries/handhelds etc.

Choice is just one reason for using Linux. Marketing hype hopefully will never rule in Tux space.

Enjoy,

Re:No Duh

[NullProg]

You should read your own links.

The first one is MSDN AA (Academic Alliance), and has absolutely nothing to do with this discussion. Unless you're a college/university, or a student receving MS software through the MSDN AA program, then this has absolutely nothing to do with this discussion.

I'm more than willing to be wrong on this. Can you show me/provide a EULA that allows proffessionals to benchmark .net vs Java and publish the results? I did read the links. Have you read the .Net installer EULA?

Thanks.

So....Coffee Flavoured Chips.

[Anonymous Coward]

And yet there are Java Chips.

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

[Anonymous Coward]

Aside: Hotmail live runs on ASP.net

Re:Dogfood

[Doc Ruby]

Original post: "it took them years and many failed efforts to switch it over from unix to Windows". I said they switched. You can't turn years of failure into instant success just by loving Microsoft as hard as you can.

Re:Dogfood

[Anonymous Coward]

Despite what you may think even Microsoft is not dumb enough to shitcan the tens (or hundreds) of millions of dollars in capital hardware that comprise Hotmail's unix backend. The front end was migrated off unix in one shot with no failures, no downtime and no hardware changes. The backend had a different set of issues and I can guarantee you that Windows 2003 is a more robust platform because of the work that was done to pull off that migration (and yes, it's still going).

Re:Dogfood

[jcr]

The front end was migrated off unix in one shot with no failures, no downtime and no hardware changes.

Sorry, but based on conversations with a friend who was working for Hotmail at the time, I flat-out don't believe you.

-jcr

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.

z0mg

[Anonymous Coward]

Solaris doesn't make their kernel run in the JVM means that we should all stop using Java because it's obviously shit.

It's a low level hardware code you zealot fanboys.

Re:z0mg

[maelstrom]

z0mg you are a dumbass for not understanding the difference between userland and kernel. Like I said earlier, most Solaris admin tools ARE written in Java. Twit.

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?

[Anonymous Coward]

Hmm, the biggest user of Managed code (and twice as much as everything else) is a tool for creating Managed code! I know this isn't the same, but Sun tried implementing a few Solaris services in Java, (WBEM is a good example) and they had absolutely horrible performance compared to C implementations. Many times, newer isn't better.

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:So?

[Petrushka]

Sorry, just another afterthought: if you could effect a change, your readers' affect might be more pleasing.

Re:So?

[Anonymous Coward]

You do know that two of the programs you listed I have tried/own through MSDN. Both are slower than molasses in a cold January. Whats your point? .Net sucks?

Re:So?

[Anonymous Coward]

Sorry but your constant posts are affecting my mental state greatly. Unless you stop your ridiculous posts, you will feel the long term effects once I come and bomb your house.

Re:So?

[Anonymous Coward]

That's a perfect example of what's wrong with .NET. You don't need 7.5 million lines to write *anything* unless your language stops you building up to appopriate levels of abstraction. .NET has so many features that inhibit abstraction that useful new functionality has to be added as new language features, not libraries.

Whereas applications on the other hand...

[Colin Smith]

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

What?

[d_jedi]

Is Solaris written in Java, now?

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:What?

[Profound]

Thank God they don't write userland apps in Java. Just imagine:

>ls -l | grep foo | sort | more

would cause 4 JVMs to load (at 2-3 seconds startup time each) each gobbling up insane amounts of ram.

Re:What?

[ultraklon]

Yes, but it would run almost anyware :P

Microsoft's first good decision!

[JSchwage]

I can't believe that Microsoft is actually making a good decision for once. Although .NET may be easy to work with, it's quite slow. I'm glad to see they're slowly moving away from .NET. I wouldn't mind if it died out anyway.

Big surprise

[maelstrom]

.Net was one of the few technologies that I've seen come from Microsoft in recent years where I've actually said, "hey that's pretty slick, good call!"

So of course they'll let it languish. Anyone heard any status from Parrot?

Re:Big surprise

[Anonymous Coward]

.Net was one of the few technologies that I've seen come from Microsoft in recent years where I've actually said, "hey that's pretty slick, good call!"

So why weren't you running Java in 1995? What benchmarks do you own that show .Net
is faster at development time or runtime than Java/Python/Ruby or any other interpreted/bytecode language doesn't match?

Are you speaking out your ass or are you just a Microsoft (tm)moron?

Re:Big surprise

[chromatic]

Anyone heard any status from Parrot?

It still passes all of its tests, even after Audrey and Leo hacked on it all day to connect it to Pugs.

Re:Big surprise

[maelstrom]

I was running Java in 1995. I was also running Slackware Linux in 1995, so it would be hard to call me a Microsoft moron by any means. Sure is easy to snipe at people as an anonymous coward.

Re:Big surprise

[VGPowerlord]

So of course they'll let it languish. Anyone heard any status from Parrot?

She said "Polly want a cracker!"

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.

Re:Reflection!

[ichin4]

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

Wrong. None of the .NET Framework library assemblies are obfuscated. (You can find them under C:\WINDOWS\Microsoft.NET if you install the framework.) Feel free to take a look using a decompiler. (My favorite is Lutz .NET Reflector.) When I need to understand a .NET API in more detail, I often find looking at the decompiled source to be quite instructive.

Re:Reflection!

[bencvt]

None of the .NET Framework library assemblies are obfuscated.

Yes, those are part of the language core. Thanks for pointing that out. It would be counter-productive to obfuscate them, after all.

But you'd better believe that Microsoft obfuscates their enterprise-level assemblies (e.g., SharePoint Portal Server, Business Scorecard Manager, ...).

Re:Reflection!

[rsbroad]

I agree that IP protection is a top priority at Microsoft.

However, decompiling Windows services is just as easy as decompiling .Net Assemblies, if you have sufficient money and time.

Entities that have plenty of money and time ( and labor ) are known as Nation/States. They have armies also.

It is greatly in the interest of some countries to decompile Windows.

This makes compiled code only somewhat more obfuscated than MSIL Assemblies.

Microsoft's real hope for IP protection will be Digital Rights Management.

And RealDRM(tm) will be hardware based.

Re:Reflection!

[Tim C]

Be fair. You said "Doubtlessly, MS already uses obfuscation extensively in every one of its published .NET assemblies. " (Emphasis mine)

ichin4 merely pointed out that that's not the case, as "every... published .NET assemblies" includes the core framework assemblies. That says nothing about assemblies that make up for-profit products, of course, but does disprove your original assertion.

Re:Reflection!

[marco.antonio.costa]

That's probably why OpenSource development using Mono doesn't really mind writing .NET code. ( i.e. GNOME )

Probably in a few years, when machines run managed code as fast or nearly as fast as your average C++ code, the opensource community will benefit more from the .NET legacy than Microsoft ever did.

I don't like .NET, but I gotta admit that it's quite straightforward for GUI development.

Re:Reflection!

[davebert]

Nope, I've poked around in the Base Class Library with Reflector quite extensively and not encountered anything remotely obfuscated.

The trouble is, Intellisense in Studio wouldn't work with an obfuscated class library as it's all reflection-based.

Re:Reflection!

[bencvt]

Yes, I misspoke in my original post. Oops. Hence the sentence in my reply: "Thanks for pointing that out."

Re:Reflection!

[Jaime2]

I just ran reflector on some of the SQL Reporting Services assemblies. I saw a minimal level of obfuscation in there. Pretty lame stuff that the DotFuscator Community edition might do. No strange overloading of unrelated methods or other advanced techniques like false refactoring. They just removed the names of some private or internal properties/methods and anonymized them with a, b, c, and so on. It wasn't done to most assemblies. Most were just compiled and shipped. For example, all the code for the UI in Report Manager is there plain as day.

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

[SnarfQuest]

Just how much crap will MS developers take?!?!?!

Considering what they have already put up with, without a whimper, I'd guess that there is plenty room for much more.

Why should MicroSoft care, when they can get them to line up six deep begging for more?

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.

Just a few short months ago...

[Anonymous Coward]

I remeber posters here on /. predicting that .NET was the wave of the future: it was easier and faster to code apps with; it was more secure; and most of all, it was the future, get off your dead ass and learn it!

Naysayers were modded down and anyone who dared to mention that Microsoft has done this in the past only to yank the rug out from under and release the next "new" thing to force everyone to buy all over again was derided.

Well, where are you now, you Microsoft shills? Still coding in what Microsoft will soon make obsolete technology?

Size comparison: MFC42.dll vs. .NET Framework

[tepples]

I remember specifically having to download MFC42.dll when installing ICQ with windows 98.

MFC42.dll was never 20 MB, and entry-level Internet access hasn't got any faster since Windows 98 came out. (Windows 98 and V.90 modems came out in mid-1998.)

Re:Of Course!

[elchuppa]

I'm not so sure. I think that C++ is probably the opposite of what you suggest... although I guess that can't be true either. The statement 'to problem solve' is too general. C/C++ when you absolutely must squeeze everything out of the hardware that you possibly can, regardless of whether it means a rewrite each time the general community figures out faster way of doing things. But most of the time, for your average problem, far better I think to use a higher level language like java, ruby, c#. Then you solve the problem more quickly, more robustly, and more concisely, and usually since you're coding to standard API's you get automatic performance gains when your dependencies show up with newer better versions or when your sandbox figures out a faster way to allocate objects or garbage collect. The right tool for the right job my man. I think.

You don't need a virtual machine.

[Anonymous Coward]

If you want to avoid buffer overflows, you don't need to resort to a virtual machine. O'Caml can be compiled to very efficient native code, including unobtrusive automated garbage collection. The risk of buffer overflows is extremely minimal, assuming you don't go interfacing with poorly written C code.

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:Easy: you don't start over unless you have to

[Jugalator]

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

Microsoft has given one of the major reasons for developing in .NET being improved security due to running in a sandbox and with fine grained security rules. With .NET apps, even the common buffer overruns would be caught, and not require special CPU hardware either. Sure, critics may say it makes programmers "sloppier", but Microsoft themselves never said this.

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

[jcr]

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.

Don't kid yourself: that's the ONLY reason finder is a Carbon app. I'm hoping that within a decade of the NeXT merger, Apple will decide that it's time to quit coddling the foot-draggers by throwing more money down the Carbon rathole.

-jcr

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

[mpcooke3]

Also, explorer.exe doesn't really qualify as userland.

Actually I thought Iexplorer.exe/explorer.exe and related libraries was software that would most benefit from the .NET security model. Surely, in the same way NT stopped direct hardware access eventually all programs that users interact with directly should run under .NET?

Also, I would have thought that it would be the .NET runtime that would enforce DRM restrictions since it already has a suitable security model, if that were the case then it would seem inevitable that explorer would sit ontop of the .NET runtime.

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

[Nurgled]

I'd be more concerned if MS started throwing away codebases that have had at least ten years of development and real-world testing in favor of fancy new stuff just for the sake of pushing the new platform. New software always has bugs.

In their place, though, I'd probably do it for unimportant things like WordPad and Paint, since no-one really uses these for anything important. However, this is still development time that could be used for improving the existing product, so I can see why MS would choose to work from what they have. It's their new products that we should be keeping an eye on; for those, they have no such excuse since .NET can interoperate with legacy native DLLs and COM objects.

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

[tau-lepton]

OK, here's why... .Net sucks. OK I said it, .Net is a useless waste of time that sucks months of productivity from every developer that is forced to use it by clueless higher ups that have been getting hand jobs by the MS marketing and sales sluts. --- Mono on the other hand is very promising and has few of the bugs that still persist in the .Net framework. And C# is a fine language; not my personnel favorite, but a good OO language.

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

[Slime-dogg]

Queue Notepad v. Vim flamewars now! Face it. You're just picky. Notepad is great for what it is... a cheap app that shows text. If you prefer something else, use something else. Using your preference for something else to talk about the stability or usability of something completely different is rather stupid.

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

[jasondlee]

I never said notepad was unstable or unusable. I just said that it wasn't good, which happens to be my opinion, and, is therefore undebatable. :) Furthermore, it was a snide joke. Don't take it so seriously.

nothing new, duh!

[smartsaga]

If vista's explorer is not hosting the runtime it does not mean that it won't support the .NET platform. It only means that it is now less risky to have a .NET app running and that if it crashes, when it does, it will not take down the OS along with it.

It would seem that this is more like the JVM that takes care of eating it own dogfood.

And like many people have said here already, .NET is easy on development it was not advertised that it would be the fastest thing in the world. Have a good one. P.S. Don't bother to reply to this 'cause I rarely ever check my posts.

Re:nothing new, duh!

[Slashcrap]

P.S. Don't bother to reply to this 'cause I rarely ever check my posts.

So I guess there's little chance that you'll see me calling you a smug little cocksucker then?

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?

Re:Your sig is a lie

[Surt]

I took a shot at that sig about a month ago, I doubt it is going to get changed.

Re:Your sig is a lie

[xiphoris]

I read Slashdot to correct the FUD where I can. Or minor things like this :/ I read with a hearty dose of skepticism, as one should read all publications, and I energetically respond if I see something's amiss.

It's not too broken, I don't think. Just biased. But then, all people are biased. I'd rather hear anti-Microsoft sentiments than anti-Black.

Seriosuly.

[Dogun]

Whoever thinks that writing the most heavily stressed user-mode components of your operating system in anything other than native code is a good idea, please raise your hands.

Guards, please remove those hands, that these fools never type a line of code again.

'Nuff said.

Re:Seriosuly.

[Jussi K. Kojootti]

Lets see, here are some .NET executables in the PDC03 Longhorn version:

# Help Pane
# Migration Wizard
# Out Of The Box Experience
# Scheduled Jobs
# Sound Volume

Man I'm glad that they decided to not include these heavily stressed user-mode components of the operating system as .NET-components -- that would have been so stupid. Maybe they should write them in assembler just to be sure they don't slow the machine to a crawl.

Bloated windows always lost market share.

[SynapseLapse]

You're absolutely right. Look how much ground Windows lost when 95 came out and it's bloated system requirements.
And when windows xp came out with its hefty requirements...

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.

What a combination...

[Aqua04]

.Net and Windows Vista, even separately neither of these sound appealing to me. Combined, wow, that's as appealing as, say, some raw Rhubarb & a hefty slice of Blue Cheese.

Linux uses more 'managed code' then Microsoft...

[Anonymous Coward]

The desktop applications (as opposed to games or special applications) that I use that are made with high level languages.. (Python, Mono, etc)

Beagle -- desktop search engine (files/meta data/email/IM/etc): mono.
Deskbar Applet -- Integrates internet search, dictionary, email, beagle search, etc etc: python
Straw -- RSS agrigator: python
Tomboy -- note taking: mono
F-spot -- advanced photo management: mono.

(of course I include python because that has very aggressive memory management. Also it is compiled into intermediate bytecode before being run through a interpreter.. so don't think of it as a 'basic' style interpreted language either. It just happens in a more automatic fasion then mono and such does.)

And that is just the stuff off of the top of my head. Of course the 'core' stuff that is sensitive to speed is almost exclusively C. I am sure that there are more apps like this sneaking around that I and I just don't realise that they are using stuff like that.

Originally Longhorn was suppose to be all managed code. Remember??! Or has the Microsoft marketting people managed to wipe another little peice of undesirable Microsoft history off into the dustbin?

Google around for that.. You'll find it.

Of course early on Microsoft found out that this ran like shit so they shut up about it very quickly.

In reality all Vista is is just a WinME to WinXP like WinME versus Win98 SE.

That's all it is.

Sure there are substantial changes in a evolutionary manner, but fundatmentally it's the same OS as XP and uses the same codebase.

I've read that wallstreet article before too. The one were Microsoft released information that made it look like they've completely redone it.

But go and look at what MS said about WinXP with their marketting machine back then. When they compared to to Win9x and Win2k saying that it was all new and such. But it is fundamentally the same OS as Win2k and has the vunerabilities to prove it.

Nobody can afford to rewrite a OS anymore. Even Microsoft.

Managed Code for Shell Extensions Not Recommended

[jsight]

Microsoft actually advises pretty strongly against using managed code for extensions to Windows explorer due to issues with language version binding that can cause problems in some cases.

It shouldn't be too much of a surprise that they aren't really using it so much themselves as a result of that.

Studies say otherwise

[Anonymous Coward]

The assumption that managed code runs slower than native code is more myth than fact. Many studies have shown (just search on the net) that in a lot of circumstances managed code can be just as fast as, if not faster, than native code. This is mainly due to garbage collection and managed structures. Also as a platform becomes more mature performance will continue to improve (which you can't say for native code).

I'd say that MS not using .Net is more a case of not wanting to write everything again. There is a lot of stuff which is going to be carried over from previous versions of NT. Even if these things have new versions small updates is quite different to a complete reimplementation in .Net. If they were to do that they might aswell just completely write a new OS from scratch and then provide emulation software etc to run legacy apps. Somehow I really don't think MS is going to do that.

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:Of Course!

[Anonymous Coward]

I understand what you are saying. In an ideal world it SHOULD work like
that. But, after more than 2 decades of development I can say, sadly, it
does not. I have, many times, been called in to convert systems from their
existing form, into one that would more completely do the job. dBase-->c, Foxpro-->c,
Access-->c++, VB-->c++. Speed, and lack of needed features were the primary
reasons for this. I think MS is shooting themselves in the foot with .NET.
There will be a great opportinuty for someone to step in a replace their OS dominance.

If you want quick and dirty then go with the high level language. If you want to clean it
up and optimize it then go as low as you can while keeping it maintainable (which is exactly what
C was invented for).

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.

Re:Power is cheap, time is expensive.

[rseuhs]

Quite simply, hardware is cheaper than developer time.

What nonsense.

If you write an application that will run on your basement computer, then yes "hardware is cheaper than developer time".

If you write an application that will run on thousands if not hundreds of thousand computers, then no, hardware is not cheaper than developer time.

Re:Power is cheap, time is expensive.

[Ravatar]

I'm getting sick of this myth that .NET is so much slower than native code. For one example that completely shatters this theory, click here.

Re:Power is cheap, time is expensive.

[Anonymous Coward]

> Why would someone sacrifice application performance for ease of development?

Yes, why indeed? Let's get some real numbers:

* Data extraction code that used to take from 15mins to 1:45 to run, after working on it for a couple of weeks we had the critical parts of it improved by a factor of 500 or so, resulting in times of about 30-60s for the same job. Sure it took ~200 hrs to write, but our clients didn't exactly mind. Not with that kind of improvement.

* Database search + report code that started out taking 10-45 mins. However, this was deemed critical since it was to be used together with customers, and requiring customers to twiddle their thumbs while they waited for the report to be processed would lose them sales. It was a bitch to write and will be a bitch to maintain (sunk probably 200+ hours into it thus far, and expecting more) but when I got that time down to ~20s our clients were overjoyed in spite of the cost!

Moral of the story: if you think that cutting a few corners and cutting down on development time only costs you 10-20% in performance, you're wrong. Sometimes, it costs a LOT more.

Mind you, this has nothing to do with .NET or not but is a real-world example of what development time can buy you. There's no one-size-fits-all solution and while you may be right some of the time a narrow-minded approach like yours will ensure that you're in for a rough surprise if you ever run into a problem that doesn't fit your world view.

Re:Power is cheap, time is expensive.

[nmg196]

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

GRRRR. Why would it be slower? What rubbish have you read that shows that in real world tests, .NET is slower? Most of the tests I've seen show that .NET is no slower than native code. In fact it's often FASTER. Your entire argument falls flat on it's face unless you can explain why your app would be slower under .NET when many people have proven the opposite.

> Even if it took me an extra 100 hours to write the app in C/Win32

Also, I tend to find that the extra time taken to develop an app in C/Win32 instead of .NET is measured in days weeks or months rather than hours. It's MUCH MUCH faster to write applications in .NET than Win32 (that being almost the entire point of it) and I don't think you'll ever convince anyone otherwise. Combine that with the fact the software will NOT necessarily be any slower as you suggest and your argument fails. If the app did take a few extra days or weeks to write, that would be charged out to the company at hundreds of dollars a day and your savings would be undone unless the app was in use for decades.

Re:Power is cheap, time is expensive.

[Anonymous Coward]

When processing takes 8-10 minutes people usually switch to ther tasks in the meantime. So you shouldn't count a 2-min difference in execution time as 2 min of lost productivity.

If someone is indeed waiting these 8-10 minutes doing nothing and, as you allege, the task is CPU-bound, it would often make a lot of sense to throw enough hardware at it to make it IO-bound.

Re:Power is cheap, time is expensive.

[NynexNinja]

You are assuming that C/C++ development libraries do not exist and you are writing code "from scratch". This is simply not the case. Development libraries and frameworks do exist for C/C++ development, cross platform ones too, that can be used to design GUI apps which become portable to Linux, MacOSX, handheld devices, etc... IMHO, it simply does not make sense to write one line of code in .Net (or Java for that matter) when you spend *the same amount of time* writing it in C or C++ and its portable. .Net and Java are the flavor of the week, and slow as hell, not to mention any intellectual property protection is thrown out the window because all this stuff can be decompiled directly to commented source code. Also, if you want your app to work on Win98 or any other platform that doesnt have .Net installed (which is a 25MB download), writing it in of these languages just is not an appropriate option. I dont want to require my users to have to lug around some 25MB download that does not come preinstalled with the operating system.

I dont know about you, but when I write code, I'd rather do it in a portable language all the time, rather then have to sacrifice performance, portability, and intellectual property protection by doing it in one of these other languages.

Re:Power is cheap, time is expensive.

[Jaime2]

Dude, that's funny.
First of all, many of those development libraries add almost as much overhead as the .Net framework. To really get the advantage of C/C++, the critical sections of code have to be written by hand. Second, .Net and Java are not "slow as hell". Granted, I wouldn't write a password cracking routine in .Net, but that's an extreme case. 95% of what business programmers do is as fast in .Net as in C/C++. Third, you cannot decompile to "commented source code". If you do a debug build and distribute the .pdb file, you can get line numbers. If you do a standard release build with no extra effort, you get all the names of anything exposed outside the assembly (anything public), nothing else. Stuff like method scoped variables won't have a name in the compiled code. No way does it compile comments. You can even use tools like the DotNetFuscator to remove a lot more identifying information. BTW, if your C++ code is mostly a bunch of calls to common libraries then it can be decompiled to nearly the same level.

.Net apps also are somewhat portable. They run on Windows, OSX and Linux (with Mono), and handhelds using the compact framework.

What you don't get in .Net is the chance to write an application that leaks memory or exposes an inordinate number of buffer overrun vulnerabilities.

Re:Power is cheap, time is expensive.

[slashdotwannabe]

oy vey

- Developer time is *always* more expensive than hardware. Using an extreme edge case of a fifty line app that runs on ten thousand servers does not change this.

- As someone who's programmed since 6502 assembly was state of the art, on every OS under the sun, in just about every language worth learning, and can testify that .Net is the cat's own ass. My personal productivity and that of my entire team is better than any other language I've ever used, not by a little, but my a significant amount.

- Maintenance, flexibility and security are all drastically improved.

- Only a dolt would say a managed development environment is inferior because it isn't as fast as native code. That's like saying apples are better than banannas because they taste different.

- As for what started this whole thread "eating your own dogfood", IMO the author has no real appreciation for just how HUGE the M$ codebase is. Even if they were to decide they're not interested in profit anymore (as if), why?. There are plenty of .Net reference applications, and no dev team likes to do a lot of work to get something that's essentially the same.

- Recall that apps like notepad and solitare were the reference/utility apps of their day. They were never intended to be competitive in the market in the own right. IMO the original authors are probably astonished their apps are still being used so many years later.

.Net in Windows ?

[cpatil]

In school, I had read a paper on qualifying software tools for use in US Military and Airforce. Specifically the compiler, used to build software should be certified at D0-178B(I think) standards. Myearliest lesson was if the tools used to build software were poor, then the software built using those tools could never be better. Likewise, VISTA would have created history for being the most expensive software project that failed to take off. And finally, fire Cutler & Allchin ;-)

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.

Re:actually, I rather like notepad

[xtracto]

I agree with you.

I like notepad.exe in the same way I like pbrush.exe. MS Paint may be a very basic product, it may not have multiple layers or whatever else but it is designed as that, as a straight forward easy to use drawing program.

One of the things for what I use Paint for example is to transform something to an image (like text or powerpoint drawings. It is so easy to CTRL+A CTRL+C CTRL+TAB CTRL+V and you have an Image.

Also, it is a great program to make kids spend time, it is very easy to use for them, I mean, even after comparing tuxpain with MS Paint I find the Linux alternative quite confusing or at least overwhelming.

Notepad is the same, it is great for text buffers, or to write emails (or slashdot comments) before pasting them to the web form.

As someone else kind of pointed out, Microsoft could "update" any of these two programs but they would not be Notepad or Pbrush anymore, they would be other programs. And, as everybody has noted there are tons and tons of programs available already, so why bother?

Re:actually, I rather like notepad

[Anonymous Coward]

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

A dozen years of screwing up newline characters.

Re:actually, I rather like notepad

[digital_dump]

Also, check out Paint.Net http://www.eecs.wsu.edu/paint.net/ It wouldn't surprise me they use something this in the final release of Vista. It almost takes on Fireworks, Photoshop, etc and it's free.

Re:actually, I rather like notepad

[Anonymous Coward]

at the very least it could deal with UNIX and Mac style text files intelligently.

That would Microsoft would be working toward "fair competition" , and we all know Microsoft can't have that.

Re:actually, I rather like notepad

[kailoran]

I'd agree with you... IF notepad didn't suck so badly on Unix text files. And that's probably one of a zillion tiny annoyances that make notepad.exe a pain.

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.

Re:they did have managed code, but pulled it out

[Anonymous Coward]

Riiight. One developer shows up at your office to interview. Because he's leaving Microsoft. Or was removed. And you believed him when no one else in the 'verse is backing up the story?

I personally know a lead on a prominent team there. He has virtually no idea what is going on in Vista, and I doubt your interviewee does either. Microsoft is a VERY big company.

Re:Big surprise (parrot)

[Anonymous Coward]

The whole perl6/parrot thing is taking much longer than many observers expected.

That's not to say it's going slowly... it's quite fast considering the sizes of the development teams.

Now that Pugs (haskell implementation of Perl6) is leaping ahead, the parrot folks have a realistic consumer of their product... several major upgrades of parrot have ensued.

perl6 will be mostly ready long before parrot (the platform) is a polished product.
At the time that parrot is "ready" for general use (I'd expect 1.5 years), there'll be lot's of interoperability with your .NETs,JVM's,LispMachines and the like.

I don't think parrot will be in the same space as .NET/JVM. For starters, it's written to optimise dynamic strongly type-inferenced languages with many optimised in-core FP (functional programming) constructs.

I'd expect that by the time polished language compilers (other than perl6) are available targetting parrot in a meaningful way, Microsoft will have shipped many core/non-core products utilising .NET.

-just my opinion

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

[Anonymous Coward]

"You're saying they should just throw away everything and do it all over again in .NET?"

No different than when some complain about 'X' and say we should throw it away and start over.

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.

Re:The real story

[jrumney]

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.

I'm not sure what you mean here. The latest 1.6beta2 JVM can still run bytecode compiled with a Java 1.1 compiler (and probably a 1.0 compiler if you can find one). If you're talking about API differences, the standard APIs are backwards compatible (methods and classes have been marked deprecated, but never removed), the only problems you have is if you decided to dig deeper into the API and used vendor specific classes instead of sticking to the published APIs - except in the case of Microsoft's JVM where they actively encouraged developers to use their proprietary classes instead of the equivalent standard ones, something they seem to be continuing with .NET if the tales of non-backwards compatibility are to be beleived.

Re:The real story

[Anonymous Coward]

He's talking about if for example you use a library that depends upon RandomJavaLibrary version 1.0. You also want to use another library (from the same application using the first library) that depends upon the (incompatible with version 1.0) RandomJavaLibrary 2.0.

I've never actually tried this to see what would happen, or bothered looking for any documentation on it, so I can't say whether he's right or not.

Re:The real story

[Anonymous Coward]

That's mostly correct. The problem gets into two things - buggy features that were relied on for their buggy behavior and features that were changed or removed. Java 1.0 had a number of things that were not just deprecated, they were removed entirely from future releases; any bytecode compiled to that would be broken running under a different JVM. The buggy issue is more problematic, and one that bites MS in the butt quite often. The basic tenet is this: if you want to run multiple packages in the same process in java, they must all be using the same JVM - and that might not be desirable.

Even if Java didn't have this problem, .NET absolutely did. MS wanted to reserve the right to change the IL as necessary for future releases. There were some security issues involved here too, but the long and short of it was that this versioning issue bit everyone in the butt.

Re:The real story

[jrumney]

Can you give an example of this RandomJavaLibrary? Or are you just making up this hypothetical situation to justify the mistakes Microsoft has made with their .NET 1.1 to .NET 2.0 upgrade?

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.

Re:Forget Sun... is Apple using Cocoa?

[jcr]

The difference: there isn't another NeXT for Microsoft to buy.

You know, looking at the whole Longhorn train wreck, I have to wonder whether MS has the guts to make a very bold business decision for their next OS release cycle. Having blown several billions of dollars, having had to rollback to the windows 2003 server code base, having spent SIX YEARS without shipping, you have to ask: should they go through that again?

There are two OSs they could buy, which have a hope of fixing the mess. They could buy Solaris, or they could buy OS X. With Solaris, their customers will still be living in "patch hell", and there's no hope at all of Sun ever improving MS's UI, but at least the underlying OS will be securable, something that no MIcrosoft product has ever been. If they buy a license for OS X however, they could actually make life better for many, many people.

-jcr

Re:Forget Sun... is Apple using Cocoa?

[ivoras]

One more difference: Cocoa's default language (Objective C) is not interpreted at runtime (though it has dynamic properties that make it almost so :) ) and is not a garbage collected language. This makes it almost as fast as raw C.

Re:Forget Sun... is Apple using Cocoa?

[Blakey Rat]

What bothers me is this:

If Cocoa is so great, why is the Finder so shitty? I can't go an entire day without it crashing, and I know several things to trigger crashes. Dragging a file from Cyberduck, my FTP program, to the desktop will freeze Finder about 80% of the time. Unplugging my USB2 external HD will do it about 33% of the time. Then there are the multitudes of bugs... folder contents don't update in real-time, nor does any other metadata (like filesize.) I love running a rsync backup script and, when it's done, having Finder tell me the folder it was backing up to still has zero items... double-click it, and suddenly there's 100 items. Its handling of text clippings is FAR inferior to OS 9's Finder, and it still lacks features that OS 9 Finder had. (No spatial option, for example. No pop-up folders-- Apple says the Dock can replace pop-up folders, but it can't.) I usually organize my photos using a Windows fileshare because Windows XP's filmstrip view is about 10,000 times better for graphics than anything in Finder, and it won't crash if you have more than 500 images in a single folder.

Anyway, I was excited about the re-write of Finder when it was announced (for 10.3, I believe)... but they actually ended up with a Finder that was just as poor as the one before and less stable to boot.

Note to Apple: Finder is the FIRST THING people see when they walk up to a Mac. Make it work, or you'll give people a bad impression.

Re:Forget Sun... is Apple using Cocoa?

[wandazulu]

It's my understanding that one of the major pieces of 10.5, slated to come out this year, is a total revamping of the Finder.

I agree that the Finder is the weakest part of the OS. Although, as was mentioned in the grandparent, I believe, the Finder is not written in Cocoa; it's still a straight Carbon port from OS9 that has been beefed up, sure, but still probaby has its fair share of OS9-ish stuff in there.

It wouldn't use JIT for the kernel

[Myria]

Since the kernel is unchanging (except service packs), they would probably use static compilation of .net code if they were to go that route, which is very unlikely.

You could certainly write many parts of the kernel in a language like .net and it would be fine. The big problem is that garbage collection in a kernel environment is a big no-no. Kernel allocations must be *very* carefully managed for things to work right under heavy load like WoW.

Melissa

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

[Anonymous Coward]

I'm with you... The JVM is supposed to, among other things, isolate apps from the OS. But for years that's what processes under both UNIX and Windows have done. Granted, VMs give you garbage collections and bounds checking, but you can get that without VMs as well. If the process model has security holes then the solution is not to basically nest one OS within another (eg, the VM within an OS process) but to fix the process model.

That said, one area where VMs _might_ have an edge is with JIT compilation. VMs can observe a running program and collect profiling data to optimize code that has already been JIT'ed (although in principle this might be possible with native code, too). But you don't need anywhere near the amount of infrastructure to support this one feature as you do to support all of .NET or the JVM.

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

[sydneyfong]

That's what ACL's are for.

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

[MickDownUnder]

Security is all about layers....

If you want to secure an OS, you don't allow non-secure applications to run on it directly, you do it through a VM.

Basically what you're saying is... I should be able to connect my network to the internet without a firewall. But the reality is that everyone has a firewall to restrict communication between the world and their network. Likewise you have a VM to regulate the api that can be called by applications. Microsoft .NET or some other VM is an absolute necessity in the world of distributed applications, which lays beyond HTML and AJAX.

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

[Anonymous Coward]

So what you run are toy programs. In the real world applications crash, and they are dumped to a core. And teh whole world doesn't come crashing down around them.

Microsoft is and will remain a toy operating system.
It has no use in the real world of Industrial, robotic and telecomunications equipment.

Imagine if buffer overrun results in elevator failure, or banking not working, or robots smashing into end-stops.

Microsoft is a toy operating system.

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.

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

[LightningBolt!]

first, in todays day and age, what is not facing the web?
ls, rm, cat, echo, ln, find, grep, vi, tail, gcc...

second, doesn't that make the JVM an extension (of the OS) whose sole purpose is to run the apps?
No. VMs can, and frequently do, exist in user space. No OS extension.

but the OS isn't secure! so the VM on top of that very same OS is?
Yes. Sort of like encrypted network channels running on unsecure networks.
Please provide some Java code that's vulnerable to a buffer overrun exploit.

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

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

[DrSkwid]

start here : man man

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

[DrSkwid]

In computer science we call these the kernel and userland

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

[Anonymous Coward]

You mean you don't run your web browser as a different user?

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

[Hooya]

Please provide some Java code that's vulnerable to a buffer overrun exploit.

you seem to be mixing VMs and one particular language that happens to be using the VM. sure java can't have buffer overrun. can you say the same about the VM? is the VM not implemented in C/C++?

i can also point you to plenty of lisp/python/even c++ with std::string code that i have written that do not feature possibilities of buffer overrun. none of which needs a VM to achieve that.

stupid microsoft

[szhao]

1. heard about the longhorn restart? lol, this has been long predicted 2. a lot of windows applications are being developed in .net 3. mono = linux implementation of .net that came AFTER .net was developed (though pretty well done) 4. people will eventually have c# notepad, it is only a matter of time 5. singularity, singularity, singularity, its actually quite interesting in concept; However, in practice it is something extremely different. 6. in practice certain components of managed, can be compiled down to native with special experimental compilers (was talking to some guy that was working on singularity about this earlier) 7. yes, no one in their right mind write the quickest and slickest code in managed, but it is (in my preference the easiest to naturally understand) 8. i probably would never go back to native for any of my research projects, for the sole reason that it is easier to think about the problem rather at the efficiency for example it is easier to think about webservices, objects, delegate than cgi, structures with functions, and function pointers (even though they are virtually the same thing respectively) 9. actually if you guys haven't realized a good amount of new softwares (as quoted above) have been done in dot net, the most common example that anyone can view is their website. 10. I am completely disappointed in they way they are running most of their projects (especially some of their live projects) SIGH.... live messenger beta was much better before the stupid update lol.

security

[RahoulB]

Part of the point of .NET is, like Java, it protects you from basic programming faulta - no buffer overflows and the like. so rewriting lots of services in .NET ought to improve the vulnerability of those services to exploits.

Re:security

[Nataku564]

This has been mentioned before, but like Java, .Net will only protect you while in the VM (or its JIT'd output, or whatever). System services tend to do low level things, and will most likely need to call at least one compiled DLL. While writing services in .Net would likely reduce the number of bugs/holes by some amount, it would most likely not remove the larger ones.

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

[Jacco de Leeuw]

Good point, but Microsoft probably uses an obfuscator.

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.

Re:Because .NET is effectively open source

[WWWWolf]

But you can decompile C/C++ apps too. Okay, perhaps you don't get the same level of information out of them. You can mess up the binaries with obfuscators, but no level of object code obfuscation is enough if you're paranoid, I mean really paranoid, about decompiling.

If Microsoft were worried about decompiling their apps, they'd stop making operating systems and implement everything as a web (or any other dumb-client, everything-fancy-on-server-side model) application.

Re:Because .NET is effectively open source

[Schnapple]

Besides the fact that Microsoft uses an obfuscator, you can't really use Reflector to decompile things. I hooked up a plugin to it once that would dump out complete source code files and visual studio projects for things you were reflecting. What you wind up with is a bunch of code which doesn't quite compile. It has lots of things which flat out don't work. The amount of effort to go in and fix tons of things that don't compile in complex and diffuclt to read code that you didn't write is mostly not worth it.

MS isn't the first to do this..

[Anonymous Coward]

What about Sun's JDS? I'd wager it had the same amount of Java apps as Vista has .Net apps. Does that mean Sun isn't invested fully in Java?
The real interesting question is what percentage of Office is going to be written in .Net. That's going to be the signal to developers to leverage .Net in their *user* apps.

Missing the point

[nobodyman]

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

The same application in C/Win32 does the same task in 8 minutes. That is 2 minutes per day times 60 people or 120 minutes/2 hours per day....[snip]

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

...Even if it took me an extra 100 hours to write the app in C/Win32 at $50/h that would only be $5,000.

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

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

Re:Missing the point

[Aladrin]

Eh, that's not exactly right either. Those users aren't going to stand still for 100 hours, or they all get fired. They will continue whatever less-efficient method they are currently using for the task.

Re:Missing the point

[gbjbaanb]

Lets rephrase the problem he was trying to make.

Imagine I have a C/win32 app that takes 8 hours to perform an intensive batch task (import data into a DB, or export data from a DB to a warehousing app, etc etc - we have several of these already where I work). Now, I re-write it in C#/.NET and it takes 10 hours... suddenly people come into work at 9am and find the overnight batch app is still running... sayng "get a coffee guys, it'll finish in an hour" is not an option.

Simlarly, I had to consolidate some data in a DB recently, and a little app was ideal for the task (itr was a one-off task, so a throwaway bit of code was ok). I decided to write it in .net, did the coding, ran it on my test database.. ran in seconds. all looked good. Copied the app to the real database with half a million rows and set it going.... and it ran, and ran, and ran... So I killed it and set about improving the performance, and re-ran it. We figured it would have taken several hours to complete. So I junked it and rewrote it as a plain c++/ole-db/win32 app, and the half a million rows were updated in 12 minutes. The time it took me to write it was not really a factor, it was better for me to re-write it than it was for us to run the slow version of the app.

Similarly, its not about the speed an app runs at. I'm currently working on changing the UI of an app to prevent users selecting a particular option. My work will save the FM team a heap of time, and will help the operators complete their jobs quicker and correctly. The result is that I could even spend weeks on this (yes, instead of reading /. :-) ) and it would be worth it for the business.

Re:Missing the point

[dodobh]

What happens if I don't have inhouse programmers, but I buy the application? It costs the vendor more to produce applications, but this cost is divided across their customer base (assuming code reuse). Whereas my users spend more time waiting for application response, and that is a direct cost.

Re:Missing the point

[AstroDrabb]

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

I recently had to update some old financial app that is written in VB 6. The app is slow. It takes about 15 minutes to do its processing. I wasn't given the time to rewrite it correctly in an OO language like C#. Some prototypes in C# I did showed processing could come down to 5 minutes or so. This app is ran multiple times when it is used. Saving 10 minutes per-execution * X executions/day * Y days = nice productivity/money savings.

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 is just completly stupid. Do you think those 60 people were hired to just sit and wait for the "super-speedy C version" of the app? Don't you think those 60 people have other processes/applications in place to use until they get that "super-speedy C version" of the app? Don't you think those 60 people have *other* jobs to do? Assuming 60 people would be paid $8.00/hour for 100 hours to do nothing is just stupid.

My argument was to the GP stating that I think it is stupid to think that developer time is the only thing that matters or is the most important thing in software development. For a software company yes, the former may be true. However for most of corporate America that do not produce software for sale, employee productivity is usually one of the top priorities.

Here is another quick example. Where I work they switched to a People Soft portal. The thing is total bloat-ware. It takes about 5 seconds to login (it used to be closer to 10). The previous old-school ASP portal was crappy but login took about 2 seconds. We could have re-written it in PHP/C#/Java and kept a 2-3 second login. Most people would think what is the big deal about an extra 3-4 seconds to login? Well it is not a big deal for 10 employees. However we have 150,000+ and average about 200,000 employee logins per week. 200,000 * 3 extra seconds = 166.6 hours a week that employees are waiting to login instead of working. And that is just login times. Add in all the other waiting some of the big bloated People Soft apps and the lost productivity gets ugly.

Of course you can now counter and say that the people may be waiting an extra average of 5 seconds for login, however they are saving 8 seconds trying to find applications in the portal. Trying to figure out true ROI could be never ending. My original post was simply that it is silly to look only at developer time. I think that non-developer productivity is more important for non-IT companies.

Re:Missing the point

[Slime-dogg]

Not to mention that .NET apps seem to run just as fast as C apps. It isn't Java 5 that we're talking about here. Every subsequent execution of the .NET app will run faster, and in some cases, may even beat out the C/Win32 apps.

Re:Missing the point

[AstroDrabb]

Well said ; )

I basically wanted to say what you did, except I tried late last night with one eye open : )

Re:Missing the point

[l3v1]

I don't care how much money a sw dev company can spare by writing less optimized code. Software and hardware companies just have to make use of each other to make us pay our yearly sw&hw upgrade cash. Still, I can't do anything against or about it. There's one thing I can do, make the best out of my own code, not much else.

As a l3g!+!m4te cr4cker..

[Anonymous Coward]

I take issue with you referering to me as a 'Script Kiddie'..

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:Reasons I can think of

[caluml]

Large parts of Vista are built on existing code.

And yet people are going to shell out loads for lots of new gimmicks they won't really use.

Re:Reasons I can think of

[Anonymous Coward]

If something's not broken, you don't rewrite it from scratch

Remember you are talking about Windows..

MOD PARENT UP (NT)

[Anonymous Coward]

(NT)

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.

ATI CC

[octopus72]

If managed code means something like ATI Control Center, then I'm happy that MS didn't develop it's core windows applications in .NET.

Of course we all in the end use third party software because MS always avoids support for common formats in it's picture viewers, music players (their media player sucks in fact), etc.

Re:ATI CC

[zlogic]

Mod parent up!
I have an ATI card in a Pentim III-1000, and am using the latest Catalyst drivers. Well, the system stops responding for about 10 seconds while Ati Control Center is loading its icon (and probably all the other stuff).
I've also made a simple app (about 120 lines of code) that generates crosswords. It also has a really long start time of about 5-7 seconds. It's a really long time compared to native (and much more complex) stuff like Miranda. This 120-liner actually loads the same amount of time as MS word!

Get the facts straight.

[Anonymous Coward]

Parent mention things moved into addon releases because they were dangerous. The reality is that they were moved into addons so they could also be used for applications targeting XP and 2003. That, if anything, shows that they are less dangerous, not more, given that they are going to make them more widely available, not less.

The parent is written just barely well enough to fool some readers into believing it. Don't.

Do as I say, not as I do?

[Tim C]

So, what, MS is telling people to write their OSes in .NET? Or could you just not resist yet another cheap, meaningless shot?

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

Another black mark for 15259

[Anonymous Coward]

Read the article, microturfer. Did you buy your account on E-Bay? You are disgrace to the 15,000s.

Re:Of Course!

[Naelphin]

I take the old definition of high/low level languages: Assember is low level, and everything else is high.

I know Java does JIT, but originally it was intended to be entirely interpreted, so it higher level, as it abstracts more than say plain C.

Another Slashdot Troll Article

[Anonymous Coward]

In other news, Red Hat announced today that its newest Linux release was written entirely in Perl.

A foolish consistency is the hobgoblin of little minds

Because it's not the right tool for the job...

[Anonymous Coward]

.NET is not intended for OS development. It is intended for business application (web or desktop) development. A similar comparison would be how many web sites are now developed in C++, none because it is not efficient and is the wrong tool for the job. I'm still waiting for an article that is critical because Sun hasn't developed Solaris in JAVA, but I doubt that will happen either because it would be silly. This is more a slash dot circle jerk against MS.

Vista's supposed to be mostly new...

[Svartalf]

...not mostly old stuff... But hey, that's marketing for you.

only conclusion that can be made from these result

[Anonymous Coward]

Yes. That is indeed the ONLY conclusion one could make - on Slashdot.

In other news

[borgboy]

Solaris is written in C!

OMG!

No Way!

MFC's the basis for VS, but...

[Svartalf]

...it's still not really classes and pretty stilted to code for in the first place. Just because a "winning" environment uses something, it does not go to be that it's good and usable for anything other than that application- and you just don't know how problematic development for VS might be.

If it ain't broke...

[gravyface]

...don't fix it. 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? With Vista as late as it is, I doubt they have the time to port all their working user-land apps over to .Niet, and quite frankly, I'm glad they didn't -- why introduce new bugs in a well-tested, stable (yes, stable, I can't recall ever hearing of notepad crashing) application for the sake of the .Niet Marketing initiative? They really don't need to either; go to monster.com and search for ".NET developer" and you'll see what I'm talking about.

Win32 promotes bugs

[Makarakalax]

If it was written in Win32, IME it would take a lot longer before it was a bug-free and stable application. c# encourages better programming in the first place.

So for 12 months all your users may take twice as long to use the app due to crashes and buggy behaviour if you wrote it in win32.

Only 1 version of CLR can be in memory

[Anonymous Coward]

You can't have .net applications in the OS because only 1 version of the CLR can be running at one time. The OS would essentially lock the computer at the version of .net it was using -- or worse -- crash if another app had loaded a previous version into memory.

Honestly, Grimes has to know this -- and by not including it at the top of the article, it makes me suspect this was just a troll.

To ActiveX or to not ActiveX, that is the question

[Latent Heat]

Should a tools/component developer hang on to their legacy ActiveX codebase or should they reimplement everything as .NET controls?

Windows 95 was a big thing on a number of fronts -- preemptive processes and threads, 32-bit virtual memory, the Start button, standardized File dialogs. Another front was the COM/ActiveX component software model.

Having some kind of object and/or software component standard at the operating system level has been this long-time dream -- Taligent/Pink, Copeland, Open Doc, Wirth's Black Box. For all of its warts, COM and ActiveX became the standard for Windows, using an object-reference based standard to replace earlier attempts based on Windows messages and HWNDs.

Besides that ActiveX became the new plumbing for Visual Basic widgets, Microsoft did consume their own dog food in that COM/ActiveX became pervasive throughout the Windows desktop and desktop apps. Think of all of those demo programs of how to control Excel through your favorite scripting language (Automation) or how to include an IE window into your GUI (ActiveX). There is a lot more code sharing on the Windows desktop than you realize thanks to COM and ActiveX and the fact that Microsoft uses it.

I am in the boat that it has taken me a good 10 years to absorb the lessons of ActiveX, to decide on tools to develop for it, to develop software in it, to consume one's own dog food and use one's own ActiveX controls, to develop ActiveX libraries for commercial release. And this .NET thing comes along. Is this the Wave, should I drop everything I am doing in ActiveX and write .NET components? Or should I keep plodding along because that is what Microsoft is doing -- they too have 10 years invested in their own ActiveX libraries and are not about to start over.

ActiveX is incredibly crufty -- no one knows what half the interfaces do, and no one develops for it from ground zero without using automatic code generation from either Microsoft or some 3rd party tools (Delphi), and no one knows what that automatic code generation is doing. ActiveX controls are clunky in that they are software components, but they are not true object classes that you can inherit and extend in your own applications. But they get the job done, they are superbly language-independent (of course restricted to the Windows world), and .NET apps can mix and match ActiveX widgets with the newer .NET widgets.

So why .NET widgets? They allow true object inheritence, the crufty parts are better hidden and encapsulated away, and they are, well, the new thing! On the other hand, everything from the open-source Python to the commercial Matlab has excellent support for ActiveX but nothing for .NET widgets.

When someone does this analysis of .Net use in Vista, this is not just a matter of "ha, Microsoft doesn't eat their own dogfood." I really need to know what state my investment in ActiveX is in and where I need to go next. For example, the current support for 2-D graphics in .NET is rather hamstrung compared to what you can do with CreateDIBSection and ScrollWindowEx under Win32/ActiveX. On the other hand, if there is a whole 'nother graphics model under Vista requiring .NET to access, and if legacy ActiveX controls under Vista start looking like 16-bit Windows apps under Windows 95, then I have to respond to that. But if Microsoft hasn't seen the need to bother with reimplementing their disktop apps under .NET, maybe I am OK with my stuff. If they have reimplemented their desktop stuff to give it a Vista/Aero look but are not using .NET to do it, I sure as heck want to know what they are using instead.

In case you are wondering, I am looking to Java if I have to go through the bother of rewriting all my ActiveX stuff. First off, the BufferedImage.setRGB() and Graphics.copyArea are pretty m

this doesn't contradict what MS says

[rnd()]

The idea of the .NET framework is to make it easy to create robust applications quickly, writing as little code as possible.

The goal of Operating System code is to be as fast as possible.

The two goals aren't best solved in the same way, which is why MS didn't solve them that way. The important thing is that you can use .NET to add on functionality to the core OS seamlessly.

Microsoft has rewritten Notepad in .Net

[SoopahMan]

It's a technicality, but actually Microsoft has written Notepad in .Net - it comes as a free example app with the SDK. They've even shown how to do it as a tabbed interface, or how to draw it with 3D calls.

But, the basic Notepad in .Net incurs a small startup hit as the .Net library kicks off, so it doesn't start quite as fast as the existing Win32 Notepad app, which is pretty much the fastest-starting app of any use in Windows. So, you get both - a free .Net Notepad implementation to play with, and a faster-starting native one built-in. I think that's a nice way to slice it.

If Microsoft rewrites any of these apps in .Net, it won't just be in .Net - it'll be in Sparkle. Look for that as an awkward Plus pack in 2008 or 2009 that's eventually integrated into the version of Windows after Vista/Longhorn.

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.

Old News

[ClubStew]

Have you been living in a hole? Microsoft publicly announced that .NET would not be core to Vista (then, "Longhorn") and listed many reasons why, but that it would consider putting some of the effort back into the V.next release.

You need to read /. more often if you're going to post crap.

Notepad *has* changed

[DrSkwid]

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

Re:Notepad *has* changed

[mixmasta]

that was improved in win2k, I think.

Re:Notepad *has* changed

[DrSkwid]

You'll find it was on NT that notepad increased its text size capability.

64k is the maximum amount of memory you could malloc on x86 in real mode becuase 64k is the segment size.

It is also why Win 3x/9x would run out of memory as resources such as fonts & icons where all kept in one segment.

Memory Consumption

[Wolvey]

Launch notepad.exe and look in Task Manager (yes I know). How much memory does it use? Roughly 2900KB. Now compile a .NET application that does nothing more than:

static void Main() { Application.Run(new Form()); }

This uses 6300KB, and we have zero functionality coded. .NET is freaking amazing when you need to write a complex system in a minimal amount of time, but there is a price. If Vista came out and suddenly RAM requirements doubled (they may still) we /.ers would tear 'em a new one.

Really, we're gonna tear 'em a new one no matter what they do...

Are they using Visual Studio 6? :)

[argent]

You know, there's a lot of developers who prefer VS6 to its successors, and there's even community patches to keep the libraries up to spec. It wouldn't surprise me if there's people in Microsoft still using VS6 and checking on VS200x occasionally to take advantage of its tighter syntax checking.

Well, duh.

[moochfish]

I always thought the power of .NET was its speed for development, not its execution. I think it's kind of silly to think it's some magical tool that makes programming easier AND YET is as fast as native code. I'd be horrified if Microsoft made their OS based on .NET. Everything would be even more bloated than it already is. Seems like a trolling observation to me.

Really?

[ZxCv]

I've been working with both C# and Objective-C for a good 5+ years now and there's good and bad about both. However, you are slightly off on a couple things:

Cocoa's default language (Objective C) is not interpreted at runtime

And neither is C#. It is compiled at runtime. Meaning that once the program is running, it is no slower than it would be as a "native" app.

This makes it almost as fast as raw C.

And yet, its no faster than C#. And with as much experience I have using both side-by-side, I can definitively say that if you can't get the same performance from an algorithm written in C# as one written in Obj-C, you are most likely doing something wrong.

Bottom line, both Obj-C and C# have their advantages over the other, but raw speed is not one of them.

Re:Really?

[ivoras]

I'd be first to advertise that a) Microsoft has really good JIT compilers and b) better algorithms always win over brute force speed but the fact is that using non-native code has at least two downsides:

• Something sometime has to translate it to native code (so at best, the startup time of the app is increased)
• It takes more memory to load the intermediate code, compile it and run it than to load and run native code

Additionally, Obj-C is not garbage collected, so it doesn't have "the usual suspects" issues of GC (application pause while collecting garbage, oportunity for bloat, etc.). In the absolute performance, native code will almost always win.

(BUT: it's true that with todays machines, memory configurations and the "usual" applications, most users probably won't distinguish between a hand-coded assembler application and a totaly interpreted one)

Notepad handles Unicode better than Visual Studio

[SloppyElvis]

...and the text editor never freezes because Intellisense is barfing.

Ever try to work with Unicode translations in east asian languages in Visual Studio? Guess what, it craps out horribly. Notepad is your best option unless you've got the money to buy some specialized big $$$ software for the task (or write your own, I guess). It is absurd that in this day and age, translation support is so crappy in Windows dev tools. Anyone know of some OSS software for Unicode file editing that doesn't Sh1t all over the line feeds and such?

Notepad doesn't require you wait for a runtime to startup. It is very quick to launch. One of the first things I do to a Windows box is put Notepad in the SendTo context menu.

It is a stupid simple program, and that is probably a major reason why it works. I often get angry about the single level of undo and other such shortcomings, but I still find myself using Notepad quite a bit.

They should rewrite Visual Studio, because it has some serious stability issues. Oh wait, they do that every year or so, and it never gets better.

Re:To ActiveX or to not ActiveX, that is the quest

[metallic]

You don't have to throw all that work away unless you want to. It's fairly trivial to use COM/ActiveX from .NET using COM interop. Visual Studio will generate a wrapper around the COM object for use by a .NET application. The interface that is exposed is usually pretty crufty, at least from my experience with doing Word automation from ASP.NET (don't ask...).

P.S Say what ?!

[MickDownUnder]

You do OS development.... yet you've not used C++ in 10 years ?

I'm curious .... What are you developing in ?

I've not heard of an OS out there that's not implemented in C++ or C.

Re:P.S Say what ?!

[Eivind Eklund]

I use C, and occasionally assembly.

And I still suspect you're missing the point of how many OS components can run with effectively NO privileges, and how to use bridges for the cases where they don't. There is little point in arguing further, though - I'm obviously fairly short on knowledge of .NET, and from how you write it seems like you're not experienced with OS programming, which gives us very little common ground to discuss this (especially since I don't have time to learn details of .NET).

Let's just agree to disagree, OK?

Eivind.

Re:P.S Say what ?!

[MickDownUnder]

I don't think you understand what exactly I was getting at. I don't disagree with your assessment as to how an OS should be constructed, I disagreed with your assumption that Microsoft had overlooked this approach simply because they have not utlised .NET in implementing its kernel for Vista. My point was that I don't think .NET would be suitable in it's current form. If I were Microsoft and I were wishing to write a kernel using a VM like .NET, I would actually take .NET and customise it specifically for the job of building the OS. I would not write it on .NET out of the box, in particular the evidence based security in .NET out of the box simply would not facilitate what you'd need to do in constructing a kernel.

I think your comment and this whole topic has just revealed what a petty silly little website slashdot is, it's really lost it's credibility with me as a serious source of technical discussion.

Re:P.S Say what ?!

[Eivind Eklund]

You are making the assumption that "OS" is "kernel". It isn't. A kernel is a very small piece of an operating system. I have not at any time been talking about constructing the kernel in .NET; that would, indeed, be silly.

Eivind.