Re: msvc*.dll loading
"Mario Semo" <mario_semo@Xhotmail.com> wrote in message
news:u3YWQCicIHA.1376@TK2MSFTNGP02.phx.gbl
Can someone explain or point to to a documentation about the
msvc*.dll's in Visual Studio 2008 Express?
http://msdn2.microsoft.com/en-us/library/abx4dbyh.aspx
a) what are the dlls for (which of the dlls is for what functionality
- except for 'd' at the end which is obviously)
b) what and how to install on customers PCs (non developer machines)?
http://msdn2.microsoft.com/en-us/library/ms235299.aspx
c) what to do to make the non debug versions available for me as a
developer?
Aren't they already? Just build Release configuration.
when i try my dllfind against msvcp90d.dll it is found in this WinSxS
directory. But how???
Inspect your application's resources. There's a manifest file embedded
as a resource. It tells which versions of which DLLs your application
depends on, and the loader then looks for them in side-by-side folders.
(Thats the reason for my 3rd question : what to do to make the non
debug version available for developers).
i have done some more testing on this:
i compile dllfind.cpp without an /MDx option -> i cannot LoadLibrary
msvcm90.dll, but msvcm90d.dll
i compile dllfind.cpp with /MD -> i can load MSvcm90.dll, but not
msvcm90d.dll
i compile dllfind.cpp with /MDd -> i can load MSvcm90d.dll, but not
msvc90.dll
You can successfully load whichever DLLs are mentioned in the manifest.
The manifest is automatically generated based on various project
settings:
http://msdn2.microsoft.com/en-us/library/ms235229(VS.80).aspx
You can turn off automatic manifest generation, then hand-craft and
embed one manually. It could then list all flavors of CRT DLLs.
It's not clear why you would want to do that though. Why would you want
to load CRT DLLs with LoadLibrary? Your application is linked to them
already anyway, LoadLibrary doesn't do anything.
Now i tried another scenario :
compile a dll with /MDd and compile a main which dynamically links to
dll.dll with /MD.
start main.
nothing happens. it just terminates.
What do you mean, just terminates? If you run it under debugger, does it
enter main() or WinMain() at all? If so, at what point exactly does it
stop working?
this means, that it is not more possible to develop the main
application which loads plugins and the plugins with different
compile options???
I develop Internet Explorer plugins just fine. I compile both debug and
release, and they work either way, hosted by the same copy of
iexplore.exe (built as Release, I presume).
(This i one of my scenarios : i have a lot of dlls which should work
together and exchange Data (new, delete in different DLLs)
Now that's a different story altogether. If you want to allocate CRT
resources in one module and deallocate them in another, both modules
_must_ use the same flavor of CRT DLL. That is, both linked with /MD or
both with /MDd. Otherwise you have two distinct copies of memory manager
loaded in your process. One memory manager has no idea what to do when
handed a pointer allocated by the other. At best, your application will
crash right away. At worst, it will corrupt internal data structures,
then crash much later, in seemingly unrelated piece of code. That one is
fun to debug.
Define your interfaces so that they don't require transferring ownership
between modules. E.g., for every exported function that allocates
memory, provide a function (in the same DLL) that the client should use
to free this memory. Or, make it a responsibility of the caller to
allocate sufficiently large buffer and pass it to the DLL to fill in.
Or, use OS APIs to allocate memory (e.g. COM mandates using
CoTaskMemAlloc, SysAllocString et al).
i even cannot use LoadLibrary to load a dll which is compiled with
/MDd or /MD when my main.exe is compiled without /MDx options.
(see sample dllf.cmd).
You can - just give full path to the DLL. You are trying to load by
relative path, and thus relying on the manifest to locate the DLL file.
Note : i tried to compile dllfind.exe with another compiler -> cannot
load the msvc* dlls anymore.
That other compiler didn't generate the manifest.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925