>Any of those settings is far larger than most VFP exes, which presumably explains why it's so reliable to extract the whole app from memory. By my understanding, you'd need to try pretty hard in 2021 to get VFP not to make the app memory resident.

I don't think that is true. An VFP EXE is not a real regular exe and won't be loaded into memory by default. When a class(lib) is not used or referenced in the app before a certain point, it won't be resident in memory.

Only when you try to load a resource (frx, scx, prg, vcx, etc) for the first time, it will read the resource from the exe and it will be resident in memory from that point onwards. This is the reason why it pays off to use a loader to load the exe in the %appdata% folder for local execution, because if it was located on the network, the accessing of the resources will induce network traffic which will result in slowness on high latency networks (like VPNs to external sites).

You can actually witness this activity by the process monitor available from MS (formerly from sysinternals).

Things will be different if you use a packer (I used to play around with armadillo, but the were others as well), they will load the whole exe into memory and execute it from there. This explains why some packers seem to let run VFP faster right from a network resource compared to a regular VFP exe.

I suspect VFP Advanced will do the same (I have not played with that enough to be sure): It will unpack everything into memory and run from there.