I’m writing an app which will go on an industrial system (or, hopefully, 6000 of them) and all the systems have version 8.0.50727.42 of the Microsoft VC80 (2005) redist installed.
The SDL 1.3 libraries (image, especially) seem to link 8.0.50727.4053 which is installed on my system (as is version .42, btw).
Of course, when you try to run it on the target system, it won’t start, complaining that the Windows SxS (side by side) version isn’t installed. Which is true.
Most people will say “install the latest redist file on the target”, but NONE of them can be updated. This is a physical impossibility. My software HAS to work with 8.0.50727.42.
A google search brings some useless help from MS. Does anyone know anything I can do to resolve this?
You could distribute your software with the 4053 runtime in the same folder
of the binaries and it will pick those instead of the ones installed in the
target system.On Fri, Dec 24, 2010 at 11:39 AM, ebyard <e_byard at yahoo.co.uk> wrote:
I’m writing an app which will go on an industrial system (or, hopefully,
6000 of them) and all the systems have version 8.0.50727.42 of the Microsoft
VC80 (2005) redist installed.
The SDL 1.3 libraries (image, especially) seem to link 8.0.50727.4053 which
is installed on my system (as is version .42, btw).
Of course, when you try to run it on the target system, it won’t start,
complaining that the Windows SxS (side by side) version isn’t installed.
Which is true.
Most people will say “install the latest redist file on the target”, but
NONE of them can be updated. This is a physical impossibility. My software
HAS to work with 8.0.50727.42.
A google search brings some useless help from MS. Does anyone know anything
I can do to resolve this?
Thanks for the post but I already tried that, and it doesn’t work. I have tried just the DLLs in my application folder, also the x86_microsoft… file and mainfests/security catalog files etc. Nothing works.
Why you cannot just link against this version of the runtimes you want, I do not know. It’s a massive problem by the looks of it (on google) and it’s actually going to cost me a significant amount of time and money to fix. It’s annoying as SDL 1.2 seems to work OK, but I didn’t build the libraries for that.
Make sure to compile your program and all its dependencies with the same
runtime (Multi threaded or single threaded dll’s) and also to do it in
release mode. Check your program’s dependencies in the target computer with
something like dependency walker or pe-explorer. Maybe some static lib or
dll you are using is linked to a debug runtime dll you are not including, it
happened to me once.
You could also try to use MingW to compile everything. If your project is
small it would be fairly easy to set up using Code::Blocks.On Fri, Dec 24, 2010 at 1:31 PM, ebyard <e_byard at yahoo.co.uk> wrote:
Felipe
Thanks for the post but I already tried that, and it doesn’t work. I have
tried just the DLLs in my application folder, also the
x86_microsoft… file and mainfests/security catalog files etc.
Nothing works.
Why you cannot just link against this version of the runtimes you want, I
do not know. It’s a massive problem by the looks of it (on google) and it’s
actually going to cost me a significant amount of time and money to fix.
It’s annoying as SDL 1.2 seems to work OK, but I didn’t build the libraries
for that.
Well I managed to get it working by using dependancy walker to show what’s going on. SDL_image needs most of the CRT stuff, so I just static linked everything and now the exe runs on the target OK, but the problem now is that SDL_CreateWindow makes the system give an exception and Windows shuts it down.