我正在运行Windows 7x64和Excel 2010x32。我使用ExecCmd（一个等待命令提示过程完成的Microsoft函数）通过vba调用32位dos程序（用Fortran编写）。我向此函数发送一个命令行，该命令行显式包含程序路径以及输入文件和输出文件的路径。
这在我的电脑和运行相同软件（操作系统和办公室）的公司电脑上运行良好，并且我可以通用访问C：驱动器。
在没有对C：驱动器进行一般访问的其他公司PC上，这不起作用 - 即dos程序不生成输出文件。在这些PC上，我仍然可以在命令提示符下手动运行程序。只是调用此命令提示符不能通过Excel VBA工作。
现在奇怪的是，我可以通过在命令行的开头添加“cmd.exe / c”来成功运行其中一个程序。这似乎是在命令提示符（！）中运行命令提示符。另一个程序（顺便提一下，它相当大）在这些PC上通过vba完全不起作用。我需要能够为其他员工提供有用的东西。
任何人都可以对这里发生的事情有所了解并建议解决一下吗？我可以通过一些代码，但我认为上面的内容应该是自我解释的。
答案 0 :(得分：4)
您将命令shell与控制台窗口混淆。在这种情况下，区别至关重要。
控制台模式程序（又名“命令行程序”）需要一个控制台窗口来提供输入和输出。从GUI程序启动控制台模式程序时，Windows会自动为其创建一个控制台窗口（除非另有说明）。
命令shell（又名“命令提示符”）是cmd.exe，一个控制台模式程序。
这里重要的一点是，并非每个控制台窗口都有一个cmd.exe个实例在其中运行。当从GUI程序启动控制台模式程序时，Windows会自动创建一个控制台窗口，但不会自动创建cmd.exe的实例。如果要将命令传递给cmd.exe，则必须自己执行此操作，或使用运行时库例程为您执行此操作。
ExecCmd不这样做;它直接运行程序。因此，将cmd /c <command>传递给ExecCmd并不是“在命令提示符下运行命令提示符”。如果没有cmd /c您没有运行命令shell命令，那么您只需启动可执行文件。
您可能需要将命令传递给命令shell的原因有很多。例如：
它可能是一个内置命令，如dir或type，它只存在于命令shell中;
它可能包括重定向或流水线操作符，或环境变量替换;
它可能是一个脚本而不是一个可执行文件。
还有其他案例。如果您向我们展示传递给ExecCmd的命令行，我们可能会提供更具体的建议。 （同一命令行显然在某些机器上工作这一事实令人费解，但如果没有更多信息就无法解决。）