[Mono-list] could linux be MORE .Net then windows ?
kornelpal at gmail.com
Mon Mar 27 06:26:28 EST 2006
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.
----- Original Message -----
From: "Jonathan Pryor" <jonpryor at vt.edu>
To: "ted leslie" <tleslie at tcn.net>
Cc: <mono-list at 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
>> seems to state a shocking conclusion:
> And the rebuttal:
> 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
> At which point we can realize that Microsoft is still using more managed
> code than SuSE. :-)
> - Jon
> Mono-list maillist - Mono-list at lists.ximian.com
More information about the Mono-list