I was reading in MSDN ( here ) about the different CRT libraries in Windows.
According to it, msvcrt.lib is a:
Static library for the native CRT startup for use with DLL UCRT and vcruntime.
while ucrt.lib is a:
DLL import library for the UCRT.
This is why ucrt.lib have an associated vcrtbase.dll dll, but for my understanding of the reference there is no associated dll for msvcrt. Yet, I can see there is a msvcrt.dll out there, and that its loaded into applications.
So my question is simple, why a static library needs a dll? maybe its because msvcrt.dll is actually the same as msvcrt.lib but in a dynamic form? If so, why ucrtbase.dll is needed? (maybe performance over the outdated msvcrt?)
Thanks for any insight that dissolve this mist.
Related
Does anyone know where I can find a Firebreath sample (either Mac OS X or Windows) that illustrates how to create a plugin that includes 1 or more other libraries (.DLLs or .SOs) that each rely on other sub-projects built as static libraries (LIBs)?
For example, let's say that the Firebreath plugin is called PluginA, and that PluginA calls methods from DLL_B and DLL_C. DLL_B and DLL_C are C++ projects. DLL_B calls methods from another project called LIB_D, and DLL_C calls methods from a project called DLL_E.
Therefore, the final package should contain the following files:
PluginA.dll
DLL_B.dll (which also incorporates LIB_D)
DLL_C.dll
DLL_E.dll
I am currently forced to dump all source files in the pluginA solution, but this is just a bottleneck (for example I cannot call libraries written in other languages, such as Objective-C on Mac OS X).
I tried following the samples on Firebreath, but couldn't get them to work, and I found no samples from other users that claimed they were able to get it to work. I tried using CMAKE, and also running the solutions directly from X-Code, but the end result was the same (received linking errors, after deployment DLL_C couldn't find DLL_E etc.)
Any help would be appreciated - thank you,
Mihnea
You're way overthinking this.
On windows:
DLLs don't depend on a static library because if they did it would have been compiled in when they were built.
DLLs that depend on another DLL generally just need that other DLL to be present in the same location or otherwise in the DLL search path.
Those two things taken into consideration, all you need to do is locate the .lib file that either is the static library or goes with the .dll and add a target_link_library call for each one. There is a page on firebreath.org that explains how to do this.
On linux it's about the same but using the normal rules for finding .so files.
I'm trying to create an D application which uses a (third party) COM .dll so I can scrape a text box of another application so I can sound an error when a certain string shows up.
However the third party doesn't provide .lib, .def or .h files that go with the dll (atleast with the free trial version). I can create the .lib file with the implib tool but I don't see any of the library's functions in the created .lib.
Their (visual c++) samples use the #import directive to link it in however that is of no use for me ...
On a side note how can I get the proper interfaces (in a .di with boilerplate that does the linking) of the dll automatically? I ask so the correctness of the linkage doesn't depend on my (likely to be incorrect) translation of the functions. They do have a webpage which gives all functions but the object model is a bit chaotic to say the least.
From what I know, COM libraries only expose a few functions, required to (un)register the library and to create objects.
You can however view the interfaces and functions in a COM .dll using the OLE/COM Object Viewer. It seems it might be able to output header files (.h). Afterwards, maybe you could use htod as a starting point to converting everything to D interfaces.
The DMD distribution seems to include a .COM sample (chello.d, dclient.d, dserver.d), and at first glance it doesn't look like it would require any LIBs explicitly.
Unfortunately, I've never actually used COM in D, so I can't advise any further. I hope this helps in some way.
While I have yet to actually do COM work myself, I am trying to revive Juno over on Github/he-the-great. Part of the project is tlbimpd which is what will output a D file from a DLL.
I've tested the examples and successfully run tlbimpd. Please do try things out for your use and submit any issues.
What is the meaning of building a dll as export library ? I just googled it.I found its a dynamic link library.Can anyone please explain what actually dll is ? and why do we need to add these statement in the .dll file
extern "c" _declspec(dllexport)
I studied the static and shared libraries but Im not sure why do we go for dll files.I learnt .dll is used for the run time. But can you help me and give me more information.Thank you in advance
I may have been a bit harsh in my comments. I am not an authority on dlls, but I have a bit of working knowledge of them, so I will try to give a short explanation.
The difference between static and shared libraries should be easy to find in a web search, but basically the code in a static library gets included into the final executable, so after the linking stage, the actual library file is not needed anymore to run the program; on the other hand, code in a shared library doesn't get included in the main program - the two parts remain separate, so the shared library (called dll on windows) will be needed every time the program is run.
"Building a dll as export library" is a bit of a confusing term. I had not heard of it before, and during a short search could only find it on a cygwin page, which you might have read, considering your initial tags. A dll can export some or all of its functions and data. Exporting means that they are available for other programs and dlls to use. Which names get exported can be controlled in various ways. One of those is inserting _declspec(dllexport) in the declaration of the function. Another way is by using a definition file with an exports section.
When creating a dll, an import library can be created. This is a file that can then be used when building an executable that uses the dll, during the linking stage, to let it know which names are exported from the dll, so the program knows how to resolve references to those functions; in other words: how to import them. (This is not always necessary. Many linkers allow you to directly link against the dll itself, thereby removing the need for an import library.)
I realize it can be confusing, but try to find a tutorial and some small examples to see how it works, and play with it a bit.
I am in the midst of evaluating the benefits of changing our program from 30+ statically linked libraries to 30+ dynamically linked libraries. We hope by changing to DLL, it will reduce the link time.
One immediate problem is the requirement to add __declspec in front of all the classes to create the lib file for other dlls to link. Is there a way to get around that? Is there a flag in the compiler to force a lib generation so to make all classes inside the DLL available for export? If not, is there any existing script/program that will do that? That will certainly make the switch from statically linked library to a dynamic one a lot easier. If not, what is the rationale behind __declspec? Why not an option to make all dll functions exportable?
Thank you.
Perhaps it's too late, but have you looked into using a DEF file?
There is one another way to solve your problem.
You just need to create one definition file(.def) and export all the methods or class you want to share.
U will also have to set :
Properties->Linker->Input->Module Definition File -> add name of your created .def file.
Now use run time dynamic linking:
In project where you want to call the exported methods use LoadLibrary to get handle of your Dll and call the required method using GetProcAddress.
I get the following exception when showing a form:
InvalidOperationException was unhandled
Mixed mode assembly is build against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
alt text http://img69.imageshack.us/img69/2599/captureya.png
Dont really know why this isnt working. Any help?
I haven't seen the code for LoginForm. But I think you need to set an app.config flag to fall back to .NET 2.0 era bindings...
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
First, what's a mixed mode assembly? A
mixed mode assembly is an assembly
that contains both managed (CIL) and
unmanaged (machine language) code.
Consequently, they are not portable to
other CPU instruction sets, just like
normal C and C++ programs and
libraries.
Next, why use them? The primary
purpose for mixed mode assemblies is
as "glue", to e.g. use a C++ library
class as a base class of a managed
class. This allows the managed class
to extend unmanaged methods, allowing
the managed code to be polymorphic
with respect to existing unmanaged
functions. This is extremely useful in
many contexts. However, as something
like this involves extending a C++
class, it requires that the compiler
know all about the C++ compiler ABI
(name mangling, virtual function table
generation and placement, exception
behavior), and thus effectively
requires native code. If the base
class is within a separate .dll, this
will also require that the mixed mode
assembly list the native .dll as a
dependency, so that the native library
is also loaded when the assembly is
loaded.
The other thing that mixed mode
assemblies support is the ability to
export new C functions so that other
programs can LoadLibrary() the
assembly and GetProcAddress the
exported C function.
Both of these capabilities require
that the shared library loader for the
platform support Portable Executable
(PE) files, as assemblies are PE
files. If the shared library loader
supports PE files, then the loader can
ensure that when the assembly is
loaded, all listed dependent libraries
are also loaded (case 1), or that
native apps will be able to load the
assembly as if it were a native DLL
and resolve DLL entry points against
it.
Source
I had this issue, tried the answer above and it did not work.
After much reading and trial and error and not finding anything that worked I noticed that I had both imported the Mysql dlls and added them in properties. After I removed the import statements it worked.
I know it was removing the import statements because I tested between every change I tried.
Hope that helps somebody.