You still had a 4GB memory limit for processes, as well as a total memory limit of 64GB. Especially the first one was a problem for Java apps before AMD introduced 64bit extensions and a reason to use Sun servers for that.
Finding the reason for its existence from a credible source isn’t as easy, however. If you’re fine with an explanation from StackOverflow, you can infer that it’s there because some programs treat pointers as signed integers and die horribly when anything above 7FFFFFFF gets returned by the allocator.
It’s a silly flag to use as it only works when running 32-bit Windows applications on 64-bit Windows, and if you’re compiling from source, you should also have the option to just build a 64-bit binary in the first place. It made a degree of sense years ago when people actually used 32-bit Windows sometimes (which was usually just down to OEMs installing the wrong version on prebuilt PCs could have supported 64-bit) if you really wanted to only have one binary or you consumed a precompiled third party library and had to match its architecture.
You can also toggle it on precompiled binaries with the right tool (or a hex editor if you’re insane), which was my main use case. Lots of old games that never got 64-bit releases that benefit from having access to the extra RAM, especially if you’re modding them. It’s a great way to avoid out of memory crashes.
32 bit CPU’s having difficulty accessing greater than 4gb of memory was exclusively a windows problem.
You still had a 4GB memory limit for processes, as well as a total memory limit of 64GB. Especially the first one was a problem for Java apps before AMD introduced 64bit extensions and a reason to use Sun servers for that.
Interesting! Do you have a link to a write up about this? I don’t know anything about the windows memory manager
Only slightly related, but here’s the compiler flag to disable an arbitrary 2GB limit on x86 programs.
Finding the reason for its existence from a credible source isn’t as easy, however. If you’re fine with an explanation from StackOverflow, you can infer that it’s there because some programs treat pointers as signed integers and die horribly when anything above 7FFFFFFF gets returned by the allocator.
It’s a silly flag to use as it only works when running 32-bit Windows applications on 64-bit Windows, and if you’re compiling from source, you should also have the option to just build a 64-bit binary in the first place. It made a degree of sense years ago when people actually used 32-bit Windows sometimes (which was usually just down to OEMs installing the wrong version on prebuilt PCs could have supported 64-bit) if you really wanted to only have one binary or you consumed a precompiled third party library and had to match its architecture.
You can also toggle it on precompiled binaries with the right tool (or a hex editor if you’re insane), which was my main use case. Lots of old games that never got 64-bit releases that benefit from having access to the extra RAM, especially if you’re modding them. It’s a great way to avoid out of memory crashes.