Hi Thomas and Jos,

if you load 30 instances of VFP on an x86 server with 3 GB of ram, each one taking 100MB of memory, you will find all those instances running in the space below 2GB. VFP can not address memory above 2GB. Why? Here http://msdn.microsoft.com/en-us/library/wz223b1z(v=vs.80).aspx and here http://us.battle.net/wow/en/forum/topic/1658706617?page=6 (it's been a big thing in the gaming community). Given when VFP was written, this makes sense. It's not that it can't address _more_ than 2 GB of memory (although that's true also), but that it can't address _above_ the 2GB line. This is true for every x86-compiled program, except those that has the /LARGEADDRESSAWARE flag set in the linker; or those who are capable, if the corresponding header flag (usually called the LARGEMEMORYAWARE flag by the gamers, but not by Microsoft) is set in the header of the EXE.

I've tested on Windows 2008 R2 (which is always x64), where there is no /PAE flag because nearly all 4GB of the lower 4GB are automatically made available to x86 programs, using the modifed EXE, and, no joy, still crammed into 4GB. I left a note for Calvin on his blog, but he doesn't really answer those, and I've had no answer.

Hank

>>Hi All,
>>
>>Several days or even weeks ago I read a post here which I think was from Hank Fay. It mentioned something about the maximum amount of memory that all running instances of VFP could collectively have was the 2Gb limit. I understand that VFP cannot reach beyond 2Gb. But why would this affect separately running instances of VFP on a single machine? If they share the same DLLs then again I can understand it. But what if they all had their own copies of the VFP DLLs? Could someone expand on this?
>
>Pretty sure you misinterpreted his post.
>It was about the possibility to patch vfp with the LARGEMEMORY[too lazy too Google] or something flag,
>which IN OTHER programs allows those to adress 3 insted of 2 GB RAM inside each W32 process.
>So it is not collectively, but in each instance the maximum "program" footprint, as some memory is needed from the top as well,
>hence the 1 GB even with LARGEMEMORY. There are some programs that look for the correct location in an exe and patch,
>but if Hank says it doesn't work, I would first look at other alternatives. SSD can speed up previosly disc bound programs like crazy -
>this is the direction I went 18 month ago. Depending on the task I got a speedup of 20 - 60%, elevating single core allocation from
>30 ~50 to 90 ~ 95%. If you are running VM's on big RAM HW check out the different modes of using that RAM:
>depending JUST on the configuration the speed can be different by a factor of 3 on the same HW.
>
>regards
>
>thomas