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

问题描述

我正在用 Visual Studio C++ 编写一个程序，该程序需要在任何运行 Windows XP 32 位或任何更高版本的 Windows 操作系统的计算机上作为 32 位进程本机运行.该程序需要能够访问计算机上的 C:Windowssystem32 文件夹，无论该程序是在 64 位还是 32 位系统上运行.为此，我使用 Wow64DisableWow64FsRedirection 来禁用 Windows 通常对 32 位进程执行的重定向，将它们发送到 C:Windowssyswow64.不幸的是，这破坏了兼容性——虽然我的程序可以在 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:Windowssystem32 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:Windowssyswow64. 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 位 Windows 出现后引入的任何调用的情况下确定系统是 64 位还是 32 位.>

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屋！