msvcp90d.dll and msvcr90d.dll
George
I find when a C++ console process loads, the DLLs msvcp90d.dll and
msvcr90d.dll are always loaded. My question I want to find the different
functions of the DLLs and why CRT runtime provides two DLLs other than one.
I have not find any formal information from search. I just did some self
analysis and find msvcp90d.dll exports C++ functions and msvcr90d.dll exports
C functions. I am not 100% sure. Any ideas?
thanks in advance,
George
Igor Tandetnik
news:8C0F278B-6C83-4D30...@microsoft.com
> I find when a C++ console process loads, the DLLs msvcp90d.dll and
> msvcr90d.dll are always loaded. My question I want to find the
> different functions of the DLLs and why CRT runtime provides two DLLs
> other than one.
One is C runtime, the other is C++ runtime. C runtime contains
implementations of standard functions (e.g. malloc or printf) that are
common for C and C++. C++ runtime contains code specific to C++, e.g.
support for new and delete, RTTI and so on.
--
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
David Webber
> I find when a C++ console process loads, the DLLs msvcp90d.dll and
> msvcr90d.dll are always loaded. My question I want to find the different
> functions of the DLLs and why CRT runtime provides two DLLs other than
> one.
msvcp90d.dll is the debug version of the C++ runtime libary (not used by
programs in C).
msvcr90d.dll is the debug version of the C runtime library (which is also
used by C+).
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
George
In my previous understanding, STL is built with source code directly into
our program, as you can see when installed with VC, the source code for STL
is avaliable. So, I am confused why we need an DLL named msvcp90d.dll for
STL. Please feel free to correct me if I am wrong. :-)
regards,
George
George
I find STL function also included in msvcp90d.dll from dumpbin /exports. In
my previous understanding, STL is built with source code directly into our
program, as you can see when installed with VC, the source code for STL is
avaliable. So, I am confused why we need an DLL for STL. Please feel free to
David Webber
The STL is a *template* library, and so, yes, a lot of it is built in just
by including the appropriate headers.
But as Igor indicated explicitly assorted elements of the C++ runtime
support are in msvcp90.dll (and ...d.dll for the debug version). It
isn't always necessary to use the DLL, but I supply msvcp90.dll with my
program. I forget what necessitated it, but I do use something in there.
(I vaguely remember that either the vector [] operator, or the vector "at()"
function needs it, but I may be wrong.)
George
I think you mean a small part of STL is in msvcp90d.dll, a large part is
built into of application by using the source code directly, correct?
But I am confused, because I have just used dumpbin /exports to check export
functions from msvcp90d.dll, seems almost 1000 exported functions, almost all
STL functions exported. Any comments?
regards,
George
David Webber
> I think you mean a small part of STL is in msvcp90d.dll, a large part is
> built into of application by using the source code directly, correct?
Well I'll step back from words like "large" and "small"...
> But I am confused, because I have just used dumpbin /exports to check
> export
> functions from msvcp90d.dll, seems almost 1000 exported functions, almost
> all
> STL functions exported. Any comments?
But you can check for yourself. Open the header file "vector" and look at
the source code. It looks to me as if almost all the member functions are
coded right there in the header file. In which case you'll get them by
including the header. Of all the STL classes, vector is the one I use most,
and so most of the code I use is in the headers :-) Other STL classes may
be more reliant on the contents of the DLL, I'd have to check, but you can
do that yourself too by looking at the headers and seeing which functions
are defined there. [It never occurred to me to care too much.] I do
remember getting away without the DLL for quite a while, but then I did
something which needed it - but that was a few versions of VC++ ago.
Igor Tandetnik
You don't _need_ the DLL. You have an option to use it (or not).
Standrad C++ library consists mostly, but not entirely, of templates.
Indeed, you can't put templates into a DLL. However, you can put
non-template classes and functions, as well as specific template
instantiations, into a DLL.
For example, you cannot put std::basic_string into a DLL, it being a
template. However, most people only use two specializations of this
template - basic_string<char> (also known as std::string) and
basic_string<wchar_t> (also know as std::wstring). And indeed
msvcp90d.dll contains code for these two specializations. So if you use
basic_string<char>, you link to the code from the DLL. If you use
basic_string<SomeCustomCharType> (highly unlikely), the compiler will
generate code for this instantiation from the template source, and make
it part of your executable.
Similar situation occurs with I/O streams and locale facets: while
technically templates, for most of them only two specializations are
ever used, one for char and one for wchar_t.
As an example of non-template classes and functions that are part of
STL, see std::terminate, std::ios_base.
George
I would happy to follow your comments to find which functions from the
msvcp90d.dll is needed by vector header file.
All I could think of is export functions of msvcp90d.dll, and to see if any
of them are invoked by anything inside vector file. But the export names in
msvcp90d.dll is not quite friendly...
Do you have any better or smart ideas to check the dependencies?
regards,
George
George
1.
Why we can not put template into a DLL? The root cause is?
2.
I think using template is faster than using binary code in DLL, since
template code is built into source code directly, and to use code in DLL we
need an additional level of indirection through import address table. Any
benefits of putting commonly used code into DLL?
regards,
George
Igor Tandetnik
> Why we can not put template into a DLL? The root cause is?
... the same one that we have already discussed many times before.
> I think using template is faster than using binary code in DLL, since
> template code is built into source code directly, and to use code in
> DLL we need an additional level of indirection through import address
> table. Any benefits of putting commonly used code into DLL?
You have a choice to link to C++ standard library statically, just as
you have a choice to link to CRT statically (in fact, both are
controlled by the same compiler options, you can't mix and match).
If you have a large application comprised of many modules (EXEs and
DLLs), then using CRT DLL may reduce the total size, since common code
is present in only one place. If every module links to CRT statically,
each one will contain its own copy of the CRT code it uses. The same
holds for C++ standard library code.
George
1.
> .... the same one that we have already discussed many times before.
I understand in C++ template expansion is happening at compile time. But I
did not remember we discussed why template could not be in DLL. Does it
before DLL needs compile, and during compile process all templates are
expanded/instantiated?
2.
Sorry that I did not remember we discussed the same issue before after some
search here. If you think anywhere we discussed before, could you provide a
link please? :-)
regards,
George
Ben Voigt [C++ MVP]
> Thanks Igor,
>
>
> 1.
>
>> .... the same one that we have already discussed many times before.
>
> I understand in C++ template expansion is happening at compile time.
> But I did not remember we discussed why template could not be in DLL.
> Does it before DLL needs compile, and during compile process all
> templates are expanded/instantiated?
It's a limitation of the Microsoft C++ compiler (and most other compilers)
that all users of a template need to see source code for the complete
template definition. This is actually a violation of the C++ standard (lack
of support for the export keyword).
George
> It's a limitation of the Microsoft C++ compiler (and most other compilers)
> that all users of a template need to see source code for the complete
> template definition. This is actually a violation of the C++ standard (lack
> of support for the export keyword).
It is very convenient to see the template code, for example, when debugging
we can see/debug source code into files like string/vector. Why do you think
such behavior is a violation of C++? Or I wrongly understand your points?
regards,
George
Tim Roberts
>
>I would happy to follow your comments to find which functions from the
>msvcp90d.dll is needed by vector header file.
>
>All I could think of is export functions of msvcp90d.dll, and to see if any
>of them are invoked by anything inside vector file. But the export names in
>msvcp90d.dll is not quite friendly...
No, but they are predictable. That is, you can look at the names and
figure out to which class they belong.
Also, you can answer this specific question this way:
link /dump /exports msvcp80.dll | findstr vector
There are none. Neither are there any references to list or map. There
are, however, lots of references to basic_string, istream, and ostream.
>Do you have any better or smart ideas to check the dependencies?
Again I need to ask, why do you care? This information will not help you
become a better programmer. You really need to learn to identify the point
at which a thread stops being useful.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
George
I just want to understanding the basics. I think whether STL in VC is
provided in source form or in binary form is some basics and I want to
understand. In my previous understanding, I think all of STL is delivered in
source code format. But from debugging, I do find msvcp90d.dll is loaded by a
console application. So, this is why I asked this question.
Do you have any ideas what parts of STL are in source form and what are in
DLL form?
regards,
George
George
I think your command -- "link /dump /exports msvcp80.dll" has no advantage
over command dumpbin. Any comments?
regards,
George
Bo Persson
Everything is in the source. The DLL just contains pre-instantiated
templates created from the headers.
If you have an edition above Express, there is an instances.cpp file
that is used to create this. It just includes a bunch of headers, and
then goes on to explicitly instantiate selected operators for string,
I/O streams, and complex.
That's it!
Bo Persson
George
1.
A little confuse. Just want to clarify -- your point is for frequently used
classes, like string, it is actually provided in the DLL, and we can see the
source does not prove STL functions are built in source into our application?
2.
The reason why template class can not be in DLL is because template class
itself is expanded (disappear) to concrete class by type parameters during
compile/link, and DLL is generated by compile/link process, so template class
can not be in a DLL?
regards,
George
Ben Voigt [C++ MVP]
"George" <Geo...@discussions.microsoft.com> wrote in message
news:EF77EA9E-B4AE-4008...@microsoft.com...
The C++ standard allows you to give the source code to callers, but also
allows you to choose not to give the source code, by using the export
keyword. The Microsoft C++ compilers don't give you the second option,
there is no choice.
>
>
> regards,
> George
Tim Roberts
>
>I think your command -- "link /dump /exports msvcp80.dll" has no advantage
>over command dumpbin. Any comments?
"dumpbin" is a very thin shell command that does nothing except pass its
parameters to "link /dump".
The same is true of "editbin" (which is "link /edit") and "lib" (which is
"link /lib"). In each case, the real operation is handled by "link.exe".
So, why do I type "link /dump" when "dumpbin" does the same thing and is
three characters shorter? I don't know -- personality flaw, I guess. I
also type "erase" instead of the shorter "del". It doesn't make sense, but
that's what my fingers do.
Tim Roberts
This is true. The following is not a "real function". It does not have a
body, and will never have a body, so it will never be seen in object code
of any kind:
template< typename T >
T doubleme( T x )
{
return x+x;
}
This, however, CAN have a body:
template<>
int doubleme( int x )
{
return x+x;
}
Same concept.
George
I understand your point now. My further question is do you think STL is
provided in source form which built into client application code directly or
through DLL in binary form (e.g. msvcp90d.dll)?
regards,
George
George
George
Your reply is prefect! Cool!
One more question, the reason why put commonly used template parameter
instantiation into DLL is to save the size of client application?
regards,
George
George
Perfect reply!
regards,
George
Ben Voigt [C++ MVP]
STL is provided in source form. It would be possible for a couple very
particular template instantiations to be stored in a DLL and imported in
binary form, but since Microsoft C++ doesn't support "export" it's not
possible to share C++ templates in binary form. With the Microsoft C++
compiler, you can't use a template unless you have source code for it.
>
>
> regards,
> George
George
> STL is provided in source form. It would be possible for a couple very
> particular template instantiations to be stored in a DLL and imported in
> binary form, but since Microsoft C++ doesn't support "export" it's not
> possible to share C++ templates in binary form. With the Microsoft C++
> compiler, you can't use a template unless you have source code for it.
I think the root reason why STL can not be provided in DLL is because,
- template is compiled and linked;
- during compiling, template is expanded with specific type parameter, and
there is no pure template there.
I am confused about why you say using export could we export source code in
DLL, could we export source code in DLL? I doubt. DLL is binary, and source
code is not.
regards,
George
Ben Voigt [C++ MVP]
I didn't say that.
Export (which Microsoft C++ compiler cannot do) makes a binary version of
the unspecialized template. Then you could use the template by having this
binary version. This binary version probably would not be a DLL, it would
be closer to a static library (which also contains no source code).
Since Microsoft C++ compiler doesn't support "export", you can only use a
template if you have the source code.
>
>
> regards,
> George
George
regards,
George
Tim Roberts
>
>Your reply is prefect! Cool!
>
>One more question, the reason why put commonly used template parameter
>instantiation into DLL is to save the size of client application?
Yes. The generic template doesn't generate any code in an application that
doesn't use it. However, specializations DO generate code.