LabVIEW
Not able to utilize 4 GB Memory for 32 Bit Labview
@Yamaeda wrote:
There used to be an ini-key (config.sys?) to get access to a larger address space in 32 bit windows, do you still need to use that on a 64 bit system?
That was to increase the available memory from 2GB to 3GB. By default Windows used the upper half of the available virtual memory address space for its own system DLLs such as ntdll.dll, kernel32.dll etc, etc. This was to conserve memory space as it could load these once into an address memory space and then map that into every process, rather than loading it again and again for each process. That still costs some management infrastructure to maintain the correct process independent reference count but is a lot cheaper than loading it repeatedly into memory for every process.
The 2GB limit comes from a time when the physical memory of Windows computers was measured in Megabytes rather than Gigabytes. Only 20 years ago 256 MB of physical RAM was very common for a computer, 512 MB was considered a beast (and cost more than 32GB nowadays). 😁
So choosing it like that seemed like a VERY safe choice as it required only a one bit check to see if an address was in the special system memory address space or rather in the user space.
As available memory grew, the 2GB limit started to turn out to be a real problem and careful review showed that the Windows system could safely live in 1GB of memory, so that extra switch was introduced. And since there are always programmers out there who find ways to abuse certain features of a system, despite dire warnings to not go beyond the safe lines of documented behaviour, Microsoft decided in the name of the holy grail of backwards compatibility to make it a feature that you had to specifically enable at boot time.
With Windows 64-bit that limit doesn't exist anymore and for the SysWOW64 subsystem they sacked the compatibility mode too, since applications that abuse the system in such a way that they would stumble over that, would almost certainly stumble over a number of other compatibility issues in the SysWOW64 subsystem and it was easy to sell, that such hacky applications simply can't work on 64-bit Windows anymore.
As to the claim that 32-bit applications are allowed to use the full 4GB of memory themselves under 64-bit Windows, I heard that too but have my doubts that it applies as generally as most people would like to think. It may also be dependent on hardware such as CPU family and generation.
And in almost all cases I have seen so far, where the available 3GB limit was a problem it was really due to a bad choice of the used algorithme and/or data model to work on, usually resulting not only in huge memory consummation but also rather bad performance. With applications where 3GB of memory is a limit, an increased limit to 4GB only buys you a few minutes of extra air. Rather sooner than later the 4GB is going to blow up too, and it is simply a sign to reconsider your options rather than trying to buy you a few more gaps of air before you ultimately run out of it.
There are applications where 4GB of working memory is a legitimate problem, but much of what I have seen in the past does not fit in those categories. And if you happen to work in these categories you should have searched for ways to move to 64-bit already back in Windows 7 times.
