32位Windows XP上的Wow64DisableWow64FsRedirection [英] Wow64DisableWow64FsRedirection on 32-bit Windows XP

问题描述

我正在用Visual Studio C ++编写一个程序，该程序需要在32位Windows XP或任何更高版本的Windows操作系统上以32位进程本机运行。该程序需要能够访问计算机上的 C：\Windows\system32\ 文件夹，而不管该程序运行在64位还是64位上。 32位系统。为此，我使用了 Wow64DisableWow64FsRedirection 来禁用Windows通常对32位进程执行的重定向，并将其发送到 C：\Windows＼ ＼syswow64 。不幸的是，这破坏了兼容性-尽管我的程序可以在Server 2003和XP x64版本上运行，但是只要在32位XP RTM系统上运行，该程序就会失败，这是我的错误：

I'm writing a program in Visual Studio C++ which needs to run natively as a 32-bit process on any computer running Windows XP 32-bit, or any later Windows operating system. This program needs to be able to access the C:\Windows\system32\ folder on a computer, regardless of whether the program is running on a 64-bit or 32-bit system. To do this, I was using Wow64DisableWow64FsRedirection to disable the redirection that Windows typically does to 32-bit processes, sending them to C:\Windows\syswow64. Unfortunately, this breaks compatibility -- though my program can run on Server 2003 and XP x64 edition, the program fails whenever it runs on a 32-bit XP RTM system, giving me this error:

[Program Name] - Entry Point Not Found
  The procedure entry point Wow64DisableWow64FsRedirection could not be located
  in the dynamic link library KERNEL32.dll.

由于系统是32位的，因此通话显然是多余的，但我不知道一种在运行时确定系统是否为64位以及是否跳过该调用而无需添加另一个本身破坏兼容性的调用的方法，例如 IsWow64Process（），它需要XP Service Pack 2。

Since the system is 32-bit, the call is obviously superfluous, but I can't figure out a way to determine at runtime whether a system is 64-bit or not, and therefore whether or not to skip the call, without adding another call that itself breaks compatibility, such as IsWow64Process(), which requires XP Service Pack 2.

tl; dr：如何确定系统是64位还是32位位，而不使用在64位消费者Windows出现之后引入的任何调用。

tl;dr: How can I determine whether a system is 64-bit or 32-bit without using any of the calls that were introduced after the advent of consumer 64-bit Windows.

推荐答案

继续使用 Wow64DisableWow64FsRedirection ，但不要静态导入。而是使用动态绑定（ GetProcAddress ）或延迟加载，这两种方法都可以使您处理丢失的函数而不会崩溃（或更糟糕的是，甚至无法启动，这是当前的）

Go ahead and use Wow64DisableWow64FsRedirection, but don't import it statically. Instead use either dynamic binding (GetProcAddress) or delay-loading, either of which allow you to handle a missing function without crashing (or worse, not even starting, which is the current case).

而且不用担心系统的位问题。如果存在该函数，则调用它。

And just don't worry about the system bitness. If the function is present, call it.

typedef BOOL WINAPI fntype_Wow64DisableWow64FsRedirection(PVOID *OldValue);
auto pfnWow64DisableWow64FsRedirection = (fntype_Wow64DisableWow64FsRedirection*)GetProcAddress(GetModuleHandleA("kernel32.dll"), "Wow64DisableWow64FsRedirection");

if (pfnWow64DisableWow64FsRedirection) {
   // function found, call it via pointer
   PVOID arg;
   (*pfnWow64DisableWow64FsRedirection)(&arg);
}
else {
   // function was missing
}

现在，链接器将找不到名为 Wow64DisableWow64FsRedirection 的未解析符号，因此它不会将该函数放在导入表中，Windows也不会查找为此，请在流程启动期间进行。

Now the linker won't find an unresolved symbol named Wow64DisableWow64FsRedirection, so it won't put that function in the import table, and Windows won't go looking for it during process startup.

这篇关于32位Windows XP上的Wow64DisableWow64FsRedirection的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！