blocks|key|2006156|text|因为许多遗留代码都期望“负”指针是无效的。32位进程的前两Gb中的任何内容都设置了msb。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2006157|因此，对于微软来说，采取安全措施要容易得多，并且需要(a)需要完整的4+4Gb和(b)已经在大内存情况下开发和测试的应用程序，以简单地设置标志。|2006158|正如你已经注意到的，这并不难。|2006159|Raymond+Chen+-在他的博客The+Old+New+Thing中-涵盖了为所有(32位)应用程序打开它的问题。|offset|length|2006160|entityMap|0|LINK|mutability|MUTABLE|url|https://devblogs.microsoft.com/oldnewthing/20050601-24/?p=35483^0|0|0|0|J|H|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Because lots of legacy code is written with the expectation that "negative" pointers are invalid. Anything in the top two Gb of a 32bit process has the msb set.

As such, its far easier for Microsoft to play it safe, and require applications that (a) need the full 4Gb and (b) have been developed and tested in a large memory scenario, to simply set the flag.

It's not - as you have noticed - that hard.

Raymond Chen - in his blog <a href="https://devblogs.microsoft.com/oldnewthing/20050601-24/?p=35483" rel="nofollow noreferrer">The Old New Thing</a> - covers the issues with turning it on for all (32bit) applications.

blocks|key|2818999|text|不，在这个上下文(C/C%2B%2B)中的“遗留代码”并不是唯一使用MSB指针的丑陋把戏的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2819000|它还包括所有使用“int”来存储两个指针之间的差异或内存区长度的代码，而不是使用正确的类型“size_t”：“int”被签名有31位，并且不能处理超过2+Gb的值。|2819001|修复大部分代码的一种方法是检查并纠正所有那些无害的“混合签名和未签名”警告。它应该做了很好的工作，至少如果你还没有定义函数，其中int类型的参数实际上是一个内存长度。|2819002|然而，“遗留代码”很可能会在相当长的一段时间内正常工作，即使您什么都不修改。|2819003|只有在一个块中分配的空间超过2+Gb时，才会中断。或者当你要比较两个不相关的指针时，它们彼此之间的距离超过2+Gb。|2819004|因为从技术上讲，比较不相关的指针是一种未定义的行为，所以你不会遇到那么多这样做的代码(但你永远不能确定)。|2819005|而且通常情况下，即使您总共需要超过2+2Gb，您的程序实际上也不会进行大于2+2Gb的单次分配。事实上，在Windows中，即使使用LARGEADDRESSAWARE，默认情况下也无法分配那么多内存。您需要打乱系统DLL，以获得大于2+2Gb的连续块|2819006|但是墨菲定律说，这种代码总有一天会崩溃，只是在你启用LARGEADDRESSAWARE之后很长一段时间，没有人会记得已经做过了。|2819007|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

No, "legacy code" in this context (C/C++) is not exclusively code that plays ugly tricks with the MSB of pointers.

It also includes all the code that uses 'int' to store the difference between two pointer, or the length of a memory area, instead of using the correct type 'size_t' : 'int' being signed has 31 bits, and can not handle a value of more than 2 Gb.

A way to cure a good part of your code is to go over it and correct all of those innocuous "mixing signed and unsigned" warnings. It should do a good part of the job, at least if you haven't defined function where an argument of type int is actually a memory length.

However that "legacy code" will probably apparently work right for quite a while, even if you correct nothing.

You'll only break when you'll allocate more than 2 Gb in one block. Or when you'll compare two unrelated pointers that are more than 2 Gb away from each other. 
As comparing unrelated pointers is technically an undefined behaviour anyway, you won't encounter that much code that does it (but you can never be sure). 
And very frequently even if in total you need more than 2Gb, your program actually never makes single allocations that are larger than that. In fact in Windows, even with LARGEADDRESSAWARE you won't be able by default to allocate that much given the way the memory is organized. You'd need to shuffle the system DLL around to get a continuous block of more than 2Gb

But Murphy's laws says that kind of code will breaks one day, it's just that it will happen very long after you've enable LARGEADDRESSAWARE without checking, and when nobody will remember this has been done.

