我有一个在 Windows 中注册的旧 Pascal/Delphi 应用程序 (#1)。它是一个 COM 组件可执行文件。我还有另一个旧的 Delphi 应用程序 (#2)，它调用该 COM 组件，已包装并声明了该组件的类型，并完成了进行调用所需的所有操作。效果很好。当然，这些都是 32 位应用程序。
我通过右键单击项目并添加 COM 引用，在 x86 目标（32 位）控制台应用程序中引用了相同的 COM 可执行文件 (#1)。我从 Windows 内注册的 COM 组件列表中选择了 COM 库（没有浏览到 #1 的 exe）。
这添加了类型并包装了 COM 组件，并允许我从 C# 控制台应用程序调用它。但是，它会失败，因为注册的 COM 组件正在 C:\Windows\SysWow64 中查找其配置文件，而不是在 COM 组件的程序文件目录中（同样，COM 组件是已安装的旧应用程序的可执行文件，#1） .
我运行进程监视器并观察另一个旧的 Delphi 应用程序 (#2) 调用 COM 组件，一切似乎都工作相同，除了当 COM 组件访问其配置文件时，它在“c:\program files”中查找它，其中它已安装（#1 的安装位置）。当我的应用程序调用它时，COM 组件尝试访问 c:\windows\syswow64 中的配置。在这种情况下，是什么导致了工作目录的差异？
正如 @Serg 提到的：Windows 由于 COM 调用而启动了一个新进程。结果我必须在进行 COM 调用之前手动启动该进程。一旦我这样做了，并设置了进程的工作目录，一切就按预期进行了。 ShellExecute 线索被深深地埋藏在 Delphi 应用程序的意大利面条代码中，直到我明确地去寻找它时我才看到它。
最后，这还要求我执行大量与检测、重用和终止进程相关的内务工作。正如人们所预料的那样，运行多个进程会导致问题。