Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Analysis of .NET Use in Longhorn and Vista 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.""
This discussion has been archived. No new comments can be posted.

Analysis of .NET Use in Longhorn and Vista

Comments Filter:
  • Re:Uh... (Score:1, Informative)

    by Anonymous Coward on Wednesday March 15, 2006 @11:07PM (#14929973)
    The interpreter caches the resulting machine code after JITting it the first time.
  • by CastrTroy ( 595695 ) on Wednesday March 15, 2006 @11:18PM (#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.
  • So? (Score:5, Informative)

    by WalterGR ( 106787 ) on Wednesday March 15, 2006 @11:29PM (#14930083) Homepage

    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:Not suprising. (Score:3, Informative)

    by bphant ( 650357 ) on Wednesday March 15, 2006 @11:38PM (#14930124) Homepage
    .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).
  • by drsmithy ( 35869 ) <drsmithy@nOSPAm.gmail.com> on Wednesday March 15, 2006 @11:54PM (#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.

  • Re:What? (Score:3, Informative)

    by maelstrom ( 638 ) on Wednesday March 15, 2006 @11:56PM (#14930203) Homepage Journal
    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.

  • by 3770 ( 560838 ) on Thursday March 16, 2006 @12:12AM (#14930276) Homepage

    Deploy your applications with clickonce. Problem solved.
  • by xiphoris ( 839465 ) on Thursday March 16, 2006 @12:19AM (#14930302) Homepage
    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:No Duh (Score:3, Informative)

    by 0xdeadbeef ( 28836 ) on Thursday March 16, 2006 @12:21AM (#14930313) Homepage Journal
    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.
  • by Joe U ( 443617 ) on Thursday March 16, 2006 @12:22AM (#14930317) Homepage Journal
    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)
  • Your sig is a lie (Score:5, Informative)

    by xiphoris ( 839465 ) on Thursday March 16, 2006 @12:23AM (#14930320) Homepage
    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 [answers.com]. You can read about those of effect here [answers.com], if you want to learn more.

    Anyway, please change your sig. It's bad to spread misinformation.
  • Seriosuly. (Score:2, Informative)

    by Dogun ( 7502 ) on Thursday March 16, 2006 @12:24AM (#14930323) Homepage
    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:Your sig is a lie (Score:4, Informative)

    by sik0fewl ( 561285 ) <xxdigitalhellxxNO@SPAMhotmail.com> on Thursday March 16, 2006 @12:36AM (#14930364) Homepage

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

  • Re:No Duh (Score:5, Informative)

    by NullProg ( 70833 ) on Thursday March 16, 2006 @12:39AM (#14930372) Homepage Journal
    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 [msdnaa.net]


    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 [microsoft.com]

    *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:Well DUH (Score:5, Informative)

    by tshak ( 173364 ) on Thursday March 16, 2006 @12:47AM (#14930399) Homepage
    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.
  • so i've heard (Score:2, Informative)

    by Anonymous Coward on Thursday March 16, 2006 @12:53AM (#14930421)
    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:Well DUH (Score:5, Informative)

    by Coryoth ( 254751 ) on Thursday March 16, 2006 @01:00AM (#14930447) Homepage Journal
    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 [microsoft.com] 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.
  • by Anonymous Coward on Thursday March 16, 2006 @01:11AM (#14930479)
    "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.

  • 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.
  • by man_of_mr_e ( 217855 ) on Thursday March 16, 2006 @02:47AM (#14930878)
    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.
  • by DrXym ( 126579 ) on Thursday March 16, 2006 @05:46AM (#14931387)
    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:Can't blame them (Score:3, Informative)

    by gbjbaanb ( 229885 ) on Thursday March 16, 2006 @07:45AM (#14931713)
    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:Well DUH (Score:5, Informative)

    by diegocgteleline.es ( 653730 ) on Thursday March 16, 2006 @08:06AM (#14931774)
    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 (Score:2, Informative)

    by plague3106 ( 71849 ) on Thursday March 16, 2006 @09:11AM (#14932016)
    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 (Score:2, Informative)

    by plague3106 ( 71849 ) on Thursday March 16, 2006 @09:16AM (#14932043)
    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 [ondotnet.com]

    It was written 3 years ago though, but seems to make sense still.
  • Re:Dogfood (Score:3, Informative)

    by Doc Ruby ( 173196 ) on Thursday March 16, 2006 @10:17AM (#14932502) Homepage Journal
    Not only is your vehement "no" merely the uncited denials of an Anonymous Coward, another poster has actual eyewitness accounts [slashdot.org] 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.
  • by DrSkwid ( 118965 ) on Thursday March 16, 2006 @01:24PM (#14934595) Journal
    It no longer has a 64k file size restriction [microsoft.com] and now lets you have extensions that are not .txt.

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Working...