[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: system error 14001 and vcredist_x86.exe
- From: Ross Berteig <Ross@...>
- Date: Thu, 07 Aug 2008 00:53:29 -0700
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:
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
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
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/