MSVCR70.DLL vs. MSVCRT.DLL - multiple instances of C runtime library

[Claus Brod]

Hi all,

MSVCR70.DLL has been mentioned a couple of times before in this
newsgroup. VC.NET ships with this new version of the runtime library
while previous versions used MSVCRT.DLL. The usual recommendation seems
to be to link an application with the new libraries and ship them along
with the application.

I'm not sure, however, if this is sufficient in call cases. For
instance, Microsoft's NETAPI32.DLL or GLU32.DLL libraries are linked
against MSVCRT.DLL. If my app links against NETAPI32 or GLU32 *and* the
new MSCVR70.DLL, I will suddenly have two different C runtime libraries
attached to your process at runtime. To illustrate the dependency:

MYAPP.EXE
|
|----- NETAPI32.DLL
| |-- ...
| |-- MSVCRT.DLL
|
|----- GLU32.DLL
| |-- ...
| |-- MSVCRT.DLL
|
|----- MSVCR70.DLL

So when code in GLU32.DLL or NETAPI32.DLL calls malloc() or fopen() or
strdup() or whatever, they will call functions in MSVCRT.DLL, while
MYAPP calls code in MSCVR70.DLL. It also means that both MSVCRT.DLL and
MSVCR70.DLL maintain independent versions of data such as open handle
tables or memory free lists etc.

Let us now assume that one of the libraries which use MSVCRT.DLL returns
such a handle or memory pointer (or other kind of C-library resource) to
the caller in MYAPP.EXE, expecting it to free this
handle/memory/resource later using, say, fclose() or free(). This will
inevitably fail since MYAPP will call fclose()/free() in MSCVR70.DLL,
but that instance of the C runtime library doesn't have a clue about any
of the files or memory blocks allocated via MSVCRT.DLL.

I'm not sure whether this could actually happen while using system
libraries such as GLU32 or NETAPI32. However, any non-trivial
application links against lots of system DLLs which in turn use
MSVCRT.DLL, so the probability of a resource issue as described above is
certainly non-zero and maybe even quite high.

We recently ran into this situation in one of our applications, and
we're not sure what the recommended solution is. Obviously, we can't
just ship modified versions of all those system DLLs with our
application. On the other hand, we'd still like to upgrade to VC.NET and
use the new and improved C runtime libraries.

Any ideas or advice?

Thanks!

Claus

[Ron Ruble]

"Claus Brod" <claus_no_...@no.cocreate.spam.com> wrote in message
news:3DD389AD...@no.cocreate.spam.com...

> Hi all,
>
> MSVCR70.DLL has been mentioned a couple of times before in this
> newsgroup. VC.NET ships with this new version of the runtime library
> while previous versions used MSVCRT.DLL. The usual recommendation
seems
> to be to link an application with the new libraries and ship them
along
> with the application.
>
> I'm not sure, however, if this is sufficient in call cases. For
> instance, Microsoft's NETAPI32.DLL or GLU32.DLL libraries are linked
> against MSVCRT.DLL. If my app links against NETAPI32 or GLU32 *and*
the
> new MSCVR70.DLL, I will suddenly have two different C runtime
libraries
> attached to your process at runtime.

<snip>

> So when code in GLU32.DLL or NETAPI32.DLL calls malloc() or fopen() or
> strdup() or whatever, they will call functions in MSVCRT.DLL, while
> MYAPP calls code in MSCVR70.DLL. It also means that both MSVCRT.DLL
and
> MSVCR70.DLL maintain independent versions of data such as open handle
> tables or memory free lists etc.
>
> Let us now assume that one of the libraries which use MSVCRT.DLL
returns
> such a handle or memory pointer (or other kind of C-library resource)
to
> the caller in MYAPP.EXE, expecting it to free this
> handle/memory/resource later using, say, fclose() or free(). This will
> inevitably fail since MYAPP will call fclose()/free() in MSCVR70.DLL,
> but that instance of the C runtime library doesn't have a clue about
any
> of the files or memory blocks allocated via MSVCRT.DLL.
>
> I'm not sure whether this could actually happen while using system
> libraries such as GLU32 or NETAPI32.

