Vista and .NET
-
Which is why shell extensions should never be written in .NET unless you absolutely know that your target environment will only have one version of the runtime or that all your shell extensions will only require that particular version.
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
-
Say... do you have a link to more information on this?
Now taking suggestions for the next release of CPhog...
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.
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
-
Nishant Sivakumar wrote:
So I guess Stone got his facts wrong when he said it was written in managed code.
Everything I quoted said 1.5 Million lines of C# code. C# code can't help but be managed code. And I assume that since they all mention that 2004 was a complete re-write, that it'd all be in C#. Besides, when did this turn into a quest for the 100% managed application? I'd argue that if a majority of the application runs on the CLR, then it can be called a managed application.
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
David Stone wrote:
Everything I quoted said 1.5 Million lines of C# code. C# code can't help but be managed code. And I assume that since they all mention that 2004 was a complete re-write, that it'd all be in C#. Besides, when did this turn into a quest for the 100% managed application? I'd argue that if a majority of the application runs on the CLR, then it can be called a managed application.
I posted that before you replied with those links :-) Ignore this post of mine, please. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
John Cardinal wrote:
You don't pick up a screwdriver to hammer in a nail
You do if you're Chuck Norris. :) Jeremy Falcon
Jeremy Falcon wrote:
You do if you're Chuck Norris.
I thought he pressed them in using his thumb! :rolleyes: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
Hey Judah That link says Visual Studio 2005 has parts written in managed code. And I am pretty sure it's a very low percentage. I don't remember where or when I asked that, but I did ask someone and the reply was that VS 2005 is a native app, that uses a little managed code. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!Odd, because I've talked to a Microsoft dev over at some MSDN blog who said that Visual Studio is lots of C#, and a little native interop.
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
-
Nishant Sivakumar wrote:
So I guess Stone got his facts wrong when he said it was written in managed code.
Everything I quoted said 1.5 Million lines of C# code. C# code can't help but be managed code. And I assume that since they all mention that 2004 was a complete re-write, that it'd all be in C#. Besides, when did this turn into a quest for the 100% managed application? I'd argue that if a majority of the application runs on the CLR, then it can be called a managed application.
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
David Stone wrote:
I'd argue that if a majority of the application runs on the CLR, then it can be called a managed application.
Bah, any application that ever, directly or indirectly, calls a routine in the C runtime library is, at heart, a C application. If the top 99% are written in something else, well, that just demonstrates the wonderful ability of C apps to host other, lesser, languages... :rolleyes:
Now taking suggestions for the next release of CPhog...
-
Jeremy Falcon wrote:
You do if you're Chuck Norris.
I thought he pressed them in using his thumb! :rolleyes: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!No, only sissies do that. Chuck Norris pounds them in with a round-house kick! :)
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
-
No, only sissies do that. Chuck Norris pounds them in with a round-house kick! :)
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
Judah Himango wrote:
No, only sissies do that. Chuck Norris pounds them in with a round-house kick!
:laugh: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
David Stone wrote:
I'd argue that if a majority of the application runs on the CLR, then it can be called a managed application.
Bah, any application that ever, directly or indirectly, calls a routine in the C runtime library is, at heart, a C application. If the top 99% are written in something else, well, that just demonstrates the wonderful ability of C apps to host other, lesser, languages... :rolleyes:
Now taking suggestions for the next release of CPhog...
Bah, any application that ever, directly or indirectly, calls a routine in assembly is, at heart, an assembly application. If the top 99% are written in something else, well, that just demonstrates the wonderful ability of assembly apps to host other, lesser, languages... :rolleyes: ;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
-
Odd, because I've talked to a Microsoft dev over at some MSDN blog who said that Visual Studio is lots of C#, and a little native interop.
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
Judah Himango wrote:
Odd, because I've talked to a Microsoft dev over at some MSDN blog who said that Visual Studio is lots of C#, and a little native interop.
One thing's sure. VS 2005's devenv.exe is a mixed-mode app. It may use CLR hosting, but it also has a dependency on mscoree.dll, so it must contain MSIL blocks too. Anyway again, I am not 100% sure of whether it's more native than managed or vice versa, so I won't make any more comments on this :-) Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
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.
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
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! -
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.
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
-
Judah Himango wrote:
Odd, because I've talked to a Microsoft dev over at some MSDN blog who said that Visual Studio is lots of C#, and a little native interop.
One thing's sure. VS 2005's devenv.exe is a mixed-mode app. It may use CLR hosting, but it also has a dependency on mscoree.dll, so it must contain MSIL blocks too. Anyway again, I am not 100% sure of whether it's more native than managed or vice versa, so I won't make any more comments on this :-) Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!Yeah I agree, it definitely is mixed mode.
-
Bah! It's a dead issue. There are a *lot* of applications out there written in fully managed code. We have a large commercial app used in over 34 countries at last count that is written in fully managed code. If I was writing an OS I would use native code as well. You don't pick up a screwdriver to hammer in a nail unless your an idiot. His argument is dogs bollocks.
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
-
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.