致力于将32位Windows C ++应用程序移植到64位。不幸的是，代码在DWORD和指针值之间的两个方向上使用频繁的转换。
其中一个想法是在进程启动期间尽早保留前4GB的虚拟进程空间，以便所有后续的保留内存调用都来自大于4 GB的虚拟地址。这将导致访问冲突错误从指针到DWORD的任何不安全的强制转换，然后返回到指针，将有助于及早发现错误。
当我查看一个非常简单的单行C ++程序的内存映射时，底部4GB内有很多库加载？有没有办法确保所有库等只能加载到4GB以上？
由于
答案 0 :(得分：6)
使用/Wp64开关编译项目（检测64位可移植性问题）并修复所有警告。
答案 1 :(得分：4)
答案 2 :(得分：2)
您可以尽早在应用程序中插入对VirtualAlloc()的调用，以便在较低的4GB内分配内存。如果使用MEM_RESERVE参数，则仅分配虚拟内存空间，因此这将仅使用非常少量的实际RAM。
但是，这只会帮助您从堆中分配内存 - 程序中的任何静态数据都已经在WinMain（）之前分配，因此您将无法更改它的位置。
（顺便说一句，即使您可以在加载主二进制文件之前保留内存，我认为主二进制文件需要在特定地址加载 - 除非它是作为位置无关的可执行文件构建的。）
答案 3 :(得分：2)
布鲁斯道森发布了一项技术代码，用于保留底部4 GB的VM：
https://randomascii.wordpress.com/2012/02/14/64-bit-made-easy/
它使用VirtualAlloc保留大部分地址空间（不是实际内存），然后使用HeapAlloc跟踪进程堆，并使用malloc完成CRT堆。它简单，快速，而且效果很好。在我的机器上，它实现了大约3.8 GB的虚拟分配和仅1 MB的实际分配。
我第一次尝试时，我立即在我正在进行的项目中发现了一个长期存在的错误。强烈推荐。
答案 4 :(得分：1)
最好的解决办法是修复这些演员......
你可能会因为它而截断指针（与投射到POINTER_32相同），因为我相信Windows无论如何都会为你的应用程序提供更低的4GB。但这绝不是保证。你最好解决这些问题。
搜索代码“（DWORD）”并修复您找到的任何内容。没有更好的解决方案......
基本上，您要求的是在启用AWE的情况下以32位内存模式运行64位代码（即失去64位的所有真正优势）。我不认为微软可能会因为这么少的收益而感到困扰......谁能责怪他们呢？