Problem with program -- non-multibyte issue?
Part of a product I develop consists of a Windows program developed in Visual C++, without MFC.
This program can install & remove itself from Windows services and runs as a Windows service.
When attempting to run it on the Danish version of Windows XP Pro SP2, it failed to run in any way. An error message is shown (on command-line) which roughly translates as 'the system could not run the program' and the exit code 9020 is returned (which doesn't seem to be a defined exit code...)
This program is *not* developed with multibyte systems in mind; there is no use of the _T or _TCHAR macros and we compile without Unicode support. What I thought was strange though was that it did not run at all -- I don't think it even got to WinMain().
I recall having seen _tWinMain() on my travels before which obviously has the usual wide character prefix, but surely once compiled the entry point is referred to be address within the binary, not by an ASCII / Unicode symbol?
I do not have access to the OS so cannot test this theory, so I'd like to get some info on whether you'd expect to see a program not even start if it wasn't developed for multi-byte operation.
Thanks!
This program can install & remove itself from Windows services and runs as a Windows service.
When attempting to run it on the Danish version of Windows XP Pro SP2, it failed to run in any way. An error message is shown (on command-line) which roughly translates as 'the system could not run the program' and the exit code 9020 is returned (which doesn't seem to be a defined exit code...)
This program is *not* developed with multibyte systems in mind; there is no use of the _T or _TCHAR macros and we compile without Unicode support. What I thought was strange though was that it did not run at all -- I don't think it even got to WinMain().
I recall having seen _tWinMain() on my travels before which obviously has the usual wide character prefix, but surely once compiled the entry point is referred to be address within the binary, not by an ASCII / Unicode symbol?
I do not have access to the OS so cannot test this theory, so I'd like to get some info on whether you'd expect to see a program not even start if it wasn't developed for multi-byte operation.
Thanks!
ASKER
D'oh that's disappointing. Do you have any idea on the non-existent exit code, or other reason why a well-tested program would not even get to its entry point? We've tested well on XP Pro SP2, it's standard Intel single-core 32-bit architecture, ...
Have you ever succeeded to run the program on non-US Windows? What is the error message exactly (in Danish)? Have you tried to change the regional settings to Denmark on your computer?
ASKER
The Danish error message is this:
Systemet kan ikke udføre det angivne program.
As I understand it, that loosely translates as 'the system could not run the program'.
I'll try Danish regional settings now...
Systemet kan ikke udføre det angivne program.
As I understand it, that loosely translates as 'the system could not run the program'.
I'll try Danish regional settings now...
ASKER
Danish regional settings had no effect. I'm hoping to get hold of a copy of the Danish Windows shortly so hopefully I can reproduce the problem it under that.
Was your program rebuilt recently? Was it by chance rebuilt with Visual Studio 2005 or 2005 express?
Another direction to look for is that the installer could misplace some files because in Danish Windows, the folders like "Program Files" or "My Documents" are named differently.
Another direction to look for is that the installer could misplace some files because in Danish Windows, the folders like "Program Files" or "My Documents" are named differently.
ASKER
The one that was distributed was built in January under Visual C++ 2005 Express. Why do you mention that?
No, the error happened even when attempting to run the file directly from command-line. I checked that the message for a non-existent file was different too.
No, the error happened even when attempting to run the file directly from command-line. I checked that the message for a non-existent file was different too.
With Visual C++ 2005 on Windows XP, the programs need manifest to run. Many ported projects suffer from that: the manifest is not embedded into the executable, and not copied into the correct place during installation. The easiest thing is to copy the manifest file to the same folder where the executable is stored.
Your second answer suggests that the program does not need installation, and is simply copied to any directory. Make sure that the manifest file is copied there, too. But maybe it would be worthwhile to embed it - you go into the linker settings for your project in VS 2005, and set "embed manifest" on.
See the article with detailed expplanations in MSDN: http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx
Your second answer suggests that the program does not need installation, and is simply copied to any directory. Make sure that the manifest file is copied there, too. But maybe it would be worthwhile to embed it - you go into the linker settings for your project in VS 2005, and set "embed manifest" on.
See the article with detailed expplanations in MSDN: http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx
On the second thought, there is a one-in-a-million chance that your problem with Danish is similar to the one we found in https://www.experts-exchange.com/questions/22150503/Terminated-in-an-unusual-way-message-in-Europe-only-never-in-US.html, but to believe Terry Pratchett, "one-in-a-million chances crop up nine times out of ten". So, check if there could be an exception thrown by some static or global variable initialization.
ASKER
Unfortunately the only static initialisations are for fundamental types, so good idea but no success.
I'm installing the same copy of Windows on a VM so will see if I can reproduce the problem then try copying / embedding the manifest file.
Alex, MSDN is really bad at clearly explaining what a manifest is and what assemblies are. Am I right in thinking that assemblies are things that are dynamically linked, and the manifest file details which version of each assembly the program expects?
I'm installing the same copy of Windows on a VM so will see if I can reproduce the problem then try copying / embedding the manifest file.
Alex, MSDN is really bad at clearly explaining what a manifest is and what assemblies are. Am I right in thinking that assemblies are things that are dynamically linked, and the manifest file details which version of each assembly the program expects?
Working with unmanaged (that is, native, or not-CLR, or not-.Net) code, you don't care about assemblies; the assemblies are for the .Net virtual machine. Consider an assembly as a group of binaries. The manifest declares (in a digitally signed way) some meta-information about an assembly, including what dependencies it has, whether it wants to uses XP themes, its security requirements and credentials, etc.
The bottom line is that an application needs an assembly, and that the MSVC 2005 runtime library is a set of DLLs that also require a manifest. The latter may be either present in the application directory, or in the special system store called SxS (side by side).
The purpose of SxS is that the system will choose the appropriate version of the DLL from the range of versions (with the same name) installed, according to the manifest of the application. This was intended to solve the problem known as "the DLL hell". It has been widely acknowledged that the SxS "solution" produces more headaches than it actually solves.
The bottom line is that an application needs an assembly, and that the MSVC 2005 runtime library is a set of DLLs that also require a manifest. The latter may be either present in the application directory, or in the special system store called SxS (side by side).
The purpose of SxS is that the system will choose the appropriate version of the DLL from the range of versions (with the same name) installed, according to the manifest of the application. This was intended to solve the problem known as "the DLL hell". It has been widely acknowledged that the SxS "solution" produces more headaches than it actually solves.
ASKER
Ok thanks for that.
The manifest is not the problem here -- the program is compiled with an embedded manifest anyway, and generating it as a separate file which is put in the same directory as the executable doesn't change anything.
FYI, I'm compiling a release build and copying msvcr80.dll and msvcp80.dll into the same directory.
There is another program in this which I've also tested, also with the same result, but it is compiled with similar options so it's not that surprising.
In the absence of any other suggestions I'll create a new program and start attempting to narrow down the possible reasons.
The manifest is not the problem here -- the program is compiled with an embedded manifest anyway, and generating it as a separate file which is put in the same directory as the executable doesn't change anything.
FYI, I'm compiling a release build and copying msvcr80.dll and msvcp80.dll into the same directory.
There is another program in this which I've also tested, also with the same result, but it is compiled with similar options so it's not that surprising.
In the absence of any other suggestions I'll create a new program and start attempting to narrow down the possible reasons.
Have you copied the manifest file for msvcr80.dll in the directory?
ASKER
Err no?
Where do I find that? Searching In my WinSXS directory I can find the DLLs but not dllname.manifest.
I do have a set of manifest files of the form x86_Microsoft.Windows.Comm
Where do I find that? Searching In my WinSXS directory I can find the DLLs but not dllname.manifest.
I do have a set of manifest files of the form x86_Microsoft.Windows.Comm
Get the package from http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en
You need the file Microsoft.VC80.CRT.manifes
You need the file Microsoft.VC80.CRT.manifes
ASKER
Ok that's fixed it. Thanks very much for the help; what a headache SxS is!
So to do this properly for my applications, should I include running the VC redist at the beginning of installation, or should I just copy the required files and folders from the WinSxS folder on the system which builds the installer?
So to do this properly for my applications, should I include running the VC redist at the beginning of installation, or should I just copy the required files and folders from the WinSxS folder on the system which builds the installer?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Brilliant, thank you very much; you've been extremely helpful.
Anyway, for an application compiled without Unicode support, _tWinMain() and WinMain() are strictly equivalent.