因此32位程序中的可寻址内存空间为4千兆字节。分别在64位应用程序中，有大约18艾字节的可寻址空间。
kernel32.dll API有很多关于程序堆和/或内存的方法。
所以我目前的理解是，例如，如果你调用HeapAlloc并传递你需要分配的内存量，它将返回一个指向该分配的内存空间地址的指针...（如果我'，请纠正我我错了。）
现在使用win32-api函数的优点显然是Windows最擅长放置其他组件（如加载的DLL）。这就是我要问的原因......
内存中是否有固定的DLL文件位置。我想我读到的地方，对于32位，它通常是内存空间的上半部分（0x80000000及以上），但即使这是真的，64位应用程序的位置是什么？
另外，如果没有Windows首先分配它，是不是可以简单地使用指向某个内存的指针？副作用会是什么？
我对这个主题不熟悉，所以任何帮助或提示都会受到赞赏！ =）
答案 0 :(得分：6)
另外，如果没有Windows首先分配它，是不是可以简单地使用指向某个内存的指针？副作用会是什么？
副作用很简单：你的应用程序会崩溃。
Windows（以及其他所有理智的操作系统）都使用虚拟内存：操作系统将物理内存映射到进程看到的虚拟地址空间。它会按需执行此映射：当您要求它分配内存块时，它会将相应范围的虚拟内存地址映射到有效的内存块。
写入任意地址意味着您将打到一个尚未被操作系统映射到任何后备内存的内存页面。然后，您将获得访问冲突（或* nix上的分段错误）
内存中是否有固定的DLL文件位置
不。怎么会有？如果您有一个 DLL文件，则可以完成。如果您的应用程序加载两个DLL怎么办？如果加载40怎么办？ 400？并且每个DLL具有不同的大小，因此如果它们被加载到固定位置，它们可能最终重叠。
除此之外，最新版本的Windows执行地址空间随机化：为了缓解某些安全漏洞，如果多次启动应用程序，Windows会尝试确保将DLL和可执行文件加载到不同的位置
简而言之：您的流程在Windows下运行。它是Windows公民，必须遵守Windows法律。如果它需要访问资源（包括但不限于内存），它必须要求Windows提供该资源。