Aether wrote:I found the answer to my question at:
http://stackoverflow.com/questions/6395 ... ing-system"
You've got the same basic restriction when running a 32bit process under Win64. Your app runs in a 32 but subsystem which does its best to look like Win32, and this will include the memory restrictions for your process (lower 2GB for you, upper 2GB for the OS)"
If your program is 32-bit, then that's probably your answer.
There is one caveat to that: if the 32bit program is marked as
Large Address Aware, it will get 4GB of virtual address space when running on a 64bit OS (or 3GB when running on a 32bit OS with the /3GB switch, but let's ignore obsolete OSes, k?). This is a linker option (ie, it's something that should be set by the developer when compiling the program); however, t's actually possible to patch the header of a 32bit application so it is marked as LAA -- and there was a time when people were doing this with some success for some games. However, the program may have been written under assumption it will never see more than 2GB of VAS and so will crash when it does. That's bad program design, but it happens, so YMMV.
Not that that has anything to do with this particular problem, but just FYI.
If the program is 32bit, it certainly can exhaust its virtual address space, and that will happen at the 2GB mark. Note that an application that does a lot of allocation and freeing can end up with its memory space badly fragmented, to the point where it can't allocate the memory it needs even though it should be able to. Most programs don't handle a failed memory allocation very gracefully. Exhaustion of the system virtual memory (physical memory + page file) is a possibility also, particularly if the page file has been "tweaked" so it won't grow, as a couple of folks have noted. There are other, more obscure resources that can be exhausted and might be reported this way by Windows, but those are increasingly unlikely as recent versions of Windows have removed those even for 32bit programs.
