What
the hell is a DLL?
The Microsoft Win32 SDK has this to say about DLL's (Dynamic Link Library):
In Microsoft® Windows®, dynamic linking provides a way for a process to call a function that is not part of its executable code. The executable code for the function is located in a dynamic-link library (DLL), containing one or more functions that are compiled, linked, and stored separately from the processes using them. The Microsoft® Win32® application programming interface (API) is implemented as a set of dynamic-link libraries, so any process using the Win32 API uses dynamic linking.
To be quite blunt, a DLL is kinda like a chunk of a program. It is made up of a bunch of functions which other programs can call.
Why are DLL's
necessary?
DLL's offer a host of other benefits in the real programming world. Code in a DLL can be used by any program who knows what functions are in the DLL. This makes it easy for programs to share code with each other. If you have Microsoft Office, ook in the "Program Files/Common Files" directory. In there is a ton of DLL's and stuff all Microsoft Office apps share with each other. This saves alot of space because it means the same code doesn't have to be present in each Office app. It also saves memory by allowing a program to load the executable code for an operation (eg importing a graphic file) only when it's needed, and then unload it from memory after the operation is done.
Why did Id decide to use a DLL
instead of QuakeC?
The main reason is quite simple - speed. QuakeC is an interpreted language. The Quake engine reads in the compiled progs.dat file and parses all the functions and stuff out of it. It then reads the byte codes of the compiled code and performs actions from there - the progs.dat file is not executing like a program, it is telling Quake what and how to execute. This process of interpreting the progs.dat takes time, and I guess the guys at Id did not want to burden the Quake2 engine. Since Quake2 is a Win32 program, DLL's were the perfect solution to this problem under Win32. I heard someone say Id was considering Java for this, but Java is also an interpreted language (that's why it can be run on any computer platform). There is something for Java called Just-In-Time compiling, which produces processor specific code just before the Java code is executed, but that's a whole other story.
For other operating systems, like Unix and such, Quake2 will make use of that operating system's way of implementing DLL functionality. If you plan on using your mod on multiple operating systems, it will pay to make your code very portable the first time you write it. In this case it would be best if you did not use Delphi, because C and C++ are much more portable (from what I understand) to other non MS operating systems.
How do DLL's really work? (Warning
- extreme nerd info follows!)
As we know now, DLL's are really just a big hunk of functions all lumped together. Well, it really is a little more complicated than that. Along with all those functions is a chunk of data called an export table which tells programs exactly where the functions are located inside the DLL. When you write and compile a DLL, you also create a special file that tells the linker what functions you want to be listed in this export table. This file is called a .def file, and when you link the DLL you give the linker this .def file so it knows which functions to list in the DLL's export table. The functions that are listed in a DLL's export table can be called by any other program that knows about them.
If you have installed the Quick View stuff with Windows 95 or NT, right click on a DLL and select the "Quick View" option. Scroll down a little bit and you'll see a section called "Export Table" which lists all the functions that this DLL makes visible to other programs.
Ok, now let's say we are writing a program and we want to use some functions from a DLL in it. We need to link our program with the information in the DLL's export table so that the compiler knows where the functions in the DLL are. Usually you run a program on the DLL that will put all of this information into a lib file. When you compile and link your program, you also link in this lib file so that the linker knows how to generate calls to the DLL functions.
When this program starts, Windows looks at its Import Table and figures out which DLLs this program uses. It then makes sure each of these DLLs is loaded into memory and increments their reference count by one. It then goes through the program's code and makes sure the program knows the exact memory address of each function it uses in the DLLs. When the compiler generated the program code, it left "gaps" in the code where the code was calling functions from DLL's. When Windows loads the program, it looks through the code and fills these "gaps" with the memory addresses of the functions in the DLLs.
If you've ever gotten some error that says "Undefined Dyna-Link", it means that Windows was not able to correctly fill in all these gaps in a program's code. This is usually caused by out-of-date DLL's which do not contain some functions that the program expects them to contain.
Ok, so if you're really on the ball today you're now saying "Since you have to link a program with a .lib file describing the DLL's exports, won't we have to re-link the Quake2 engine in order for it to use our DLL?". Well, the answer is no as long as the exported functions have not changed name and they still accept the same parameters.
The above method (ie linking with .lib files) is the most common method for using functions located in a DLL. At runtime (when your program is compiled, linked, and already running), however, you can look up other functions by name in DLL's. Once you have found the address of the function, you use a function pointer to call the function. This method is a total pain in the butt, however, and is only used in certain situations.
The above two methods of using functions in DLL's is specific to the Win32 operating systems. Id uses a different method to get at the multitude of functions inside gamex86.dll.
