This is a newbie request. I'm looking for materials on .dll creation. Specifially, i want to create a .dll out of a simple 3D engine i've made to learn about the process. I need information on dynamic link libraries that go deeper than the wikipedia page, how are they created, what's necessary, how to create different .dll files for "debug" and "release", how to create a PDB file for it and how to create a header file that'll allow for easy usage of the library from a, f.e., C++ program. Material with strong theoretical side (not as much, "how to create a dynamic link library in visual studio") would be great.
Please share good materials on the subject, all i can find is some information here and there and it doesn't paint the picture for me.
Reading between the lines, I think you really want to know about libraries in general rather than dll's specifically. A library is simply a handy package of object (compiled) code, along with some information about how to call into it. In C++, this usually takes the form of a .h file.
With static libraries (.lib), the linker pulls in the code it needs in exactly the same way as it does with all the rest of your classes. A normal class will get compiled to object code (MyClass.obj), and when they're all done the linker sticks them all together and wires up any inter-object calls with the appropriate addresses. It's the identical process with .lib library files. You end up with a big ball of executable code which includes both your classes, and the library functions within it.
With a dynamic library (.dll), the only difference is that the linking (wiring) happens at runtime instead of at compile time, and the library object code remains in a separate ball - the dll file. When you compile your exe, all calls that use functions in the library are mapped to a stub function. When Windows loads the dll for you, it will stick the dll code into the same memory area as your process, and wire up the stub functions to the real functions that are now available.
The only other difference is that a dll must expose a function that Windows can call when it loads or unloads the dll, in case the dll wants to do any initial setting up / clearing down. This is traditionally called DllMain().
If you want to learn about libraries, I would concentrate on creating a static .lib first before worrying about dll's. This is where most of the work is. Once you have a lib it is child's play to turn it into a dll.
The main thing you need to think about when creating a library is how you are going to expose your API (Application Programming Interface). This is just which functions/classes you are going to expose to the people using your library. You don't have to expose them all, but you do have to decide WHAT to expose. Are you just going to expose some C style functions, or are you going to expose entire objects? This is the real challenge when designing a library. You should try and make your API as easy to use, and obvious as possible if people (and you!) are going to find your library useful.
As for pdb files, differently named release/debug modules, and creating .h files. These are identical to when doing so in an exe.
1) Create a new DLL project, using VS wizard.
2) Add your existing source files to it.
3) Put into *.def file (which should have been created by the wizard) the names of the functions that you want to export from your DLL, as described here.
Basically, that's it. Debug and release configurations are automatically created by the wizard, but if you want the 2 variants to be named differently, you can change their output names: go to Project Properities -> Configuration Properties -> General -> Target name.
Related
I have paid for an expensive .dylib file however, the code is non objective-c in short, horrendous! I am thinking of creating a wrapper of some sort like an API to make interfacing with this .dylib nightmare free. How is this done? Here is what I was going to do:
Create a customDylibSDKWrapper .h and .m file, and have the appropriate function names that will keep things simple, and in the .m file, add all the c++ functions inside each objective-c function. So then all I would need to do in the future is, call the objective-c function and that will automatically call the C++ code.
Is this the correct way of creating a wrapper?
If it is, this does not create a private hidden wrapper, all the code will still be visibile. Is there anyway to package the .dylib file along with my objective-c .m files exposing only the objective-c .h file?
If anyone is curious to see the horrendous code feel free to look at this link: link to hard to decipher code
You can create both a dynamic library and a static library with Xcode.
Creating dynamic libraries isn't officially supported, and it requires editing some XML, and apps that include dynamic libraries won't be approved by Apple, so I'm not going to bother with dynamic libraries in this answer.
You can however easily create static libraries.
Step one: start a new project, being sure to select Cocoa Touch Static Library when you create the project:
Step two: Write your code.
Step three: Push the run button. Since your static library should have any code that will actually run, nothing should actually run. Instead, Xcode builds the library.
In the view on the left that shows all your folders and files and such, you should see a .a file, which is the compiled library. You can find on your computer by right-clicking and clicking "Show in Finder".
Now all that's left is distributing the .h/.a files to whoever you want.
I do not have much experience working with COM and was wondering if anyone knew the minimum amount of information I have to provide to #import a dll into a cpp file (which will be used to make a dll). According to MDSN (http://msdn.microsoft.com/en-us/library/8etzzkb6(v=vs.80).aspx) I need to include a type library resource such as an .ocx file. Is this the case even for a Microsoft shared dll (e.g. mso.dll)? In addition, what are the other type library resources can I use?
From what I have gathered so far, I just need to provide enough information to the MIDL for it to form the interface to the dll in the right way (this seems to be the essence of COM).
The original link is dead. https://learn.microsoft.com/en-us/cpp/preprocessor/hash-import-directive-cpp?view=vs-2019 seems to be the new URL.
In the link that you listed a key sentence is "#import creates two header files that reconstruct the type library contents in C++ source code". When you #import MSO.DLL you are importing a type library to your project (not to your cpp file) and it creates the necessary COM interface definitions. So you don't need to provide additional information.
But there are probably other files you need to #import in order to use Office applications, depending on what you are trying to do.
I want to emulate an unmanaged dll in c++. Is there a good tool to open and view it's interface?
Thanks
The most commonly used tool is Dependency Walker. This shows the list of exported symbols.
However, it does not show the function prototypes because they are not contained in the DLL meta data. To get that information you need a header file for the DLL. The exception to this statement are DLLs containing a COM/ActiveX component with a type library.
And even if you do have the prototypes, that's not enough to know how to emulate the DLL. You need full documentation for the DLL. And then you probably still have a lot of reverse engineering to do.
Currently my visual studio is basically generating Engine.dll and Game.exe
Engine.dll links to some other basic libraries like:
d3dx9d.lib
ComCtl32.lib
WinMM.lib
WSock32.lib
etc.
I also wanted to try to create an Engine.lib, but I get some really nice warnings now: Symbol x has been defined already. These libraries define the same symbols.
So I read somewhere that I must force my user (Game.exe) to link to the libs instead. But this is just really inconvenient I think, especially if I have many games and I decide to add another library to my engine. It's just maintenance for something so simple.
Should I stick to the .dll, or is there some way to fix this beauty up?
Thanks a lot,
Antoon
You need to make up your mind whether the want the DLL or the static link library. Advantage of a DLL is that the build times can be quicker if you make local changes. Advantage of a .lib is that you'll end up with only one deployable file.
Getting it linked (either the static .lib or the dll's import .lib) is otherwise automatic. You want to make sure that the library is built first, can't link the .exe without it. Right-click the exe project in the Solution Explorer window, Project Dependencies, tick the library project. That automatically adds the .lib to the exe project's additional dependencies.
Using #pragma comment(lib, "engine.lib") in the engine's header file is another way. Repeat for other dependencies like the OS import libraries. Getting the library path right is a // todo item.
Did you create a different namespace to avoid naming clashes?
EDIT -- seems like there is some confusion as to what you're asking, because you are asking a couple of questions.
To me, it sounds like you want to take a stab at implementing your own Engine class. However, you've got naming issues. I am treating this as more of an architectural question now. If you write your Game to an interface, then the problem goes away. For example, if your Engine is using different algorithms, then if you had written an EngineInterface that the current Engine and YourEngine implemented, then you could easily use Strategy to flip between the different implementations on the fly. This is nice because you'll be able to see the differences in-game if you wire the preferences into the app.
If the symbols are not supposed to be the same, use diferent names or control how they are exposed. Another option is the usage of namespaces to avoid naming conflicts.
If the symbols are supposed to be the same thing, you need to define those only once in one of the libs.
How are DLLs created out of C++ source code, and how are they used in other sources?
The DLL is a 'Dynamic Link Library' which works a lot like other libraries but is not linked with your executable application. At run time you can call specific functions for loading your DLL and executing its exported methods.
You can try creating a DLL yourself- create a project using visual studio and specify a DLL. This will create some of the base constructs for your project such as settings for your project to compile the DLL and also some base code for exposing methods, objects, or variables.
There are many walk through's to help you at this point: check here.
So, to summarize:
A DLL is a library which you can be loaded at runtime. This is a very flexible 'plug-in' model. Example: You can programmatically select and load different DLL at runtime. Each DLL can be a 'plug-in' to provide different functionality.
A DLL Has an entry point. Just like your Main function of your command line executable is the entry point, the DLL has an entry point function which is called when different events occur on the DLL such as loading, unloading, and more.
To use a DLL you must use the exported objects or methods of the DLL.
When Calling these exported functions from another application it is very important that you match compatible types! Also, make sure the calling conventions are compatible