Recommended DLL programming books
-
Hi, I'm trying to learn more about dll programming, and wonder if anyone can recommend any good books on the subject. I program in C++ and C#. I really want to understand writing them, using them, as it will help me in my projects. Thanks for your thoughts, Patrick
-
Hi, I'm trying to learn more about dll programming, and wonder if anyone can recommend any good books on the subject. I program in C++ and C#. I really want to understand writing them, using them, as it will help me in my projects. Thanks for your thoughts, Patrick
Programming DLLs aren't much harder than writing apps. Acquaint yourself with __declspec(dllimport) and __declspec(dllexport) (or equivalent method if dealing with a non-Microsoft compiler). Also refrain from doing anything in DllMain(). Many functions can't safely be called from DllMain() as it may very well cause lockups. I would imagine Raymond Chen[^] has an entry or two on pitfalls in the land of DLLs.
-- Painstakingly Drawn Before a Live Audience
-
Programming DLLs aren't much harder than writing apps. Acquaint yourself with __declspec(dllimport) and __declspec(dllexport) (or equivalent method if dealing with a non-Microsoft compiler). Also refrain from doing anything in DllMain(). Many functions can't safely be called from DllMain() as it may very well cause lockups. I would imagine Raymond Chen[^] has an entry or two on pitfalls in the land of DLLs.
-- Painstakingly Drawn Before a Live Audience
Jörgen Sigvardsson wrote:
Also refrain from doing anything in DllMain().
Um... say what? I've always put init routines and clean ups in DLLMain and I have never once had a problem with lockups. The only thing I could think of is not accounting for thread safety, but that's not the fault of DLLMain() - it's just an entry point. You gotta start somewhere.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Hi, I'm trying to learn more about dll programming, and wonder if anyone can recommend any good books on the subject. I program in C++ and C#. I really want to understand writing them, using them, as it will help me in my projects. Thanks for your thoughts, Patrick
If you want to cover *almost* the entire of gamut of what you'll be doing with Windows programming more times than not (including writing DLLs), I still recommend this book[^]. It is a bit dated now, but still has plenty of great info that's not too difficult to apply to Win64 dev. But, in the end, it's not that much different. You have to think differently though in that a DLL is meant to be shared, but at least it gets mapped to the process space that loads it, so even that isn't that big of a deal. I would definitely, have a few reads on how linkers and name decoration/mangling works before you do anything else. It'll save you needless headaches down the road.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Jörgen Sigvardsson wrote:
Also refrain from doing anything in DllMain().
Um... say what? I've always put init routines and clean ups in DLLMain and I have never once had a problem with lockups. The only thing I could think of is not accounting for thread safety, but that's not the fault of DLLMain() - it's just an entry point. You gotta start somewhere.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
The problem is that the loader takes a process-wide lock just before entering
DllMain. It also doesn't guarantee an order for calling different DLL'sDllMainfunctions. That reduces the set of reliably callable functions to those that the loader will definitely have processed before calling yourDllMain, which basically means most things inkernel32.dllare OK, but anything else is risky. For more, see Michael Grier's blog[^]. He was one of the developers to work on the loader in the Windows XP product cycle.Stability. What an interesting concept. -- Chris Maunder
-
If you want to cover *almost* the entire of gamut of what you'll be doing with Windows programming more times than not (including writing DLLs), I still recommend this book[^]. It is a bit dated now, but still has plenty of great info that's not too difficult to apply to Win64 dev. But, in the end, it's not that much different. You have to think differently though in that a DLL is meant to be shared, but at least it gets mapped to the process space that loads it, so even that isn't that big of a deal. I would definitely, have a few reads on how linkers and name decoration/mangling works before you do anything else. It'll save you needless headaches down the road.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
I would definitely, have a few reads on how linkers and name decoration/mangling works before you do anything else. It'll save you needless headaches down the road.
Yes, I understand the basic concepts of name mangling and decoration. Thanks for the tips.
-
Jeremy Falcon wrote:
I would definitely, have a few reads on how linkers and name decoration/mangling works before you do anything else. It'll save you needless headaches down the road.
Yes, I understand the basic concepts of name mangling and decoration. Thanks for the tips.
Stick^ wrote:
Thanks for the tips.
BTW, since I'm in the middle of writing a DLL lib myself; I needed to know just what was being said about avoiding DLLMain() usage. This whitepaper (by far) was the best explanation of it and is a very worthy read if you want to write DLLs also. Best Practices for Creating DLLs[^] Make a long story short, in DLLMain() stay away from launching other processes, threads, working with global memory, etc. Although, that's really a duh. The non duh part is to watch out for relying on calls to other DLLs (even stuff like user32.dll) because you're not gauranteed it'll be loaded (practially speaking yeah (if the serializer does its job right) but no garuantees because that's life). Point is, limit the scope of DLLMain to initilization routines that your DLL needs (allocation, configs, etc.), but make sure you don't accidently call something that references something that uses an API, etc. outside of your DLL that may not loaded.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
If you want to cover *almost* the entire of gamut of what you'll be doing with Windows programming more times than not (including writing DLLs), I still recommend this book[^]. It is a bit dated now, but still has plenty of great info that's not too difficult to apply to Win64 dev. But, in the end, it's not that much different. You have to think differently though in that a DLL is meant to be shared, but at least it gets mapped to the process space that loads it, so even that isn't that big of a deal. I would definitely, have a few reads on how linkers and name decoration/mangling works before you do anything else. It'll save you needless headaches down the road.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
I still recommend this book[^].
Got it, amongst others. All I need to do now is save up some dollars, buy VS2005 and start coding again.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash 24/04/2004
-
Jeremy Falcon wrote:
I still recommend this book[^].
Got it, amongst others. All I need to do now is save up some dollars, buy VS2005 and start coding again.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash 24/04/2004
Michael Martin wrote:
Got it, amongst others.
The only thing I don't like about the book is the installer for the source code samples craps out every time you use it. But oh well, it happens. :laugh:
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]