×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Analysis of .NET Use in Longhorn and Vista

samzenpus posted more than 8 years ago | from the what-would-bill-do dept.

479

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

479 comments

first (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14929938)

Well, duh.

frastus psotus (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14929942)

frastus psotus

Well DUH (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14929944)

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 (5, Interesting)

CastrTroy (595695) | more than 8 years ago | (#14929990)

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 (1)

DarkOx (621550) | more than 8 years ago | (#14930061)

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 (3, Insightful)

Albinofrenchy (844079) | more than 8 years ago | (#14930185)

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.

You don't need a virtual machine. (0)

Anonymous Coward | more than 8 years ago | (#14930277)

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.

Re:Well DUH (5, Interesting)

AstroDrabb (534369) | more than 8 years ago | (#14930062)

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 (4, Interesting)

Jason Earl (1894) | more than 8 years ago | (#14930088)

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 (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14930163)

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 (0)

Anonymous Coward | more than 8 years ago | (#14930199)

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 (2, Insightful)

Jason Earl (1894) | more than 8 years ago | (#14930244)

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 (5, Interesting)

digitalinfinity (875333) | more than 8 years ago | (#14930193)

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 (0)

Anonymous Coward | more than 8 years ago | (#14930275)

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

Easy: you don't start over unless you have to (5, Insightful)

xiphoris (839465) | more than 8 years ago | (#14930286)

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:Well DUH (1)

yabos (719499) | more than 8 years ago | (#14930319)

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.

Whereas applications on the other hand... (4, Funny)

Colin Smith (2679) | more than 8 years ago | (#14930109)

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

 

Re:Well DUH (2, Interesting)

jbplou (732414) | more than 8 years ago | (#14930125)

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 (1)

this great guy (922511) | more than 8 years ago | (#14930152)

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

Mono (4, Interesting)

zbyte64 (720193) | more than 8 years ago | (#14929946)

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 (2, Insightful)

djradon (105400) | more than 8 years ago | (#14929981)

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 (1)

aussie_a (778472) | more than 8 years ago | (#14929996)

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 (0)

Anonymous Coward | more than 8 years ago | (#14930002)

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

Re:Mono (4, Interesting)

Zeinfeld (263942) | more than 8 years ago | (#14930140)

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 (0)

kabz (770151) | more than 8 years ago | (#14929988)

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!

So.... (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14929947)

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.... (2, Insightful)

Evers (961334) | more than 8 years ago | (#14929978)

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.

So....Coffee Flavoured Chips. (0)

Anonymous Coward | more than 8 years ago | (#14930070)

And yet there are Java Chips [developer.com].

cunty mcunt (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14929951)

ahoy!

Not a good basis for decision (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14929955)

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.

the only good news I've heard about Vista... (4, Funny)

Anonymous Coward | more than 8 years ago | (#14929958)

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

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

Anonymous Coward | more than 8 years ago | (#14930145)

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... (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14929964)

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... (1, Informative)

Anonymous Coward | more than 8 years ago | (#14929973)

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

Of Course! (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14929971)

Look, it has been Bill's dream to put forth BASIC as the
#1 programming language from day 1. c# is BASIC. It is C++-like enough
to placate/trick the C++ users into taking it seriously. But its
a 4GL -- a runtime dependent language.

In the end, C++ is and always will be the language of choice for
the developer that needs to problem solve.

As an added bonus, the more developers that use C#/.NET instead of C++,
the less MS has to be concerned with competition.

Hmmm. So why am I even posting this? I guess I must want competition.... ; )

Re:Of Course! (1)

elchuppa (602031) | more than 8 years ago | (#14930260)

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.

Not suprising. (3, Insightful)

rfernand79 (643913) | more than 8 years ago | (#14929975)

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. (3, Informative)

bphant (650357) | more than 8 years ago | (#14930124)

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

Saint Stephen (19450) | more than 8 years ago | (#14930198)

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

bphant (650357) | more than 8 years ago | (#14930274)

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.

The proof is not OS services (5, Insightful)

BadAnalogyGuy (945258) | more than 8 years ago | (#14929977)

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 (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14930215)

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.

Allez-y! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14929984)

Et tu, Brute?

.NET is for rapid app development (1)

sexyrexy (793497) | more than 8 years ago | (#14929991)

...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 (2, Insightful)

Brandybuck (704397) | more than 8 years ago | (#14930200)

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

Can't blame them (5, Interesting)

electromaggot (597134) | more than 8 years ago | (#14929998)

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 (1)

jbplou (732414) | more than 8 years ago | (#14930099)

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 (0)

Anonymous Coward | more than 8 years ago | (#14930159)

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 (1)

electromaggot (597134) | more than 8 years ago | (#14930213)

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 (2, Funny)

vosgienne (840792) | more than 8 years ago | (#14930126)

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.

When the baby came with instructions (1)

Bucc5062 (856482) | more than 8 years ago | (#14930003)

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 (2, Informative)

CastrTroy (595695) | more than 8 years ago | (#14930029)

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 (2, Informative)

drsmithy (35869) | more than 8 years ago | (#14930195)

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

Size comparison: MFC42.dll vs. .NET Framework (1)

tepples (727027) | more than 8 years ago | (#14930205)

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:When the baby came with instructions (2, Informative)

3770 (560838) | more than 8 years ago | (#14930276)


Deploy your applications with clickonce. Problem solved.

The point here... (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14930007)

.. 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? (1)

BadAnalogyGuy (945258) | more than 8 years ago | (#14930011)

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? (1)

chundo (587998) | more than 8 years ago | (#14930054)

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? (0)

Anonymous Coward | more than 8 years ago | (#14930310)

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? (1)

CajunArson (465943) | more than 8 years ago | (#14930091)

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? (1)

jbplou (732414) | more than 8 years ago | (#14930119)

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? (1)

BadAnalogyGuy (945258) | more than 8 years ago | (#14930127)

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.

Always knew it was a sucker bet (1)

jmorris42 (1458) | more than 8 years ago | (#14930013)

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.

Should consider only new code (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14930015)

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 (2, Insightful)

RobertLTux (260313) | more than 8 years ago | (#14930134)

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"

OT: South Park (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14930027)

Did comedy central pull the scientology episode tonight? They hyped it all week. This could get very interesting.

Java Appliance (0)

kevlar (13509) | more than 8 years ago | (#14930030)

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... (3, Insightful)

mattgreen (701203) | more than 8 years ago | (#14930040)

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

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

Irrelevant (4, Interesting)

popeyethesailor (325796) | more than 8 years ago | (#14930044)

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 (5, Interesting)

kabz (770151) | more than 8 years ago | (#14930133)

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 (0)

Anonymous Coward | more than 8 years ago | (#14930272)

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 (2, Insightful)

caspper69 (548511) | more than 8 years ago | (#14930201)

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.

What is it anyway? (0, Troll)

ArkonChakravanti (953458) | more than 8 years ago | (#14930048)

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? (3, Funny)

TrappedByMyself (861094) | more than 8 years ago | (#14930085)

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? (2, Insightful)

Octorian (14086) | more than 8 years ago | (#14930147)

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? (1)

ArkonChakravanti (953458) | more than 8 years ago | (#14930177)

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? (2, Informative)

xiphoris (839465) | more than 8 years ago | (#14930302)

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.

No Duh (3, Insightful)

NullProg (70833) | more than 8 years ago | (#14930068)

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 (2, Informative)

0xdeadbeef (28836) | more than 8 years ago | (#14930313)

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

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.

Dogfood (2, Insightful)

Doc Ruby (173196) | more than 8 years ago | (#14930072)

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 (0)

Anonymous Coward | more than 8 years ago | (#14930300)

Aside: Hotmail live runs on ASP.net

z0mg (0, Redundant)

Anonymous Coward | more than 8 years ago | (#14930078)

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 (1)

maelstrom (638) | more than 8 years ago | (#14930216)

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? (5, Informative)

WalterGR (106787) | more than 8 years ago | (#14930083)

Read this blog posting [msdn.com] 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? (0)

Anonymous Coward | more than 8 years ago | (#14930139)

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? (2, Funny)

Petrushka (815171) | more than 8 years ago | (#14930261)

--
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? (1)

Petrushka (815171) | more than 8 years ago | (#14930293)

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

What? (1)

d_jedi (773213) | more than 8 years ago | (#14930111)

Is Solaris written in Java, now?

Re:What? (2, Informative)

maelstrom (638) | more than 8 years ago | (#14930203)

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.

Microsoft's first good decision! (1)

JSchwage (961515) | more than 8 years ago | (#14930115)

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 (1)

maelstrom (638) | more than 8 years ago | (#14930120)

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

Anonymous Coward | more than 8 years ago | (#14930268)

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

Reflection! (5, Insightful)

bencvt (686040) | more than 8 years ago | (#14930156)

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 [microsoft.com] 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! (1)

ichin4 (878990) | more than 8 years ago | (#14930241)

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 [aisto.com].) 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! (1)

bencvt (686040) | more than 8 years ago | (#14930305)

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

This wouldn't be the first time (3, Interesting)

Whatsmynickname (557867) | more than 8 years ago | (#14930162)

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 (2, Informative)

Joe U (443617) | more than 8 years ago | (#14930317)

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)

Just a few short months ago... (0, Troll)

Anonymous Coward | more than 8 years ago | (#14930170)

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?

 

nothing new, duh! (1)

smartsaga (804661) | more than 8 years ago | (#14930311)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...