Re: system error 14001 and vcredist_x86.exe

[Ross Berteig <Ross@...>]

Sometime on 8/6/2008, RJP Computing wrote:
>This will then *require* 'vcredist.exe' to be installed. I just 
>can't stress enough that I feel this is the wrong desision. I 
>think others can comment on this to help stress the problem or 
>to explain how I am wrong.

Lua for Windows is currently using the "private assembly" 
technique, and I assume that Ryan did that on purpose. Lots of 
detail can be found by Google for "private assembly", but the 
reference article at MSDN is at:

http://msdn.microsoft.com/en-us/library/aa375674(VS.85).aspx

As I understand it at the moment, if the application has a 
manifest (either in a resource or in a sidecar file) that names 
the CRT assembly correctly and there is a private assembly in the 
.EXE's folder, then the right things happen. You can show this by 
using depends.exe to profile an application with a manifest (like 
LfW's lua.exe) loading a DLL that itself references the same CRT 
version.

I've been testing this lately with the manifest in the 
application and not in the DLL, and according to my reading of 
dependency walker's output, the right DLLs are being loaded.

>> ....
>Yes, and the only way that happens is through the vcredist_x86.exe, 
>as far as I can tell.

IRRC, the officially supported ways for an application to provide the 
CRT are:

1. A merge module for the VC redistributables, merged into the 
.msi installer for the application. This is the "right thing to 
do" if your application is distributed in a .msi installer 
package. Personally, I have found .msi packages to be more 
difficult to build than I want to deal with, especially compared 
to the relative ease of InnoSetup.

2. vcredist*.exe. An installer built by InnoSetup can, in 
principle, carry a copy of the correct vcredist.exe and run it if 
the system doesn't seem to have a copy of the CRT assembly yet. I 
haven't seen a good description of how to find out if that is the 
case, and I hate to run something like that on every update to an 
application. I haven't yet worked out any InnoSetup kludges to 
attempt that check.

3. Private assemblies. These work on certain "new enough" 
versions of Windows, and only require shipping a folder with a 
magical name containing the CRT DLLs. It isn't clear from the 
docs if its ok to only ship the DLL you intend to need, so I have 
been doing the same thing LfW does and including all three CRT 
DLLs in my installers. If some other app has provided a public 
assembly, then the system will use it instead of the private one 
under many scenarios. This punts the work of getting a copy of 
the CRT into the system assembly repository to someone with a 
budget ;-) while still delivering a working application to those 
who don't already have the CRT DLL.

4. On older Windows, such as Win9x and NT4 or earlier, the kernel 
doesn't know how to locate assemblies (public or private) so it 
is necessary to put the CRT DLLs you actually use in the same 
folder as the EXE file. I do that in InnoSetup with a conditioned 
copy of MSVCR80.DLL that operates only on Win9x, or NT.

I suspect that DLLs "should" also get manifests, but I don't know 
what kind of quirky mess you get when an application with a 
manifest nameing one version of the CRT assembly loads a DLL 
naming another version. Somehow I don't think that DLL hell has 
been completely eradicated yet.... or that it can be in an 
environment where a whole community supports an application and a 
rich array of plug-in DLLs.


Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/