📄 lion-tutorial17.htm
字号:
<html>
<head>
<link rel="stylesheet" href="../../asm.css">
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>Iczelion's win32 asm tutorial</title>
</head>
<body bgcolor="#FFFFFF" background="../../images/back01.jpg">
<p align="center">Tutorial 17: Dynamic Link Libraries</p>
<hr size="1">
<strong> </strong> In this tutorial, we will learn about DLLs , what are they
and how to create them. <br>
You can download the example <a href="files/tut17.zip">here</a>. <br>
<h3> Theory:</h3>
If you program long enough, you'll find that the programs you wrote usually have
some code routines in common. It's such a waste of time to rewrite them everytime
you start coding new programs. Back in the old days of DOS, programmers store
those commonly used routines in one or more libraries. When they want to use the
functions, they just link the library to the object file and the linker extracts
the functions from the library and inserts them into the final executable file.
This process is called static linking. C runtime libraries are good examples.
The drawback of this method is that you have identical functions in every program
that calls them. Your disk space is wasted storing several identical copies of
the functions. But for DOS programs, this method is quite acceptable since there
is usually only one program that's active in memory. So there is no waste of precious
memory. <br>
Under Windows, the situation becomes much more critical because you can have several
programs running simultaneously. Memory will be eat up quickly if your program
is quite large. Windows has a solution for this type of problem: dynamic link
libraries. A dynamic link library is a kind of common pool of functions. Windows
will not load several copies of a DLL into memory so even if there are many instances
of your program running at the same time, there'll be only one copy of the DLL
that program uses in memory. And I should clarify this point a bit. In reality,
all processes that use the same dll will have their own copies of that dll. It
will look like there are many copies of the DLL in memory. But in reality, Windows
does it magic with paging and all processes share the same DLL code.So in physical
memory, there is only one copy of DLL code. However, each process will have its
own unique data section of the DLL. <br>
The program links to a DLL at runtime unlike the old static library. That's why
it's called dynamic link library. You can also unload a DLL at runtime as well
when you don't need it. If that program is the only one that uses the DLL, it'll
be unloaded from memory immediately. But if the DLL is still used by some other
program, the DLL remains in memory until the last program that uses its service
unloads it. <br>
However, the linker has a more difficult job when it performs address fixups for
the final executable file. Since it cannot "extract" the functions and insert
them into the final executable file, somehow it must store enough information
about the DLL and functions into the final execuable file for it to be able to
locate and load the correct DLL at runtime. <br>
That's where import library comes in. An import library contains the information
about the DLL it represents. The linker can extract the info it needs from the
import libraries and stuff it into the executable file. When Windows loader loads
the program into memory, it sees that the program links to a DLL so it searches
for that DLL and maps it into the address space of the process as well and performs
the address fixups for the calls to the functions in the DLL. <br>
You may choose to load the DLL yourself without relying on Windows loader. This
method has its pros and cons:
<ul>
<li> It doesn't need an import library so you can load and use any DLL even
if it comes with no import library. However, you still have to know about
the functions inside it, how many parameters they take and the likes.</li>
<li> When you let the loader load the DLL for your program, if the loader cannot
find the DLL it will report "A required .DLL file, xxxxx.dll is missing" and
poof! your program doesn't have a chance to run even if that DLL is not essential
to its operation. If you load the DLL yourself, when the DLL cannot be found
and it's not essential to the operation, your program can just tell the user
about the fact and go on.</li>
<li> You can call *undocumented* functions that are not included in the import
libraries. Provided that you know enough info about the functions.</li>
<li> If you use LoadLibrary, you have to call GetProcAddress for every function
that you want to call. GetProcAddress retrieves the entrypoint address of
a function in a particular DLL. So your code might be a little bit larger
and slower but by not much.</li>
</ul>
Seeing the advantages/disadvantages of LoadLibrary call, we go into detail how
to create a DLL now. <br>
The following code is the DLL skeleton.
<p>;--------------------------------------------------------------------------------------
<br>
;
DLLSkeleton.asm <br>
;--------------------------------------------------------------------------------------
<br>
<b>.386</b> <br>
<b>.model flat,stdcall</b> <br>
<b>option casemap:none</b> <br>
<b>include \masm32\include\windows.inc</b> <br>
<b>include \masm32\include\user32.inc</b> <br>
<b>include \masm32\include\kernel32.inc</b> <br>
<b>includelib \masm32\lib\user32.lib</b> <br>
<b>includelib \masm32\lib\kernel32.lib</b>
<p><b>.data</b> <br>
<b>.code</b> <br>
<b>DllEntry proc hInstDLL:HINSTANCE, reason:DWORD, reserved1:DWORD</b> <br>
<b> mov eax,TRUE</b> <br>
<b> ret</b> <br>
<b>DllEntry Endp</b> <br>
<b>;---------------------------------------------------------------------------------------------------</b>
<br>
<b>;
This is a dummy function</b> <br>
<b>; It does nothing. I put it here to show where you can insert functions
into</b> <br>
<b>; a DLL.</b> <br>
<b>;----------------------------------------------------------------------------------------------------</b>
<br>
<b>TestFunction proc</b> <br>
<b> ret</b> <br>
<b>TestFunction endp</b>
<p><b>End DllEntry</b>
<p>;-------------------------------------------------------------------------------------
<br>
;
DLLSkeleton.def <br>
;-------------------------------------------------------------------------------------
<br>
<b>LIBRARY</b> DLLSkeleton <br>
<b>EXPORTS</b> TestFunction <br>
<p>The above program is the DLL skeleton. Every DLL must have an entrypoint function.
Windows will call the entrypoint function everytime that:
<ul>
<li> The DLL is first loaded</li>
<li> The DLL is unloaded</li>
<li> A thread is created in the same process</li>
<li> A thread is destroyed in the same process</li>
</ul>
<b>DllEntry proc hInstDLL:HINSTANCE, reason:DWORD, reserved1:DWORD</b> <br>
<b> mov eax,TRUE</b> <br>
<b> ret</b> <br>
<b>DllEntry Endp</b>
<p>You can name the entrypoint function anything you wish so long as you have
a matching END <Entrypoint function name>. This function takes three parameters,
only the first two of which are important. <br>
<b>hInstDLL</b> is the module handle of the DLL. It's not the same as the instance
handle of the process. You should keep this value if you need to use it later.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -