Ivan
Thu Jul 19 18:27:38 CDT 2007
For msvcrtd.dll, you have no other option that deploy your own version.
For msvcrt.dll, you can bind with the first match in DLL search order.
The debug versions of msvcrt[70|71|80]d.dll are non redistributable.
The retail version of msvcrt[70|71|80].dll are redistributable, and,
you can choose to link them in SxS, or, in close-proximity (DllPath search
order).
My take would be to give-up the idea of distributing debug
versions of the C-Rutnime, period.
IIRC, in the DDK/WDK toolset, even if you build in a checked command prompt,
you will always link against msvcrt.dll (the system version),
by using the proper macros in the SOURCES file.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
<r_konjeti@yahoo.com> wrote in message
news:1184876041.755299.156030@n2g2000hse.googlegroups.com...
> Thanks a lot for the detailed reply.
>
> Can you give me more pointers on how I can plan for binary
> distribution. I am missing something very important here.
>
> My question is since the dll search algorithm and path is same for all
> executables, are we not binding all to msvcrt.dll in windows/system32
> no matter which VS 6.0 or VS 2005 we compile. Only other way is if we
> have a copy of dll in exe directory. I read about 3 kinds of run-time
> libraries but all I understood is to use same C-runtime lib for all
> modules (exes and dlls).
>
> I my project I took care not to mix runtime resources between modules
> like allocating memory or file handles and freeing within the module
> boundaries.
>
> Do I need to worry about free build also like what it was compiled
> with and tested on one machine and what was binded with when deployed.
>
> Thanks,
> Raj
>
> On Jul 18, 1:40 pm, "Ivan Brugiolo [MSFT]"
> <ivanb...@online.microsoft.com> wrote:
>> The main point to get here is that linking an arbitrary C-Runtime
>> is that may or may not be deployed is never a good idea.
>>
>> It used to happen that the C-Runtime of VC6.0 used to have the same name
>> as the OS-version of the C-Runtime.
>> For this unfortunate reason, if you have a VC6 compiled binary, it may
>> try
>> to use
>> the OS version of the runtime instead of the specific version, given
>> a certain DLL-Search Path.
>> Then, the DevDiv choose to use SxS to bind an executable with a specific
>> version
>> of the C-Runtime, and that's why we have msvcr[d][70|71|80].dll.
>>
>> The DKK/WDK allows you to build an executable that binds to the
>> OS-Supplied
>> version of the C-Runtime, and, the implicit contract is that the
>> C-Runtime
>> behaviors
>> are consistent across supported versions of the DDK.
>> [I will not go to the details of the lack of certain string-to-64-bit
>> integer in msvcrt.dll in Win2000, the convoluted way of binding the
>> throwing C++ behavior, and other issues with conformace of several
>> features of the language across different OS-es, and bug-for-bug
>> unfortunate
>> compatibility issues].
>> [On a side note, the OS version of the C-Rutnime is only tested with the
>> OS
>> binaries,
>> and, not with all the possible binaries that developer may want to write.
>> That
>> is the mission of the Visual Studio C-Runtime.]
>>
>> Please re-think your binary distribution policy before finding yourself
>> to
>> debug
>> the worst test matrix you could ever dream of.
>>
>> --
>>
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Use of any included script samples are subject to the terms specified
>> at
http://www.microsoft.com/info/cpyright.htm
>>
>> "Raj" <R...@discussions.microsoft.com> wrote in message
>>
>> news:13E55C23-AE9E-4EF7-A9FF-23DD1E041A1B@microsoft.com...
>>
>>
>>
>> > Will using 'dynamic link' option /MDd help in this case ?
>>
>> > "r_konj...@yahoo.com" wrote:
>>
>> >> I was not thinking there will be version issues between different
>> >> msvcrtd.dll files. So I didnot specifically expect
>> >> to use any particular version of file.
>>
>> >> Now that this is an issue, how can other programmers use my debug
>> >> build dll easy way?
>> >> Since they have their own MSDN professional subscription, I dont have
>> >> to ship standard windows dll
>> >> if there is licensing issue. But still how would anyone use this ?
>> >> Should they have to copy runtime dll into
>> >> same directory as my debug built dll.
>>
>> >> I wont have this issue with actual release software because I will be
>> >> using free build for release anyway.
>>
>> >> Thanks,
>> >> Raj
>>
>> >> On Jul 13, 2:55 pm, "Jeff Henkels" <jeff.henk...@mapson.gmail.com>
>> >> wrote:
>> >> > IIRC, the licensing for MSVC doesn't allow you to ship any MS debug
>> >> > DLLs.
>>
>> >> > <r_konj...@yahoo.com> wrote in message
>>
>> >> >news:1184340762.895058.267520@k79g2000hse.googlegroups.com...
>>
>> >> > > Is it general practice that we ship msvcrtd.dll along with our
>> >> > > debug
>> >> > > build dll (debug build for application development purpose of
>> >> > > other
>> >> > > programmers)?
>>
>> >> > > On Jul 12, 6:45 pm, "Ivan Brugiolo [MSFT]"
>> >> > > <ivanb...@online.microsoft.com> wrote:
>> >> > >> The debug version of the OS-Provided C-Runtime is not shipped in
>> >> > >> the
>> >> > >> OS.
>> >> > >> Where did you get a working version of msvcrtD.dll from ? Maybe
>> >> > >> some obsolete VC6.0 installation ?
>>
>> >> > >> You can always inspect build<fre|chk>.log to see the list of
>> >> > >> compiler
>> >> > >> options
>> >> > >> and linker flags used.
>> >> > >> Makefile.def has the rules and the macros that you specify in the
>> >> > >> sources
>> >> > >> file.
>>
>> >> > >> --
>>
>> >> > >> --
>> >> > >> This posting is provided "AS IS" with no warranties, and confers
>> >> > >> no
>> >> > >> rights.
>> >> > >> Use of any included script samples are subject to the terms
>> >> > >> specified
>> >> > >> at
http://www.microsoft.com/info/cpyright.htm-Hide quoted text -
>>
>> >> > - Show quoted text -
>
>