Double Your App's Available Memory On Win64
(Originally published at http://www.clarionmag.com/cmag/v12/v12n12tip4.html)
All 32 bit applications running on Windows are, by default, limited to 2GB of RAM. That's not always enough, as some Clarion developers with really big apps are discovering.
The long term solution is for SoftVelocity to produce a 64 bit compiler, and there's definitely hope this will happen.
In the meantime, you can give your 32 bit Clarion 7.1 and later apps access to somewhere in the neighborhood of 4GB of RAM, if your application is running under a 64 bit version of Windows. All it takes is one wee little line of code.
In Clarion 7.1 SoftVelocity introduced the LARGE_ADDRESS statement for EXP files. From the help:
The LARGE_ADDRESS statement
LARGE_ADDRESS
Alternatively, you can add the following to the LNK file:
/LARGE_ADDRESS
With either option set above, the linker adds the IMAGE_FILE_LARGE_ADDRESS_AWARE flag to the PE header. If this flag is not set, the 32-bit application receives 2 GB virtual address space.
With NT architecture, every 32 bit process runs in the 4GB virtual address space, but the amount of the virtual memory available for process data and code is dependent on Windows characteristics and settings in the process main executable's PE header.
WOW64 enables 32-bit applications to take advantage of the 64-bit kernel. Therefore, 32-bit applications can use a larger number of kernel handles and window handles. However, 32-bit applications may not be able to create as many threads under WOW64 as they can on x86. On some processors, there is less virtual address space available, and each thread contains a 64-bit stack (usually 512K). On the x64 processor, each 32-bit application receives 4 GB virtual address space in the WOW64 environment, if the application has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header. If this flag is not set, the 32-bit application receives 2 GB virtual address space.
The EXP option is easy to implement. Go to your application's global embeds, and simply add the text
LARGE_ADDRESS
to the Inside the export list embed point (Figure 1).
Generate and compile your application and it's good to go!
You can confirm the flag has been set if you have Microsoft's dumpbin utility (which comes with Visual Studio).
On my machine I used the following command to verify the header. You may need to adjust the dumpbin path portion, and you will definitely need to point it at your EXE and not the path shown.
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\dumpbin" /header s "d:\dev\c7\people\people.exe"
Here's a portion of what dumpbin returned:
PE signature found File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (x86) 7 number of sections 4CFF850B time date stamp Wed Dec 08 07:15:55 2010 0 file pointer to symbol table 0 number of symbols E0 size of optional header 81AE characteristics Executable Line numbers stripped Symbols stripped Application can handle large (>2GB) addresses Bytes reversed 32 bit word machine
Note the third-last line: Application can handle large (>2GB) addresses. As noted above, this only applies when your app is running under 64 bit Windows.
Although the Clarion help doesn't specifically say whether your modified 32 bit EXE will still run on 32 bit Windows, I don't see any reason why it wouldn't; in my simple test of the People app the EXE runs fine on both 32 bit and 64 bit versions of Windows 7. The only difference is that on 32 bit Windows the EXE will only get up to 2GB of RAM.
The long term solution to the 2GB memory constraint is a 64 bit Clarion compiler with (presumably) up to eight terabytes of addressable memory. In the short term, another 2GB of memory probably won't hurt.
If you're running into memory constraints, give this option a try. And please post a comment with your experiences.