I am new to DLL development and appreciated for any help.
I have an existing c++ project and am trying to build it into dll using visual studio 2012. I changed the target extension and configuration type to be dll. I also excluded my main function. When I rebuilt it, the compiler complains:
LINK : fatal error LNK1561: entry point must be defined
When I moved the main function back, I could build the project successfully.
I want to make a dll only because there are functions and objects I need to use for another project, so i don't think I need a main function for the dll. Is having a main function the only solution for this error? Thank you in advance.
Just like a program requires main, DLLs require DllMain, a place to start and handle loading and unloading of the DLL.
Rather than a DLL consider a static library. There is far less overhead, no DllMain and supporting loaders and unloaders, and they are built directly into the compiled executable so you don't have to carry an extra file around and run the risk of clients with out of date DLLs or some malicious tool replacing your DLL with theirs. If you don't need the ability to swap out the the library with a replacement, a DLL is probably overkill.
Related
I've been making a program in Visual Studio 2012, what comes with it is that when I send my application to someone, they need the VS2012 Runtime, which sometimes they don't know where to download or what they need (for normal users "xxx.dll is missing" is very misleading).
I know exactly which dependencies my application requires (fantom.dll [Lego Mindstorms stuff] and the VC++ 2012 Redist).
I would like to show a dialog when these libraries are missing on application startup and provide the user with download links for these libraries.
Is this possible to accomplish?
Yeah you could do something like:
Move all of the code in your binary into a DLL.
Create an EXE which dynamically loads the DLL using LoadLibrary and unloads it with FreeLibrary.
If LoadLibrary fails, check if its due to missing DLLs, if so then display a MessageBox/your custom message and exit.
Of course this means your EXE project must NOT depend on the runtime itself - this shouldn't be an issue since you'll only need to call 3 win32 API's.
No it's not possible but you can create an installer for your program. The error is thrown during the loading of your program, before your code execution...
You can try with that : http://www.codeproject.com/Articles/24187/Creating-an-Installer
I can't speak for testing the VS2012 Runtime dynamically, but you can certainly validate fantom.dll dynamically. Instead of static-linking to the DLL directly, you can dynamically load it instead. You can configure your project to delay-load the DLL at run-time, and then provide a delay-load callback handler that the RTL will call if the delay-load fails. Or you can simply skip the delay-load feature and load the DLL yourself manually by calling LoadLibrary() and GetProcAddress() directly.
Sure, you can verify if a dependency exists on the deployed system. A few things come to mind...
You can see if the assembly is recognized on the running system by calling AppDomain.AssemblyResolve() . Further reading here
Another more primitive option is to call a File.Exists(your assembly path here) test, but I would advise against this as it's a bad practice to require hard-pathed installation locations.
That said, and as others have stated, it's still by far the best approach to create yourself an installation distribution.
Assume this scenario: An application (app.exe) is using multiple .dlls. I am debugging a function, bugged_function() from one of the .dlls used by the app: util.dll. While I am debugging bugged_function() from this I realize that something in the code is wrong and changes have to be made.
Steps to perform normally:
1. close app.exe
2. modify code in the function
3. recompile util.dll
4. rerun app.exe
What I want:
Bypass step 1 and 4. To do that I need to unload in some way, if possible, util.dll library so when compiling it can be overridden. The the application must somehow reload the library again.
EDIT 1:
I do not know how bugged_function() is called. Assume that I only have access to the source code of the library util.dll used by app.exe.
EDIT 2:
I am using Visual Studio 2010, and when I debug, I attach to app.exe process.
If the application is using the dll via run-time dynamic linking, it could be unloaded (FreeLibrary or similar), then reloaded (LoadLibrary or similar).
If the application is using the dll via load-time dynamic linking, I think you're out of luck.
Edit: I misread the question slightly. Since you can't modify app.exe, you'll have to rely on built-in functionality of that application for runtime loading and unloading, if it has it. That depends totally on the application.
Visual studio can edit and continue. So if you are at a breakpoint, you can make the changes you need to then continue your debugging. Visual studio will compile and apply the changes while maintaining state.
Edit: fixed edit and continue naming.
I need to build a DLL that can then be loaded with JNI from a java program. I was able to do this last year and it worked fine. I'm trying to recompile my same .cpp file now though that I make the dll with and it is failing because of an included dll dependency that gets brought in.
I have a c++ program that calls about 5 functions from some existing C++ code here. These functions are part of a huge codebase that are normally all linked together to build a set of 5 dlls.
I use dependency walker to view my dll and last year it compiled with just 2 dependent system dlls being put in my dll. Today I'm trying to recompile the same dll, but it brings in a 3rd dll file if I link with the .lib file from our existing codebase that contains the functions I use.
Basically I know my dll will work fine with JNI if I can avoid that 3rd dll showing up in my program. The problem is I don't know how to reference the functions I need in my code from our existing code base without linking to the lib file.
I can get this to work with standard c++ files and methods. This problem only happens when I reference this preexisting code from our huge codebase.
If I do not link my .obj file with a .lib file from our code I get unresolved reference messages from my Borland 5.5 compiler I have to use.
The overall issue is that my dll file works fine when I call it from a c++ exe file, but Java cannot handle something in it. Also, if I compile my code into a .so file in unix instead of a windows dll, Java JNI works fine and can load it. I know the problem is related to how Windows uses dlls, and I know if this 3rd dll doesn't load as part of my dll it will also work. I just have no idea what I did last year to build my dll without this 3rd one showing as a dependency.
If I comment out the functions from our existing code it compiles fine and loads because the 3rd dll dependency doesn't get put in my dll.
More Details
I had a message about missing _strcopy, so I linked in the cw32mti.lib file and that went away, but then that cw32mti.dll shows up in my dll file. How do I prevent the missing reference message for something like that and prevent it from putting the dll in my dll?
My link command looks like this.
ilink32 mydll.obj, mydll.dll,,cw32mti
The only way I get the other missing references to work is adding the other dll to my link command like:
ilink32 mydll.obj, mydll.dll,,cw32mti.lib other.lib
Where other.dll contains functions I call from mydll.dll such as calculate(int a, int b), so my code has a link it in like calculate(num1, num2); The problem is when I use the lib that contains the calculate method, it also brings in other dlls linked to the other.dll that I do not want to load. I need to be able to call calculate(num1, num2) without adding other.dll to mydll.dll. This worked before without dynamically calling calculate and using the getprocaddress type of coding.
Update - I eventually had to give up on getting the windows dll to work with the smartheap memory manager. Since this code was deployed in unix, I was able to just build the .so files and get those to work with JNI. For the Windows dll compile, I put some conditional compiler statements around the JNI code that was causing the smartheap dll to be loaded, so then when it compiles in windows it does not use that code. Instead I just had it print out a statement saying it was not executing in windows.
We also ran into issues later with getting our 64 bit JBoss server to run and load these 32 bit .so files. I ended up running a parallel JBoss server next to the 64bit one and called the methods that referenced the 32 bit library on the 32 bit instance of JBoss.
It may evolve into more later, but for now this task is working for us after months of trying many different things. I appreciate all of the help and input here.
If you can get your hands on the application DLL built from last year, use TDUMP to see what the module dependencies are. (You might have to analyze all the DLLs to get a good picture.) Then endeavor to reproduce that in the new DLL, probably by adjusting the linker's configuration .DEF file.
Without any code or .DEF file shown in your question, it is very difficult to be more specific.
I'm using Visual Studio 2010 to create a 32-bit DLL as a plug-in to a 3rd party app (AviSynth). The DLL was being correctly loaded by the 3rd party app until I tried to use the FFTW (http://fftw.org) DLL. I took the 32-bit FFTW DLL, ran "lib /def:libfftw3-3.def" to create a .lib file, added that as a resource in the project. Made some calls to the functions. It compiles fine, but when I try to load it in the third party tool, it fails.
I've tried putting the FFTW DLL alongside my DLL, and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
I am able to stop the debugger in the DllMain function and in the function called by AviSynth (AvisynthPluginInit2), but AviSynth claims to be unable to load the DLL after that, and breakpoints at the tops of functions that were called before are no longer hit.
The AviSynth error message is:
LoadPlugin: unable to load "C:\Program Files (x86)\AviSynth 2.5\plugins\xxxMYPLUGINxxx.dll"
Thanks for your help.
The first thing I try when I get something like this is Dependency Walker:
http://www.dependencywalker.com/
It won't catch every possible problem, but it's very quick to check for simple problems (missing DLLs, missing exports). You can also set it to open any number of file-extensions by double-clicking them. I usually set .dll, .ax, .ocx, .sys, .exe.
IMO one of the essential tools for any Windows developer.
ps: if Dependency Walker doesn't find any problems, try to load your DLL with LoadLibrary() and see what GetLastError() returns.
BTW:
and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
You cannot call LoadLibrary() from DllMain().
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order.
(The entry-point function is your DllMain)
Turns out that the FFTW DLL had to be in the same directory as the AVS script, not the AVISynth plugin directory. I guess that's the working directory for Virtual Dub.
Anyway, it works now. Thanks for the help!
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