Is the "4 GB patch" of any use in real life?
And if so, how. I'm talking about this 4GB Patch .
At first glance, this looks pretty nice: on Windows, each 32-bit application usually only has access to 2 GB of address space, but if you have 64-bit Windows, you can enable a small flag so that the 32-bit application can access the full 4 GB. This page provides some sample applications that can benefit from this.
HOWEVER, most applications assume that memory allocation is always successful. Some applications check to see if the allocations are successful, but even then they can fail with an error at best. I have never in my (short) life come across an application that could crash memory allocation and will still continue without loss of functionality or impact on correctness, and I feel that such applications range from extremely rare to substantially inadequate. existing in the field of desktop computers. With this in mind, it would be reasonable to assume that any such application would be programmed to not exceed 2GB of memory under normal conditions, and the few that were made would be built using this magic flag already included in favor of 64-bit users.
So, have I made some wrong assumptions? If not, how does this tool help in practice? I don't see how it might be, but I can see there are a few people around the internet who claim that this works (for some definitions of work).
source to share
Your awkward guesses are as follows:
Some applications check to see if the allocations are successful, but even then they can fail with an error at best. I have never in my (short) life come across an application that could crash memory allocation and will still continue without loss of functionality or impact on correctness, and I feel that such applications range from extremely rare to substantially inadequate. existing in the field of desktop computers.
There are applications out there that are better than "exiting gracefully" on failure. Yes, functionality will be affected (after all, there is not enough memory to continue with the requested operation), but many applications will at least be able to remain operational - so, for example, you may not be able to add text to your huge document anymore. but you can at least keep the document in its current state (or shrink it, etc.).
With this in mind, it seems reasonable to assume that any such application would be programmed not with 2GB of memory usage under normal conditions, but the few that would have been built with this magic flag already enabled for the benefit of 64-bit users.
The problem with this assumption is that, in general, the memory usage of an application is determined by what you do with it. So, as storage sizes have grown in recent years and memory sizes have grown, the sizes of the files people want to work with have also grown - so an application that worked great when 1GB files were unheard of can now struggle, which (for example) High definition video can be taken by many consumer cameras.
In other words: apps that used to fit comfortably into 2GB of memory no longer run because people want to do more with them.
source to share
I think the following excerpt from your 4 GB Patch link pretty much explains the reason for how and why it works.
Why everything is so on x64 is easy to explain. In x86 applications, there are 2 GB of virtual memory out of 4 GB (the remaining 2 GB is reserved for the system). On x64, these other two GBs can now be accessed by 32-bit applications. For this, a flag must be set in the internal file format. It's of course very easy for insiders who do it every day with CFF Explorer. This tool was written because not everyone is an insider, and probably a lot of people don't even know that this can be achieved. Even I wouldn't have written this tool if someone hadn't explicitly asked me.
And for CFF expansion ,
CFF Explorer has been designed to make editing PE as easy as possible without losing sight of the portable executable internals. This app includes a number of tools that can help not only distract engineers but also programmers. It offers a multi-file environment and a switchable interface.
And, to quote Microsoft insider Larry Miller from Microsoft MCSA in a blog post, report fixing games with this tool.
On 32-bit windows, the application has access to 2GB of VIRTUAL memory. Windows 64-bit allows 4GB for apps. Without the mentioned change, the application will be able to access 2 GB.
This was not an arbitrary limitation. Most 32-bit applications simply cannot handle address spaces larger than 2GB. The switch indicates to the system that it is capable of handling. If this switch is manually set, most 32-bit applications will crash into 64-bit environments.
In some cases, a switch can be useful. But don't be surprised if this is an accident.
And finally, add from MSDN - Porting 32-bit Managed Code to 64-bit .
PE also has information that tells the Windows loader if an assembly is for a specific architecture. This additional information ensures that assemblies intended for a particular architecture are not loaded into another. C #, Visual Basic.NET, and C ++ Whidbey compilers allow you to set appropriate flags in the PE header. For example, C # and THIRD have / platform: {anycpu, x86, Itanium, x64}.
Note . While it is technically possible to change the flags in the PE header of an assembly after it has been compiled, Microsoft does not recommend doing so.
Finally, to answer your question - how does this tool help in practice?
Since you have malloc in your tags, I believe you are working on unmanaged memory. This patch will mostly result in invalid pointers as they are now getting twice as large and almost all other primitive data types will scale by 2. But for managed code, since they are all handled by the CLR in .NET, this would mean that this is really useful and won't have much of a problem unless you deal with one of the following:
- Calling the platform API via p / invoke
- Calling COM Objects
- Using unsafe code
- Using marshaling as a mechanism for sharing information
- Using serialization as a way to persist state
To summarize , as a programmer, I would not use a tool to convert my application and rather port it myself by changing the build targets. that if I have an exe that can look good like games with a lot of RAM then it is worth a try.
source to share