我有一个我构建的EXE，我试图将其安装在Win7机器的程序文件(x86)文件夹中。这里发生了非常有趣的行为。该程序有一个gui-我们使用wx-Python和XRC来处理接口。我们在发行版中包含了一个XRC文件夹。该程序使用getcwd()来定位自身并查找xrc文件夹。然而，这真的很有趣——当我把程序放在程序文件中时，一切都很好。当我将程序放在program Files x86文件夹中时，我得到一条消息，告诉我它找不到xrc文件夹。
让我明确一下，这个应用程序在XP机器的程序文件中运行良好，在Vista机器和Win7机器的程序文件
现在还有什么有趣的是，如果我双击程序文件(x86)文件夹中的exe，它运行良好，但当我试图运行它的快捷方式添加到开始/程序菜单，它不能正确运行。这就是我得到错误消息的地方，提示程序没有找到xrc文件夹。我还把程序移到了桌面上的一个文件夹中，在根目录和其他任何位置，它都能正常启动和运行。因此，我确信指向xrc文件夹的代码是正确的。
回到问题上来。当程序从x86文件夹运行时，是否发生了导致路径引用变得混乱的事情?更重要的是，它是可以解决的吗?
最后一点注意-为了尽可能确定问题与xrc文件夹的路径有关，我从应用程序的两个实例中删除了xrc文件夹，我得到了与在x86文件夹中安装程序时收到的相同的错误消息。
只是为了澄清，程序不会运行的唯一时间是当我使用开始菜单上的快捷方式，exe和所有部分都保存在program Files (x86)文件夹
塑料刀的回答真的帮助我了解问题，我能够解决它。这不是Vista和XP的问题，而是32位操作系统和64位操作系统的问题。
我需要在64位XP和32位Win7上运行。
根据这个说明，Program Files (x86)文件夹是专门为32位程序文件准备的，而Program Files文件夹是为64位程序准备的。
但是为了让32位程序假装它在32位机器上，工作目录的名称必须返回为' program Files '，因为这是32位机器上的名称。这就是当您使用getcwd()向Windows请求工作目录时所看到的结果。由于您的程序试图在路径中使用该目录名，而这实际上不是真正的64位机器上的文件路径，因此它会中断。
查看WOW64文档，我怀疑它只有在从开始菜单启动时才会中断的原因是，这是一个64位进程创建32位进程的实例，这会导致系统更改ProgramFiles环境变量。在双击启动它的情况下，它从一开始就是一个32位进程。
看来你不是唯一一个遇到这种情况的人;这个Windows API似乎是专门设计来解决你所描述的问题的。如果没有别的，它表明你所看到的行为是经过设计的。
但这是学术性的。为了避免这种情况的发生，我会获取你的exe的绝对路径，使用类似os.path.realpath(__file__)的东西，然后从那里开始。