Using _BIND_TO_CURRENT_VCLIBS_VERSION=1
Oleg Tsulun
(this is visible in SD some.exe.intermediate.manifest). But when application is executed
system redirects bindings to newer CRT libraries.
Application is tested on machine with newer CRT libraries, but
distribution of application need older CRT libraries. And because of
this on user's machine there can be some bug, which was not on
developer's machine.
I suggest to use "_BIND_TO_CURRENT_VCLIBS_VERSION=1" preprocessor
definition to remove this inconsistent at all. So this definition
can be added to wxWidget's release configurations.
Oleg
Vaclav Slavik
> I suggest to use "_BIND_TO_CURRENT_VCLIBS_VERSION=1" preprocessor
> definition to remove this inconsistent at all. So this definition
> can be added to wxWidget's release configurations.
Whether you want or don't want to use this depends on the details of how
you deploy your app. It's not something that is universally useful and
shouldn't be done unconditionally in wx itself. You'll have to do it in
your build scripts (I do the same).
Vaclav
Oleg Tsulun
I think that it is hard to imagine such situation, when wx user needs to
link to older version of CRT.
Oleg
Vadim Zeitlin
OT> > On Fri, 2010-07-23 at 12:22 +0000, Oleg Tsulun wrote:
OT> >> I suggest to use "_BIND_TO_CURRENT_VCLIBS_VERSION=1" preprocessor
OT> >> definition to remove this inconsistent at all. So this definition
OT> >> can be added to wxWidget's release configurations.
OT>
OT> > Whether you want or don't want to use this depends on the details of how
OT> > you deploy your app. It's not something that is universally useful and
OT> > shouldn't be done unconditionally in wx itself. You'll have to do it in
OT> > your build scripts (I do the same).
OT>
OT> I think that it is hard to imagine such situation, when wx user needs to
OT> link to older version of CRT.
I thought about it myself but decided that it was on the contrary very
easy to imagine it: if you want to send just an updated binary to someone
who doesn't have the new libraries, it wouldn't work if we used
_BIND_TO_CURRENT_VCLIBS_VERSION. Admittedly, you're not supposed to do this
and install the application with all its dependencies using a setup instead
but it still can be handy to update by just copying a single file.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Vaclav Slavik
> I think that it is hard to imagine such situation, when wx user needs
> to link to older version of CRT.
E.g. when you don't ship the CRT. The _BIND_TO_CURRENT_VCLIBS_VERSION
hack is intended specifically for the situation when you install the CRT
assembly alongside your app (i.e. you don't use the recommended MSI
method).
Vaclav
Oleg Tsulun
In this case it could be better to also copy Microsoft.VC90.CRT folder
and it's size in archive only 400KB.
Oleg Tsulun
I think that most developers use this method, because vc_redist.exe is
much larger in size.
Vadim Zeitlin
OT> OT>> I think that it is hard to imagine such situation, when wx user needs to
OT> OT>> link to older version of CRT.
OT>
OT> > I thought about it myself but decided that it was on the contrary very
OT> > easy to imagine it: if you want to send just an updated binary to someone
OT> > who doesn't have the new libraries, it wouldn't work if we used
OT> > _BIND_TO_CURRENT_VCLIBS_VERSION. Admittedly, you're not supposed to do this
OT> > and install the application with all its dependencies using a setup instead
OT> > but it still can be handy to update by just copying a single file.
OT>
OT> In this case it could be better to also copy Microsoft.VC90.CRT folder
OT> and it's size in archive only 400KB.
It won't work if you just copy it though, will it? You need to create a
proper manifest for it too. And, anyhow, the copy of this folder in MSVS
directory contains the original (old) redistributables and not the new ones
your binary depends on. So you'd have to remember to copy them from WinSxS
directory and not there and, of course, you'd get it wrong exactly one time
out of two because it would run correctly on your machine with any version
or even without anything and it's only on customers machine that the
problem will manifest itself (speaking from experience here as you can
guess...).
Frankly, I don't know what's the right way to deal with this SxS mess
but I don't think we need to confuse matters further by changing the
default behaviour unless it would make it *unambiguously* better.
Vadim Zeitlin
OT> > E.g. when you don't ship the CRT. The _BIND_TO_CURRENT_VCLIBS_VERSION
OT> > hack is intended specifically for the situation when you install the CRT
OT> > assembly alongside your app (i.e. you don't use the recommended MSI
OT> > method).
OT>
OT> I think that most developers use this method, because vc_redist.exe is
OT> much larger in size.
I would have thought that most people just link statically. Whatever the
problems of this approach, at least it's extremely simple and it always
works.
Oleg Tsulun
> On Fri, 23 Jul 2010 13:45:46 +0300 Oleg Tsulun <ots...@ukr.net> wrote:
OT>> OT>> I think that it is hard to imagine such situation, when wx user needs to
OT>> OT>> link to older version of CRT.
OT>>
OT>> > I thought about it myself but decided that it was on the contrary very
OT>> > easy to imagine it: if you want to send just an updated binary to someone
OT>> > who doesn't have the new libraries, it wouldn't work if we used
OT>> > _BIND_TO_CURRENT_VCLIBS_VERSION. Admittedly, you're not supposed to do this
OT>> > and install the application with all its dependencies using a setup instead
OT>> > but it still can be handy to update by just copying a single file.
OT>>
OT>> In this case it could be better to also copy Microsoft.VC90.CRT folder
OT>> and it's size in archive only 400KB.
> It won't work if you just copy it though, will it? You need to create a
> proper manifest for it too. And, anyhow, the copy of this folder in MSVS
> directory contains the original (old) redistributables and not the new ones
> your binary depends on. So you'd have to remember to copy them from WinSxS
> directory and not there and, of course, you'd get it wrong exactly one time
> out of two because it would run correctly on your machine with any version
> or even without anything and it's only on customers machine that the
> problem will manifest itself (speaking from experience here as you can
> guess...).
All is much simplier. Microsoft.VC90.CRT folder already has manifest.
Only what you need is to copy this folder to folder with your
application. Operation system first try to use WinSxS. If it has newer
or same version, than it uses it. Next it try folder, where
application exists and use it in that case.
Oleg
Oleg Tsulun
> directory contains the original (old) redistributables and not the new ones
> your binary depends on.
The copy of this folder in MSVS contains new redistributables.
Manifest, which included to *.exe is generated automatically by VS.
> Frankly, I don't know what's the right way to deal with this SxS mess
> but I don't think we need to confuse matters further by changing the
> default behaviour unless it would make it *unambiguously* better.
It seems so.
Vaclav Slavik
> It won't work if you just copy it though, will it? You need to create a
> proper manifest for it too.
No, it is contained in said folder.
> And, anyhow, the copy of this folder in MSVS
> directory contains the original (old) redistributables and not the new
> ones your binary depends on
This is not true.
Vaclav
Vaclav Slavik
> > Frankly, Idon't know what's the right way to deal with this SxS
> mess
> > but I don't think we need to confuse matters further by changing the
> > default behaviour unless it would make it *unambiguously* better.
>
> It seems so.
Again: no, it doesn't, both I and Vadim gave you counterexamples.
Vaclav
Oleg Tsulun
For both examples it is better choice to use suggested method.
Vadim Zeitlin
VS> On Fri, 2010-07-23 at 12:54 +0200, Vadim Zeitlin wrote:
VS> > It won't work if you just copy it though, will it? You need to create a
VS> > proper manifest for it too.
VS>
VS> No, it is contained in said folder.
Right, I forgot about this, sorry.
VS> > And, anyhow, the copy of this folder in MSVS
VS> > directory contains the original (old) redistributables and not the new
VS> > ones your binary depends on
VS>
VS> This is not true.
Ok, apparently I was confused by the fact that I only have 9.0.30729.1 in
...\dev\msvc\9\VC\redist\x86\Microsoft.VC90.CRT\Microsoft.VC90.CRT.manifest
(and the DLLs in the same directory which are dated Nov 2009) but newer
9.0.30729.4974 (from May 2010) in the SxS directory. However it seems the
latter was installed by VC10 and is not used by the files built using VC9
if I read sxtrace output correctly.
Vadim Zeitlin
OT> > On Fri, 2010-07-23 at 14:05 +0300, Oleg Tsulun wrote:
OT> >> > Frankly, Idon't know what's the right way to deal with this SxS
OT> >> mess
OT> >> > but I don't think we need to confuse matters further by changing the
OT> >> > default behaviour unless it would make it unambiguously better.
OT> >>
OT> >> It seems so.
OT>
OT> > Again: no, it doesn't, both I and Vadim gave you counterexamples.
OT>
OT> For both examples it is better choice to use suggested method.
My example was that I'm working with another developer who has VC9
installed. I send him just a binary thinking that he doesn't need anything
else as CRT DLLs are already installed on his machine. But with binding to
the latest version it wouldn't work unless he had SP1 too.
Granted, maybe I shouldn't expect anything as non trivial as copying an
executable file to a machine which already has its dependencies installed
to work. But I still think it would be less surprising if it did.
Vaclav Slavik
> For both examples it is better choice to use suggested method.
It *breaks* things if you rely on the shared CRT assembly (version of
which you cannot control). So no, breaking things is not better than not
doing it, sorry.
Vaclav
Oleg Tsulun
> Ok, apparently I was confused by the fact that I only have 9.0.30729.1 in
> ...\dev\msvc\9\VC\redist\x86\Microsoft.VC90.CRT\Microsoft.VC90.CRT.manifest
> (and the DLLs in the same directory which are dated Nov 2009) but newer
> 9.0.30729.4974 (from May 2010) in the SxS directory. However it seems the
> latter was installed by VC10 and is not used by the files built using VC9
> if I read sxtrace output correctly.
I have checked this twice on Vista by "Attach to Process..." in VS.
Application uses 9.0.30729.4974 version.
Oleg Tsulun
> It *breaks* things if you rely on the shared CRT assembly (version of
> which you cannot control). So no, breaking things is not better than not
> doing it, sorry.
If you are using shared libraries, you rely on the shared CRT assembly
in both cases: with using _BIND_TO_CURRENT_VCLIBS_VERSION=1 or without
it. In first case it is better because user at least will use minimum
of yours current CRT version and it is better than it can use
older version.
Oleg
Oleg Tsulun
> My example was that I'm working with another developer who has VC9
> installed. I send him just a binary thinking that he doesn't need anything
> else as CRT DLLs are already installed on his machine. But with binding to
> the latest version it wouldn't work unless he had SP1 too.
This is permissible if you hint that developer that it needs SP1 or
vc_redistr.exe with the comparison of developing and testing your application with
the newer version of CRT and shipping it with the much older one.
Vadim Zeitlin
OT> Vadim Zeitlin wrote:
OT>
OT> > Ok, apparently I was confused by the fact that I only have 9.0.30729.1 in
OT> > ...\dev\msvc\9\VC\redist\x86\Microsoft.VC90.CRT\Microsoft.VC90.CRT.manifest
OT> > (and the DLLs in the same directory which are dated Nov 2009) but newer
OT> > 9.0.30729.4974 (from May 2010) in the SxS directory. However it seems the
OT> > latter was installed by VC10 and is not used by the files built using VC9
OT> > if I read sxtrace output correctly.
OT>
OT> I have checked this twice on Vista by "Attach to Process..." in VS.
OT> Application uses 9.0.30729.4974 version.
Was this for a wx application? Minimal sample definitely uses .1 here and
not .4974. I saw mentions of MFC applications using .4974 though. Maybe MFC
forces the use of _BIND_TO_CURRENT_VCLIBS_VERSION somehow?
In any case, if you still have .1 in VC9 redist directory (and I think you
do, as VC10 shouldn't have mucked with the files there) doesn't it mean
that your recipe won't work at all just as I said initially?
Vadim Zeitlin
OT> Vaclav Slavik wrote:
OT>
OT> > It breaks things if you rely on the shared CRT assembly (version of
OT> > which you cannot control). So no, breaking things is not better than not
OT> > doing it, sorry.
OT>
OT> If you are using shared libraries, you rely on the shared CRT assembly
OT> in both cases: with using _BIND_TO_CURRENT_VCLIBS_VERSION=1 or without
OT> it.
Yes, but without it I rely on the version installed with VC9 and with it
I rely on this version or some undetermined later one (maybe from SP1,
maybe -- if your other post is correct -- from VC10). IOW this brings even
more uncertainty to an already confusing (at least to me) situation.
Oleg Tsulun
My recipe works, because without _BIND_TO_CURRENT_VCLIBS_VERSION=1 my
application depends on CRT version="9.0.21022.8" which is older and I
need to ship it to the installer.
With _BIND_TO_CURRENT_VCLIBS_VERSION=1 my application depends on
newer version (which is in VS9 directory) and redistribute it with my
application is enough.
Vadim Zeitlin
OT> OT>> I have checked this twice on Vista by "Attach to Process..." in VS.
OT> OT>> Application uses 9.0.30729.4974 version.
OT>
OT> > Was this for a wx application? Minimal sample definitely uses .1 here and
OT> > not .4974. I saw mentions of MFC applications using .4974 though. Maybe MFC
OT> > forces the use of _BIND_TO_CURRENT_VCLIBS_VERSION somehow?
OT>
OT> > In any case, if you still have .1 in VC9 redist directory (and I think you
OT> > do, as VC10 shouldn't have mucked with the files there) doesn't it mean
OT> > that your recipe won't work at all just as I said initially?
OT>
OT> My recipe works, because without _BIND_TO_CURRENT_VCLIBS_VERSION=1 my
OT> application depends on CRT version="9.0.21022.8" which is older and I
OT> need to ship it to the installer.
OT> With _BIND_TO_CURRENT_VCLIBS_VERSION=1 my application depends on
OT> newer version (which is in VS9 directory) and redistribute it with my
OT> application is enough.
I don't know how to explain it but we're observing completely different
results. Let me just give you again the two facts about my VC9 installation
under x64 Win7:
1. I have 9.0.30729.1 in my redist directory under VC9.
2. The binaries I build (without using _BIND_TO_CURRENT_VCLIBS_VERSION)
depend on the same 9.0.30729.1 version.
I also have all of 9.0.21022.8 and 9.0.30729.{1,4148,4926,4974} in SxS
directory but this is probably less important.
Once again, I have no idea why things are so different for you.
Oleg Tsulun
> I don't know how to explain it but we're observing completely different
> results. Let me just give you again the two facts about my VC9 installation
> under x64 Win7:
> 1. I have 9.0.30729.1 in my redist directory under VC9.
> 2. The binaries I build (without using _BIND_TO_CURRENT_VCLIBS_VERSION)
> depend on the same 9.0.30729.1 version.
> I also have all of 9.0.21022.8 and 9.0.30729.{1,4148,4926,4974} in SxS
> directory but this is probably less important.
The problem that actually your application is dependent on 9.0.21022.8
version. Try it on clear system as "Side by side" method (locate CRT's
directory in the directory with your application) and you will see
that it willn't work without 9.0.21022.8 library.
I meet this problem when I tried to install my application on clear
system (Where no VC CRT at all).
With _BIND_TO_CURRENT_VCLIBS_VERSION it depends only on 9.0.30729.1
(but can use better one).
Oleg
Oleg Tsulun
> Yes, but without it I rely on the version installed with VC9 and with it
> I rely on this version or some undetermined later one (maybe from SP1,
> maybe -- if your other post is correct -- from VC10). IOW this brings even
> more uncertainty to an already confusing (at least to me) situation.
In any case even without _BIND_TO_CURRENT_VCLIBS_VERSION=1 my simple console application
uses 9.0.30729.4974
Vadim Zeitlin
OT> Vadim Zeitlin wrote:
OT>
OT> > I don't know how to explain it but we're observing completely different
OT> > results. Let me just give you again the two facts about my VC9 installation
OT> > under x64 Win7:
OT>
OT> > 1. I have 9.0.30729.1 in my redist directory under VC9.
OT> > 2. The binaries I build (without using _BIND_TO_CURRENT_VCLIBS_VERSION)
OT> > depend on the same 9.0.30729.1 version.
OT>
OT> > I also have all of 9.0.21022.8 and 9.0.30729.{1,4148,4926,4974} in SxS
OT> > directory but this is probably less important.
OT>
OT> The problem that actually your application is dependent on 9.0.21022.8
OT> version.
Right. And it can use it or a later version if it's available. Isn't this
the most flexible solution and thus appropriate unless you absolutely need
to require the use of a later version (e.g. because some CRT bug affecting
your application was fixed there)? IOW by binding to the current CRT
versions you lose the possibility to use the older version and also expose
yourself to all sort of surprises as the next SP or hotfix or whatever can
change the CRTs versions on your machine thus changing the requirements of
your application. And what do you gain?
Again, if you do need some version of CRT, presumably you can be expected
to take the extra steps to ensure you get it. But why would you want to do
it by default? E.g. why do you need it in your particular case?
Oleg Tsulun
Because when you are developing, you are using new version of CRT and testing
against it. When you deploy - you need to deploy with untested one.
And you are not shure that it will be worked correctly with older one.
However using _BIND_TO_CURRENT_VCLIBS_VERSION=1 in wxWidgets needs
additional knowledge to the user that it is used, so user needs also
to use this flag in his project. This is also not quite good.
Oleg
Vadim Zeitlin
OT> > Again, if you do need some version of CRT, presumably you can be expected
OT> > to take the extra steps to ensure you get it. But why would you want to do
OT> > it by default? E.g. why do you need it in your particular case?
OT>
OT> Because when you are developing, you are using new version of CRT and testing
OT> against it. When you deploy - you need to deploy with untested one.
OT> And you are not shure that it will be worked correctly with older one.
In theory this makes sense but in practice I have trouble believing that
much code is affected by the changes in the minor or even micro releases of
the CRT. Of course, I don't know what changed in details (do you?) but I
hope the bugs fixed in the latest versions should affect sufficiently few
applications to make sense of opting it.
OT> However using _BIND_TO_CURRENT_VCLIBS_VERSION=1 in wxWidgets needs
OT> additional knowledge to the user that it is used, so user needs also
OT> to use this flag in his project. This is also not quite good.
No but OTOH this has really nothing to do with wxWidgets. I don't say it's
a good idea that Microsoft did it like this (mind you, I don't say it's a
bad one neither, all this stuff is sufficiently complex for me to hesitate
to formulate an opinion one way or the other) but this is how they chose
their toolchain should behave and why should linking in some library that
your application uses change this?
Oleg Tsulun
OT>> However using _BIND_TO_CURRENT_VCLIBS_VERSION=1 in wxWidgets needs
OT>> additional knowledge to the user that it is used, so user needs also
OT>> to use this flag in his project. This is also not quite good.
> No but OTOH this has really nothing to do with wxWidgets. I don't say it's
> a good idea that Microsoft did it like this (mind you, I don't say it's a
> bad one neither, all this stuff is sufficiently complex for me to hesitate
> to formulate an opinion one way or the other) but this is how they chose
> their toolchain should behave and why should linking in some library that
> your application uses change this?
If you set this flag in one project but not in other or vice versa,
your application became dependent on both versions of CRT library.
Vadim Zeitlin
OT> OT>> However using _BIND_TO_CURRENT_VCLIBS_VERSION=1 in wxWidgets needs
OT> OT>> additional knowledge to the user that it is used, so user needs also
OT> OT>> to use this flag in his project. This is also not quite good.
OT>
OT> > No but OTOH this has really nothing to do with wxWidgets. I don't say it's
OT> > a good idea that Microsoft did it like this (mind you, I don't say it's a
OT> > bad one neither, all this stuff is sufficiently complex for me to hesitate
OT> > to formulate an opinion one way or the other) but this is how they chose
OT> > their toolchain should behave and why should linking in some library that
OT> > your application uses change this?
OT>
OT> If you set this flag in one project but not in other or vice versa,
OT> your application became dependent on both versions of CRT library.
Well, yes, exactly. If wxWidgets set this flag on its own by default (as
you advocate) there would be a very real risk of such mismatch occurring.
If the user sets this flag himself, it's his responsibility to ensure that
it doesn't and we can't be held responsible for any resulting problems.