>BTW, if it's accepted that a prg/fxp in your project *is* loaded into memory at startup with the rest of the app, then an fxp "file read error" suggests either something (virus scanner?) is able to lock memory supposed to belong to your app, or the app is trying to access a copy other than its own. The developer's %temp% path could be a clue; definitely check the path to the prg in project manager since file read error could simply signal an attempt to access a %temp% other than the user's.

I think embolded is unproven except for functions still on the stack.
FP sported overlay mechanisms (as did many programs trying to fit into 640KB or utilize small EMS mapping window) and I don't think vfp loads every byte of its exe into memory. Tables are kept on disk until first usage, fxp uncertain if read en block (doubting Thomas here!), as memory in vfp still can be set to 256KB this strongly suggests swapping/overlay availability ;-))

Could be tested running from USB, but at least half rigorous testing would need huge # of large prgs, as perhaps either disk blocksizes or memory slizes are read cached. But how else could a (sans tables) multi MByte vfp exe run in tiny memory ?

my 0.02 €
thomas