I've encountered a strange behavior in __declspec(dllexport) in my project.
I have a C++ project that uses classes, namespaces, try-catches and more cpp elements.
When exporting any dummy function in this DLL, no other C project will be able to load it with LoadLibrary (Getting error 'module not found').
Is it possible to load dynamically C++ dlls through C projects?
These projects are Windows Mobile projects, but they should behave the same as on regular PC win32.
I'm stuck on it and any help will be appreciated.
Thank you,
Emil.
LoadLibrary is completely oblivious to the language used to compile a module. If LoadLibrary says it can't find the module, then it's very likely the case that it really can't find it. Make sure you've specified the right file name. If you've included a drive and path, make sure they're correct, too. If you haven't included a drive or path, then make sure the file exists somewhere where LoadLibrary can find it. The places it searches are listed in Dynamic-Link Library Search Order. Also consider whether Windows Vista's directory-virtualization feature might be interfering.
Once the DLL is loaded, you may have any number of other issues in using the C++ DLL from your C code. The C++ compiler may have mangled the function names, so you'll need to provide the right names when you call GetProcAddress. The C++ code might use a different calling convention from what your C code expects, so you may need to change declarations in the C++ code, the C code, or both. If the C++ functions expect to receive pointers to classes or other C++-specific types, you'll need to change your C++ code so that its API is compatible with C. If your DLL allocates memory that the host program should free, or vice versa, you'll need to make sure that both modules can use the same memory manager.
All that is separate from the problem you're reporting, though, which is simply that the OS can't find your file. Focus on that first.
I found the problem. It was really a dependency dll problem. It was not found in the directory of the loading DLL.
Thank you all.
Related
I was wondering if I can take an existing windows DLL and static link the dynamically-linked files?
I saw a number of projects to do this with Linux/elf
http://magicermine.com/
http://statifier.sourceforge.net/
http://bitwagon.com/jumpstart/jumpstart.html
I imagine this is most likely not possible, but I am running into some issues in WinPE where when I statically linked the DLLs everything started working great.
I don't have the source to the existing DLL.
I guess I could make a pass-through DLL that exposed all of the same functions and static linked?
There is no tool support for linking in the code of a DLL statically.
The problem is that a DLL is a full Windows PE executable, not a C or C++ “library” in any sense. The C++ standard has only one statement that is vaguely in support of DLL-like things (in the para about dynamic initialization after first statement of main). You’re out of luck.
But if you had the source code (as e.g. with MFC), which you say you don’t, then you could just have created static libraries.
Do note that there already is a meaning for “linking statically” a DLL, namely to have it loaded and have its functions resolved automatically.
Which is the usual way of using a DLL.
And which is in contrast to explicitly loading it dynamically and using GetProcAddress to resolve its functions.
Regarding
” when I statically linked the DLLs everything started working great
presumably earlier you have explictly loaded the DLLs dynamically, and used GetProcAddress, and presumably something about that did not work perfectly.
One main problem with GetProcAddress is that it assumes that the provided function name is encoded as Windows ANSI (the machine-dependent encoding reported by GetACP), and then (apparently) translates that to UTF-8 for the function lookup.
One workaround could be to access the function by ordinal rather than name.
One way to find the ordinal with Microsoft's tools, is to use dumpbin /exports.
I know it's impossible to reverse a dll into a c++ code so I would like to collect as much as possible details from it.
It's not my dll, so I don't have the source code of course. Which program should I use?
Well, if you are skilled you can disassemble the DLL and understand all of its functions. This takes a substantial amount of time, but if you do that you can reverse it back to source by hand.
Otherwise, you can start by using a tool like Dependency Walker to get the DLLs and functions it depends on, and the functions it exports. From there you can find functions that interest you, and use a disassembler like IDA to see what they do.
You can see the list of exported functions by using the dumpbin tool. If C++ functions are exported, you might be able to infer parameters by the name mangling.
You can extract all the resources from the DLL by just "opening" it as a file for resource viewing in Visual Studio. If the DLL is a COM based DLL, there's a small chance the Type Library is embedded as a resource inside it. And if you have the Type Library, you can #import it to reconstruct the header files for the public interfaces.
That's about as good as it gets.
You need a PE file viewer. This will tell you the exports from the DLL and you can get the data in the .text section to see the machine code.
I know that if I have an .a or .so file and a header file for that library (for example for SystemC), I should
1. include header file
2. link the appropriate library.
But I can't handle with only .dll file as I can link it as well, but don't have a hearer file to include and to use commands. Con someone explain me what kind of .dll-s exist and how they are possible to use? Is it possible to use any .dll file or it should be a specific kind of .dll to be able to integrate to my application?
A DLL is functionally equivalent to a .so file (also know as a 'shared object' or 'shared library'). You need a header to declare the functions that are available inside the DLL and you need to link against a library which handles the business of loading and executing DLL calls (mostly delegated to the OS).
It is possible to use a DLL without any sort of header. You can directly call Win32 API's which will dynamically load a DLL into your programs virtual address space and call other API's which will give you what are essentially function pointers. However, you need to know the signatures of the function pointers to use the properly so what you're effectively doing in that case is declaring a tiny subsection of the actual DLL header for your use.
This wikipedia article may help, especially the section on shared libraries
Unlike Linux, Windows libraries are seperated into two forms: DLL (for runtime linking) and LIB for symbol declarations. link.exe (the windows linker) expects .lib files to resolve symbols being used by your program's headers during build time. More information here:
http://msdn.microsoft.com/en-us/library/ba1z7822(VS.71).aspx
Note that if you load a DLL compiled in C++, you hvae to avoid passing object pointers across the interface, as they are in general not portable. You have to keep to basic C calls and calling conventions, as that is what is defined by the Windows or Linux platform ABI.
Over the months I've written some nice generic enough functionality that I want to build as a library and link dynamically against rather than importing 50-odd header/source files.
The project is maintained in Xcode and Dev-C++ (I do understand that I might have to go command line to do what I want) and have to link against OpenGL and SDL (dynamically in SDL's case). Target platforms are Windows and OS X.
What am I looking at at all?
What will be the entry point of my
library if it needs one?
What do I have to change in my code?
(calling conventions?)
How do I release it? My understanding
is that headers and the compiled
library (.dll, .dylib(, .framework),
whatever it'll be) need to be
available for the project -
especially as template functionality
can not be included in the library by
nature.
What else I need to be aware of?
I'd recommend building as a statc library rather than a DLL. A lot of the issues of exporting C++ functions and classes go away if you do this, provided you only intend to link with code produced by the same compiler you built the library with.
Building a static library is very easy as it is just an collection of .o/.obj files - a bit like a ZIP file but without compression. There is no need to export anything - just include the library in the list of files that your application links with. To access specific functions or classes, just include the relevant header file. Note you can't get rid of header files - the C++ compilation model, particularly for templates, depends on them.
It can be problematic to export a C++ class library from a dynamic library, but it is possible.
You need to mark each function to be exported from the DLL (syntax depends on the compiler). I'm poking around to see if I can find how to do this from xcode. In VC it's __declspec(dllexport) and in CodeWarrior it's #pragma export on/#pragma export off.
This is perfectly reasonable if you are only using your binary in-house. However, one issue is that C++ methods are named differently by different compilers. This means that nobody who uses a different compiler will be able to use your DLL, unless you are only exporting C functions.
Also, you need to make sure the calling conventions match in the DLL and the DLL's client. This either means you should have the same default calling convention flag passed to the compiler for both the DLL or the client, or better, explicitly set the calling convention on each exported function in the DLL, so that it won't matter what the default is for the client.
This article explains the naming issue:
http://en.wikipedia.org/wiki/Name_decoration
The C++ standard doesn't define a standard ABI, and that's bad news for people trying to build C++ libraries. This means that you get different behavior from your compiled code depending on which flags were used to compile it, and that can lead to mysterious bugs in code that compiles and links just fine.
This extends beyond just different calling conventions - C++ code can be compiled to support or not support RTTI, exception handling, and with various optimizations that can affect the the memory layout of class instances, which C++ code relies on.
So, what can you do? I would build C++ libraries inside my source tree, and make sure that they're built as part of my project's build, and that all the libraries and the code that links to them use the same compiler flags.
Note that name mangling, which was supposed to at least prevent you from linking object files that were compiled with different compilers/compiler flags only mostly works, and there are certain things you can do, especially with GCC, that will result in code that links just fine and fails at runtime.
You have to be extra careful with vendor supplied dynamic C++ libraries (QT on most Linux distributions, for example.) I've seen instances of vendor supplied libraries that were compiled in ways that prevented certain things from working properly. For example, some Redhat Linux releases (maybe all of them) disabled exceptions in QT, which made it impossible to catch exceptions in main() if the exceptions were thrown in a QT callback. Fun.
I have a C++ dll file that uses a lot of other c++ librarys (IPP, Opencv +++) that I need to load into matlab. How can I do this?
I have tried loadlibrary and mex. The load library does not work.
The mex finds the linux things (platform independent library) and tries to include them. And that does not work.
Does anyone have any good ideas?
loadlibrary should work. I use it all the time to call functions from dlls written in C++ with C wrappers.
What errors are you getting when you try to use loadlibrary?
Make sure that the exported functions of the dll are C functions, not C++ functions. If not, then write C wrappers.
More info on exactly what you are doing when using loadlibrary would be helpful.
As mentioned by others, you should first wrap your C++ library as a C library - mathworks used to advise not to use C++ code directly in mex (dlopening C++ core directly is complicated), maybe it is still true.
Your description is quite unclear, too: what do you mean by "mex finds the linux thing", but that does not work. Saying that it does not work is not helpful: the exact commands and error message are.
You could go for the Java approach (since Matlab runs on a JRE and can access Java objects/methods -- just be aware that the Matlab JRE is not as up-to-date as the latest JRE, the one I'm running uses Java 1.5) and use JNA to access your DLL.
Or, if you wrote the top-level DLL, you could go for the COM/ActiveX approach.
I've had good success architecting the interface to my C++ functions as COM/ActiveX libraries -- you don't have to bother with that .h stuff.
See the External Interfaces guide on COM clients, particularly the part about managing/converting data.
It would be extra work to add the COM/ActiveX layer, but would make your library more portable within the Windows world and probably more easily used in MATLAB.
If you have a lot of function calls to your DLL, the COM/ActiveX approach might be faster (not sure), but otherwise I think the JNA approach would be easier.