Howdy, folks!
I'm a little confused about DLLs, and the excellent book on C++ I bought doesn't cover them.
So I have a few quextions:
1) How does my program (helloworld.exe) use/connect to a DLL (plugin.dll)?
2) How can my program get information from a group of unknown DLLs in a directory (like Winamp plugins)?
3) How do I call a function in a DLL? (helloworld.exe calls "print_me()" in plugin.dll)
4) How do I make a DLL? (I'm using Dev-C++, and I know there's a DLL project, but are there any gotcha's I have to know about?)
5) Are there performance issues for DLLs?
6) Can a DLL designed for Windows be recompiled into a DLL equivalant in Linux? Or are they that different of a animal?
7) (A little wierd) Can consoles (XBOX, Playstation, GameCube, etc) use DLLs, or is that like an operating system function?
I would really appreciate any light shed on this subject! Thanks!
How do DLLs work? How do I make them?
-
omaremad
ok im not sure but ill try
ok imagine the dll is a library of books telling the pc on how to do 3d rendering
now
ur exe is just u telling the pc wich books to read
now the confusing part
when u compile the exe the linker(in the compiler) links the relavent books in the dll to the exe so ur exe doesnt have to load up the whole irrlicht source
the linker needs the help of a .lib file or .a in devcpp
this tell sthe linker what the books are
btw xbox does support xbox compiled dlls
ps2 maybe (it runs linux)
gc(well
up till now no one has been able to use gcs gpu(sealed off some how)
BUt
gc runs linux(google it)
doom has even been ported to it
but all this runs on the cpu which would not run fst 4 3d gfx)
however
yeti engine has been ported to gc and runs fast (but still uses software mode)
bye
ok imagine the dll is a library of books telling the pc on how to do 3d rendering
now
ur exe is just u telling the pc wich books to read
now the confusing part
when u compile the exe the linker(in the compiler) links the relavent books in the dll to the exe so ur exe doesnt have to load up the whole irrlicht source
the linker needs the help of a .lib file or .a in devcpp
this tell sthe linker what the books are
btw xbox does support xbox compiled dlls
ps2 maybe (it runs linux)
gc(well
up till now no one has been able to use gcs gpu(sealed off some how)
BUt
gc runs linux(google it)
doom has even been ported to it
but all this runs on the cpu which would not run fst 4 3d gfx)
however
yeti engine has been ported to gc and runs fast (but still uses software mode)
bye
OK. So if I make a DLL in Dev-C++, I should get a .DLL and a .A, and I link to the .A (like for Irrlicht, gotcha).
But now what If I have 10 DLLs that I know nothing about (like plugin DLLs). How can I run code in these if I don't know who/what/where they were compiled as. (Like in Winamp, all I have to do is drop a DLL into the plugins directory, and next time I start Winamp, I get the new plugin installed)?
But now what If I have 10 DLLs that I know nothing about (like plugin DLLs). How can I run code in these if I don't know who/what/where they were compiled as. (Like in Winamp, all I have to do is drop a DLL into the plugins directory, and next time I start Winamp, I get the new plugin installed)?
-
darklordsatan
Interesting questions my friend
1) How does my program (helloworld.exe) use/connect to a DLL (plugin.dll)?
Usually this is acomplished by means of an import dll (a dll with some exported functions, a header, and a static lib). You include the header(s) in your program, and link to a .lib, then use the functions in the dll as normal functions. This is the normal way.
Another way to do this is to link the dll functions on the fly, by means of function pointers. Its a little more tricky, and you need to know the function names and parameters...
2) How can my program get information from a group of unknown DLLs in a directory (like Winamp plugins)?
You can use a PE "spy" to get info on a given dll (like the export functions it has, the resources it has in case it does, and so on...). With the help of this, you could use the second tecnique I explained in 1), and provided you dont have the info on the functions...
3) How do I call a function in a DLL? (helloworld.exe calls "print_me()" in plugin.dll)
See my latest statement...
4) How do I make a DLL? (I'm using Dev-C++, and I know there's a DLL project, but are there any gotcha's I have to know about?)
No gotchas... If you happen to have any questions, try the official forums at http://www.bloodshed.net/forum
5) Are there performance issues for DLLs?
Nope, they are great, they rock!
6) Can a DLL designed for Windows be recompiled into a DLL equivalant in Linux?
Yeah, this is tricky, and once I got a tutorial on this...
The Linux dll equivalent is a "shared object" or *.so.
So, you can try searching google for creating dlls and so
I dont recall how I found that great article...
Or are they that different of a animal?
Nope!
7) (A little wierd) Can consoles (XBOX, Playstation, GameCube, etc) use DLLs, or is that like an operating system function?
Yes, they can!!! Obviously, you dont talk about DLLs, Those are windows specific, you need to talk more about "dynamic libraries", and since every console uses a different OS, then probably the format is different from the normal DLLs you know...
But for example, XBOX uses a modified version of winME (or win2k/NT dont remember), so basically everything is the same, what changes is the compiler and the API...
Dlls are not an OS function; they are an implementation of a programming concept : dynamic libraries. And Im sure pretty much every OS has them.
Ok folk, check out those links, I hope your apetite for DLLs is filled
http://www.flipcode.com/articles/articl ... dlls.shtml
http://www.codeproject.com/dll/
Cheers folk,
"Guest"
1) How does my program (helloworld.exe) use/connect to a DLL (plugin.dll)?
Usually this is acomplished by means of an import dll (a dll with some exported functions, a header, and a static lib). You include the header(s) in your program, and link to a .lib, then use the functions in the dll as normal functions. This is the normal way.
Another way to do this is to link the dll functions on the fly, by means of function pointers. Its a little more tricky, and you need to know the function names and parameters...
2) How can my program get information from a group of unknown DLLs in a directory (like Winamp plugins)?
You can use a PE "spy" to get info on a given dll (like the export functions it has, the resources it has in case it does, and so on...). With the help of this, you could use the second tecnique I explained in 1), and provided you dont have the info on the functions...
3) How do I call a function in a DLL? (helloworld.exe calls "print_me()" in plugin.dll)
See my latest statement...
4) How do I make a DLL? (I'm using Dev-C++, and I know there's a DLL project, but are there any gotcha's I have to know about?)
No gotchas... If you happen to have any questions, try the official forums at http://www.bloodshed.net/forum
5) Are there performance issues for DLLs?
Nope, they are great, they rock!
6) Can a DLL designed for Windows be recompiled into a DLL equivalant in Linux?
Yeah, this is tricky, and once I got a tutorial on this...
The Linux dll equivalent is a "shared object" or *.so.
So, you can try searching google for creating dlls and so
I dont recall how I found that great article...
Or are they that different of a animal?
Nope!
7) (A little wierd) Can consoles (XBOX, Playstation, GameCube, etc) use DLLs, or is that like an operating system function?
Yes, they can!!! Obviously, you dont talk about DLLs, Those are windows specific, you need to talk more about "dynamic libraries", and since every console uses a different OS, then probably the format is different from the normal DLLs you know...
But for example, XBOX uses a modified version of winME (or win2k/NT dont remember), so basically everything is the same, what changes is the compiler and the API...
Dlls are not an OS function; they are an implementation of a programming concept : dynamic libraries. And Im sure pretty much every OS has them.
Ok folk, check out those links, I hope your apetite for DLLs is filled
http://www.flipcode.com/articles/articl ... dlls.shtml
http://www.codeproject.com/dll/
Cheers folk,
"Guest"
-
darklordsatan
You "drop" the plugins because they are meant for winamp, so its made to recognize them at startup...AutoDMC wrote:OK. So if I make a DLL in Dev-C++, I should get a .DLL and a .A, and I link to the .A (like for Irrlicht, gotcha).
But now what If I have 10 DLLs that I know nothing about (like plugin DLLs). How can I run code in these if I don't know who/what/where they were compiled as. (Like in Winamp, all I have to do is drop a DLL into the plugins directory, and next time I start Winamp, I get the new plugin installed)?
If you were to use one of those (dont find a reason though), you'd need to use a PE spy like I said before, to see the export functions they probably have, in order to be able to use them inb your own applications. And since you dont have an import library (.lib or .a) nor even a header, you need to load them dynamically (on-the-fly) like I explained before...
Cheers
Thank you, that is very helpful.
What I was trying to do, is make something similar to a batch language. You could install plugins (dlls) that would extend the language with more commands.
So, check me here...
I have a directory of DLLs which are designed to be plugins.
They all export a function named "get_commands()", which returns a list of command names and function pointers into that DLL.
Then I could simply follow the function pointer into the DLL to call that "command?"
What I was trying to do, is make something similar to a batch language. You could install plugins (dlls) that would extend the language with more commands.
So, check me here...
I have a directory of DLLs which are designed to be plugins.
They all export a function named "get_commands()", which returns a list of command names and function pointers into that DLL.
Then I could simply follow the function pointer into the DLL to call that "command?"
-
darklordsatan
Im sorry but I kinda lost you.
What I can tell you is this:
You have an app, and wanna extend some functionality with it by means of plugins.. ok
You could follow 2 approaches
1. Create a plugin SDK. Its basically an structured thingie (check in codeproject all around for articles, there are some good ones on this), and you provide the user (you, or people who want to create plugins) a .lib (or .a if on gnu/mingw compiler) and a header file (with the function signatures). Then, the plugin must implement a main entry point that you call from the main app (basically some initialization is performed here), and some other functions...
One of them could be
getPluginAuthor() -> Returns the author to put it in the plugin about panel or somethin
getCommands() -> Could return, I dont know, a list of function pointers as you say that would execute commands
And so on
2. Instead of providing a .lib and a header, you call the dll on the fly (use this one if youre not interested in people making plugins for your app, only you...)
A good starter point would be to look at some plugins sdk around
Some examples are http://www.astonshell.com, http://www.delgine.com, and my amazing new love (good bye devcpp) http://www.codeblocks.org
Cheers
What I can tell you is this:
You have an app, and wanna extend some functionality with it by means of plugins.. ok
You could follow 2 approaches
1. Create a plugin SDK. Its basically an structured thingie (check in codeproject all around for articles, there are some good ones on this), and you provide the user (you, or people who want to create plugins) a .lib (or .a if on gnu/mingw compiler) and a header file (with the function signatures). Then, the plugin must implement a main entry point that you call from the main app (basically some initialization is performed here), and some other functions...
One of them could be
getPluginAuthor() -> Returns the author to put it in the plugin about panel or somethin
getCommands() -> Could return, I dont know, a list of function pointers as you say that would execute commands
And so on
2. Instead of providing a .lib and a header, you call the dll on the fly (use this one if youre not interested in people making plugins for your app, only you...)
A good starter point would be to look at some plugins sdk around
Some examples are http://www.astonshell.com, http://www.delgine.com, and my amazing new love (good bye devcpp) http://www.codeblocks.org
Cheers
-
hybrid
I think the plugin mechanism i not as hard as told before. You just have to deal with dynamic loader interface of the OS you're using.
The idea of having a common interface the dll has to implement is correct. Thus, the dll will have some methods known to your app regardless of who compiled the dll. Next, a call to the dynamic loader passing the filename of the dll will create an object on which you can call the API methods (more or less this scheme, depending on OS and programming language).
The problem with this mechanism is that you can't know which interface was implemented by the library so it's easiest to drop them in specific directories. Otherwise you have to query the libraries using the dynamic loader interface again.
BTW: There are some runtime penalties with shared libraries, but mostly upon startup due to loading, i.e. disk access. Later on access to methods in dynamic libraries is done similar to access to methods statically bound. It could be the case, though, that it needs one level of indirection more, i.e. one method call more. Not really sure about this.
The idea of having a common interface the dll has to implement is correct. Thus, the dll will have some methods known to your app regardless of who compiled the dll. Next, a call to the dynamic loader passing the filename of the dll will create an object on which you can call the API methods (more or less this scheme, depending on OS and programming language).
The problem with this mechanism is that you can't know which interface was implemented by the library so it's easiest to drop them in specific directories. Otherwise you have to query the libraries using the dynamic loader interface again.
BTW: There are some runtime penalties with shared libraries, but mostly upon startup due to loading, i.e. disk access. Later on access to methods in dynamic libraries is done similar to access to methods statically bound. It could be the case, though, that it needs one level of indirection more, i.e. one method call more. Not really sure about this.