blocks|key|557830|text|盲目地将LargeAddressAware标志应用于您的32位可执行文件将部署一个定时炸弹！|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|557831|通过设置此标志，您可以向操作系统证明：|557832|557833|是的，我的应用程序(以及在运行时加载的所有all+)可以处理高达4+GB的内存地址。|blockquote|557834|557835|因此，不要将进程的VAS限制为2+GB，而是解锁整个范围(4+GB)。|557836|557837|但你真的能保证吗？|557838|您是否对您的进程可能使用的所有系统DLL、microsoft可再发行文件和第三方模块负责？|557839|通常，内存分配以从低到高的顺序返回虚拟地址。因此，除非您的进程消耗大量内存(或者它具有非常零碎的虚拟地址空间)，否则它永远不会使用超过2+GB边界的地址。这隐藏了与高地址相关的bug。|557840|即使存在这样的bug，也很难识别。他们迟早会零星地出现。这只是个时间问题。|557841|幸运的是，windows操作系统中内置了一个非常方便的系统级开关：|557842|出于测试目的，请使用MEM_TOP_DOWN注册表设置。|557843|这会强制所有内存分配自上而下，而不是正常的自下而上。|557844|[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session+Manager\Memory+Management]
"AllocationPreference"=dword:00100000|code-block|syntax|javascript|557845|(这是十六进制0x100000。当然，需要重新启动windows+)|557846|启用此开关后，您将“更快”地发现问题，而不是“稍后”。理想情况下，你会“从一开始”就看到它们。|557847|附注:对于第一次分析，我强烈推荐使用工具VMmap+(SysInternals)。|557848|结论：|557849|将LAA标志应用于32位可执行文件时，必须在设置了AllocationPreference++x64+开关的TopDown+OS上对其进行全面测试。|557850|对于您自己的代码中的问题，您也许能够修复它们。|557851|举个很明显的例子:内存指针使用无符号整数而不是有符号整数。|557852|当遇到第三方模块的问题时，您需要请求作者修复他的错误。除非这样做，否则最好从可执行文件中删除LargeAddressAware标志。|557853|557854|关于测试的注释：|557855|对于由本身未启用MemTopDown的“测试运行器”执行的单元测试，LAA注册表开关无法获得所需的结果。|557856|请参阅：Unit+Testing+for+x86+LargeAddressAware+compatibility|557857|557858|PS：|557859|从32位代码到64位代码的迁移也是非常“相关”和非常有趣的。|557860|有关示例，请参阅：|557861|557862|As+a+programmer,+what+do+I+need+to+worry+about+when+moving+to+64-bit+windows?|unordered-list-item|557863|https://www.sec.cs.tu-bs.de/pubs/2016-ccs.pdf+(两倍的位数，两倍的麻烦)|557864|557865|entityMap|0|LINK|mutability|MUTABLE|url|http://www.sysinternals.com/|1|https://stackoverflow.com/questions/23114068/|2|https://stackoverflow.com/q/544296/1468842|3|https://www.sec.cs.tu-bs.de/pubs/2016-ccs.pdf^0|4|H|15|4|0|0|0|0|0|0|0|0|0|0|0|0|X|0|0|0|0|0|0|K|5|R|C|0|0|0|0|19|1F|N|P|K|0|0|0|3|3|0|0|5|3|0|T|4|0|4|1G|1|0|0|0|0|0|0|0|25|2|0|0|19|3|0|0^^$0|@$1|2|3|4|5|6|7|2O|8|@$9|2P|A|2Q|B|C]|$9|2R|A|2S|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|2T|8|@]|E|@]|F|$]]|$1|I|3|-4|5|6|7|2U|8|@]|E|@]|F|$]]|$1|J|3|K|5|L|7|2V|8|@]|E|@]|F|$]]|$1|M|3|-4|5|6|7|2W|8|@]|E|@]|F|$]]|$1|N|3|O|5|6|7|2X|8|@]|E|@]|F|$]]|$1|P|3|-4|5|6|7|2Y|8|@]|E|@]|F|$]]|$1|Q|3|R|5|6|7|2Z|8|@]|E|@]|F|$]]|$1|S|3|T|5|6|7|30|8|@]|E|@]|F|$]]|$1|U|3|V|5|6|7|31|8|@]|E|@]|F|$]]|$1|W|3|X|5|6|7|32|8|@]|E|@]|F|$]]|$1|Y|3|Z|5|6|7|33|8|@$9|34|A|35|B|D]]|E|@]|F|$]]|$1|10|3|11|5|6|7|36|8|@]|E|@]|F|$]]|$1|12|3|13|5|6|7|37|8|@]|E|@]|F|$]]|$1|14|3|15|5|16|7|38|8|@]|E|@]|F|$17|18]]|$1|19|3|1A|5|6|7|39|8|@]|E|@]|F|$]]|$1|1B|3|1C|5|6|7|3A|8|@]|E|@]|F|$]]|$1|1D|3|1E|5|6|7|3B|8|@$9|3C|A|3D|B|C]]|E|@$9|3E|A|3F|1|3G]]|F|$]]|$1|1F|3|1G|5|6|7|3H|8|@]|E|@]|F|$]]|$1|1H|3|1I|5|6|7|3I|8|@$9|3J|A|3K|B|D]|$9|3L|A|3M|B|D]|$9|3N|A|3O|B|C]]|E|@]|F|$]]|$1|1J|3|1K|5|6|7|3P|8|@]|E|@]|F|$]]|$1|1L|3|1M|5|6|7|3Q|8|@]|E|@]|F|$]]|$1|1N|3|1O|5|6|7|3R|8|@$9|3S|A|3T|B|D]]|E|@]|F|$]]|$1|1P|3|-4|5|6|7|3U|8|@]|E|@]|F|$]]|$1|1Q|3|1R|5|6|7|3V|8|@$9|3W|A|3X|B|D]]|E|@]|F|$]]|$1|1S|3|1T|5|6|7|3Y|8|@$9|3Z|A|40|B|D]]|E|@]|F|$]]|$1|1U|3|1V|5|6|7|41|8|@]|E|@$9|42|A|43|1|44]]|F|$]]|$1|1W|3|-4|5|6|7|45|8|@]|E|@]|F|$]]|$1|1X|3|1Y|5|6|7|46|8|@]|E|@]|F|$]]|$1|1Z|3|20|5|6|7|47|8|@]|E|@]|F|$]]|$1|21|3|22|5|6|7|48|8|@]|E|@]|F|$]]|$1|23|3|-4|5|6|7|49|8|@]|E|@]|F|$]]|$1|24|3|25|5|26|7|4A|8|@]|E|@$9|4B|A|4C|1|4D]]|F|$]]|$1|27|3|28|5|26|7|4E|8|@]|E|@$9|4F|A|4G|1|4H]]|F|$]]|$1|29|3|-4|5|6|7|4I|8|@]|E|@]|F|$]]|$1|2A|3|-4|5|6|7|4J|8|@]|E|@]|F|$]]]|2B|$2C|$5|2D|2E|2F|F|$2G|2H]]|2I|$5|2D|2E|2F|F|$2G|2J]]|2K|$5|2D|2E|2F|F|$2G|2L]]|2M|$5|2D|2E|2F|F|$2G|2N]]]]

