Help to understand compiling in .NET

[Anders S. Willumsen]

I'm sorry - but I need some help understanding what's going on in the
framework when it comes to IL and executable.



Consider this simple code:



Imports System

public class test

public shared sub Main()

Console.WriteLine("test")

End sub

End class



When saved as demo.vb it can be compiled with vbc.exe like this:



Vbc demo.vb



And this generates demo.exe. I know that demo.exe do not contains executable
code - it contains CIL and metadata.



And now the questions begins.



When executing vb.exe what really happens? (1). As I understand it CLR
compiles CIL to something executable - but where is the file (2). Will
demo.exe remain unchanged? (3) What is the file (vbdemo.exe containing IL)
called - PE file or assembly? (4)

If demo.exe contains IL and metadata can it be moved to another platform
(rotor/mono) unchanged because the IL compiler on this platform understands
the information in demo.exe? (5)

How does ilasm fit in to all this - as I understand it, ilasm compiles
IL/meta to an executable. Does that mean that you can use ilasm to
precompile an assembly file? (6)



I'm sorry about the many questions - but I need some help understanding
this. Can anyone help me - or guide me to some information about it?



Thanks,

Anders

 

[remotesoft]

Those are all very good questions, and actually require some deep
understanding of the whole CLR loading process in order to get them
anwsered.

Simply put, .NET assemblies still conform to the regular PE format spec,
except that .NET PE file has an additional data directory entry that holds a
RVA to all .NET related data, such as metadata information. Metadata
contains methods info, which in turns contain RVAs for IL code. This is how
it fits into the PE picture, you can see, that, it can also contain native
code just as the traditional PE file from C/C++ does.

As for how the .NET runtime is loaded (CLR), each .NET assembly has a DLL
import table, exactly in the same way as C/C++ executable. One entry holds a
pointer to _CorExeMain(), _CorDLLMain(() to mscoree.dll. The assembly also
contains an entry point, so when a .exe or .dll is executed, it will jump to
that entry point, which is _CorExeMain for exe, and _CorDllMain for dll,
this will then go to mscoree.dll, from where all CLR stuff will be loaded,
the main CLR code is in mscorwks.dll.

All IL code is compiled into native code using the jitter (mscorjit.dll)
during execution. Each method gets jitted the first time it gets invoked.
Jitting is another magic piece that requires more explanation ...

In other platforms, .NET assemblies are usually loaded using as external
program, (same as java.exe for java programs).

If you want to examine the DLL import table, you can download our free tool,
..NET Explorer, http://www.remotesoft.com/dotexplorer

Hope this is helpful,

Huihong
Remotesoft, Inc.

 

[Anders S. Willumsen]

Thanks a lot for your answer - but still confused. Maybe I just don't have
the knowledge to understand it.

Let me respond by taking one q at a time.

When you compile with vbc/csc you end up with a file containing il/meta. Can
you move this file (exe or dll) directly to another platform (like mono on
linux), and let the il compiler there make it into native code?

Anders

 

[remotesoft]

Yes, since all .NET assemblies conform to the same standard in terms of file
format. Mono should be able to
jit .NET assemblies compiled from vbc/csc. Since the underlying system
libraries differ, so your program may
not run correctly under mono. For instance, if your .NET program uses COM,
it may not run correctly under mono runtime.

 

[Etienne Boucher]

To anwser the remaining questions, when the CLR compiles (just-in-time) your
demo.exe, no file is created. The native machine code is simply loaded in
memory. demo.exe is not modified.

Etienne Boucher

 

[Anders S. Willumsen]

Things are begining to clear up. The part about the assembly being portable
is now clear. Thanks.

The part about the executable just being loaded into memory I don't get.
Does that mean that it is jitted every time it executed (after a reboot when
memory is "blank")?

Anders

 

[Etienne Boucher]

Each time demo.exe is launched, it is jitted again. This is the only way to
maintain cross-platform compatibility. If you launch it on .NET 1.1, it is
compiled for Windows x86, but if you launch it on a mac with mono, it is
compiled for MacOS X PowerPC.

Etienne Boucher