64,648
社区成员
发帖
与我相关
我的任务
分享什么样的32bit程序不能直接在64bit os上通过WOW64模拟运行？
有什么特定条件的32bit程序不能直接在64bit os上通过WOW64模拟运行？
请告知，谢谢。
请告知，谢谢。
...全文
请发表友善的回复…
发表回复
qubo 2008-03-27
- 打赏
- 举报
全部的32bit程序都能直接在64bit os上通过WOW64模拟运行，这样理解正确吗？
有不能运行的特例吗？
有不能运行的特例吗？
jixingzhong 2008-03-27
- 打赏
- 举报
分析模拟的过程，自己总结
貌似没有看到类似的“龟腚”出现
貌似没有看到类似的“龟腚”出现
星羽 2008-03-27
- 打赏
- 举报
星羽 2008-03-27
- 打赏
- 举报
转
以高阶语言编写的应用软件，从 32 位架构转换到 64 位架构的各种困难。一个共同的问题是，部分程序员假定指针如同其它数据型态一样有相同的长度。程序员假定他们可以在数据型态之间传送数量而不遗失信息。这些假定只在一部分 32 位机器上如此（甚至是一部分 16 位机器），不过在 64 位机器上就不再如此。C 语言及其后代 C++ 尤其容易产生这种错误[1]。
要在 C 和 C++ 中避免这种错误，如果确定原始类型的大小为所需的基础，sizeof 操作符可用来确定原始类型的大小，无论是在编译以及执行时期。此外，在 C99 标准中的 <limits.h> 表头，以及在 C++ 标准中的 <limits> 表头的 numeric_limits 类，可提供更多有用的信息；sizeof 只返回字符大小。这个用法使人产生误解，因为一个字符（CHAR_BITS）的大小是由自身决定，在所有的 C 或 C++ 实作中并未以相同方式定义。然而，除了这些编译器目标 DSP 以外，“64 位 = 8 字符（每一字符有 8 位）”已成标准。
必须谨慎使用 ptrdiff_t 型态（在标准表头 <stddef.h> 中）两个指针相减的结果；太多代码宁可不正确的使用“int”或“long”。表示一个指针（而不是指针差异）为一个整数，在此可以使用 uintptr_t（它只定义在 C99 中，不过某些编译器另外集成较早版本的标准以提供之，作为一个扩充）。
C 和 C++ 并未定义指针、整数型（int）、长型（long）为特定的位数目。
在主要的 32 位机器程序设计环境中，指针、“int”变量、“long”变量全部都是 32 位长。
然而，在 64 位机器下的许多程序设计环境，“int”变量仍然是 32 位宽，不过“long”和指针是 64 位宽，上述内容称为 LP64 数据模型。另一个选择是 ILP64 数据模型，三种数据型态都是 64 位宽，甚至 SILP64 连“short”变量也是 64 位宽。然而，大多数情况下所需的修改是相对次要且简单，而且许多编写良好的程序可以简单的重新编译给新的环境，而无须修改。另一个选择是 LLP64 模型，其维持 32 位代码的兼容性，使 int 和 long 为 32 位。“LL”指“long long”型态，其在所有平台下至少是 64 位，包括 32 位环境。
今天有许多 64 位编译器使用 LP64 模型（包括 Solaris、AIX、HP、Linux、Mac OS X、IBM z/OS 本地编译器）。微软的 VC++ 编译器使用 LLP64 模型。其缺点是在 LP64 模型中将 long 存放到 int 可能会溢出。另一方面，还会使强制转型一个指针为 long 可以作用；在 LLP 模型下，情况则刚好相反。两者皆不应该出现在合乎 C99 的代码中。
注意，程序设计模型是在预编译器底层选择的，且数个模型可共存于同一操作系统。然而一般由 OS API 选择程序设计模型作为原始模型。
另一个考量是用于驱动程序的数据模式。在现代的操作系统中，驱动程序弥补了大多数的操作系统代码（尽管许多代码可能不会加载，当操作系统执行时）。许多驱动程序大量使用指针操控数据，且在某些情况下必须读入一定大小的指针进入支持 DMA 的硬件。举个例子，提供给 32 位 PCI 设备的驱动程序，请求设备的 DMA 数据进入 64 位机器内存的较高区域，可能无法满足来自操作系统从设备到大于 4 GB 内存读入数据的要求。因为对于这些地址的指针，将不适合设备的 DMA 寄存器。这个问题可如下解决，当向设备发出 DMA 请求时，OS 采用与设备相符的内存限制，或者使用 IOMMU。
以高阶语言编写的应用软件，从 32 位架构转换到 64 位架构的各种困难。一个共同的问题是，部分程序员假定指针如同其它数据型态一样有相同的长度。程序员假定他们可以在数据型态之间传送数量而不遗失信息。这些假定只在一部分 32 位机器上如此（甚至是一部分 16 位机器），不过在 64 位机器上就不再如此。C 语言及其后代 C++ 尤其容易产生这种错误[1]。
要在 C 和 C++ 中避免这种错误，如果确定原始类型的大小为所需的基础，sizeof 操作符可用来确定原始类型的大小，无论是在编译以及执行时期。此外，在 C99 标准中的 <limits.h> 表头，以及在 C++ 标准中的 <limits> 表头的 numeric_limits 类，可提供更多有用的信息；sizeof 只返回字符大小。这个用法使人产生误解，因为一个字符（CHAR_BITS）的大小是由自身决定，在所有的 C 或 C++ 实作中并未以相同方式定义。然而，除了这些编译器目标 DSP 以外，“64 位 = 8 字符（每一字符有 8 位）”已成标准。
必须谨慎使用 ptrdiff_t 型态（在标准表头 <stddef.h> 中）两个指针相减的结果；太多代码宁可不正确的使用“int”或“long”。表示一个指针（而不是指针差异）为一个整数，在此可以使用 uintptr_t（它只定义在 C99 中，不过某些编译器另外集成较早版本的标准以提供之，作为一个扩充）。
C 和 C++ 并未定义指针、整数型（int）、长型（long）为特定的位数目。
在主要的 32 位机器程序设计环境中，指针、“int”变量、“long”变量全部都是 32 位长。
然而，在 64 位机器下的许多程序设计环境，“int”变量仍然是 32 位宽，不过“long”和指针是 64 位宽，上述内容称为 LP64 数据模型。另一个选择是 ILP64 数据模型，三种数据型态都是 64 位宽，甚至 SILP64 连“short”变量也是 64 位宽。然而，大多数情况下所需的修改是相对次要且简单，而且许多编写良好的程序可以简单的重新编译给新的环境，而无须修改。另一个选择是 LLP64 模型，其维持 32 位代码的兼容性，使 int 和 long 为 32 位。“LL”指“long long”型态，其在所有平台下至少是 64 位，包括 32 位环境。
今天有许多 64 位编译器使用 LP64 模型（包括 Solaris、AIX、HP、Linux、Mac OS X、IBM z/OS 本地编译器）。微软的 VC++ 编译器使用 LLP64 模型。其缺点是在 LP64 模型中将 long 存放到 int 可能会溢出。另一方面，还会使强制转型一个指针为 long 可以作用；在 LLP 模型下，情况则刚好相反。两者皆不应该出现在合乎 C99 的代码中。
注意，程序设计模型是在预编译器底层选择的，且数个模型可共存于同一操作系统。然而一般由 OS API 选择程序设计模型作为原始模型。
另一个考量是用于驱动程序的数据模式。在现代的操作系统中，驱动程序弥补了大多数的操作系统代码（尽管许多代码可能不会加载，当操作系统执行时）。许多驱动程序大量使用指针操控数据，且在某些情况下必须读入一定大小的指针进入支持 DMA 的硬件。举个例子，提供给 32 位 PCI 设备的驱动程序，请求设备的 DMA 数据进入 64 位机器内存的较高区域，可能无法满足来自操作系统从设备到大于 4 GB 内存读入数据的要求。因为对于这些地址的指针，将不适合设备的 DMA 寄存器。这个问题可如下解决，当向设备发出 DMA 请求时，OS 采用与设备相符的内存限制，或者使用 IOMMU。
qiuqiu173 2008-03-27
- 打赏
- 举报
数据类型位数变了吧,查一查资料吧
星羽 2008-03-27
- 打赏
- 举报
注意一下数据长度，特别是int long之类
64BIT机器有三种模式：ILP64,LP64,LLP64.
Windows采用LLP64,即int,long都为32，pointer为64
Linux采用LP64,即int为32，long和pointer为64
64BIT机器有三种模式：ILP64,LP64,LLP64.
Windows采用LLP64,即int,long都为32，pointer为64
Linux采用LP64,即int为32，long和pointer为64
