For MS Compiler experts: Dann C and ...

[CRoberson]

I compiled Telpath and the binary runs on:
o my laptop Win XP Pro SP 3
o my dual AMD 2000+ Win XP Pro SP2

But it does not run on a Pentium M laptop with
WinXP Pro SP2.

My first thought was something like SSE extensions ...
However, I didn't find any compile or link options to
set or unset that. The only hw option was machine type
which is set to MACHINE:X86.

The compiler is Visual C++ 2005 express.

[Dann Corbit]

If you did not set the C/C++ "Code Generation" property "Enable Enhanced Instruction Set" then I suspect it is a case of undefined behavior when your program runs on one machine but not on another.

Splint may be helpful for a C program or Gimpel Lint for a C++ program to track the problem down. Also runtime checkers like the DUMAS memory profiler and BoundsChecker may prove helpful to isolate the issue. Turn your warnings up to level 4 for the MS compiler and it may help to spot something.

There are rare cases when a compiler actually emits a bad instruction. But those cases are extrememly rare.

[CRoberson]

Thanks for the response Dann.

Trying to run the binary via command line in a cmd box.

As soon as return is hit we get:
"the system cannot run the specified program"

Is that message more meaningful to you than it is to me?

[sje]

Trying to run the binary via command line in a cmd box.

As soon as return is hit we get:
"the system cannot run the specified program"

Is that message more meaningful to you than it is to me?

It means "Please install Linux and try again."

Also, "You are missing some DLLs but I'm not going to tell you which ones."

[Dann Corbit]

Thanks for the response Dann.

Trying to run the binary via command line in a cmd box.

As soon as return is hit we get:
"the system cannot run the specified program"

Is that message more meaningful to you than it is to me?

Get Depends from here:
http://www.dependencywalker.com/

and run it on the binary. I guess that you did a build that uses the DLL runtime (if you link against the static libraries you will not have that problem). You can send the runtime DLLs with the binary, but that will cause problems too (e.g. the wrong DLL files might be someplace earlier in the path).

[Dann Corbit]

Look at Configuration Properties "C/C++", "Code Generation", "Runtime Library" and make sure it is set to "Multi-Threaded /MT and NOT set to "Multi-Threaded DLL /MD"

[CThinker]

Trying to run the binary via command line in a cmd box.

As soon as return is hit we get:
"the system cannot run the specified program"

Is that message more meaningful to you than it is to me?

It means "Please install Linux and try again."

Also, "You are missing some DLLs but I'm not going to tell you which ones."

It is not the fault of the OS that a DLL is missing. In Linux, this is a common issue:
ImportError: libstdc++.so.5: cannot open shared object file: No such file or directory

Windows bashing is uncalled for.

[CThinker]

Thanks for the response Dann.

Trying to run the binary via command line in a cmd box.

As soon as return is hit we get:
"the system cannot run the specified program"

Is that message more meaningful to you than it is to me?

If the issue is indeed a missing DLL, you can run the "Depends" tool that comes with your Visual Studio installation. That will tell you what DLL's are being linked and whether or not they can be found on the machine.

You can avoid dependencies on the runtime DLL by simply specifying a static linking of the runtime library:

In your project properties, under "Configuration Properties" - "C/C++" - "Code Generation" - "Runtime library", select "Multi-threaded (/MT)" or "Multi-threaded Debug (/MTd)". Avoid any of the DLL options.

Another possible cause is that you are distributing the manifest file. It maybe trying to validate your application. If so, simply delete the manifest file and just run the EXE.

[Robert Pope]

Yeah, when I've seen that, it was because I was trying to run it on a computer without Visual Studio installed. If you change your switches from MD to MT, your executable gets bigger, but it runs on all machines.

[CRoberson]

Thanks guys. That was the problem - it was on /MD and changed it
to /MT.