Page 1 of 1

VS2008 portability problem

Posted: Sat Sep 06, 2008 10:12 am
by happilylazy
I have a problem with a game I made in IrrLicht and compiled it under VS2008 Visual C++ (Win32 Con App - Empty Project).

It runs on my laptop perfectly but on any other computers, after executing the EXE, I get an error:

"This application has failed to start because application configuration is incorrect. Reinstalling the application may fix the problem."

... or ...

"application failed to start because side-by-side scripting
configuration is incorrect." - this is on Vista SP1 and XP SP2.

The funny thing is that I compiled the same code on VS2003 Visual C++ (Win32 Con App - Empty Project) and it runs anywhere without a problem.
I checked and rechecked the paths and DLL but I use the same in both VS's.

Anybody had this problem? And solved it maybe?
VS2008 is very user friendly so I'd like to work in it, if this issue get's solved.

Posted: Sat Sep 06, 2008 10:21 am
by hybrid
I hope you didn't do a debug build, because those are not meant to be put onto another computer. For release builds you need the proper MSVC runtime on all computers installed where the app should run. Older versions of the runtime are often already installed, hence less problems :)

Posted: Sat Sep 06, 2008 10:42 am
by happilylazy
No, no I did release build, and you do have a point, after that Vista error it was stated that I install "vcredist_x86" , but it still didn't work. :(
So I guess I can program and test in VS2008, and build the final product in VS2003, damn that Microsoft :evil:

Posted: Sat Sep 06, 2008 11:27 am
by rogerborg
I'd recommend reading this page.

You can distribute the vcredist with your app, the same way you'd include the DirectX redistributables. It's only 1.7MB.

Posted: Sat Sep 06, 2008 12:34 pm
by happilylazy
Excellent!
Thanks! This is just what I need!
But still for a small game I'll go with VS2003 building, it's much more easier for the end user (Click&Play).

Posted: Sat Sep 06, 2008 6:45 pm
by Dark_Kilauea
It is possible to turn off the managed library support in 2005 and later for C++ projects. The option is buried somewhere deep inside the options area though.

Posted: Sat Sep 06, 2008 6:58 pm
by nmn
Dark_Kilauea wrote:It is possible to turn off the managed library support in 2005 and later for C++ projects. The option is buried somewhere deep inside the options area though.
I believe the situation is the application is not managed, but the MSVCRT runtime for 2008 isn't already installed.

In that case, many people just don't care and include MSVCRT against it's license, directly with the application with no installer. You may also be able to automate the installation of Microsoft's installer, but that would skip the EULA and probably also be against the license.

If it's a really small distribution I seriously doubt anybody will care if you distribute the DLLs alongside the application. The DLL-Files.com website includes DLLs against their licenses all the time, And nothing has happened to them yet.

Posted: Sat Sep 06, 2008 8:41 pm
by Dark_Kilauea
The MSVCRT runtime is a managed code runtime for C++/C code. It's Microsoft's way of cleaning up after a program if it crashes and leaves allocated memory all over the place.

Posted: Sun Sep 07, 2008 6:34 pm
by vitek
Dark_Kilauea wrote:The MSVCRT runtime is a managed code runtime for C++/C code. It's Microsoft's way of cleaning up after a program if it crashes and leaves allocated memory all over the place.
No, and no. You're wrong on both accounts. It is not managed code, and it is not microsofts way of cleaning up after crashes.

The MSVCRT is the C RunTime library for Microsoft compilers. It is the same as libc.so that you would find on most Unix platforms. It is a shared library that contains definitions for standard C and C++ functions that are provided by the implementation. There are also a few symbols in there, but those are not a concern for most users.

Travis

Posted: Sun Sep 07, 2008 6:45 pm
by Dark_Kilauea
I stand corrected then.

Posted: Sun Sep 07, 2008 9:15 pm
by ehenkes

Posted: Mon Sep 08, 2008 7:15 am
by vitek
Using the static library in a program that links to a dll (the Irrlicht.dll) is asking for trouble. The static library and the dll will maintain seperate copies of static data, and that can cause heap corruption, unexpected behavior, and crashes.

This is the cause of crashes that occur when using the texture matrix on Windows systems.

Travis