A Console .EXE

[Jay]

In console programming what does the .EXE file contain. Is it native code
or MSIL? Where does the JIT fit in the picture? Is JIT line by line
interpreted or does it compile the entire module?

[Chua Wen Ching]

Hi Jay,

I believe it contains the MSIL.

Try this.

1) Make sure you have created a .NET console app exe from the vs.net (just build it).

2) Use Microsoft Visual Studio .NET 2003 Command Prompt.

3) Type ildasm.exe ConsoleApp.exe

4) You can see the IL codes there.

About JIT, i am not that sure. Maybe someone can elaborate further.

Thanks. Correct me if i am wrong.
--
Regards,
Chua Wen Ching :)
"Jay" wrote:

In console programming what does the .EXE file contain. Is it native code
or MSIL? Where does the JIT fit in the picture? Is JIT line by line
interpreted or does it compile the entire module?

[Niki Estner]

"Jay" <[e-mail]> wrote in news:QUHFc.1219$r3.904@okepread03...

In console programming what does the .EXE file contain.
A CLR stub, metadata and IL. Same as for "regular" executables.
Is it native code or MSIL?
MSIL
Where does the JIT fit in the picture?
When you launch the EXE, the CLR creates a stub for each method that will
compile it from IL to native code as soon as it gets called for the first
time - just in time (JIT).
Is JIT line by line interpreted or does it compile the entire module?

It's not interpreted. It's compiled. It compiles a function when it is
called.

Niki

[Jay]

> A CLR stub, metadata and IL. Same as for "regular" executables.

When you refer to regular executables are you referring to C++ executables.
I was under the impression that C++ executables contained native code

Also, what form does the code take on after JIT? Is it in memory only or is
a file created?

Thank You so much for your response!

[Daniel O'Connell [C# MVP]]

"Jay" <[e-mail]> wrote in message news:y8VFc.1748$r3.868@okepread03...

A CLR stub, metadata and IL. Same as for "regular" executables.
When you refer to regular executables are you referring to C++
executables.
I was under the impression that C++ executables contained native code

A regular executable would be any native executable, be it created by C++,
Pascal, fortran, or compiled perl. As long as it is standard machine codes
in a recognized executable format.

Also, what form does the code take on after JIT? Is it in memory only or
is
a file created?

JIT generated code must exist in memory, asthe processor must execute it. On
disk caches would be something I would consider implementation specific.
While some JIT's may write caches(and if memory serves, the .NET frameworks
does atleast under some circumstances), there is no requirement to.

[Niki Estner]

"Jay" <[e-mail]> wrote in news:y8VFc.1748$r3.868@okepread03...

A CLR stub, metadata and IL. Same as for "regular" executables.
When you refer to regular executables are you referring to C++

executables. I was under the impression that C++ executables contained native code
Oh, that was not very precise of me. I meant windows forms or service or any
other kind of executable created by a managed compiler. Non-Managed (e.g.
C++) executables have different structure. Sorry.
Also, what form does the code take on after JIT? Is it in memory only or is a file created?

Initially it's in main memory, but it may be cached to disk if physical
memory is low. When it is executed, it goes into the processors's cache and
finally, into the processor.

If you're interested in the details of the framework, there's an excelent
book on that topic by Jeffrey Richter.

Niki

[Daniel O'Connell [C# MVP]]

"Niki Estner" <ni*********@cube.net> wrote in message news:%>

Initially it's in main memory, but it may be cached to disk if physical
memory is low. When it is executed, it goes into the processors's cache
and
finally, into the processor.

For clarities sake, the caching I was refering to relates to on-disk
caches(into a seperate file) for the purposes of maintaining the generated
code for as long as possible(until the system changes in such a way that the
code is invalid), whereas the caching here(if I got you right, anyway) would
be related to the paging system, which may be based off the system page file
or off a mapped cache file, entirely based upon circumstances and the
implementation.