How to create DLL's?
Author
How do I create DLL''s? On Flipcode.com there is a tutorial that covers functions. But when I tried to apply it to classes and other things it wouldn''t work. So would someone point me to a place that will explain how to create DLL''s?
Pop open MSVC, make a new workspace, choose "Win32 Dynamic-Link Library" and choose "A DLL that exports some symbols" to get some example code the exports some functions and data.
Magmai Kai Holmlor
- The disgruntled & disillusioned
Magmai Kai Holmlor
- The disgruntled & disillusioned
Author
Thanks a lot! That solves many of the problems. Now I have just one more question for now. When my DLL is created will people have to use the resulting library along with the DLL or can I somehow make it so that they can load it themselves in their code so that they do not have to update their code when the DLL is updated?
Basically you got 2 ways of using DLLs: load-time linking (MSDN lingo) that is pretty much the easiest way to use DLLs: All you need to compile is the static library and the header the defines the exported functions (Pretty much like how the DirectX libraries works, I guess) and you also got run-time linking which is more annoying, but sometimes necessary:
You load the library with LoadLibrary(), then, if you want to use a function, you need to get it''s address in memory with GetProcAddress() and save it with a function pointer (It''s not that complicated).
The difference is pretty simple: When you use load-time linking, the DLL is REQUIRED for the application to run, meaning that if the DLL isn''t around, the user get a nasty error ("Required Library was not found") but with run-time linking, you load the library yourself (Your application is not directly linked with the library, so you can choose if to show an error message or not and so on)
- Goblineye Entertainment
The road to success is always under construction
You load the library with LoadLibrary(), then, if you want to use a function, you need to get it''s address in memory with GetProcAddress() and save it with a function pointer (It''s not that complicated).
The difference is pretty simple: When you use load-time linking, the DLL is REQUIRED for the application to run, meaning that if the DLL isn''t around, the user get a nasty error ("Required Library was not found") but with run-time linking, you load the library yourself (Your application is not directly linked with the library, so you can choose if to show an error message or not and so on)
- Goblineye Entertainment
The road to success is always under construction
Author
I don''t think that answered my question. Nice information to know however. Let me rephrase the question.
When I compile the DLL project there are three files created. The DLL, a static library(*.lib), and an ''object file''. I have no idea what the object file is for. Now, currently when I test my DLL''s I use the static library to create the test programs. I then update the DLL by changing something in the functions in such a way as that the functions themselves, context wise, do not change. But when the new DLL is placed with the old program the program doesn''t like it and it gives me that error mentioned in the previous response.
What I want is so that people who use my DLL won''t have to re-compile their programs. They will just have to replace the DLL when a new version comes out. This is, of course, assuming that the update didn''t change the context or parameters of a funcition used in the program.
When I compile the DLL project there are three files created. The DLL, a static library(*.lib), and an ''object file''. I have no idea what the object file is for. Now, currently when I test my DLL''s I use the static library to create the test programs. I then update the DLL by changing something in the functions in such a way as that the functions themselves, context wise, do not change. But when the new DLL is placed with the old program the program doesn''t like it and it gives me that error mentioned in the previous response.
What I want is so that people who use my DLL won''t have to re-compile their programs. They will just have to replace the DLL when a new version comes out. This is, of course, assuming that the update didn''t change the context or parameters of a funcition used in the program.
--
When I compile the DLL project there are three files created. The DLL, a static library(*.lib), and an ''object file''. I have no idea what the object file is for. Now, currently when I test my DLL''s I use the static library to create the test programs. I then update the DLL by changing something in the functions in such a way as that the functions themselves, context wise, do not change. But when the new DLL is placed with the old program the program doesn''t like it and it gives me that error mentioned in the previous response.
--
What error message?
When I compile the DLL project there are three files created. The DLL, a static library(*.lib), and an ''object file''. I have no idea what the object file is for. Now, currently when I test my DLL''s I use the static library to create the test programs. I then update the DLL by changing something in the functions in such a way as that the functions themselves, context wise, do not change. But when the new DLL is placed with the old program the program doesn''t like it and it gives me that error mentioned in the previous response.
--
What error message?
Hey Running Wolf, what you want to do is called COM, though if your just talking DLL without COM specifics, you have to distribute the static lib with it if anything name specific(outside member functons or functions) there will need to be a recompile(unless you are using COM or a COM like method :-))
and remember for any C functions to specify
#ifdef _cplusplus
extern "C"
{
}
cuz C++ compilers mangle the names and it gets confused when it tries to resolve them, also try looking up virtual function tables in MSDN itll help alot.
and remember for any C functions to specify
#ifdef _cplusplus
extern "C"
{
}
cuz C++ compilers mangle the names and it gets confused when it tries to resolve them, also try looking up virtual function tables in MSDN itll help alot.
Author
Thanks a lot!!! I''ll look that up! I have just one question....which will probably be answered when I wake up. It''s late where I am so I''m probably not thinking straight but what do you mean by ''name specific''?
quote:Original post by Running_Wolf
What I want is so that people who use my DLL won''t have to re-compile their programs. They will just have to replace the DLL when a new version comes out. This is, of course, assuming that the update didn''t change the context or parameters of a funcition used in the program.
You don''t have to use COM for that. Let''s say you got a function called DoSomething(). Now let''s say you update the DLL with a new version, you fixed a couple of bugs in DoSomething(), but you didn''t change the function name or parameters, then it should work.
Also, like anony said, add #extern "C" before functions you want to export or the C++ compiler will mess up the name.
- Goblineye Entertainment
The road to success is always under construction
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement