windows - win32自定义内存管理有什么限制？

Question

因此 32 位程序中的可寻址内存空间为 4 GB。相应地，在 64 位应用程序中，有大约 18 艾字节的可寻址空间。

kernel32.dll API 有多种关于程序堆和/或内存的方法。

所以我目前的理解是，例如，如果你调用 HeapAlloc 并将你需要分配的内存量传递给它，它将返回一个指向该分配内存空间地址的指针......(如果我'不过我在这里错了。)

现在为此使用 win32-api 函数的优势显然是 Windows 最清楚它放置其他组件(如加载的 DLL)的位置。这就是为什么我要问...

DLL文件在内存中是否有固定位置。我想我在某处读到，对于 32 位，它通常是内存空间的上半部分(0x80000000 及以上)，但即使这是真的，64 位应用程序的位置又是什么？

此外，如果 Windows 不首先分配它，就不能简单地自由使用指向某些内存的指针吗？会有什么副作用？

我是这个主题的半新手，所以非常感谢任何帮助或提示! =)

Answer 1

Also, is it not possible to simply use pointers to some memory freely without having Windows allocate it first? What would the side-effects be?

副作用很简单:您的应用程序会崩溃。

Windows(以及所有其他正常的操作系统)使用虚拟内存:操作系统将物理内存映射到您的进程看到的虚拟地址空间。它按需执行此映射:当您要求它分配一 block 内存时，它会将相应范围的虚拟内存地址映射到有效的内存块。

写入任意地址意味着您将命中一个尚未被操作系统映射到任何后备内存的内存页。然后您将遇到访问冲突(或 *nix 上的段错误)

Is there a fixed position in memory for DLL files

没有。怎么会有？如果您有一个 DLL 文件，就可以完成。如果您的应用程序加载两个 DLL 怎么办？如果加载 40 怎么办？ 400？而且每个 DLL 都有不同的大小，因此如果将它们加载到固定位置，它们最终可能会重叠。

最重要的是，最新版本的 Windows 执行地址空间随机化:为了减轻某些安全漏洞，如果您多次启动应用程序，Windows 会尝试确保将 DLL 和可执行文件加载到不同位置.

简而言之:您的进程在 Windows 下运行。它是 Windows 公民，必须遵守 Windows 法律。如果它需要访问资源(包括但不限于内存)，它必须请求 Windows 使该资源可用。