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.
Analysis of .NET Use in Longhorn, Vista
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
My conclusion is that Microsoft has lost its confidence in .NET. They implement very little of their own code using .NET. The framework is provided as part of the operating system, but this is so that code written by third party developers can run on Vista without the large download of the framework.
In reality, MS’ limited targeting of .NET/WinFX for platform code because it’d be like building on a fondation of loose sand. Both .NET and WinFX were constantly moving targets at the time, and the OS teams were avoid dependencies on such moving targets after the “reset” unless they had to take them, because the dependencies slowed down development (fixing build breaks during constant API changes) and (such as in the case of WinFS) the base system could be removed if it wasn’t passing the quality gates or. based on feedback, needed more engineering work that would place its release beyond the goal for RTM.
If they lost confidence and provided the managed frameworks only for third parties, they wouldn’t be releasing tools like Expression Interactive Designer which is written in managed code, using the WinFX APIs.
That, and the fact that it only detects ‘managed assemblies’ – what about those which are a mixture of managed and unmanaged code? it doesn’t actually tell us anything as to whether there is native compiled code, but they also link back to managed code for the heavy lifting.
True about the Expression Interactive Designer, but I would also personally would like to see the next messenger and other things that ‘expose’ themselves to the network, to be managed as well; which should push security up a few notches.
MS’ limited targeting of .NET/WinFX for platform code because it’d be like building on a fondation of loose sand
That’s true, but it was not a problem for trying to ‘sell’ .Net as the greatest invention since… Java.
It does not show confidence in the platform itself as a really viable way of doing things, just as a sellable product.
That’s true, but it was not a problem for trying to ‘sell’ .Net as the greatest invention since… Java.
The platform they were selling was in final form and released (.NET v. 1.0 and 1.1). The platform they were building WinFX and Vista on was in development (.NET 2.0), but nice try.
but nice try
Oh. Don’t get me wrong, I’m not trying anything.
But anyway… does selling version 1.1 and not wanting to adopt version 2.0 really show confidence? I’m just asking.
I may not see, as the article author pretends, that Ms has lost its confidence in .Net, but I certainly don’t see your point either.
But anyway… does selling version 1.1 and not wanting to adopt version 2.0 really show confidence? I’m just asking.
As stated earlier, they are using 2.0 (they even have commercial applications that use 1.x). WinFX is built on 2.0. If you use WPF, WCF, WF, et al, you are using .NET 2.0 code. If you use MSH, that’s .NET 2.0, EID is WinFX/.NET 2.0, Office 12 uses WF. SQL Server 2005 hosts .NET 2.0.
If you see a lack of confidence, you don’t have a view of the full picture.
If you see a lack of confidence…
In case you missed it:
I may not see, as the article author pretends, that Ms has lost its confidence in .Net, but I certainly don’t see your point either.
In case you missed it:
I may not see, as the article author pretends, that Ms has lost its confidence in .Net, but I certainly don’t see your point either.
My mistake. The rest still stands WRT seeing the point.
This whole article is just total nonsense.
“The platform they were selling was in final form and released (.NET v. 1.0 and 1.1). The platform they were building WinFX and Vista on was in development (.NET 2.0), but nice try.”
But still: if MS can not build against .NET 2.0 (because it is a moving target), why do they expect builders to code for 1.0 or 1.1 and later have to rebuild it for 2.0?? I still think Gonzalo has a point here.
Apparently the differences between 1.1 and 2.0 are so big that it is not trivial to go from 1.1 to 2.0.
Else MS own developers would have started coding in 1.1 and have a (near) trivial port 4 years later when the final 2.0 comes out
But still: if MS can not build against .NET 2.0 (because it is a moving target), why do they expect builders to code for 1.0 or 1.1 and later have to rebuild it for 2.0?? I still think Gonzalo has a point here.
Apparently the differences between 1.1 and 2.0 are so big that it is not trivial to go from 1.1 to 2.0.
Else MS own developers would have started coding in 1.1 and have a (near) trivial port 4 years later when the final 2.0 comes out
In the majority of cases, 1.0/1.1 apps would not have to be rebuilt against 2.0. That’s not the issue at all. The issue is that WinFX and anything that took a dependency on it was dependent on .NET 2.0, which was currently in active development. WinFX uses many features that are specific to .NET 2.0. During the time of Vista’s development, the APIs for both .NET 2.0 and WinFX were in constant flux. New features were being developed, and others were undergoing API changes based on feedback from MS’ partners and the wider development community. It’s hard to use something as a base when changes in the API and behavorial changes occur from build to build (which could be daily internally). This is concerning new functionality like partial types, iterators, generics, and new class libraries, not anything that involved .NET 1.x.
In reference to .NET, from what it looks like, things have stablised, and 3.0 will be merely a move of extending the foundation through more libraries, and some enhancements at the compiler level, all in all, compatibility with 2.0 will be maintained.
As for WinFX; its a completely new API for programmers to target; no different to the transition from win16 to win32, but the tranisition is alot more radical.
What I do hope is that Microsoft does a good job evangelising the features in WinFX to win over companies, so as a result, we eventually start seeing software take full advantage of the features which Microsoft have included.
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.
I can’t see .NET being used for any sort of serious multimedia or systems applications or, for that matter, consumer shrink wrapped software.
I’m quite baffled at all the attention .NET ( and Java ) gets.
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.
One word (or acronym): RAD
But I get all that already with Delphi!
And pyhton is even morer RAD than c#.
Delphi is also fairly safe and it basically gives you everything c# offers but without any bloat, overhead or excessive memory consumption at all.
.Net rocks with asp.net and like Java is better suited for server side stuff where security is paramount. (security for user space apps is not really an issue!).
Also bear in mind that underneath the .Net framework is the more traditional c/c++ libs so any vulnerability there can still be exploited (IOW .Net does not guaranteee your code is safe rather it makes it safer relatively speaking)
Some people hate Delphi (Pascal is ugly, IMHO). I hate the IDE as well.
Python also can’t be compiled to native code as well as C#.
As far as memory consumption and what not… I’m not all that familiar with Delphi, so I couldn’t say. But again, some people simply don’t like Delphi and/or the IDE. VS.Net and C# is a killer combo I think. Even though I rarely use C#.
well, now you know of one.
http://www.adam.com/aia/features.htm
written in C# on the 1.1 platform.
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.
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.
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
Hello World is certainly not 15MB, come on, get a grip on reality here, I’ll agree with you ont he startup times, but 15MBs? that’s just silly
I don’t think the fact that a new version of the .Net framework was about to be released (2.0) was the reason why they did not use .Net for system libraries and services. Frameworks are always being updated and this does not prevent developers from using the current framework.
If a team of developers are working on creating a system service or library and the current (stable) version of .Net is 1.1, then that’s what they should use. Converting to 2.0 (or later) can be done as a next iteration of the product.
If a team of developers are working on creating a system service or library and the current (stable) version of .Net is 1.1, then that’s what they should use. Converting to 2.0 (or later) can be done as a next iteration of the product.
MS could not do this as they were directly dependent on features only available in 2.0. They were developing features for 2.0 that WinFX was going to use throughout its API.
Some people are sort of dim-wittedly single-minded. .Net is not in Vista because it’s an application tool, not a systems tool. Just because you like .Net doesn’t mean you should tatoo it on your ass and try to butter your bread with it.
In that case, Microsoft have no reason NOT to script Office 2007 in .NET. There are no reasons why they should not. As I see it, They already have SQL Management Studio in 100% .NET (Look at the memory hog/bloat, and slowness of it). So … … … ?
If Microsoft fixed the defect in .NET since 1.0, ie source code available to everybody at any time … then .NET might be a decent development platform .. until then, it’s another oddity at the freak circus.
Are you calling not being open-source a defect?
Hahahahahaha.
In that case, Microsoft have no reason NOT to script Office 2007 in .NET. There are no reasons why they should not.
If by “script” you mean they should allow you to use the Office object model from managed code to create custom actions or applications that use Office, you can already do this in Office 2003 as well as in 2007.
If you’re saying they should rewrite Office 2007 in managed code, this makes absolutely no sense. There are newer Office applications like Business Contact Manager that are written in managed code however.
If Microsoft fixed the defect in .NET since 1.0, ie source code available to everybody at any time … then .NET might be a decent development platform .. until then, it’s another oddity at the freak circus.
This isn’t a defect. Get an obfuscator. There are many on the market, and a limited version of one comes with Visual Studio.
This isn’t a defect. Get an obfuscator. There are many on the market, and a limited version of one comes with Visual Studio.
True, and same situation would be required if one compiled their code into Java bytecode. There are even C/C++ obfuscators as well.
Sometimes it helps not to believe in the myth of security through obscurity …. obfuscator builds on that myth
Doesnt make it usefull 
“ie source code available to everybody at any time”
You’ve never heard of rotor then: http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7…
There’s your 1.0 source code. And look, it even builds on other OS’s.
Vista includes applications such as the firewall, malware guard, web browser, mail client, IM client, etc. along with all the accessories and simple GUIs front ends for system settings. No one is expecting the kernel or drivers to be written using .NET.
The article has some good points. It is interesting and I do remember the channel9 vids when they were touting Avalon and so on but I think the author must have missed it when an MS boffin came out and said that Blackcomb aka Vienna is goign to be using more and moer .NET stuff and use Avalon and WinFX waaaaaaay more than what is going to be used in Vista simply because all these APIs are brand new and they wanted Vista to be the platform where it matures and then Vienna is where it would be used in the way the author of this article wants.
This article of Joel Spolsky is on topic:
http://www.joelonsoftware.com/articles/fog0000000012.html
Geoff