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