1

EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!

We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.

We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.

Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.

The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.

The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Thadeux
  • 146
  • 1
  • 8
  • What exactly do you mean by 'unusable'? What's the difference in behavior? – Michael Burr Jun 29 '11 at 14:15
  • I can think that running from windows explorer, the stdout and stdin would be different than running from the console. – Vinicius Kamakura Jun 29 '11 at 14:57
  • The osg viewer does not reproduce the scene correctly. It has artifacts and mangled colors. Basically, what you'd expect with a driver issue. However, the program works fine if run from a double clicked batch file right next to the exe. – Thadeux Jun 29 '11 at 14:58
  • Does it work differently if you use the `start` command to start the app? – Mark Ransom Jun 29 '11 at 16:14
  • Yes, we were hoping this would give us the explorer behavior, because it uses ShellExecute, but it still gave us the cmd.exe behavior. :/ – Thadeux Jun 29 '11 at 16:17
  • Doing some more tests, our release build from CCNet works fine - it's extracted to desktop. WinMerge tells us that all supporting files between the CCNet/bin and developer's /bin are identical. However, running from the CCNet build works, while running from the developer's build does not. – Thadeux Jun 29 '11 at 18:22

4 Answers4

1

To rule out potential library load path issues, try using dot-local DLL redirection.

Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)

More details on dot-local redirection here, for example.

Mihai Limbășan
  • 64,368
  • 4
  • 48
  • 59
0

This thread looks like it might have the answer to your question:

http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html

In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?

kand
  • 2,268
  • 6
  • 31
  • 43
  • There's been a lot of head scratching, making sure that the executable we're running is the same, and then more head scratching. It really seems like there is some difference between how windows loads the executable in either case. I was hoping there would be a way to force explorer to load the exe from a command prompt in that thread, but I didn't find it... – Thadeux Jun 29 '11 at 15:06
0

You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.

Setup the QTDIR environmental variable.

1) Create a new System variable called: QTDIR a. Right click on My Computer -> Properties -> Advanced Tab -> Environment Variables button b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No trailing '\' character!!!)

Now, add the QTDIR on to your PATH variable.

1) Edit your PATH variable, add onto the end of it a ';' if one isn't already on the end. 2) Now add on: %QTDIR%\bin;

Example:

Before PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; After, PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;

That will make sure that our Qt application(s) will be able to find the Qt DLL files when you go to run it.

I hope this helps.

O.C.
  • 6,711
  • 1
  • 25
  • 26
  • The required binaries are next to the executable in the same directory. All the Qt and Osg ones. It's possible there is some confusion between environment variables causing different versions of dlls to be used in either case, but that means that windows uses a different set of environment variables between loading from explorer and loading from a cmd.exe. :/ – Thadeux Jun 29 '11 at 15:08
  • 1
    Well, it does. A process normally inherits the environment of its parent. You've got different parents. If you've used the SET command in the command line then this won't affect the environment of Explorer. – Hans Passant Jun 29 '11 at 16:34
0

Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.

I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.

There is an interesting community note on the ShellExecuteEx page that may or may not be applicable: ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.

I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).

sean e
  • 11,792
  • 3
  • 44
  • 56