Hi,
You don't have to have a look at the source code to determine whether Visual
Studio 2005 uses managed code.
You missed the fact that Visual Studio 2005 is much more than a single
devenv.exe. It has a lot of DLLs and supporting exe files and a lot of them
are entirely managed assemblies.
Also note that if you interact with managed code using CorBindToRuntimeEx()
for example the unamanged code that interacts with managed code won't became
managed code. Managed code is IL code.
Kornél
----- Original Message -----
From: "Jonathan Pryor" <[EMAIL PROTECTED]>
To: "ted leslie" <[EMAIL PROTECTED]>
Cc: <mono-list@lists.ximian.com>
Sent: Monday, March 27, 2006 1:08 PM
Subject: Re: [Mono-list] could linux be MORE .Net then windows ?
On Mon, 2006-03-27 at 04:28 -0500, ted leslie wrote:
This article, with at least a bit of (hopefully accurate) research behind
it,
seems to state a shocking conclusion:
article:
http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm#conclusion
And the rebuttal:
http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspx
An interesting point is that demon.co.uk says this:
If anyone tells you that Visual Studio .NET is a managed
application, you instantly know that they know nothing
about .NET. Simply typing dumpbin devenv.exe /headers (assuming
you have devenv.exe in your path) will prove this: the location
in the COM Descriptor Directory is zero.
While danielfe says that VS2005 has 7.5 million lines of managed code.
Why such a large difference?
First of all, you can have apps which embed the .NET runtime.
grimes.co.uk mentions this, even mentioning that mscoree.dll!
CorBindToRuntimeEx() will be bound.
However, this isn't entirely correct. IIRC, the .NET runtime can be
instantiated and embedded through normal COM interfaces. Result: no
explicit link between an embedding app and the .NET runtime, unless you
want to disassemble the whole thing and look for the .NET runtime
GUID.... So running `dumpbin.exe devenv.exe /headers` won't give you
the correct result.
Furthermore, due to .NET's terrific COM interop support, .NET objects
can be used as COM objects.
Thus, VS.NET can use .NET objects through COM, without having any
strict .NET dependency visible within the PE headers. You'd have to
read the source to know, which we don't have, but those which do have
access to the VS.NET source claim that it uses managed code.
So you can either rely on demon.co.uk's logic -- which we've already
seen can be faulty -- or rely on those who actually have access to the
source.
At which point we can realize that Microsoft is still using more managed
code than SuSE. :-)
- Jon
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
