Linked by Eugenia Loli on Thu 16th Mar 2006 03:00 UTC
.NET (dotGNU too) 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.
Order by: Score:
Flawed Conclusions
by n4cer on Thu 16th Mar 2006 04:27 UTC
n4cer
Member since:
2005-07-06

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.

Reply Score: 5

RE: Flawed Conclusions
by kaiwai on Thu 16th Mar 2006 05:35 UTC in reply to "Flawed Conclusions"
kaiwai Member since:
2005-07-06

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.

Reply Score: 1

RE: Flawed Conclusions
by gonzalo on Thu 16th Mar 2006 06:40 UTC in reply to "Flawed Conclusions"
gonzalo Member since:
2005-07-06

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.

Reply Score: 3

RE[2]: Flawed Conclusions
by n4cer on Thu 16th Mar 2006 06:50 UTC in reply to "RE: Flawed Conclusions"
n4cer Member since:
2005-07-06

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.

Reply Score: 5

RE[3]: Flawed Conclusions
by gonzalo on Thu 16th Mar 2006 09:45 UTC in reply to "RE[2]: Flawed Conclusions"
gonzalo Member since:
2005-07-06

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.

Reply Score: 1

RE[4]: Flawed Conclusions
by n4cer on Thu 16th Mar 2006 10:38 UTC in reply to "RE[3]: Flawed Conclusions"
n4cer Member since:
2005-07-06

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.

Reply Score: 3

RE[5]: Flawed Conclusions
by gonzalo on Thu 16th Mar 2006 10:49 UTC in reply to "RE[4]: Flawed Conclusions"
gonzalo Member since:
2005-07-06

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.

Reply Score: 2

RE[6]: Flawed Conclusions
by n4cer on Thu 16th Mar 2006 11:02 UTC in reply to "RE[5]: Flawed Conclusions"
n4cer Member since:
2005-07-06

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.

Reply Score: 1

Nonsense
by makfu on Thu 16th Mar 2006 05:15 UTC
makfu
Member since:
2005-12-18

This whole article is just total nonsense.

Reply Score: 1

RE[2]: Flawed Conclusions
by Wondercool on Thu 16th Mar 2006 07:44 UTC
Wondercool
Member since:
2005-07-08

"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

Reply Score: 2

RE[3]: Flawed Conclusions
by n4cer on Thu 16th Mar 2006 09:12 UTC in reply to "RE[2]: Flawed Conclusions"
n4cer Member since:
2005-07-06

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.

Reply Score: 4

RE[4]: Flawed Conclusions
by kaiwai on Fri 17th Mar 2006 08:04 UTC in reply to "RE[3]: Flawed Conclusions"
kaiwai Member since:
2005-07-06

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.

Reply Score: 1

Common sense?
by Jamie on Thu 16th Mar 2006 11:22 UTC
Jamie
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.

Reply Score: 5

RE: Common sense?
by load_mic on Thu 16th Mar 2006 14:26 UTC in reply to "Common sense?"
load_mic Member since:
2005-12-13

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.

Reply Score: 2

RE[2]: Common sense?
by sappyvcv on Thu 16th Mar 2006 14:56 UTC in reply to "RE: Common sense?"
sappyvcv 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.

Reply Score: 4

RE[3]: Common sense?
by Jamie on Thu 16th Mar 2006 16:18 UTC in reply to "RE[2]: Common sense?"
Jamie Member since:
2005-07-06

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)

Reply Score: 1

RE[4]: Common sense?
by sappyvcv on Thu 16th Mar 2006 19:38 UTC in reply to "RE[3]: Common sense?"
sappyvcv Member since:
2005-07-06

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

Reply Score: 1

RE[2]: Common sense?
by whackedoutsavage on Thu 16th Mar 2006 15:50 UTC in reply to "RE: Common sense?"
whackedoutsavage 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.

Reply Score: 1

RE: Common sense?
by MightyPenguin on Thu 16th Mar 2006 15:06 UTC in reply to "Common sense?"
MightyPenguin 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.

Reply Score: 3

RE[2]: Common sense?
by n4cer on Thu 16th Mar 2006 21:38 UTC in reply to "RE: Common sense?"
n4cer 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.

Reply Score: 2

RE: Common sense?
by null_pointer_us on Thu 16th Mar 2006 15:16 UTC in reply to "Common sense?"
null_pointer_us 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

Reply Score: 1

RE: Common sense?
by BluenoseJake on Thu 16th Mar 2006 17:22 UTC in reply to "Common sense?"
BluenoseJake Member since:
2005-08-11

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

Reply Score: 1

Not an issue with 2.0
by barcode on Thu 16th Mar 2006 14:41 UTC
barcode
Member since:
2005-08-02

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.

Reply Score: 1

RE: Not an issue with 2.0
by n4cer on Thu 16th Mar 2006 21:15 UTC in reply to "Not an issue with 2.0"
n4cer Member since:
2005-07-06

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.

Reply Score: 1

dogen
Member since:
2005-11-13

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.

Reply Score: 1

In that case
by Shannara on Thu 16th Mar 2006 16:51 UTC in reply to "author doesn't get it - .Net is not the only road."
Shannara Member since:
2005-07-06

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.

Reply Score: 1

RE: In that case
by sappyvcv on Thu 16th Mar 2006 19:40 UTC in reply to "In that case"
sappyvcv Member since:
2005-07-06

Are you calling not being open-source a defect?

Hahahahahaha.

Reply Score: 1

RE: In that case
by n4cer on Thu 16th Mar 2006 21:46 UTC in reply to "In that case"
n4cer Member since:
2005-07-06

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.

Reply Score: 5

RE[2]: In that case
by kaiwai on Fri 17th Mar 2006 08:23 UTC in reply to "RE: In that case"
kaiwai Member since:
2005-07-06

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.

Reply Score: 1

RE[2]: In that case
by Shannara on Fri 17th Mar 2006 18:28 UTC in reply to "RE: In that case"
Shannara Member since:
2005-07-06

Sometimes it helps not to believe in the myth of security through obscurity .... obfuscator builds on that myth ;) Doesnt make it usefull ;)

Reply Score: 1

RE: In that case
by jayson.knight on Thu 16th Mar 2006 21:47 UTC in reply to "In that case"
jayson.knight Member since:
2005-07-06

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

Reply Score: 1

null_pointer_us Member since:
2005-08-19

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.

Reply Score: 1

...
by suryad on Thu 16th Mar 2006 18:09 UTC
suryad
Member since:
2005-07-09

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.

Reply Score: 2

Geoff Gigg
Member since:
2006-01-21

This article of Joel Spolsky is on topic:

http://www.joelonsoftware.com/articles/fog0000000012.html

Geoff

Reply Score: 2