Author : Glenn Jones
Page : 1 Next >>
This tutorial will explain the basics of writing a Windows 32-bit DLL. I will direct it at Visual Basic programmers who have decided they need to write a DLL for their VB applications. However, VB programmers not are the only users of DLLs. Those programmers who want to write a DLL to interface with other languages will also find this tutorial useful.
In addition, this tutorial is specific to writing a DLL using C.
What is a Dynamic Link Library
What do I need to write a DLL?
What can I do in a DLL?
Where can I get sample DLL source?
Where can I get more information on writing a DLL?
A Dynamic Link Library, DLL, is a library of functions callable by an application at runtime. The application and functions within the DLL are not bound until the application program is executed.
In the WIN32 environment DLL's are being used for more purposes then in the 16-bit environment. OLE servers, ISAPI filters and even some CGI programs are implemented as DLL's. I will only cover the basic DLL in this tutorial.
Normally the functions in a DLL are for a particular purpose (internet access, graphing, serial port communication). They may also be a collection of functions required by an application and only be specific to that application. This is only convention, if you are writing a DLL you can put whatever functions you want into it.
If you are going to write and distribute a DLL, you do not need to register its name nor get an ID from anyone. You can name it whatever you want, but please try to make it unique. If you call your DLL "KERNEL.DLL" you will have problems with it (KERNEL is a Microsoft Windows DLL used to perform operating system kernel functions).
An application can bind to a DLL in two ways:
Load Time Binding
On Call Binding
Load Time Binding loads the DLL when an application that uses it is loaded for execution. Windows loads the DLL for the application.
With On Call Binding, the DLL is loaded when it is needed. If it is never needed by the application it will never be loaded.
Visual Basic loads DLLs when the form that contains their Declare statement is loaded. If a VB application places the DLL function declare in a module or on a form that is loaded when the application is loaded, then the DLL will be bound at application load time. If the declare is placed in a form that is dynamically loaded by the VB application, then the DLL will be loaded when the form is loaded.
One last note on loading DLL's, Windows will locate a DLL in the following order:
In memory, a DLL, once loaded, is global to all of Windows until it is unloaded.
In the directory where the application was loaded from
In the windows directory
In the windows\system directory
In directories specified in the DOS PATH
As of today, most DLL's are written in C. It is also possible to write a DLL in PASCAL/Delphi, assembly language or BASIC. (Visual Basic cannot be used to write a true DLL. The DLL's the VB creates are OLE containers that have an extention .DLL. They are not DLL's as decribed in this tutorial.)
In order to write a 32-bit DLL you will need a compiler capable of creating Windows 32-bit DLL. The two most popular C compilers that can do this are:
Microsoft Visual C++ Version 4.0 +
Borland C++ for Windows Version 5.0 +
If you do not have a compiler, you will need one to write a DLLs.
In addition to the compiler, you will need knowledge of C and the WIN32 API.
NOTE: C is the language that is used to write a DLL, not C++. C++ is an object oriented extension of C. If you have a C++ compiler, it can handle C just fine. You can also write non-exported functions as C++ objects, but the functions that are called into from Windows applications must be C functions, not C++ functions or methods.
A Windows 32-bit DLL does not require any special functions. If you want to initialize your DLL when it is loaded, you can have a function called DllMain and do your initialization, but it is not required. Windows calls the DllMain function of a DLL in four instances:
When a process attaches the DLL
When a thread attaches the DLL
When a process detaches the DLL
When a thrad detaches the DLL
A basic DllMain function could look like this:
BOOL WINAPI DllMain(HINSTANCE hInstance,DWORD fwdReason, LPVOID lpvReserved)
{
switch(fwdReason)
{
case DLL_PROCESS_ATTACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_DETACH:
break;
}
return(TRUE); // The initialization was successful, a FALSE will abort
// the DLL attach
}
I will not discuss this any further since it is not required to write a simple DLL. If you need to perform DLL initializaton, check the WIN32 API Reference for details.
The only other requirement of functions in a DLL is that those functions that can be called from outside the DLL, must be declared "WINAPI". If you do not declare them this way, you will not be able to call them.
You will also need a special DEF file for a DLL. Below is a sample DEF file .
LIBRARY <your DLL name goes here>
EXPORTS <the name of an exported function>
<the name of another exported function>
That is it. After you compile and link, you can begin testing your DLL.
The sample that accompanies this tutorial contains all of this basic information. You can use it as a template to start writing your first DLL.
Many people ask what is permissible in a DLL. Well, just about anything is permissible. When an application calls a DLL function, the DLL is executing as an extension of the application's process. It is actually loaded into the applications local memory space. Any files it opens are open to the process; any memory allocated is allocated from the process' local or global heaps. Just keep this in mind and you will be fine.
Some of the things you might want to do in a DLL are:
Make GDI function calls to paint the screen.
Allocate Windows global memory
Perform file I/O
Search Windows internal tables
Perform port I/O
Call other API's
All of these things are possible, the most important thing to remember is to write your DLL as clean as possible. If you allocate a resource, and you do not need to keep it, free it before you return from your DLL function. Always remember, a DLL can cause all kinds of problems in Windows and they might not show until your DLL has long been unloaded.
You also need to realize that WIN32 DLL's external variables are external only to the instance of the DLL. If two processes are using the same DLL, they will each get a private copy of the external variables. I mention this because this is a major difference between 32-bit and 16-bit DLL's. You cannot use external DLL variables to share information between processes. You must use the WIN32 API shared memory objects.
I also want to warn you about an inconsistancy between Visual Basic and C. In C, an int type is 32-bits long. This is consistant with WIN32. In VB, and Integer is 16-bits long. If you use an int argument in your DLL, you need to declare the parameter as Long in VB. If you look closely, you will see this in the sample source code.
BE CAREFUL AND KEEP IT CLEAN.
Where can I get sample DLL source?
You can find source code for DLL's on almost any Internet FTP site dealing with Windows programming as well as other on-line service forums. The problem with most of this source is that the DLL was written for a purpose. You have to wade through hundreds of lines of code just to get an idea of what you need for a simple DLL.
Included with this tutorial is a sample DLL that does nothing but add two arguments and return the result. It contains the source code and DEF file . In addition it contains a VB program, with source, that calls the DLL.
Sample 32-bit DLL Source
Where can I get more information on writing a DLL?
Most good books on C programming for Windows will include a chapter or two on writing a DLL. Browse your local book store and find one you like.
Since writing a DLL is really just writing a Windows program, you will need access to the Windows API documentation. You will also want to get information on writing programs using GDI, KERNEL and other part of Windows.
About the author
I, Glenn Jones, have been a professional programmer for 18 years. For most of this time I have been designing, writing and supporting system software (compilers, debuggers, code generators, communication
Page : 1 Next >>