I do not represent MS; however...

This is never a problem using the system DLLs.
They never return C runtime library objects.

However, I would also welcome any additional
input from members of the VC team.

You are correct that it could be a problem using
third-party libaries, but only if they return C runtime
objects (which is not typical).

In general, if the DLL can be used directly by
a Visual Basic Classic compiler (4, 5 or 6),
you are safe.

> However, any non-trivial
> application links against lots of system DLLs which in turn use
> MSVCRT.DLL, so the probability of a resource issue as described above
is
> certainly non-zero and maybe even quite high.

If the DLLs are intended primarily for use
by VC (not C, VC _specifically; the same
issues would be a problem muxing Borland
or CygWin), it is definitely a possibility.

> We recently ran into this situation in one of our applications, and
> we're not sure what the recommended solution is. Obviously, we can't
> just ship modified versions of all those system DLLs with our
> application.

As above, for system DLLs, this is not a problem;
no action is required.

[Carl Daniel [MVP]]

"Claus Brod" <claus_no_...@no.cocreate.spam.com> wrote in message
news:3DD389AD...@no.cocreate.spam.com...

> Hi all,
>
> MSVCR70.DLL has been mentioned a couple of times before in this
> newsgroup. VC.NET ships with this new version of the runtime library
> while previous versions used MSVCRT.DLL. The usual recommendation seems
> to be to link an application with the new libraries and ship them along
> with the application.
>
> I'm not sure, however, if this is sufficient in call cases. For
> instance, Microsoft's NETAPI32.DLL or GLU32.DLL libraries are linked
> against MSVCRT.DLL. If my app links against NETAPI32 or GLU32 *and* the
> new MSCVR70.DLL, I will suddenly have two different C runtime libraries
> attached to your process at runtime. To illustrate the dependency:

<snip>

As Ron said, this is never a problem with the system DLLs since they never
return C runtime library resources. If they did, it would be impossible for
any program compiled with anything other than VC++ to use them, and that's
clearly not the case.

If all of your DLLs are either from the system or are your own, then you're
in complete control, so there shouldn't be any problems that you can't deal
with directly.

If you're using any 3rd party DLLs, there may be problems, especially if the
DLL is designed as a "VC++" component (e.g. supports only VC++, uses a
different version for Borland, etc). Such DLLs need to be scrutinized very
closely to determine if they're going to be problematic. My guess is that
such problematic DLLs exist and that people are using them in real-world
projects, but I don't know of any specific DLLs that fall into this
category.

So, my advice: for system DLLs, don't worry about it. For 3rd party DLLs,
examine the DLL interface carefully and determine if any C rtl objects are
returned to the caller for eventual disposal. Note that Win32 handles
(HANDLE) are NOT RTL objects and are safe to return. If a DLL you're using
does return any RTL objects, then you'll need to contact the author of that
DLL to get a VC7 version. If you run into such a situation, encourage the
author to fix his/her DLL to have a compiler-neutral interface so this
doesn't happen again.

-cd

PS: C-RTL "objects"
- FILE* (e.g. from fopen)
- file handles (e.g. from open() not from CreateFile)
- Memory to be freed by delete, delete[] or free() (memory to be freed by
GlobalFree, CoTaskMemFree, etc. is OK).

[Jan Bares]

BTW, you will have the same problem when you will use debug version of
MSVCRTD.DLL or MSVCR70D.DLL. You should not free memory pointers in
different module (EXE/DLL) from where they were allocated.. You should not
pass FILE handles to different modules.
Frankly speaking, you can. But you will have carefully watch if the modules
use the same instance of the CRT.

Regards, Jan

"Claus Brod" <claus_no_...@no.cocreate.spam.com> wrote in message
news:3DD389AD...@no.cocreate.spam.com...