从 Windows 命令提示符运行可执行文件与从 Windows 资源管理器运行可执行文件有何区别？
编辑：这是由于愚蠢。这是一个多显示器问题。只是从 cmd.exe 中我们总是在主监视器中打开，而从资源管理器中我们总是在辅助监视器中打开。感谢大家的帮助！
我们最近遇到了一个奇怪的错误。我们有一个 Qt + osg 应用程序，如果我们从资源管理器运行它，它的行为与从命令行运行它不同。从资源管理器运行是不可用的，而从命令行运行（或通过从资源管理器运行一个调用 .exe 的简单批处理文件）可以按预期工作。
我们怀疑环境变量，因为我们能想到的只有这些。但它在单行批处理文件中运行良好的事实似乎反驳了这一点。我对 Windows 不太熟悉，不知道它如何加载可执行文件的任何细微差别，也不知道在哪里可以找到答案。
还有其他差异可以解释这一点吗？ Windows 是否在每种情况下加载不同的用户环境变量集？操作系统是 Windows XP Service Pack 3。
从资源管理器（双击 program.exe）运行时遇到的行为与驱动程序问题或不正确的 OSG 场景设置一致：图像伪影、闪烁和奇怪的颜色。
从 cmd.exe 运行相同的可执行文件（或双击仅包含一行的 .exe 旁边的 .bat 文件来运行 .exe）时所经历的行为是正确的、预期的行为：场景正确，没有闪烁， ETC。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
要排除潜在的库加载路径问题，请尝试使用点本地 DLL 重定向。
为此，在与可执行文件相同的目录中创建一个（空）文件，并为其指定与二进制文件相同的名称，但附加
.local除外。即，如果您的二进制文件名为yourbinary.exe，则将该文件命名为yourbinary.exe.local。这将迫使 PE 加载程序首先在该目录中查找以解析 LoadLibrary 调用（其中包括通过系统 DLL 或通过 COM 间接加载的 DLL，无论涉及多少个间接级别。）放置尽可能多的支持 DLL（包括 Qt DLL）在该目录中。如果您使用 Qt 插件，还可以将plugins目录放在那里（或使用自定义trolltech.conf。）有关点本地重定向的更多详细信息 此处，例如。
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
.localappended. I.e., if your binary is namedyourbinary.exe, name that fileyourbinary.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 thepluginsdirectory there (or use a customtrolltech.conf.)More details on dot-local redirection here, for example.
该线程看起来可能可以回答您的问题：
http: //forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
简而言之，我认为它可能会在不同的地方寻找您的可执行文件，具体取决于您尝试使用哪种方法来运行它。也许您有 2 个不同的版本隐藏在资源管理器使用的某个地方，而不是您想要的版本？
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?
你没有提供足够的细节，所以我只能给你一个笼统的答案。为了使用 QT 及其工具，您需要 2 个环境变量。 *QTDIR 和 PATH * 确保您已设置这些变量，说明如下。我从此网站获取它们。另请参阅此链接了解 Windows 上的部署。
我希望这有帮助。
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.
I hope this helps.
也许资源管理器启动可执行文件的方式与直接从控制台运行它的方式有所不同。我认为资源管理器使用 ShellExecute 或ShellExecuteEx 我怀疑从控制台或批处理文件执行应用程序会产生相同的效果。
我将创建一个测试应用程序，尝试一些 ShellExecute 变体并使用不同的参数来查看是否可以重现资源管理器行为，以便尝试诊断传递给 ShellExecute 的哪些参数可能会导致问题。
ShellExecuteEx 页面上有一个有趣的社区注释，可能适用，也可能不适用：
ShellExecuteEx 忽略当前输入桌面。它始终使用winsta0\default。相反，请使用 ShellExecute 或 CreateProcess。我还会调查 AppCompatFlags 是否影响控制台执行应用程序（或查看是否已为您的应用程序设置了任何 AppCompatFlags）。
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).