I'm looking at incorporating Lua into a C++ project, and am a bit confused by the presence of the two binaries (lua51.dll and lua5.1.dll) in the distribution from Luabinaries.
According to the docs...
In Windows your library or application
must be linked with a stub library. A
stub library is a library with only
the function declarations that will
bind your DLL with the Lua DLL.
Why? I've never needed stub DLLs before when linking with third-party DLLs?
A stub library is a .lib file, not a DLL. It contains function declarations for all the exported functions in the DLL, which just forward the call into the DLL itself. So if you build an application that you want to link with lua51.dll, you tell the linker to link with lua51.lib, and all calls to exported functions will be forwarded to the DLL. If you didn't do this, you would get a lot of "unresolved external symbol" errors when linking.
This is only needed when statically linking with a DLL (so that it is loaded automatically when the application is run). It is not needed when loading the DLL dynamically with LoadLibrary.
Regarding why they have two different DLLs, The manual says this:
The LuaBinaries DLL packages have a dll proxy called "lua51.dll". It can be used to replace other "lua51.dll" released by other distributions. It will simply forward calls to the "lua5.1.dll". There is no compiled source code involved in the forwarding.
Basically, some existing applications link with lua5.1.dll while others link with lua51.dll and they want to support them both. In any case this is not related to the stub libraries.
I believe it's to do with __declspec(import) and __declspec(export) vs GetProcAddress. However, I don't actually know for sure.
Related
I have searched the web , but with different answers to my query. I am not an expert with Windows but I would like to understand it exactly.
When an application is compiled for Windows, which will involve the need for runtime-linking of libraries (DLLs), like using a core library kernel32.dll or some other user-created dll, does the application need to know that the dll exists before run-time.
I have read that a dll must be accompanied by a .lib file which must be linked in at compile time but somewhere it states that the .lib file is not required.
Does the application just execute and expect that it will find the functions needed in a dll and just fail if not found?
Thanks in advance.
List of dynamically linked functions is kept in import section of PECOFF executable file, as defined with the second directory item in optional header. Usual name of the section is .idata or IMPORT.
The only necessary information kept in the import directory is
name of the function
filename of the dynamic library (without path)
So the answer is negative, linker does not need to know anything about the DLL and it doesn't necessarily need to exist at link-time. It is the loader's job to find the refered DLL at run-time (and report error Entry point FunctionName was not found in the library eventually).
Import libraries .lib exist because of older compilers and linkers which lack the directive to declare imported function and its DLL, so they need the linked library which contains import definition and also indirect proxy jumps to IAT. But good linker doesn't need this, as this information can be created on the fly.
When one should implicitly or explicitly link to a DLL and what are common practices or pitfalls?
It is fairly rare to explicitly link a DLL. Mostly because it is painful and error prone. You need to write a function pointer declaration for the exported function and get the LoadLibrary + GetProcAddress + FreeLibrary code right. You'd do so only if you need a runtime dependency on a plug-in style DLL or want to select from a set of DLLs based on configuration. Or to deal with versioning, an API function that's only available on later versions of Windows for example. Explicit linking is the default for COM and .NET DLLs.
More background info in this MSDN Library article.
I'm assuming you refer to linking using a .lib vs loading a DLL dynamically using LoadLibrary().
Loading a DLL statically by linking to its .lib is generally safer. The linking stage checks that all the entry points exist in compile time and there is no chance you'll load a DLL that doesn't have the function you're expecting. It is also easier not to have to use GetProcAddress().
So generally you should use dynamic loading only when it is absolutely required.
I agree with other who answered you already (Hans Passant and shoosh). I want add only two things:
1) One common scenario when you have to use LoadLibrary and GetProcAddress is the following: you want use some new API existing in new versions of Windows only, but the API are not critical in your application. So you test with LoadLibrary and GetProcAddress whether the function which you need exist, and use it in the case. What your program do if the functions not exist depend total from your implementation.
2) There are one important options which you not included in your question: delayed loading of DLLs. In this case the operating system will load the DLL when one of its functions is called and not at the application start. It allows to use import libraries (.lib files) in some scenarios where explicitly linking should be used at the first look. Moreover it improve the startup time of the applications and are wide used by Windows itself. So the way is also recommended.
These days, I use Flex & Bison generated some codes to develop a SQL-parser alike tools, these code can't compiled silently(may be this another topic) in VS2005,but GCC/G++ works well, then I compiled these code with mingw in dll(in windows xp), and then linked these function facades in VS2005, but it seems can't link the dll during linking.
Does MS VS2005 recognize the dll which compiled using mingw on windows? Is there anything I need to do additional? For example, adding something in the include-file that declare the exported APIs?
Does any one can give some advices?
The condition is, as in VS2005, if you want to export some APIs, you may show a *.def file to tell nmake which API you want to export, and then you may create a(or some) *.h file to declare somthing about these APIs(adding some stdcall alike prefix as a call protocal) and some data-type definition. But with GCC/G++, you do not need to do such boring things, just use [ar], you can get these APIs, so my *.h file do not add call protocol and no *.def, just like common function declaration. After *.dll generated, add the *.h file and [mv] generated *.dll in VS2005 project directory, then set the linking *.dll in project setting. Does these steps generated my Question?
BTW, I found and tested VC6-compiled dll can be linked with mingw in Windows XP, but the reverse can't work.
Anyway, forgive my poor English, and thanks for your concern.
VS2005 does not recognize any DLL to compile anything, and I doubt mingw does.
When your application shall use a DLL, you need to tell VS2005 what functions are provided by the DLL.
Load Time Binding
The entry points are defined in the EXPORT directory of the DLL. The content of the EXPORT directory can be defined with the DEF file, while compiling the DLL. Theses exports can also defined using the #pragma __declspec(dllexport) directive. When you compile the DLL the linker will also generate a *.LIB file for the consuming application. This LIB is called import library.
The signatures of the exported functions must be provided by function prototypes, usually in a *.h file.
When you compile your application with load time binding, you include the *.h file in your source code and add the import library to the project settings. (not the *.DLL) When the O/S loads your application, the static code in the import library will load the DLL, read the EXPORT directory and fix all stubs to access the exported functions (and other symbols).
Dynamic Binding
You can omit the import library and load the DLL with your code using LoadLibrayy at the time that's appropriate. You need to define the pointers to the DLL entrypoints by yourself and must intialize theses pointers before calling GetProcAddress the actual functions.
I have an application that uses the winInet classes - #include <afxinet.h> and the wininet.dll
I would like to statically link the WinInet function calls in my application as well as the dll, so I followed these steps. I then copied the wininet.dll into my project directory, as I read here.
Upon building I get the following error - wininet.dll : fatal error LNK1136: invalid or corrupt file
My first question is:
-Am I correctly doing what I think is statically linking function calls and the dll?
-If so, why is the dll corrupt with this setup, but works without these changes?
Any help is appreciated. Thank You.
"Static Linking" is the process of including the code in your application. By nature, a DLL is a dynamic link library and therefore no, including the DLL in the directory of your application is not static linking - it remains dynamic. The reason for placing it in the directory of the application is so that the application can find it without the need for install.
I don't suppose it is the DLL that is "corrupt" - I suspect you are attempting to static link the DLL into the application which cannot happen. You need instead to include the correct .lib file, whatever that is, in the additional libraries to link with and ensure that the lib file you link with is not the DLL exports package for wininet.dll
You shouldn't link directly against the DLL. Instead, link against the corresponding import library (should be Wininet.lib). The DLL still needs to be accessible to your application at runtime, of course. The .lib file is needed by the linker to setup proper linkage to the DLL.
Am I correctly doing what I think is statically linking function calls and the dll?
What you're doing is usually called dynamic linkage (more or less dynamic ..), but its (afaik) the only way to go for Windows System APIs. 'Static' linkage would embed the Wininet code directly into your executable, with no need for an external DLL.
When you link with a DLL, there is a corresponding LIB file to use to set up the correct linkage to the functions. For an example, if you are using a USER32.DLL and KERNEL32.DLL, it's corresponding LIBs that needs to be linked would be USER32.LIB and KERNEL32.LIB.
Sometimes it is not so obvious, you can double check by looking at the MSDN for the function in question, when you scroll down towards the bottom of that page it will tell you what library to link with, for an example, look at the Win32API's CreateProcess, as you look at the bottom of the page, it tells you what is the library to use, in this case it's KERNEL32.LIB.
You just referenced a DLL during the linker phase which the linker could not understand the DLL as it is already a compiled library and hence the linker complained that it was "corrupt".
Change that to WinInet.LIB and all should be ok.
Hope this helps,
Best regards,
Tom.
I noticed the following about a library I use:
Library is compiled to .lib file.
My code needs to be compiled as Multi-threaded (Debug) DLL to link to this library.
I open the .sln (solution) file of the library (it is open source) and see the following in its Project properties:
Runtime Library option is set to Multi-threaded (Debug) DLL.
Configuration Type is set to Static Library (.lib)
My confusion is:
Isn't there a conflict in the library options above? (Static Library says one option, DLL says another)
What kind of an animal is a .lib that is dynamically linked? How is it different from a DLL?
Note that I am aware of the difference between static libraries and dynamic libraries in the Linux world.
The "RunTime Library" option isn't about YOUR library. It tells the compiler that you'll import your functions from MSVCRTxx.DLL at runtime.
The "configuration Type" option does refer to your library, and therefore is independent of the "RunTime Library" option.
A Windows DLL can be dynamically loaded with the LoadLibrary (or LoadLibraryEx) API, but then you have to find and bind each exported function to a function pointer using GetProcAddress or GetProcAddressEx. You'd better get the function signatures right, or Bad Things Will Happen, as usual.
A LIB file allows Windows to do all that for you when your EXE is started (including finding which DLL to use, and recursively loading dependent DLL's), linking the dynamic library statically at run time, while avoiding bloating your EXE file with the executable code, and allowing several processes to share the same DLL image in memory.
I don't know about the config mismatch, but a .LIB file when created with a .DLL library is an "export library" - it doesn't contain any code, but just the names of the callable functions and objects in the DLL. The linker uses this to satisfy references at link time which are finally resolved by dynamic loading at run-time.