First of all, let me congratulate you with having a "nice trouble". No doubt, having an ugly trouble would be much worse.
Let me continue with Solution 1.
"…when an *.exe is loaded, the OS will check the DLL file of program".
No. The statement makes no sense, because there is no such thing as "DLL file of the program".
"Compiler is a tool to open exe file".
No. Compiler is a tool to compile source code into object code (whatever it is).
"Compiler opened and "bring" a segment code…".
No. Compiler does not do it. It reads source code and just creates other file(s), the result of compilation.
"Is my understand true?"
No, apparently not.
Can I write code in order to "open" and "bring" the code like a compiler by C#…"
No. By two reasons: 1) a compiler does not do it; 2) your understanding of everything you mention is wrong.
Finally, let's get back to your main question: "How DLL works".
To
really understand it, my answer won't be enough, because this is not what you need to learn first. First, you need to learn how… everything else work: EXE, application, process, segment, memory, CPU, compiler, linker, loader… you name it. You seem to be too much confused. I can only give you few ideas.
First of all, DLL, EXE file is majorly the same thing. "DLL" and "EXE", as part of file names, is just the naming convention, there are many more "extensions" like that, they all cover one common thing: PE file:
http://en.wikipedia.org/wiki/Portable_Executable[
^].
The structure of the file is pretty complex, you can learn it if your read appropriate literature. They all often called just "executable files", including DLL. All such files contain executable code, and not only the native code for some CPU
instruction-set architecture. The PE modules built as .NET assemblies (or separate modules used by assemblies, which is also possible but rarely used) contain IL code which is compiled to native code piece by piece during runtime (on per-method basis, normally).
The major difference Dynamic Link Library make is that they may or may not have
entry point (and the entry point they may have has different signature and different purpose than EXE). This is a kind of a convention known by a system loaded. This piece of the OS takes the file name from the Shell or OS call and tries to load the file and put it to execution. The entry point is where the execution starts. The OS passes command line parameters and environment structure to the process and starts it with the defined entry point. So, when OS loads an EXE, a new process is supposed to be created.
As to the DLLs, they are
referenced by other PE modules. There are certain rules for funding actual file by their names (and .NET has a special mechanism called
strong naming which practically can make the assemblies world-unique; this is not always used). All referenced DLLs should be loaded at once before the process starts; if one is absent, the error diagnostics will be shown even before the process starts.
The DLL can also be loaded later, during runtime. Please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx[
^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx[
^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683152(v=vs.85).aspx[
^] (see other related API functions on these pages).
Compare with:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682512%28v=vs.85%29.aspx[
^].
Those rules are only applied to standard OS way to load things and start processes. First of all, EXE files can be used as DLLs, for loading in a running process and using some
exported code from them. And you can develop your own runtime system, where some host process (perhaps originally loaded and started in a "standard" way) loads some DLLs build with its special API, to load then and use as "executable modules". Something similar is really done in different
plug-in architectures.
See also:
http://en.wikipedia.org/wiki/Main_function[
^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559%28v=vs.85%29.aspx[
^].
Compare with:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx[
^].
—SA
Submit an article or tip