I'm new to Windows concepts. I'm trying to develop a DLL that also dynamically links against other DLL's. I'm using Visual Studio 2010. At linking time Visual studio tells me it's trying to link against a bunch of .lib files. I don't think Visual Studio should attempt to read any .LIB files if I want my code to perform dynamic linking is that correct? Or do I not understand the use of .LIB files enough?
thank you
How I understand, you are a little confused, because you want to use DLLs instead of LIBs.
The trick is that Kernel32.Lib, User32.Lib, AdvAPI32.Lib and so on has no implementation of the function which you use. Moreover if you use functions like CreateFileW or MessageBoxW in your program the references to the function will be unresolved after the compilation. So without having LIBs the unresolved references will stay also in the EXE. That will be bad of cause. To be executable the EXE must have resolved all external references and moreover know exactly which functions should be found in which DLLs. So named import library help to solve the problem. The import library Kernel32.Lib for example has information about CreateFileW function and User32.Lib has information about MessageBoxW. If you use a list of import libraries like Kernel32.Lib, User32.Lib, AdvAPI32.Lib your EXE resolves all referenced and includes the exact list of DLLs which it need and the list of functions used in the corresponding DLL in a special Import table (see http://en.wikipedia.org/wiki/Portable_Executable#Import_Table, http://msdn.microsoft.com/en-us/library/ms809762.aspx and http://www.microsoft.com/whdc/system/platform/firmware/pecoff.mspx). So If one starts your EXE the operation system loads the DLL in the address space of the process and resolves till the end all references up to the addresses of all functions used.
Typically import libraries will be created by linker (link.exe) when one compile a DLL. It is also possible to create an import library which corresponds to the DLL with respect of lib.exe utility. (see http://msdn.microsoft.com/en-us/library/0b9xe492.aspx)
As I recall, Visual Studio's compiler resolves .DLL files by linking against stub .LIB files.
Check, one of them should be kernel32.lib.
Related
I'm new to the world of .NET and I'm trying to understand the build process. If the concept of DLLs is to resolve references at run time why does visual studio need to to know about DLLs at compile time in order to build an executable ? Can't seem to find a definitive answer anywhere.
DLLs are loaded at runtime so your code can call code in that DLL, indeed. However, they are also needed at compile time so you can write code calling into that library.
Back in C++ I think that was done with .lib files or via COM, so the compiler didn't actually need the DLL. In .NET that's different because the DLL contains the code to run and the interface so other programs can use it.
I have a third-party static lib, libTA.lib. It was built with /MT and I can't change that. I want to link libTA into a DLL I'm building, mydll.{lib,dll}. Of course my dll should be built with /MD; my dll will be used with /MD-built exes (also not under my control). Linking mydll with libTA.lib fails (correctly, I'd say) due to LNK2038, mismatch detected for RuntimeLibrary.
So, what can I do about this? Building mydll with /MT seems like a terrible idea because I don't want to have multiple msvc runtimes.
So my question is, what are my options? Anyone been through this before and found a solution?
Keep all the projects in your solution to /MD so that they will linked dynamically with external DLL libraries. The static libraries could be included in the additional dependencies or through #pragma include () directives. Note the DLL files should have their symbols exported through a .def file (use lib.exe to convert to lib file) or .lib file. However the toolset, target platform settings of all the dynamic and static libraries should be same to avoid linker error.
I have a somewhat odd problem that I don't seem to be able to get to the bottom of. We have a mostly unmanaged C++ application that's been around for a while and thus has been built using lots of different versions of Visual Studio, with it being updated to the current version of Visual Studio on a regular basis.
I've now run into the following issue:
In VS2010 I've added two new projects to the existing solution. Both new projects are DLLs, one built in plain unmanaged C++, the built using a mix of C++ and C++/CLI and is thus built with CLR support (/clr). The second C++/CLI DLL should be used by several other components of the system
Using Properties -> Common Properties -> Framework and References, I add the two new DLLs as a dependency to a third DLL. The third DLL is doesn't know anything about .NET and is implemented in pure native, unmanaged C++. The new DLLs show up correctly in the dependency settings and the new references work in the sense that the build order of the solution is affected (correct), but for some reason, only the import library for the plain native C++ DLL is added to the linker command line for DLL that references both libraries. The second, mixed library generates an import library, but VS2010 doesn't add the import library to the linker command line which predictably results in several unresolved external symbols.
The one setting that appears to trigger this behaviour is building the DLL with Common Language runtime support as all the other settings of the libraries are identical.
I currently have a workaround for this issue - I simply add the import library as a manual dependency - but I was wondering if someone else has encountered this problem and if there is a way to get make this feature work as expected without the workaround?
When you choose /MTd static linking in Visual Studio, would it try to link to each lib statically or there are some exceptions to system libs?
Description: /MTd: Defines _DEBUG and _MT. This option also causes the compiler to place the library name LIBCMTD.lib into the .obj file so that the linker will use LIBCMTD.lib to resolve external symbols.
From what I can see there is no static linking. If you want to do static linking you need to use ILMerge. And even then you should not attempt to merge in the required .Net Framework references as they often reference others which you may miss. It may not even be possible as they use GAC for referencing.
The /MT and /MD flags only define how the C/C++ runtime library is linked in. It has no effect on other libraries, system or user defined.
The system libraries, such as kernel32.lib, user32.lib, etc) are import libraries - there is no static library to link with.
I have a makefile project that builds and links a DLL, using the command-line cl.exe compiler, which is included in the VC++ Express (free) tool. I now want to convert that makefile project into a Visual Studio project.
The DLL is not actually C++; it's all written in C.
The DLL exports a small number of symbols, functions that are called by other programs that link to the DLL. I believe that in order to produce this DLL, I need to include an /EXPORT:Foo statement on the link command line, for each exported symbol.
How do I do the same in Visual Studio 2008? How do I specify the linker options to export a specific, small set of functions from the DLL?
See the first couple of subsections of Exporting from a DLL, which says,
You can export functions from a DLL
using two methods:
Create a module definition (.def) file
and use the .def file when building
the DLL. Use this approach if you want
to export functions from your DLL by
ordinal rather than by name.
Use the keyword __declspec(dllexport)
in the function's definition.
You will have to use the "Additional Options" in the linker "Command Line" property and add the options explicitly.
I think that most people use the __declspec(dllexport) attributes along with macros to make it more usable and to make the declspec a dllimport version in the headers for clients of the library.
or you can try:
cl /LD hellodll.cpp /link /EXPORT:func01 /EXPORT:func01
for functions that is not specified by "_declspec(dllexport)"
I don't see a GUI option for it, so you could just add it manually under Command Line under Linker in the project's Properties. I think most people use a DEF file for this, though.