应用软件开发的64 位WINDOWS 系统环境兼容性
1. 64 位CPU 硬件
目前的64位CPU分为两类:x64和IA64。x64的全称是x86-64,从名字上也可以看出来它和
x86是兼容的,原先的32位程序可以在x64上运行得很好,这也就是为什么在x64的CPU上
能够成功安装32位的Windows操作系统。现在市场上卖的家用电脑的CPU通常都是x64。
两家顶级CPU公司Intel和AMD分别推出了EM64T(Extended Memory 64 Technology)和
AMD64(Advanced Micro Devices 64)。这两款x64 CPU的指令集有很多相似之处,Intel追加
的大多数64位指令也与AMD64指令集相兼容,因此Microsoft就不用为两家公司的64位处
理器开发各自的64位操作系统。比如Vista x64和SQL2005 x64即可以在EM64T上运行,也
可以在AMD64上运行。
IA64是真正的64位CPU,指令集较x86有很大变化,它不兼容32位的程序。微软的很多产
品都不支持IA64 ,特别是面向个人用户的一系列产品。但是面向服务器的一些产品还
是有IA64版本的,比如Windows 2003,SQL server 2005等等。由于IA64没有x64这么普及,
所以本文中讨论的64位CPU如果不加特别说明,指的是x64。
CPU从32位发展到64位的最大的驱动力就是为了让内存突破4GB的限制。目前的操作系
统和应用软件都越做越大,4GB的限制成了软件发展的瓶颈。然而64位的到来一下子解
决了这个问题,让软件发展的前途一片光明。64位CPU使用64位来表示地址空间,也就
是2的64次方,是一个天文数字:16EB !这个范围就目前来看太大了,当前任何软件都
用不了这么多空间,所以AMD64 CPU目前的实现只用了64位中的48位来表示地址空间。
它们分为两块,一块是从00000000 00000000到00007FFF FFFFFFFF,还有一块是从
FFFF8000 00000000到FFFFFFFF FFFFFFFF,一共是256TB(如下图的左边),在Windows
下,低位的128T是给应用程序使用(User Mode),高位128TB是给系统使用(Kernel Mode)。
如果将来有需要的话,可以扩展成56位(如上图的中间),最终还可以使用全部的64
位(Full 64bit implementation),这样的话,虚拟内存空间将是2的64次方,共16 EB。将来
可以把大文件整个的映射到内存里,通常来说,这样会使文件的读写速度会比现在快很
多。
上面所说的是虚拟内存,在物理内存方面,AMD64目前的实现支持40位的物理内存,共
1 TB,这个系统架构以后可以扩展成52位,共4PB。
内存地址空间变成了64位,那也就是意味着寄存器也是64位。先来看看最具有代表性的
RAX寄存器。从16位时代的AX,到32位时代被扩展成EAX,现在扩展成64位的RAX,它们
之间的关系如图
RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP和RIP都从原来的32位(EAX, EBX, ECX等等)变成了64
位,并且还新增加了许多新的64位寄存器和128位寄存器。
2. 64位Windows系统的32位代码兼容性设计
WOW系统
能安装64位操作系统的机器,其CPU必然是64位的。根据IA64和X64架构的区别,
MS分别推出了支持IA64以及X64的WINDOWS操作系统,包括XP,VISTA,2003SERVER,
2008SERVER等。之前的32位程序要在64位系统上运行,除了CPU要兼容32位代码
(IA64采用软件模拟方式兼容IA32和X86指令,效率不高),在操作系统层面必
然也要有一定的措施进行兼容。由于IA64的系统并不常见,因此我们的讨论针对
X64架构的硬件和软件系统。
64位Windows为了兼容32位应用程序,微软采用了WOW64技术。WOW的全称是Windows
On Windows,前一个Windows指32位,后一个是64位,意思就是说在64位Windows上的
32位Windows。WOW技术的目的是兼容以前的32位应用程序,使得它们在64位 Windows
上运行结果和在32位Windows上运行结果一样。
在64位环境下,System32目录下存放的是64位DLL。为了能兼容32位应用程序,64位
Windows也提供了一整套32位的系统DLL。他们存放在Syswow64目录下。从名字上看有
点混淆:System32是放64位DLL的,Syswow64是放32位DLL的。在Windows x64环境中,
用32位的Task Explorer查看32位应用程序的进程,可以发现,相关联接的系统DLL基本上
都是在Syswow64目录下的。
如果使用64位的Task Explorer查看32位的程序,会发现多出了3个特殊的DLL:wow64,
wow64win和wow64cpu和一个64位的ntdll.dll。
其中64位的ntdll.dll是64位系统下WINDOWS进程都加载的系统DLL,主要提供相关的系
统调用的接口。另外三个DLL就是用来创建64位系统下的模拟32位系统环境。Wow64.dll
管理进程和线程的创建,截获异常分发处理(Exception Dispatching)和系统调用
(ntolkrnl.exe所暴露出来的系统调用),这个DLL还实现了文件系统重定向(File System
Redirection),注册表重定向(Registry Redirection),和注册表反射(Registry Reflection)。这
三种技术会在后面详细介绍。 Wow64cpu.dll管理wow里每个正在运行的线程的32位CPU
上下文,并且控制CPU在 32位模式和64位模式之间的切换。 Wow64win.dll截获GUI系统
调用,这些调用是Win32k.sys暴露出来的。 由此可以看出,在64位系统下得32位程序,
用到的系统内核是64位而不是32位的。
上面所说的三个DLL共同实现了在64位Windows上WOW技术。如下图。
在32位系统中,默认情况下,应用程序可以使用2G内存,另外2G是系统使用的;通过
修改配置,应用程序能使用3G内存,这时系统使用1G内存。在WOW64环境下,一个32
位应用程序能使用最多全部的32位地址空间:4G !只需要在编译程序的时候,设置
IMAGE_FILE_LARGE_ADDRESS_AWARE标志(/LARGEADDRESSAWARE开关),如果不打开这
个开关,就和原来一样,只能使用2G内存。
文件系统重定向器(File System Redirector)
在32位Windows上的程序访问system32目录里的DLL,这些DLL是32位的。在64位windows
中System32目录里是64位的DLL,所以32位程序在64位环境下需要另外一个目录作为它
system32目录,这个目录就是syswow64,WOW64提供了文件系统重定向器(File System
Redirector)。在WOW64环境下,32位程序访问system32目录里的文件,都会被重定向到
syswow64目录。比如在32位程序中想访问%windir%system32user32.dll,那它实际上访
问的是%windir%syswow64user32.dll。
重定向也有一些例外,下面这些目录是不需要被重定向的:
%windir%system32catroot
%windir%system32catroot2
%windir%system32driversetc
%windir%system32logfiles
%windir%system32spool
使用如下的一个小程序。先输出system32下的notepad.exe文件大小,再输出
system32driversetchosts的文件大小。然后调用WOW API:
Wow64DisableWow64FsRedirection把文件系统重定向器禁止掉,然后再次输出两个文件
的大小。
void PrintFileSize(PCWSTR wszFileName)
{
wprintf(L"%ls ", wszFileName);
HANDLE hFile = CreateFile(wszFileName, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, 0, NULL);
// Check hFile value. If opening file succeeded, print file size
wprintf(L"File Size: %d Bytes
", GetFileSize(hFile, NULL));
CloseHandle(hFile);
}
void wmain(int, WCHAR*)
{
PrintFileSize(L"c:\windows\system32\notepad.exe");
PrintFileSize(L"c:\windows\system32\drivers\etc\hosts");
PVOID pOldValue;
Wow64DisableWow64FsRedirection(&pOldValue); // disable redirection
PrintFileSize(L"c:\windows\system32\notepad.exe");
PrintFileSize(L"c:\windows\system32\drivers\etc\hosts");
Wow64RevertWow64FsRedirection(pOldValue); // restore redirection
}
程序编译成32位后,在64位Windows上运行的结果是:
可以看到在没有禁用文件系统重定向器之前,notepad.exe的大小是151040字节,禁用后
是169472字节,打开“我的电脑”到Syswow64目录下找到notepad.exe,它的大小是
151040,而system32下则是169472,虽然在程序中写的都是system32下的notepad.exe,
实际上访问的却是两个不同的文件。再看一下hosts文件,它在禁用前后的大小是一模一
样的761字节,说明它没有被重定向过,可以打开%windir%system32driversetc目录看
一下,hosts文件就是761字节。
注册表重定向器(Registry Redirector)
和目录重定向类似,注册表的一些键也需要重定向,它们是:
HKEY_LOCAL_MACHINESoftware
HKEY_USERS*SoftwareClasses
HKEY_USERS*_Classes
上面的星号(*)表示用户的SID(Security ID)。也就是说32位程序访问
HKEY_LOCAL_MACHINESoftwareXXX和64位程序访问
HKEY_LOCAL_MACHINESoftwareXXX是完全独立,不相关的。比如在32位程序在
HKEY_LOCAL_MACHINESoftware下新建了一个值ABC,64位程序在访问
HKEY_LOCAL_MACHINESoftware的时候会看不到这个ABC值。
再来做一个试验:64位Windows提供了两个版本的注册表编辑器(regedit.exe),一个版本
是32位的:%windir%SysWOW64
egedit.exe,另一个是64位的:%windir%
egedit.exe。
现在,先打开64位的注册表编辑器,在HKEY_LOCAL_MACHINESoftware下面新建一个键
aaa。
然后关掉64位的注册表编辑器(注意:必须关掉,不然32位的注册表编辑器无法打开),
打开32位的版本。发现HKEY_LOCAL_MACHINESoftware和64位的时候很不一样,而且看
不到aaa键。现在,再新建一个aaa2。
关掉32位版本,再打开原先的64位版本,可以发现HKEY_LOCAL_MACHINESoftware只有
aaa键,没有aaa2键。打开wow6432Node,会惊奇的发现原来aaa2在这里。实际上当32
位程序访问或修改注册表的键时,注册表重定向器把它们重定向到了wow6432Node键。
如果一个32位程序就想访问64位的注册表,或者64位程序想访问32位的注册表,在调用
注册表API:RegCreateKeyEx,RegDeleteKeyEx和RegOpenKeyEx的时候可以加上标志
KEY_WOW64_64KEY或者KEY_WOW64_32KEY。前者表明不管程序是32位或者64位,一律
访问64位的注册表,后者表明一律访问32位注册表。
和文件系统重定向相似,注册表重定向也有一些例外:
HKEY_LOCAL_MACHINESoftwareClasses
HKEY_LOCAL_MACHINESoftwareMicrosoftCOM3
HKEY_LOCAL_MACHINESoftwareMicrosoftEventSystem
HKEY_LOCAL_MACHINESoftwareMicrosoftOle
HKEY_LOCAL_MACHINESoftwareMicrosoftRpc
HKEY_USERS*SoftwareClasses
HKEY_USERS*_Classes
WOW64使用反射技术(Reflection)来处理这些例外情况。比如在32位程序在
HKEY_LOCAL_MACHINESoftwareClasses下新建了一个值 XYZ,这个值会立刻复制到64
位的HKEY_LOCAL_MACHINESoftwareClasses下面,所以当64位程序在访问
HKEY_LOCAL_MACHINESoftwareClasses的时候就能访问到一样的XYZ值。Windows还提
供了2个API来打开和禁用反射功能:RegEnableReflectionKey和RegDisableReflectionKey。
对于COM使用的注册表HKEY_LOCAL_MACHINESoftwareClassesCLSID,它十分特别,是
特例中的特例。在处理这个键时,注册表重定向器会做一个相对复杂点的判断:如果注
册的32位COM是local server(客户端和COM是两个独立的进程[5]),那注册的信息会被
反射到64位,如果是in-proc(COM是一个DLL,客户端在使用这个COM的时候会把DLL加
载到客户端进程[5]),那不会被反射。为什么需要这种判断呢?因为一个32位的local
server COM是运行在一个独立的进程中,它即能够被32位程序调用,也能被64位程序调
用。但是32位in-proc COM的话是需要把这个32位DLL载入到64位进程中去,这是做不到
的,也就是说32位in-proc COM无法为64位程序提供服务,那也就没有必要把它的注册表
信息反射到64位了。
驱动程序和系统服务
对于驱动程序,64位系统只支持64位的驱动程序,因此对于代码中有驱动或者系统服务
的情况,必须重新编译成64位的可执行代码,并且由于64位系统有强制的签名验证,未
签名的驱动只能在开启调试状态的模式下加载。
3. 64 位编程代码注意事项(C++)
与JAVA 等依靠虚拟机解释运行的程序不同,C/C++代码通常被编译成机器码执行,虽然
提供了更快地速度和更强的功能,但也带来很多代码兼容性的问题。
数据类型
C++数据类型的变化,从下面的表格中可以看到:char, short, int, long, float, double 在64
位Windows 环境下的大小没有变化,但是size_t, time_t 和指针的大小都从32 变成了64
位,8 个字节。
Type Name x86 x64 windows
char 8 8
short 16 16
int 32 32
long 32 32
float 32 32
double 64 64
size_t 32 64
在Windows 下,一些数据类型也发生了变化,这里列举了一些最常用的类型。WPARAM,
LPARAM, LRESULT 和各种HANDLE(比如HWND, HKEY 等等)本质上都是指针,所以他们都
变成了64 位。
typedef UINT_PTR WPARAM;
typedef LONG_PTR LPARAM;
typedef LONG_PTR LRESULT;
typedef void *HANDLE; #define DECLARE_HANDLE(name) struct
name##__ { int unused; }; typedef struct name##__ *name
DECLARE_HANDLE(HWND); DECLARE_HANDLE(HKEY);
我们在32位CPU下编写的正确代码,到了64位下可能会出问题,这些问题通常只能通过
人工逻辑来逐个判断修改。
特殊数字兼容性
如果程序里出现了下列这些数字,有可能需要再检查一遍代码,看看有没有问题。
4:32位时代一个指针的字节数
32:32位时代一个指针的位数
0x7fffffff:32位有符号整数的最大值,有时用来进行位操作(与、或、异或)
0x80000000:32位有符号整数的最小值
0xffffffff:32位无符号整数的最大值。同时也是有符号整数-1,通常会被用来作为出错值,
或者无效值。
还有其他一些情况无法一一列举,但是在编成的时候利用SDK中定义的一些宏往往能避
免这些问题。
整数保存在双精度浮点数中
下面的程序, 32位中a等于c,但在64位中a就不等于c了
size_t a = -1;
double b = a;
a--;
b--;
size_t c = b; // x86: a == c
// x64: a != c
原因就是双精度类型 double 一共有 64 位(不管是 32 位环境还是 64 位环境),根据
IEEE-754, double 用1 位表示数字的符号,用 11 位表示指数,52 位表示尾数。尾数
也就是所能表示的数字的精度。尾数的位数越多,所能表示的数字的精度越高。32 位(x86)
时代的size_t 是32 位,有52 位尾数的double 类型能绰绰有余的精确表示size_t。但是
到了64 位时代,size_t 是64 位,这时double 的52 位尾数没有办法精确表示size_t,所
以导致了a 不等于c。所以在64 位环境中,尽量不要将整数保存在双精度浮点数中。
特别小心位移操作
看下面这段代码,想想i分别会是什么值。(__int64是64位有符号整数)
__int64 i;
i = 1 << 31; // i = ?
i = 1 << 32; // i = ?
您可能会认为一个是0x00000000 80000000,另一个是0x00000001 00000000。实际上在
第二行运行后i是0xffffffff80000000;第三行运行后i是0x0000000000000000,为什么呢?
编译器在处理1<<31的时候是按照32位整型来处理,得到的结果是0x80000000,由于i是
64位有符号整数,在赋值操作的时候,把0x80000000,就转成了0xffffffff 80000000。同
样,第三行的1<<32也是按照32位整型来处理的时候,得到的是0,所以把32位整数0转
成64位整数后还是0。正确的写法应该如下,先把1转成64位,这样在位移操作的时候已
经是64位了。
__int64 i;
i = __int64(1) << 31;
i = __int64(1) << 32;
5.不要混合使用32 位类型和64 位类型
对于此要点,大家需要特别注意,一般的测试比较难发现这个问题,因为它在数字较小
的情况下,一切正常,一旦数字变大,则会出现严重的错误。先来看下面一段代码,想
想有什么不正确的地方。
size_t Count = SomeValue;
for (unsigned Index = 0; Index < Count; ++Index)
{ ... }
前面说过size_t在64位环境下是64位,unsigned在64位环境下还是32位,如果Count是一
个很大的数字,超过了32位无符号整数的最大值,那条件Index <count永远成立,导致了
死循环。正确的写法应该是把Index也申明成size_t类型,和Count一致。
再看下面这个例子。
int x = 100000;
int y = 100000;
int z = 100000;
__int64 r1 = x * y * z; // -1530494976
__int64 r2 = __int64(x) * y * z; // 1000000000000000
__int64 r3 = x * y * __int64(z); // 141006540800000
如果.NET程序使用了32位的in-proc COM,在编译的时候需要指定它的目标平台为x86
.NET 1.0和.NET 1.1没有64位版本,但是从.NET 2.0开始提供了x64版本。C#,VB.NET等.NET
语言的程序在编译的时候默认的目标平台(Platform target)是Any CPU,意思是如果运行
环境是32位的,那么按照32位应用程序运行,如果在64位Windows上运行,则按照64位
应用程序运行。
回想一下“注册表重定向器”里提到的:64 位应用程序没有办法得到32 位in-proc COM的
注册信息。也就是没有办法使用这个 COM。所以如果.NET 程序使用到了 32 位 in-proc
COM,那就不要使用默认的“Any CPU”选项,我们应该指定它为x86。要不然您的程序在
x64 的Windows 环境下,将无法调用这个COM。下图是Visual Studio Orcas 的C#工程属
性。
"Detect 64-bit Portability Issues"编译开关
VisualStudio 里面的“Detect 64-bit Portability Issues”编译开关。这样,编译器可以帮您发
现大多数的 64 位问题。虽然打开这个开关会稍微增加一些编译时间,但是绝对值得这
么去做。
代码检查(Code Review)
这是最重要的一点,前面所说的这些要点能覆盖大多数的问题,但不是全部。所以在写
完代码后,一定要做检查,最好找别人帮您检查。像微软和其他知名的软件公司都十分
重视代码检查,不经别人检查的代码是不允许提交的。
让我们用一个例子来结束这篇文章,请看下面这段32位时代的代码
PVOID p;
..........
int n = int(p);
..........
p = PVOID(n);
如果把这段代码移植到64位,很多人会写成这样:
PVOID p;
..........
__int64 n = __int64(p);
..........
p = PVOID(n);
http://www.freedocuments.info/7522137270/