Vista and .NET
-
Haha. I find it funny how many people have never used BizTalk. It's an incredible server product. Takes a while to get used to...but holy crap does it give you a lot of functionality.
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 find it funny how many people have never used BizTalk.
Probably due to the price tag.:rolleyes:
A Plain English signature. Code-frog System Architects, Inc.
-
David Stone wrote:
I find it funny how many people have never used BizTalk.
Probably due to the price tag.:rolleyes:
A Plain English signature. Code-frog System Architects, Inc.
code-frog wrote:
Probably due to the price tag.
Pfft. That little thing? :rolleyes:
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
-
Haha. I find it funny how many people have never used BizTalk. It's an incredible server product. Takes a while to get used to...but holy crap does it give you a lot of functionality.
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 find it funny how many people have never used BizTalk.
:D Makes it easier to comment on, no pesky details to get in the way. (Actually, i had visited the BizTalk product page to try and remember what exactly the product did, but had forgotten what a waste of time such pages are. I think the last time i read a Microsoft product page was shortly after the release of OneNote... and left with the vague suspicion that it was a charting tool of some sort. I eventually figured out what the product did through various bloggers who discussed their use of it, but never bothered with the product site again.)
Now taking suggestions for the next release of CPhog...
-
David Stone wrote:
I find it funny how many people have never used BizTalk.
:D Makes it easier to comment on, no pesky details to get in the way. (Actually, i had visited the BizTalk product page to try and remember what exactly the product did, but had forgotten what a waste of time such pages are. I think the last time i read a Microsoft product page was shortly after the release of OneNote... and left with the vague suspicion that it was a charting tool of some sort. I eventually figured out what the product did through various bloggers who discussed their use of it, but never bothered with the product site again.)
Now taking suggestions for the next release of CPhog...
Yeah. The other thing is that BizTalk is huge. There are a lot of parts that go into it. So the marketing mumbo-jumbo page isn't going to give you a really clear picture as to what's involved. A better place to look would be this BizTalk Overview[^] page.
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
-
Interestingly that link also says BizTalk 2004 has parts written in managed code. So I guess Stone got his facts wrong when he said it was written in managed code. The 1.5 million lines he said must be the total LOC out of which a % might be in managed code. 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:
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
-
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
-
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
-
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.
-
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
-