<h2>blindly applying the <code>LargeAddressAware</code> flag to your 32bit executable deploys a ticking time bomb!</h2>
by setting this flag you are testifying to the OS:
<blockquote>
yes, my application (and all DLLs being loaded during runtime) can cope with memory addresses up to 4 GB. 
so don't restrict the VAS for the process to 2 GB but unlock the full range (of 4 GB)&quot;.
</blockquote>
but can you really guarantee? 
do you take responsibility for all the system DLLs, microsoft redistributables and 3rd-party modules your process may use?
usually, memory allocation returns virtual addresses in low-to-high order. so, unless your process consumes a lot of memory (or it has a very fragmented virtual address space), it will never use addresses beyond the 2 GB boundary. this is hiding bugs related to high addresses.
if such bugs exist they are hard to identify. they will sporadically show up &quot;sooner or later&quot;. it's just a matter of time.
luckily there is an extremely handy system-wide switch built into the windows OS: 
for testing purposes use the MEM_TOP_DOWN registry setting. 
this forces all memory allocations to go from the top down, instead of the normal bottom up.
<pre><code>[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
&quot;AllocationPreference&quot;=dword:00100000
</code></pre>
(this is hex 0x100000. requires windows reboot, of course)
with this switch enabled you will identify issues &quot;sooner&quot; rather than &quot;later&quot;.
ideally you'll see them &quot;right from the beginning&quot;.
side note: for first analysis i strongly recommend the tool <code>VMmap</code> (<a href="http://www.sysinternals.com" rel="noreferrer" title="SysInternals">SysInternals</a>).
<h2>conclusions:</h2>
when applying the LAA flag to your 32bit executable it is mandatory to fully test it on a x64 OS with the TopDown <code>AllocationPreference</code> switch set.
for issues in your own code you may be able to fix them. 
just to name one very obvious example: use unsigned integers instead of signed integers for memory pointers.
when encountering issues with 3rd-party modules you need to ask the author to fix his bugs. unless this is done you better remove the LargeAddressAware flag from your executable.
<hr>
a note on testing:
the MemTopDown registry switch is not achieving the desired results for unit tests that are executed by a &quot;test runner&quot; that itself is not LAA enabled. 
see: <a href="https://stackoverflow.com/questions/23114068/">Unit Testing for x86 LargeAddressAware compatibility</a>
<hr>
PS: 
also very &quot;related&quot; and quite interesting is the migration from 32bit code to 64bit. 
for examples see:
<ul>
<li><a href="https://stackoverflow.com/q/544296/1468842">As a programmer, what do I need to worry about when moving to 64-bit windows?</a></li>
<li><a href="https://www.sec.cs.tu-bs.de/pubs/2016-ccs.pdf" rel="noreferrer">https://www.sec.cs.tu-bs.de/pubs/2016-ccs.pdf</a> (twice the bits, twice the trouble)</li>
</ul>

We need to link one of our executables with this flag as it uses lots of memory. 
But why give one EXE file special treatment. Why not standardize on /LARGEADDRESSAWARE?

So the question is: Is there anything wrong with using /LARGEADDRESSAWARE even if you don't need it. Why not use it as standard for all EXE files?

Drawbacks of using /LARGEADDRESSAWARE for 32 bit Windows executables?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们需要用这个标志链接我们的一个可执行文件，因为它使用了大量的内存。但是为什么要对一个EXE文件进行特殊处理呢？为什么不在/LARGEADDRESSAWARE上实现标准化呢？所以问题是:即使你不需要/LARGEADDRESSAWARE，使用它也有什么错吗？为什么不把它作为所有EXE文件的标准？

问为32位视窗可执行文件使用/LARGEADDRESSAWARE的缺点？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为32位视窗可执行文件使用/LARGEADDRESSAWARE的缺点？EN