如何检查应用程序是否从\program files\运行
是否有可靠的方法来检查应用程序是否从程序文件下的某个位置运行？
如果用户将应用程序安装到本地计算机上的程序文件中，我们需要将可写文件放在其他地方以避免Vista和Win7上的虚拟化。但是，当安装到网络磁盘时，我们希望在安装时保留这些文件，以便在用户之间共享访问。
今天我们对启动路径和 CSIDL_PROGRAM_FILES 进行字符串比较，但有些东西告诉我这是一个非常不可靠的方法。
有什么聪明的解决方案吗？ 是否有我不知道的 'IsRunningFromProtectedFolder( )'-api？ 是否有其他文件夹会出现与程序文件相同的问题？
Is there a reliable method to check if an application is run from somewhere beneath program files?
If the user installs the application to program files on local machine, we need to put writable files somewhere else to avoid virtualization on Vista and Win7. When installed to a network disk, though, we want to keep these files with the installation for shared access among users.
Today we do an string comparison between startup path and CSIDL_PROGRAM_FILES, but something tells me this is a very unreliable method.
Any smart solution out there?
Is there a 'IsRunningFromProtectedFolder( )'-api that I do not know about?
Are there any other folders giving the same problems as program files do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这不是一个非常好的主意，因为用户可以将其安装在任何他们想要的地方，然后检查可能会失败。相反，当用户安装应用程序时有一个复选框，决定它是安装在本地还是服务器上。
This is not a terribly good idea, as a user can install it wherever they want to, and then the check might fail. Instead have a checkbox when the user installs the app, deciding if it is installed locally or on a server.
正如你一样，我也发现了处理 UAC 文件夹虚拟化的问题。我建议一个解决方法，看起来它应该有效。
它来自这样的假设：提升的进程始终使用原始副本而不是虚拟化副本 (CMIIW)。另外，我假设您的安装程序已提升执行，
其想法是创建一个“常规”进程（非提升，遗留），您的主安装程序应该运行。此过程将在用户选择的文件夹中创建一个文件名，其名称和内容都是您的程序都知道的（例如，test73819704.bin）。如果文件夹虚拟化，则该文件应出现在用户 VirtualStore 中，而不应出现在原始文件中（从安装程序的角度和权限来看）。
因此，对于选择的 C:\Program_Files_But_Not_Necessarily 和 Process-1（提升）
不幸的是我现在无法测试它，但我想它应该可以工作，并且这背后有一个逻辑，使用 Process-2 你只需模拟主程序的行为）
As you I also found problems dealing with UAC folder virtualization.I suggest a workaround, it seems that it should work.
It comes from the assumption that elevated processes always use original copies and not the virtualized ones (CMIIW). Also I assume that you setup processed was executed elevated
The idea is to create a "general" process (non-elevated, legacy), that your main installer should run. This process will create a file name in the user chosen folder with a name and contents that both your programs know (for example, test73819704.bin). If the folder virtualized, this file should appear in the user VirtualStore and SHOULD NOT in the original one (from the point of view and privileges of the installer).
So for chosen C:\Program_Files_But_Not_Necessarily and Process-1 (elevated)
Unfortunately I could not test it right now, but I guess it should work and there's a logic behind this, with Process-2 you just emulate the behavior of your main program )
我们允许用户在任何地方安装...
如果用户采用默认值并安装在程序文件中，我们假设需要写入文档和设置/用户。否则，我们将数据写入软件所在目录下的文件夹中。这当然仍然会导致问题，并且安装确实允许人们选择不同的数据位置（如果他们选择不使用默认值）。
最重要的是，这是一个简单的 ini 文件更改和一个用于移动数据的副本。
启动时，我们通过将从 SHGetFolderPath(CSIDL_PROGRAM_FILES) 获得的值与可执行文件所在路径的开头进行比较来检测是否位于 Program Files 目录中。
We allow our users to install anywhere...
If the user has taken the default, and is installed in Program Files, we make the assumption that we need to write to Documents and Settings/Users. Otherwise, we write our data to a folder under the directory the software is in. This of course can still cause problems, and the install does indeed allow people to choose a different data location if they choose to not go for the default.
On top of that, it's a simple ini file change and a copy to move the data.
On start up we detect if we are in the Program Files directory by comparing the value we obtain from SHGetFolderPath(CSIDL_PROGRAM_FILES) with the start of the path the executable is in.