Dll vs Lib

Well you are asking the difference between static linking and dynamic linking. Dynamic linking creates both a .dll and .lib file. You link in the .lib file into your exe - but no size is added because the lib only contntains the stubs refrencing the functions in the .dll. Static linking, no .dll, makes a lib that has all the definitions in it - so the code is added directly into the .exe - increasing the size.

.Dlls do have an overhead added on since the exe must lookup the functions used - but its neglibile. Nowadays - static linking is really inefficient and impractical. Here's why:
Let's say that you make version 1 of your engine and develop a game with it. If you use static linking - there is no .dll so it is less files and a little faster. But, let's say there is a critical bug that you must fix. You would have to recompile the .lib and recompile the game to use it. Big hassal huh?

If you would have used a .dll, all you would have to do is fix your engine and then distribute the new .dll instead of a new .exe. This is much faster and more convient. I know that game developers will not want to have to recompile a game to update the engine if it is statically linked.

The .exe updates aren't necessaily from the engine being updated - it could be specific game code that needs to be changed as well. Overall I say that you should just use dynamic linking and not consider static linking at all.

I hope this helps.

- Drew

Quote:

Original post by Anonymous Poster Drew_Benton isn't quite right. There is something called incremental linking. If your library changes, you'll have to recompile your library (which you have to do if its a static lib or a dll), then you have to inrementally link your application (for static linking) or allow the dynamic linker to do it (with a dll). Static linking is not what consumes the time with a build. Also, a .lib isn't necessary with dll files, you can link it yourself, which does require more code (LoadLibrary/GetProcAddress), but this is how plug-in systems work. My debugging experiences with DLL's have been less than nice at times, which leads me to use static libraries most of the time, except when working with a specifically designed plug-in system. (Note: debugging difficulties were personal experience and doesn't reflect actual tool capabilities, your milage probably will vary).

AP, you have misinterpreted what I have meant. I know what you are talking about, but I'm talking about changing the final game .exe's dll, not rebuilding the entire game to make a new .exe, which then you are right - you would need to distribute the .lib, so it properly compiles. But if you are not changing the underlying core functions - you *can* simply replace the .dll and it will work as i have said.

I also agree that debugging .dlls are a pain in the rear. That;s why I use all the desired .dll code in the project I want it to first - and test - then convert it to a .dll. I find it more convient and a little bit easier than trying to develop a .dll from scratch.

Further more, I agree that the .lib and even the .h file is not required for .dll files. I am actually working on my plugin class - you will see my threads in general programming [wink]. It took a bit to figure it all out as you can see from the posts, but I eventually got it all working.

Axiverse, the final decsison is up to you, but I think that using .dlls are much better than statically linking. Undoubtly your engine will be changing and as AP has said, you can use plugins! I myself have only used 1 statically linked engine - and that was when I was helping someone set up the KYRA tile engine.

Another thing I must mention is when you statically link - you must use the same IDE when you make a project. If I made the engine with VC7 - the end user must also use VC 7 in order for it to work right. Just something to keep in mind (something I learned the hard way).

- Drew

You know, I have a good book for you to read. It’s titled "3D Game Engine Programming by Stefan Zerbst with Oliver Duvel". Chapter 3 talks about using interfaces. The interfaces are their implementations all reside in a DLL. The author uses a static library only to create the base interfaces. It’s almost an exact replica of DirectX. But you do not deal with any DirectX features. You only get the interfaces from the engine. The implementations are the objects that deal with DirectX.

This is what I’m doing. I’m making a DLL for all my major components of the engine: Graphics, Sound, Input, Network, and Artificial Intelligence. So that’s five DLLs that my project will start out having. The major benefit from using DLLs is that if there was a bug in a certain component, I would only have to track down the bug, fix it, then recompile and distribute the newer version (patch). I think it works quite well. Besides, most games you see now make use of DLLs.

Another example of the benefits from using DLLs would be if you were working for a software company. You could have a separate team working on each component of the engine at the same time, hence speeding things up. Also, if you would like to update you engine with new features periodically, using DLLs would be an easy way to go. Other wise you would have to write your own plug-in system. But I would rather stick with DLLs because their easy to make and go along ways.