Memory 是",；4GB补丁“；在现实生活中有什么用处？

如果是的话，怎么做。我在说这个

从表面上看，这似乎是一个非常好的想法：在Windows上，每个32位应用程序通常只能访问2GB的地址空间，但如果您有64位Windows，则可以启用一个小标志以允许32位应用程序访问完整的4GB地址空间。本页提供了一些可能从中受益的应用程序示例

然而，大多数应用程序似乎认为内存分配总是成功的。有些应用程序确实会检查分配是否成功，但即使如此，在失败时也最多可以优雅地退出。在我（短暂的）一生中，我从未遇到过这样一个应用程序，它可以在内存分配失败的情况下继续运行，而不会丢失功能或影响正确性。我感觉，在台式计算机领域，这样的应用程序从极为罕见到根本不存在。考虑到这一点，我们可以合理地假设，在正常情况下，任何此类应用程序的内存使用量都不会超过2GB，而为64位用户的利益而启用此神奇标志的应用程序也不会超过2GB

---

那么，我是否做出了一些错误的假设？如果没有，该工具在实践中有何帮助？我不知道这是怎么回事，但我在互联网上看到不少人声称这是有效的（对于某些作品的定义）。

我确实认为以下摘自你的链接的摘录基本上解释了它如何以及为什么有效的原因

x64上出现这种情况的原因很容易解释。在x86应用程序上，4GB中有2GB的虚拟内存（其他2GB保留给系统）。在x64上，32位应用程序现在可以访问这两个其他GB。为了实现这一点，必须在文件的内部格式中设置一个标志。当然，这对于每天使用CFF Explorer的内部人员来说非常容易。写这个工具是因为不是每个人都是内幕人士，而且很可能很多人甚至不知道这是可以实现的。如果没有人明确要求，我也不会编写这个工具

进一步说,

CFF浏览器旨在使PE编辑尽可能简单， 但不会忽略可移植可执行文件的内部 结构。此应用程序包括一系列可能 不仅帮助逆向工程师，也帮助程序员。它提供了一个 多文件环境和可切换接口

引用微软内部人士、微软MCSA的拉里·米勒（Larry Miller）在一篇关于使用该工具修补游戏的帖子中的话

在32位windows下，应用程序可以访问2GB的虚拟磁盘 内存空间。64位Windows使4GB应用程序可用。 如果没有上述更改，应用程序将只能 访问2GB

这不是一个任意的限制。大多数32位应用程序 无法处理大于2GB的地址空间。开关 上面提到的向系统表明它能够应付。如果这 开关是手动设置的，大多数32位应用程序将在64位时崩溃 环境

在某些情况下，开关可能有用。但是，如果它 撞车

最后要从MSDN中添加-

PE中还有一些信息告诉Windows加载程序 该程序集针对特定的体系结构。这个额外的 信息可确保程序集针对特定的 体系结构没有加载到不同的体系结构中。C#，Visual Basic .NET和C++ WHIDBY编译器允许设置适当的标志 PE标题。例如，C#和THIRD有一个/platform:{anycpu， x86、安腾、x64}编译器选项

注意：虽然从技术上讲可以在编译程序集后修改程序集PE标头中的标志，但Microsoft不建议这样做

最后回答您的问题-此工具在实践中有何帮助？

由于标记中有malloc，我相信您正在处理非托管内存。此修补程序将导致无效指针，因为它们现在的大小是原来的两倍，并且几乎所有其他基本数据类型都将按2倍的因子进行缩放。 但对于托管代码，由于所有这些都是由.NET中的CLR处理的，这意味着非常有用，并且不会有太多问题，除非您处理以下任何一项：

• 通过p/invoke调用平台API
• 调用COM对象
• 使用不安全代码
• 将封送处理用作共享信息的机制
• 使用序列化作为持久化状态的方法

---

总而言之，作为一名程序员，我不会使用该工具来转换我的应用程序，而是通过更改构建目标来迁移它。有人说，如果我有一个exe，可以做得很好，像游戏与更多的内存，那么这是值得一试

你那些麻烦的假设是：

有些应用程序确实会检查分配是否成功，但即使如此，在失败时也最多可以优雅地退出。在我（短暂的）一生中，我从未遇到过这样一个应用程序，它可以在内存分配失败的情况下继续运行，而不会丢失功能或影响正确性。我感觉，在台式计算机领域，这样的应用程序从极为罕见到根本不存在

确实存在比失败时“优雅地退出”更好的应用程序。是的，功能将受到影响（毕竟，没有足够的内存继续执行请求的操作），但许多应用程序至少能够保持运行-因此，例如，您可能无法向庞大的文档中添加更多文本，但您至少可以将文档保存在其当前状态（或使其变小，等等）

考虑到这一点，似乎可以合理地假设任何此类申请都是无效的