From: TheOne on
I compiled a project in debug and release mode, and checked what dll's
are appended in each case using process explorer.

While mfcXXu.dll is replaced by mdfXXud.dll in debug mode, msvcrt.dll
is still attached to debug mode process and additional msvcrtd.dll is
attached. Is it correct behavior? Why doesn't msvcrtd.dll replace
msvcrt.dll?

I ask this because I might have done something wrong in building the
app. So I want to make sure if anything's wrong.

Thanks in advance.

--
Daewon YOON

Replies to this posting goes to : comp.os.ms-windows.programmer.win32

From: David Lowndes on
>I compiled a project in debug and release mode, and checked what dll's
>are appended in each case using process explorer.
>
>While mfcXXu.dll is replaced by mdfXXud.dll in debug mode, msvcrt.dll
>is still attached to debug mode process and additional msvcrtd.dll is
>attached. Is it correct behavior? Why doesn't msvcrtd.dll replace
>msvcrt.dll?

Presumably because your application is specifically linking to some
aspect of msvcrt.dll. Depends (www.dependencywalker.com), or the
verbose option of the linker may allow you to identify what it is.

What version of VC++ are you using, and is this a new project? Newer
versions don't normally link directly with those old OS supplied
run-time DLLs (though it's possible some other components you use do).

Dave
From: Ben Voigt [C++ MVP] on
David Lowndes wrote:
>> I compiled a project in debug and release mode, and checked what
>> dll's are appended in each case using process explorer.
>>
>> While mfcXXu.dll is replaced by mdfXXud.dll in debug mode, msvcrt.dll
>> is still attached to debug mode process and additional msvcrtd.dll is
>> attached. Is it correct behavior? Why doesn't msvcrtd.dll replace
>> msvcrt.dll?
>
> Presumably because your application is specifically linking to some
> aspect of msvcrt.dll. Depends (www.dependencywalker.com), or the
> verbose option of the linker may allow you to identify what it is.
>
> What version of VC++ are you using, and is this a new project? Newer
> versions don't normally link directly with those old OS supplied
> run-time DLLs (though it's possible some other components you use do).

That's why I'd be more surprised about msvcrtd.dll being loaded. The
release version, msvcrt.dll, will have been loaded by OS components.
Process Explorer doesn't distinguish between direct and transitive imports.
Dependency Walker is definitely the right tool to investigate this.

And I wouldn't be concerned about it, the OS APIs are properly designed to
not leak internal CRT objects across module boundaries, so it doesn't really
matter which CRT version they use, or if they even use any at all.

>
> Dave