Skip to main content
gamedev.net
🔒 Locked

dll's

Started by Lode 1 reply 400+ views
Original Post
Lode
Lode
How do DLL's work? How comes it I can write a program in C++ that uses a DLL, and it actually works? Can programs that aren't written in C++, use DLL's that are written in C++? Do DLL's contain compiled functions and variables? If so, how can a program written in a language that uses a totally different kind of functions use that DLL? If not, what is there inside DLL's, different parts of executable code? How can your program know which part of the DLL does what?
twix
twix
Quote:
Original post by Lode
How do DLL's work?
How comes it I can write a program in C++ that uses a DLL, and it actually works?

Cause that's what they're supposed to do. [wink]
Quote:

Can programs that aren't written in C++, use DLL's that are written in C++?

Yes.
Quote:
Do DLL's contain compiled functions and variables? If so, how can a program written in a language that uses a totally different kind of functions use that DLL?

Yes, and they can because it's all machine code, in the end. If you know the calling convention (order arguments are to be put on the stack and whatnot), you can call any function you want. Of course, the language that calls into the DLL will have to know how to do it C++'s way.

As for how you know what parts of the DLL to use, there's a sort of "table of contents" that points you toward the location of the functions you want. Those are resolved to actual addresses when the DLL is loaded into memory by your OS.

But glib responses aside, I strongly suggest that you consult Google. [grin]
Yann L
Yann L
Quote:
Original post by Lode
How do DLL's work?

They basically contain compiled, ie. executable code, much like an EXE file. The difference is that they can contain several entry points, that can be aquired and called by the loading process. The host loads a DLL (either automatically on startup, or manually via LoadLibrary in Windows), and the OS maps the executable code of the DLL in an available memory area. Since everything in the DLL is precompiled, all that is language independent. The host process then performs a kind of dynamic linking: it aquires a set of functions that are exported by the DLL, by using function pointers. As twix menioned, each DLL contains a table of content with all exported function names (or ordinal numbers) and their corresponding offset into the executable DLL code. Once the host has aquired these pointers, it can call the DLL functions.

All this is the theory, though. In practice, it's a little more complicated because of name mangling and calling conventions. When using pure C, name mangling and calling convention can usually be specified to be a standard, for example _cdecl. This will make the DLL compatible with all languages and compilers that support this convention (ie. pretty much all).

In C++, however, things get really messy, since you need to import all class methods, and reconstruct the vtables. Usually, this is done automatically, manual linking of C++ DLLs is a real PITA and rarely performed. Also, since there are no standard name mangling and calling conventions for C++ code, a C++ DLL exporting classes will be compiler dependent. To avoid these problems, people will usually export a simple C function (using the extern "C" keyword), that will return a C++ interface object.

That's just a quick rundown. DLLs have many more features, such as symbol import, startup code entry points, shared vs. private memory areas, etc. Look up on Google, there are many articles explaining DLLs out there (eg. on MSDN).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.