This article presents results of an investigation of the usage of .NET on five versions of Windows. The operating system files for the first version of Windows tested, XP Pro with Service Pack 2 applied, did not use .NET at all. This is understandable because XP was released before .NET was first released. The next version of Windows was the PDC 2003 build of Longhorn. This has a similar number of unmanaged executable files as XPSP2 but it also had thirty five .NET assemblies. Amongst these assemblies were two services.
To read all comments associated with this story, please click here.
Member since:2005-12-13
Member since:2005-07-06
One word (or acronym): RAD
.NET is great for anything that doesn't need all the processing power it can get, can use a little extra memory, and will not be terribly affected by the overhead.
The reason for this overhead is security and reliability. .NET is memory managed, so the chance for stuff like buffer overflows and memory leaks is slim to none.
.NET is very locked down and pushes security over performance. They are offering a solution for security problems (In writing apps I mean). I honestly think the .NET framework is the first thing Microsoft really got right security-wise in a while (Server 2003 and IIS6 are very good though).
There have been 6 vulnerabilities for the 1.x framework in 3 years. Only one was "highly critical", and that was the JPEG processing which wasn't specific to the framework.
Member since:2006-03-16
well, now you know of one.
http://www.adam.com/aia/features.htm
written in C# on the 1.1 platform.
Member since:2005-11-18
Have you checked that those numbers you quote scale linearly past 1 application? It's fairly likely that adding a second .Net app will have significantly less memory load since the interpreter and most libraries are shared.
As an example, one of my .Net apps in bytecode form is only 24kb. So odds are, given enough .Net executables, you might actually see an overal memory savings. Obviously a caveat here is how many non-native data types your .Net apps use.
Member since:2005-07-06
Have you checked that those numbers you quote scale linearly past 1 application? It's fairly likely that adding a second .Net app will have significantly less memory load since the interpreter and most libraries are shared.
This is correct. You can't get an accurate benchmark of .NET performance vs. unmanaged using trivial apps like Hello World. You pay an initial cost due to GC, security, and other services that get initialized. If the app is of any size, and/or you are running multiple .NET apps, the numbers get closer to unmanaged code. There are several commercial apps from MS and third parties that use managed code. In the Vista timeframe, any application that uses Avalon, Indigo, WinOE, WinFS (to use the codenames that may be more familliar to people) will be using .NET.
Member since:2005-08-19
With that logic we should be 10x more grateful that Microsoft did not scrap Longhorn for a rebranded Linux distribution. After all, the system monitor says the Gnome clock applet consumes nearly 150 MB - and so do most of the other applets. Imagine running an office suite on Linux! You'd need at least 16 GB for a decent workstation. ;-)
Edited 2006-03-16 15:17
Member since:2005-08-11
Member since:
2005-07-06
Whilst there may be legitimate reasons for MS scaling back the use of .Net in Vista (as stated in other posts) there also a number of advantages in not using .Net:
1) Less memory and resources required. Heck even a hello world app that uses a window and a button takes 15MB RAM in .Net!
Had MS used .Net more extensively then the base RAM requirement would have proabably shot up from 512MB to 1GB
2) Better performance and in particular with bigger apps. .Net's performance overhead increases with the more objects/widgets your apps has ergo its not ideal for big stuff. Also as the article said to get better performance you need to rewrite existing apps from scratch in pure .Net otherwise the overhead of mixing significant amounts of unmanaged and managed code can seriously degrade performance.
3) Faster start up time of native apps. This is normally quite noticable.
Overall there are significant quality improvements when using native over managed apps.