[Zlib-devel] visual studio linking against msvcrt.dll

[Berke Viktor]

i beg to differ, but,

On 2010.03.29. 1:26, William A. Rowe Jr. wrote:
> On 3/28/2010 4:58 PM, Berke Viktor wrote:
>> helo,
>>
>> there are vc9 and vc10 solutions in the zlib source tree. this makes it
>> easy to build the zlib libraries. there's one problem, however: they
>> link against msvcr90.dll (with vc9). that means, they won't work on xp
>> until the vcredist package is installed. xp only has msvcrt.dll.
>
> As long as they link against msvcr100.dll (with vc10), this is good...

why? yes, it will work... on the machine it was built on, coz it will 
(of course) have the dll, otherwise it wouldn't link. but the client 
won't have it by default.

>> this can be solved by updating the solutions to use the windows driver
>> kit libs and headers. this causes the build to link against the old
>> msvcrt.dll found in windows xp.
>>
>> more info: http://winbuild.daydreamer.nu/
>
> If they are building a vc9 or vc10 projects, they have the vcredist package,
> and if they are delivering projects, they are shipping those libraries.  They
> must install such libraries to use the rest of their projects.

not really. first example is gtk which comes to mind. most FOSS projects 
try to avoid linking against newer versions of the vc runtime since they 
don't want to force every user to install vcredist. they usually end up 
using vc6, AFAIK. or build with mingw. but i'd consider the "native" 
compiler a better approach, especially when the solution is so simple.

for example (quite unrelated), a recent testing showed lame mingw is 
about 15% slower than the vc build with the same config.

> There is a substantial flaw with the proposed solution, of course it is
> possible to generate import headers, but this 1) ignores Microsoft's warning
> that msvcrt.dll is for internal consumption, going forwards (as illustrated by
> a printf formatting bug closed 'won't fix', although the bug was clearly at odds
> with the relevant C standards), and 2) ignores the fact that the .h files in
> msvcr90/100 are not the correct headers for msvcrt.dll.

that's why the wdk headers have to be added as well :)

> "You may only use the provided files at your own risk" is a very good statement,
> and expecting the user to obtain such a complex toolchain is a bad place to start
> for contrib/.  The msvcrt.dll bound binaries are built with the appropriate, much
> older compiler and headers.  If a user wants to follow your suggested approach,
> then editing a few lines of the vcproj file is the least of their worries :)

looking at the bug reports related to MS (on connect, for example), 
there are always oddities... but you can't really avoid them if you 
support their platform ;)

the warning's there since i'm not the author of these software, i'm just 
building them.

about complexity: it's about 5 more clicks than installing just vs :) 
and it has to be built only once ;) that's why i suggested to make such 
builds (both x86 and x64) available, so that most users don't want to 
build on their own, coz it's a needless when it's already done, by the 
authors.

> I respect your enthusiasm, perhaps it makes the most sense to distribute a tool
> which allows the user to modify their .vcproj files into this schema, en masse?

i'm not aware of such tool, but that't better than nothing :)