I know there is a tool called Dll to lib but the developer is asking $1000.
I only need to convert one library, once, so its not easy to justify that price.
I tried IMPLIB32.EXE, but I just get empty .lib files.
How can I accomplish this?
Perhaps I can write a simple conversion app?
Added1:
The Dll's are typically stdcall not cdecl and written in older C like languages NOT C# or .NET or C++. I now need to call them from C++ apps. An example would be the SQLite.dll or zlib.dll.
I do not have access to the .lib files for these dll's.
Added2:
I re-wrote this code for VS2008
http://floodyberry.wordpress.com/2008/09/08/generating-dll-wrappers/
and included the example Dll etc downloadable here:
http://www.transferbigfiles.com/Get.aspx?id=7d86fa0b-6ddc-4f6f-8d31-2c20824aae9a
This in turn makes a project that creates a Dll. When I try to compile the Dll I get the linker error:
AddShow.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x300
Described here:
http://list.isis.vanderbilt.edu/pipermail/udm-users/2006-March/000664.html
Not sure how to proceed. So close yet so far
Next we move to this method
http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/
Running dumpbin with the argument /exports C:\path\to\AddShow.dll
does absolutly nothing
After some research
http://msdn.microsoft.com/en-us/library/aa446532.aspx
it seems that mspdb71.dll (now mspdb80.dll) is needed from the common/ide folder
dumpbin.exe now runs with error:
fatal error LNK1106: invalid file or disk full: cannot seek to 0x6179A
These threads suggests the version of dumpbin.exe might be the issue
I have Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
So I tried
Microsoft (R) COFF Binary File Dumper Version 5.12.8078
with no success.
After much reading I am no closer
http://support.microsoft.com/kb/815645
http://support.microsoft.com/kb/839286
http://markmail.org/message/p5vwzyfyv3bs6z34
http://fixunix.com/programmer/94825-fatal-error-lnk1106-invalid-file-disk-full.html
When I run ProcMon I see the first occurance of queryopen and sqlite3.dll when svchost.exe tries to open it and fails with the error PATH NOT FOUND. the path is C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\SQLITE3.DLL and is correct. If I put it at the root of the C drive then I get NAME NOT FOUND errors:
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\link.exe.Local
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\dumpbin.exe.Local
from link.exe and dumpbin.exe respectivly. Im using XPSP3 not Vista and this is about the limit of my knowledge of sysinternals. what are these .local files?
(csrss.exe is also not able to find a few manifest files.)
So no success yet, just more mystery
Added 3:
I tried to run dumpbin.exe from its installed location, \Program Files\Microsoft Visual Studio 8\VC\bin, but the OS said it couldn't find mspdb80.dll. I copied mspdb80.dll from \Program Files\Microsoft Visual Studio 8\Common7\IDE to try to get dumpbin.exe to run.
now I get the error:
"c1902 program database manager mismatch please check your installation"
If I remove mspdb80.dll from \Program Files\Microsoft Visual Studio 8\VC\bin the error goes away! but I can't run dumpbin.exe.
Added 4:
I was finally able to get dumpbin to run by copying the following files to a folder:
dumpbin.exe
link.exe
lib.exe
mspdb80.dll
I did get the error:
fatal error LNK1248: image size (FFFFFXXX) exceeds maximum allowable size
(80000000)
once, but replacing the dll fixed that. Presumably it got corrupted?
I then moved onto the next step in the instructions:
http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/
http://support.microsoft.com/kb/131313
and got the error:
warning lnk4017 statement not supported for the target platform ignored
This turns out to be because I specified the .dll instead of the .def file.
The resulting .Lib and .exp files are then added to the VS2008 project and compile and run. The debugger then reported an error:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call...
As mentioned here
"Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call" after successful C# callback from the C++ code of GameSpy lib
this is because I used stdcall in my dll and declared __cdecl in my app.
extern "C" { // put Dll C function prototypes here
int __cdecl AddTwoNum(int n, double f); // __stdcall
}
So changing this to __stdcall should fix it you would think.. but alas no.
now I get a linking error:
error LNK2001: unresolved external symbol _AddTwoNum#12
This is a decorated function name for some reason. Why?
Added n:
Well this turned out to be because the .lib file was made using a dll that with STDCALL functions. STDCALL requiers the caller to clean up the stack so the number of bytes of the arguments is appended to the function name with an # sign. IN this case I had three 4Byte iintegers for a total of 12 bytes.
Once I remade the .lib file from a dll created with the CDECL calling convention then all was good.
You can try using my .dll wrapper generator to create the stub .dll iain suggested.
I also found: this thread. Are you linking against the .dll instead of the .lib?
I am assuming you want to call some function/methods in a dll in C/C++ without having access to the lib file to link with it.
If you know the signatures of the functions you require, you can:
create your own stub version of the dll
create a dll project, with the same name as the dll you want to use
add stub implementations of the functions you want to call
the signatures are very important use depends.exe or dumpbin.exe to check they match.
then write/build your program to link to the stub dll
to run the program replace the stub dll with the real one
You could also go the dynamic way, using LoadLibrary() and GetProcAddress().
(See second link for an example).
In cases like zlib or sqlite you can download the source directly and compile your own lib file. In fact, I just did this the other day for zlib, I downloaded the source from www.zlib.net (direct zlib 1.2.3 download) opened the provided visual studio project file and compiled both a debug and release version of the lib. I haven't tried sqlite but seeing that they have the sources, it shouldn't be difficult to do.
If it's a proprietary dll, you could try asking the original developer or company for a lib file, or write your own stub dll that iain suggested or go the dynamic route that RaphaelSP.
If they are exported in C (no C++ name mangling) I would go the dynamic route myself.
I found this example rather quickly: http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/
This is supposedly a free tool that makes the conversion. I'm not sure if it's "free" as in "limited trial version" or not, the information is not very clear. If you've already tested this, edit your question and I'll delete this answer.
If you contact the developer of the Dll to lib tool they might be willing to give you a discount.
I've been in these situations before (where I needed an expensive tool just one time), and sometimes I have had success in getting a large discount.
It never hurts to try.
Good luck.
I have had success in getting a lib from DLL using details in http://wyw.dcweb.cn/dllfaq.htm. Your mileage might vary. I have used this to get a lib from python DLL to build some python extensions that are written in 'C'.
Open source edll has its own internal COFF loader. edll is written for quite different purposes, but since it has independent COFF loader within, maybe it's possible to incorporate your .dll into binary stream or resource inside your .exe, then in run-time use edll's COFF loader to load built-in dll.
Related
Per default, when compiling a Visual Studio project in release mode, the complete path to the pdb is put into the image file, e.g.:
c:\myprojects\demo\release\test.pdb
Using an undocumented linker switch (/pdbpath:none) one can force Visual Studio 2008 to reduce the full qualified name of the pdb, e.g:
test.pdb
I need to do the same with a project which is still built using VC6.
I tried the "/pdbpath:none" switch at the project settings level, but the linker complains about this unknown switch.
Does anyone knows a method (or a tool) to accomplish this either when linking a VC6 project or afterwards directly at the image level?
Your best bet is to use pdbstr.exe from MS directly. It allows for direct extraction, update, and misc other functions directly, independent of compiler version (up to the last supported version, which I think is VS2013 right now). We use it to add SVN linkings directly to PDBs which we then store in local symbol stores using srctool.
For newer link.exe versions, the syntax changed.
The option you want is now /pdbaltpath:%_PDB%
It is documented on MSDN: https://msdn.microsoft.com/en-us/library/dd998269.aspx
%_PDB% expands to the file name of the actual .pdb file without any path information
For VC6, you might want to continue using the same compilers but a new version of link.exe.
The Windows Driver Kits also come with a tool named binplace.exe which can modify this information post-build.
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.
I have a COM application that I want to use, but I only have the .exe from that app. Is there a way to extract the .tlb from that .exe?
I tried with tlbexp filename.exe from Visual Studio Command Prompt, but I get an error and I don't know why: TlbExp : error TX0000 : Exception of type 'System.OutOfMemoryException' was thrown.
I am using Visual Studio 2012 with C++.
Edit:
The .exe is in C++, later I saw that tlbexp is for .NET. This is why it didn't work, sorry for the confusion.
I still need to find a way to extract the .tlb from C++ .exe.
I have used this utility https://www.nirsoft.net/utils/resources_extract.html Just check the type libraries option.
It does now work on all cases but it works for many dlls and exe
In summary: Today I discovered that when a DLL is built without precompiled headers, a strange error shows when you try to use it.
Building the DLL goes fine when precompiled headers are disabled. However as soon as the DLL is attached (either compile-time or run-time) it results in the error "Invalid parameter". The actual error codes are different for both cases. When attaching compile-time a dialog pops up with error code 0xc000000d, when calling LoadLibrary() it returns a NULL pointer and GetLastError() returns 0x57.
EDITs:
I discovered that the problem goes away when incremental linking is disabled.
Somehow I missed the following error showed by Visual Studio when running a client that attaches to the DLL compile-time:
'TestClient.exe': Loaded 'D:\Projects\PchDllTest2\Debug\TestClient.exe', Symbols loaded.
'TestClient.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'TestClient.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'TestClient.exe': Loaded 'D:\Projects\PchDllTest2\Debug\TestDll.dll', Symbols loaded.
SXS: RtlCreateActivationContext() failed 0xc000000d
LDR: LdrpWalkImportDescriptor() failed to probe D:\Projects\PchDllTest2\Debug\TestDll.dll for its manifest, ntstatus 0xc000000d
Debugger:: An unhandled non-continuable exception was thrown during process load
The program '[5292] TestClient.exe: Native' has exited with code -1073741811 (0xc000000d).
As requested, the function declaration:
#ifdef __cplusplus
extern "C" {
#endif
MYTEST_API int MyTestFoo(int a);
#ifdef __cplusplus
}
#endif
There's one thing that is remarkable about this: When you create a new DLL using a wizard (New project -> Visual C++ -> Win32 -> Win32 Project), the wizard forces you to use precompiled headers when selecting DLL as application type. See answer from ta.speot.is.
I drastically changed the question, as it looked first like I thought that it was somehow documented that PCH is required for DLL projects. This is not the case, it's probably a weird kind of bug (let's hope it's not) or probably I'm doing something very stupid...
Why are precompiled headers required when building a DLL?
They're not.
In summary: Today I discovered that it's not possible to make a (functioning) DLL without building it with precompiled headers. Does anyone know what the reason is for this?
The reason for discovering this is that you misread something.
You can make binaries without precompiled headers just fine.
There's one thing that is remarkable about this: When you create a new DLL using a wizard (New project -> Visual C++ -> Win32 -> Win32 Project), the wizard forces you to use precompiled headers when selecting DLL as application type.
Perhaps in Visual C++ 6, but my experience with Visual Studio suggests otherwise. If you make an empty project with the wizard you do not get a precompiled header.
All that aside, I had a look on Google for "for its manifest, ntstatus 0xc000000d" and ultimately I wound up here. The last answer suggests that your CRT versions are mismatched, which would be very hard to do if you're letting Visual Studio create the projects for you and sticking with the defaults.
It might pay to check that you are linking to the same version of the CRT in your "host" application and library (e.g. both are multi-threaded debug).
The only other thing I can think of is that you're moving TestDll.dll into the Debug folder without its accompanying TestDll.dll.manifest file (if it has one).
I found out that the DLL has an embedded manifest resource containing only a little-endian UTF-16 byte order mark. The windows DLL loader crashes with the described error when it tries to load such a DLL.
I'm convinced that this just is a weird bug: If I build the DLL using Visual Studio or MSBuild, it results in an DLL with the bogus manifest resource. If I execute the commands reported by MSBuild manually on the command line, the DLL contains a valid manifest resource with a UTF-8 BOM.
As described building a DLL with PCH disabled results in a manifest resource containing only an UTF-16 LE BOM.
If a DLL is built with PCH enabled, the manifest resource contains a UTF-8 BOM followed by valid XML.
If a DLL is built with PCH disabled AND incremental linking disabled, the manifest resource contains only XML and no BOM at all.
Another option is to remove the faulty manifest resource using a resource editor after the build has been completed, than the error also disappears.
This is very reproducable, using wizard or if you create an empty project and do everything yourself.
With "precompiled" headers, you are effectively using code that was compiled earlier. If you introduced a bug later, "precompiling" will not compile the bug but use the older bugfree code.
I'm testing swig, and I found that SWIG's vcxproj file runs the mt.exe to generate the manifest file.
swig -c++ -csharp example.i
CL.exe ... -> compile the c++ source
link.exe ... -> generate dll
mt.exe ...
Csc.exe ...
What is this for? I skipped the mt.exe, but it seems to work fine.
It was a Very Big Deal in versions of VS prior to 2010. mt.exe embeds the auto-generated manifest in the executable image, important to get the DLL dependencies that are stored in the Windows side-by-side cache listed. Not much of a big deal anymore, it only embeds an "I'm compatible with Vista" manifest now. The side-by-side cache was rather a big headache and abandoned for VS2010.
You ought to check the .manifest file in the build directory and make sure nothing important is in it. Like the common dialogs version 6 entry that enables visual styles.
This has nothing to do with SWIG, but with how Visual C++ generates it's binary output.
The mt.exe tool does not generate a manifest file, it embeds the info from the manifest file that is already there (I think the linker would have created it) into the output DLL. Without this, the output DLL may only work while the manifest file resides along the DLL in the same directory.
(Note: I never really bothered to dig deeper regarding manifests, what info is exactly in there and if all the info in there is needed all the time, but since it's just all done automatically when you create an exe or dll in VC++ one shouldn't immediately need to bother unless something's not working :-)