General: Making DLL Components
By: Jack Hoxley
Written: May 2000
Download: Gm_dll.zip (39kb)

DLL stands for Dynamic Link Library, and it is also the 3 letter extension used for the file type. Basically it is a collection of procedures and functions that can be used often and by any language (to a certain extent). The entire windows API is made up of DLL's, look through your system folder and you'll find upwards of 600 different DLL files. Most of the directX files are DLL's.

Windows comes with lots of DLL's, almost all of them are the API, the rest that you'll find are probably for other applications. They are used to extend the programs that they are associated with, by offering new functions and optimized code. One common use for DLL's is to simplify the original program;

Say you had a memory access program, that used lots of extremely complex maths formulas. If you needed to use it often you would make a procedure to handle it - but it would still be in the original EXE program. If it were in a DLL it would work the same, but it would be independent from the original EXE; this would allow you to update it without having to recompile the exe (more on this later). The main advantage is that, in vb, you would only have to declare the DLL in the declarations section and you could call the procedure from anywhere in the program, and not worry about it cluttering up your project.

The second advantage is that you can rewrite it. This effectively allows it to be patched or upgraded in the future - something every PC-games player will be familiar with. You could write a game, distribute it, then find an error in the code - maybe something that only affects certain computers. You would then have to rewrite parts of the core-code (the original program), re-compile it and then redistribute it; possibly quite awkward. If however you'd designed it to be modular you could just rewrite the graphics DLL (assuming it was graphics that was to be changed), then redistribute that file. Doing this could also mean that you can customize the game for everyones individual needs. For example, person X has a super-computer that can do perfect 3D rendering, but has a poor soundcard - and cant use DirectSound or Music. You could write every DLL in the form of DirectX 5,6 and 7, or using the API (which almost every computer will support). With this structure you could then allow your person to pick-and-choose which engine they use (engine = component, ie. API or DirectX).

The other part of this is that you can advance your game after release. If you worked out that there was an amazing optimization that would speed up gameplay - rewrite the DLL and send it off to the people. This can also link in with new features; such as mods and upgrades (common in Quake/Half-life/Unreal Tournament). Also, if you shared the structure of your DLL with others, they would be able to rewrite parts of it - without stealing to many ideas, or destroying your game.

The third advantage is that the DLL can be written in a different language. This is a little bit more complicated to implement, but can have amazing advantages. If the whole game is written in visual basic, you are limited with it's short-comings and any disadvantages inherant with the language. In particular memory access in vb, which I find can be very slow - but on the other hand, C/C++ memory access is blisteringly fast (in comparison), and again, Assembler can do some incredibly fast maths routines. This ability can allow you to pick-and-choose the best parts of each language. I find that VB is much easier (and more fun) to program than C++, but I like the memory access and inherant speed advantages of C/C++; because of this I would write some parts of a game in VB (the core structure) and the low-level maths and other complicated things in C/C++

Now onto the code. The attached Zip file is much easier to understand, and it would be confusing to look at the code in anything but VB itself. You can download the file from the top of the page, or from the Downloads page.

The DLLs that we will be using aren't actually proper DLLs - their activeX DLLs. Hopefully Microsoft will implement proper DLL writing in a future release of visual basic. The ActiveX DLL is basically a remote class. You write it the same as you would if it were a normal class module in visual basic. You can then access the functions and procedures in the Class module (now a DLL) in your main application.

To allow you to update it without confusing vb (it expects a certain version of the DLL - which changes each time it's compiled), you need to set an option for the DLL so that it is Binary Compatable. You can find it under the component tab in the project properties window. But before you do that, compile the DLL without this option - you dont need any code in it yet. You now have a useless DLL (wow!) - then go back into the properties and set it to be binary compatable, and in the little text-box point it to the precompiled DLL. You can now add as much code as you like and VB will never no the difference.

One warning though - you must keep the functions/procedures the same; or at least, never delete any. If you use the DLL in VB and you call the procedure "INIT", but it isn't there, VB will kick up a stink and probably stop your program from working. You can add procedures, as VB wont ever want to call them, but you must keep the original procedures the same - including any parameters to be passed to them. If you think that you'll want to add more parameters in the future put dummy paramters in the original -
sub INIT(Screenwidth as integer,ScreenHeight as integer,Depth as integer, Reserved as string,Reserved1 as string)
In this line you'll notice the Reserved and reserved1 parameters, this means that in the future you'll be able to make use of these parameters - assuming you can pass them as a string.

Go look at the projects in the Zip file - they are well commented and will help you understand this tutorial.