This is my guess only, but for XP, Win 03, and other os'es that know about
the .net framework, it is more efficient to directly load the clr instead of
going through a stub program. There may be other things that this provides
(better security since NONE of the .exe is executed directly, ALL of it is
managed, etc).
However, in order to make the programs backwards compatible with older
os'es, they had to have a "legacy" way to invoke the clr. Take windows 98,
for example: You've installed the .NET Framework, but that doesn't mean that
that windows 98 OS knows how to do anything special with your .Net program.
It just sees the program as a windows .exe. It runs the .exe and what
happens "under the covers" is the stub program runs, invokes the CLR, and
then the CLR hosts your program.
I suppose part of the .Net framework install could have been some sort of
patch on old OS'es to make them more aware of .Net programs and how to run
them, but I'm guessing (again here) that it could have been a relatively big
undertaking for a relatively little gain.
Mike Mayer, Visual C# MVP
mi**@mag37.com http://www.mag37.com/csharp/
"Abhishek Srivastava" <ab*****************@nospam.net> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
I am reading applied .net programming by Jeffrey Richter. I am reading
about how the CLR gets loaded. From what I understand, that for all
other OSes except (XP, 2003 Server) the CLR is loaded by the x86 stub
in the .text section of the PE Header.
However for XP and windows 2003 the CLR is loaded by looking for a
directory entry. If the directory entry exists or is not 0 the CLR is
loaded.
Just curious to know why there are two ways of loading the CLR instead
of 1. Why can't all the OS look for the same directory entry. Or why
can't all the OSes load the CLR based on the stub call in the .text
section of the PE header.
regards,
Abhishek.
