why dlls, and what kind of linking
Author
I was wondering, why exactly is it good to use dlls when making your game, as opposed to just compiling it all into one .exe? also should I use run-time linking or load-time linking, or does it not even matter?
A dll provides modularity. Provided you keep the names of the export functions the same - along with the parameters they expect - you can change out the code inside the dll without having to recompile the exe as well. One important exception to that pertains to debugging and multithreading. Both the exe and the dll should use the same version of the standard libs otherwise this leads to problems.
Use runtime linking when there''s a possibility the dll or the exported function might not exist, that way you can handle the absence of the dll or function gracefully. For example, say you want to provide for plugins to your game. As the game starts up, you would scan a plugins directory looking for dlls and dynamically load them into the address space of the game. You use dynamic, because you can''t know ahead of time whether there will be any plugins in the directory or not. If you statically linked to a dll that turns out not to exist, your program won''t run at all. When the OS loads your program it looks for dlls that it statically links to and loads them as well. If it can''t find them, it throws and your program won''t run. In the case of functions not being exported in various versions of a given dll, like say differences between W9x and WNT, using dynamic loading you can check if the function exists and if it doesn''t, provide an alternative. If you don''t, then the loader will barf as well - or worse, your program will barf when it attempts to call a function that doesn''t exist - or rerturns "Error Not Implemented".
Use runtime linking when there''s a possibility the dll or the exported function might not exist, that way you can handle the absence of the dll or function gracefully. For example, say you want to provide for plugins to your game. As the game starts up, you would scan a plugins directory looking for dlls and dynamically load them into the address space of the game. You use dynamic, because you can''t know ahead of time whether there will be any plugins in the directory or not. If you statically linked to a dll that turns out not to exist, your program won''t run at all. When the OS loads your program it looks for dlls that it statically links to and loads them as well. If it can''t find them, it throws and your program won''t run. In the case of functions not being exported in various versions of a given dll, like say differences between W9x and WNT, using dynamic loading you can check if the function exists and if it doesn''t, provide an alternative. If you don''t, then the loader will barf as well - or worse, your program will barf when it attempts to call a function that doesn''t exist - or rerturns "Error Not Implemented".
Author
thanks -- that makes sense, I have only one other question, unrelated to dlls really; how do you scan for files in folders?
Ok. In the plugins example that I gave, you would set the installation program to create a plugins subdirectory. Then when your game started up, you would use the GetCurrentDirectory api to find out where you are, then you would tack on "\\plugins" to that string and then change to that directory using SetCurrentDirectory. Once there you would use FindFirstFile, FindNextFile and FindClose to scan the directory looking for plugins. For details check out this: Plug-in Architecture Framework for Beginners and this too: Plug-In framework using DLLs.
A question for you DarkHamster: are you talking about using the system or standard library DLLs, or are you talking about writing parts of your own game as DLLs? If you want to write parts of you own game as DLLs, you should think about why you want to do that. Some of the reasons one would use DLLs are not important in a game.
To add to what LessBread said, another reason to use runtime linking would be if you don’t know whether you are going to actually use the code until runtime. That way, if you don’t need the code, it is not taking up room in RAM. For example, A DLL may contain code for some particular hardware; if the user doesn’t have that hardware then you don’t need to load that code. Regarding modularity, understand what kind of modularity you’re talking about. DLLs do not give your design instant modularity. Programs can be designed modular without using DLLs.
Build parts of your program as DLLs if:
- you are trying to save RAM by not loading in parts of you program you will never need, or will only need at certain times (maybe, for example, character creation code in a role-playing game).
- you have two or more programs that share the same code. That way, the code can be written into a DLL, which then only exists once in memory thereby saving RAM space. With a game, this is not usually the case.
- you are writing a third-party library. That is, you are writing code that you will give to someone else to use in their program and you don’t want to give away the source code.
Keep in mind that the interface to a DLL is only “C” style, not C++. So putting you code into a DLL when you don’t really need to will be a disadvantage.
To add to what LessBread said, another reason to use runtime linking would be if you don’t know whether you are going to actually use the code until runtime. That way, if you don’t need the code, it is not taking up room in RAM. For example, A DLL may contain code for some particular hardware; if the user doesn’t have that hardware then you don’t need to load that code. Regarding modularity, understand what kind of modularity you’re talking about. DLLs do not give your design instant modularity. Programs can be designed modular without using DLLs.
Build parts of your program as DLLs if:
- you are trying to save RAM by not loading in parts of you program you will never need, or will only need at certain times (maybe, for example, character creation code in a role-playing game).
- you have two or more programs that share the same code. That way, the code can be written into a DLL, which then only exists once in memory thereby saving RAM space. With a game, this is not usually the case.
- you are writing a third-party library. That is, you are writing code that you will give to someone else to use in their program and you don’t want to give away the source code.
Keep in mind that the interface to a DLL is only “C” style, not C++. So putting you code into a DLL when you don’t really need to will be a disadvantage.
Author
Yes I am indeed building my own system. And thank you for the additional answers -- I''m almost entirely new to dlls, but I figured I needed to learn eventually because they''re out there for a reason.
Author
Yes I am indeed building my own system. And thank you for the additional answers -- I''m almost entirely new to dlls, but I figured I needed to learn eventually because they''re out there for a reason.
At some point you should purchase a copy of Jeff Richter''s book "Programming Applications" - it covers a lot of important ground in regards to windows programming - processes and threads, memory managment, and of course dlls. The topics Richter covers form the basis for just about everything else that goes on in a windows program.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
