Vista and .NET
-
Marc Clifton wrote:
Anyways, what you think?
Only a moron would implement the core components of an OS in managed code. Or someone with a very very fast computer.
It actually would work well if the OS was managed, as with the Singularity concept OS. The reason for this is that you could then make the CLR itself be the core of the OS, and mitigate a lot of the problems that .NET faces - the need to load the same code into memory repeatedly for each process that uses it, the native interop with the OS, etc. Compiler and JIT optimizations can be more precise, and the GC can become the primary memory allocator, optimizing it to the point that it is better than a native allocator in all respects, and you can also get a number of benefits that can only be had with managed code - for example:
-
The abolishment of the overhead of processes, replaced by App-Domain-based SIPs (saving thousands of CPU cycles that normally go to process creation and scheduling, cross-process communication, etc)
-
Overhead of communication with the kernel and drivers is reduced by 5-10x. This means that OS service call overhead and disk, bus, audio, video, and network I/O time would be reduced.
-
Verifiable and safe applications and drivers - fewer security holes, fewer crashes, fewer hard-to-detect incompatibilities, better defect detection
-
-
Visual Studio 2002, 2003, and 2005 are managed applications.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Moral Muscle The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
I talked to one of the developers at MS when VS2002 was coming out who said they were still writing it all in C/C++. So possibly some of it is in managed code just for interop but I seriously doubt any of the inner workings of 02 or 03 were managed. You might get me to believe there is much more in 05 since it's performance stinks! ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
-
David Stone wrote:
Why unmanaged C++ is still the best tool for Shell Extensions[^]. Also, there's a slieu of documentation/articles about CLR Hosting[^] that you can look at.
Not just shell extensions, managed code is not recommended for global hooks either - for the same reasons. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!Nishant Sivakumar wrote:
Not just shell extensions, managed code is not recommended for global hooks either - for the same reasons.
Excellent point. I should have been broader. Basically, managed code is not recommended for anything that requires the CLR to be loaded by any application that is likely to get targeted by more than one application written against more than one version of the runtime. ;P
They dress you up in white satin, And give you your very own pair of wings In August and Everything After
I'm after everything
-
I disagree that "there are a *lot* of applications" available using fully managed code. At my last job, we spent quite a bit of time debating whether to rewrite our main commercial/shrink-wrapped client application in .NET. We heavily leaned toward .NET but many of us were still concerned whether this was the right decision. One major area of concern was our inability to find examples of shrink-wrapped software written entirely in managed code. To this day, I still haven't found anything comparable to the program we had to write. (I'm not talking about vertical market solutions or the like, though we found nothing their either, but stuff I could buy at a local store.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Shrink wrap no, not at the moment, but that's just because it makes more sense to write completely new apps in .net, it rarely makes sense to port existing ones to it. Vertical market I would hazard a conservative guess that for the windows platform probably 50% of all new apps are written in .net. Microsoft has a list of hundreds of big names that use .net in-house. I guess the real premise behind this argument boils down to will it be there in future, because the decision to use it or not is a technical one and I suspect it's not fading any time soon. Our decision to switch to it was the very real and huge difference in time it takes to write a business app in .net versus in MFC / c++ code. Many orders of magnitude faster. Time to market is everything to a smaller company like us that can't throw a few hundred programmers at a problem. And our clients don't give a damn whether it's .net or not, they just want it to accomplish whatever task they have in mind. With .net we have been able to refocus and spend much more time on the design phase of a project and much less on the coding to get it done. Also being able to do some previously very complex and time consuming to program stuff now in .net so easily it has freed us up to think more outside the box of the tools we use and more on making a better product. I know that sounds like it comes from the Microsoft marketing department, but it's just a fact. I guess if you're looking for an example of a shrink wrap app that uses .net QuickBooks accounting software is a pretty big one.
-
It actually would work well if the OS was managed, as with the Singularity concept OS. The reason for this is that you could then make the CLR itself be the core of the OS, and mitigate a lot of the problems that .NET faces - the need to load the same code into memory repeatedly for each process that uses it, the native interop with the OS, etc. Compiler and JIT optimizations can be more precise, and the GC can become the primary memory allocator, optimizing it to the point that it is better than a native allocator in all respects, and you can also get a number of benefits that can only be had with managed code - for example:
-
The abolishment of the overhead of processes, replaced by App-Domain-based SIPs (saving thousands of CPU cycles that normally go to process creation and scheduling, cross-process communication, etc)
-
Overhead of communication with the kernel and drivers is reduced by 5-10x. This means that OS service call overhead and disk, bus, audio, video, and network I/O time would be reduced.
-
Verifiable and safe applications and drivers - fewer security holes, fewer crashes, fewer hard-to-detect incompatibilities, better defect detection
You put way too much faith into the JIT. You'd send the computer back 10 years in speed...
J. Dunlap wrote:
The abolishment of the overhead of processes, replaced by App-Domain-based SIPs (saving thousands of CPU cycles that normally go to process creation and scheduling, cross-process communication, etc)
Saving thousands of CPU cycles, while wasting millions. Doesn't sound too good of a deal to me.
J. Dunlap wrote:
get a number of benefits that can only be had with managed code
J. Dunlap wrote:
Verifiable and safe applications
That can be had with unmanaged code as well. Although, it would probably be impossible to implement in Windows, because you'd have to rewrite the kernel and subsystems so much, it wouldn't be Windows anymore.
-
-
Marc Clifton wrote:
Anyways, what you think?
Only a moron would implement the core components of an OS in managed code. Or someone with a very very fast computer.
-
You put way too much faith into the JIT. You'd send the computer back 10 years in speed...
J. Dunlap wrote:
The abolishment of the overhead of processes, replaced by App-Domain-based SIPs (saving thousands of CPU cycles that normally go to process creation and scheduling, cross-process communication, etc)
Saving thousands of CPU cycles, while wasting millions. Doesn't sound too good of a deal to me.
J. Dunlap wrote:
get a number of benefits that can only be had with managed code
J. Dunlap wrote:
Verifiable and safe applications
That can be had with unmanaged code as well. Although, it would probably be impossible to implement in Windows, because you'd have to rewrite the kernel and subsystems so much, it wouldn't be Windows anymore.
Jörgen Sigvardsson wrote:
You put way too much faith into the JIT. You'd send the computer back 10 years in speed...
Firstly, applications would be pre-compiled to native images and (IIRC) stored in a cache, much like Ngen does on Windows - no "JIT hit" at startup except the first time around. Secondly, the IL->native compiler can make a lot more optimizations in the managed-OS scenario than is possible in normal native code gen scenarios, including C/C++ compiler native code gen.
Jörgen Sigvardsson wrote:
Saving thousands of CPU cycles, while wasting millions. Doesn't sound too good of a deal to me.
Well, I'd have to disagree. I've been amazed at the perf I can achieve if I do things correctly in .NET. And, Singularity came ahead of Windows XP in several unoptimized disk and network I/O tests.
Jörgen Sigvardsson wrote:
That can be had with unmanaged code as well. Although, it would probably be impossible to implement in Windows, because you'd have to rewrite the kernel and subsystems so much, it wouldn't be Windows anymore.
Perhaps, but machine code is harder to verify through code analysis than IL is.
-
This article had me rolling on the floor. Is this guy for real? http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm[^] In the executive summary: Microsoft appears to have concentrated their development effort in Vista on native code development. In contrast to PDC03LH, 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. (I bolded the last) The "only" conclusion??? And so what? This is sort of a "duh" to me, writing an OS in native code. But I love this, near the end of a long and pointless article counting how many dll's Vista uses that are managed: 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 Lost confidence??? :rolleyes: The real reason, probably, is so the EU doesn't sue them for entangling the OS with .NET! hahaha. Anyways, what you think? Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures -- modified at 15:32 Tuesday 14th March, 2006
I thought the 'Longhorn reset' was common knowledge. .NET 2.0 wasn't finished and the dependencies in 'Longhorn' were spiralling out of control, with developers chasing a moving target. Bug counts were huge. So the project leads - eventually - decided they had to generally reduce dependencies in the system, particularly inter-component dependencies. Some parts of the Longhorn alpha builds which used .NET no longer do in Vista beta 1, and indeed the Sidebar will not support WPF Gadgets[^]. I don't see it as a sign of lost confidence in .NET in general, just simply not having confidence in where .NET 2.0 was at that point in time, and particularly in where Avalon was. Stability. What an interesting concept. -- Chris Maunder
-
I thought the 'Longhorn reset' was common knowledge. .NET 2.0 wasn't finished and the dependencies in 'Longhorn' were spiralling out of control, with developers chasing a moving target. Bug counts were huge. So the project leads - eventually - decided they had to generally reduce dependencies in the system, particularly inter-component dependencies. Some parts of the Longhorn alpha builds which used .NET no longer do in Vista beta 1, and indeed the Sidebar will not support WPF Gadgets[^]. I don't see it as a sign of lost confidence in .NET in general, just simply not having confidence in where .NET 2.0 was at that point in time, and particularly in where Avalon was. Stability. What an interesting concept. -- Chris Maunder
Mike Dimmick wrote:
I thought the 'Longhorn reset' was common knowledge.
That's what I thought too.
Mike Dimmick wrote:
and indeed the Sidebar will not support WPF Gadgets[^].
Wow. I didn't realize that. They keep trimming the hedges, so to speak.
Mike Dimmick wrote:
and particularly in where Avalon was.
Indeed. And I recently read that they've also stopped development on one of their vector graphics tools. I still get the impression that things are more chaotic than usual over at Microsoft. But I guess, when you hype something, and then the bloggers hype the hype, it's not easy to change course without looking like a fool. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
This article had me rolling on the floor. Is this guy for real? http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm[^] In the executive summary: Microsoft appears to have concentrated their development effort in Vista on native code development. In contrast to PDC03LH, 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. (I bolded the last) The "only" conclusion??? And so what? This is sort of a "duh" to me, writing an OS in native code. But I love this, near the end of a long and pointless article counting how many dll's Vista uses that are managed: 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 Lost confidence??? :rolleyes: The real reason, probably, is so the EU doesn't sue them for entangling the OS with .NET! hahaha. Anyways, what you think? Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures -- modified at 15:32 Tuesday 14th March, 2006