1. Will Microsoft be updating/replacing the PE/COFF format so that .NET framework won't have to run as a background service in Longhorn.
2. There has been a huge FUD among developers about performance of managed code & .NET, has Micrsoft addresed these issues (if yes, where... the urls please) or do they plan
to address this issue in the upcoming WinHEC ?
3. What about the rumours about XAML allowing us to create our own Visual Themes ?
4. Robert Scoble once agreed to the need for a linker (for specific deployment scenarios) reacting to
Joel on Software, is there really a need for it? I mean ( from one point of view; "its not like that our .NET executables are not like other Win32 executables, just as if a required dll isn't available a particular program doesen't
run, NET executables don't run without .NET FX") Atleast they don't require a loader like Java apps do!
.NET execution model
1.when you hit an .net exe, it loads the MSCoreEE.dll ( the runtime itself) and call the _CorMainExe function in that .dll.
2._CorMainExe looks into the manifest, and find the adress of the app entry point (sub main)
3. the il code in the entry point, is handed to the jit compiler (located in the runtime), compiled to
native code and executed.
4. as the entry point invoke other methods, the runtime uses the jit to transfrom the il in those methods to native code and executes it.
This is the way modern software execution is going to be for years to come. Your app does not run directly
on the underlaying hardware, but are managed by a man in the middle, the .net runtime.
The runtime handles memory, security and code execution...But your code will be slower.
The jit kicks inn during runtime, and that is why you have the performance hit. You will notice a slight performance hit when the runtime is loaded into memory (1).But only apps that make many method calls when started, suffer from a noticable increase in
overhead at point 4.
Why background service?
In xp and server 2003, the runtime is alredy in memory (the background service, and the app starts directly on the jit step) Most likely this will continue in Longhorn
About the PE
All windows .exes must have a pe header. One of the most important fields in the pE is the code location to jump to when the os loads the application.
But since the .net application dosnt contain any native code, there is a jmp instruction to the runtime.
(_CoreExeMain entry point i MSCoreEE.dll or _CoreDllMain for dlls)
And that is loaded into memory if its not there already.
What version of the Runtime will your app use?
1. Your app will not breake, several versions of the runtime can coexist on the same machine, and your app will be directed to the correct runtime.
You can however rederic an app to a newer runtime with a smal addition to the application configuration file.
2. There are 3 factors that affect the runtime choise:
a. the version of the runtime under which the app was compiled
b. The value of the <requiredRuntime> setting in the app configuration file. If present it overides the runtime version embedded tin the app exe file
c. if there is an enry in the app configuration file, this info is stored in the registry but will be ignored wil the safemode attribute is set to true.
3. So to change the runtime, you use the <reguiredRuntime> setting in the <startup> section of the
2. The .net compilers are very effective, but your code will never be as fast as native code.
The compilers produce IL, and that will be converted to native code during runtime by the jit.
3. The framework comes with a native image generator (ngen) wich will compile an entire app at install time instead of at runtime. Some of the bcl in gac are precomiled, and most likely you will se a shift of focus from jit to precompiled applications in the
future.(components in longhorn)
4. The jit has deeper knowlege of the underlaying enviroment than traditional compilers. The jit can emit code for a spesific cpu instead of code for a generic intel x86. It can take adantage of the intel p4, Itanium or any new prosessors produced. But that
is still a long way off.
5. Most optimizaion techniques in traditional compilers, is still used by .net compilers. (loop unrooling/constant folding)
6. There are some techniques that traditional compilers cant use.
a)The jit can optimize method calls
across diferent components cuz it controls the entire execution enviroment.
b) method calls in COM work throught indirection and uses function pointers in the vtable( the compiler does not know
where the target object is loded at runtime.)
Jit knows where the target object is in memory, and can call the method directly with a singel and faster call assembly optcode.
c) the jit is monitoring the behavior of the app, and might deside to perform method inlining on only the routines that are called more frequently.
Thanx a lot being a .NET newbee this really clears up a lot of confusion I had!
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.