>Ed,
>
>I sure hope that you are speculating here because that is not at all how I would *expect* it to work (in other words, I surely am speculating in what follows)!
>
>I would expect the entire .EXE to be loaded down to the workstation and that, rather quickly, the SWAP file would start to be used to retain unexecuted portions of the EXE.
Jim,
Think about this. Why does VFP maintain an open file handle to the .EXE while it's running? To demonstrate that this is the case, start a copy of an .EXE on one system, and try to do something that requires exclusive access to the .EXE (like deleting it) while the other station is running.
>
>In fact I would say that if it works any other way, then WIN is in serious need of re-design.
I don't think you understand the swap file, Jim. The swap file is a backing store for virtual memory; inactive segments of a loaded program are swapped to disk to make room for other code segments. The swap file is not a cache, but is a way of making the system appear to have more physical RAM than it actually has. It does not represent a quicker intermediate store that holds pieces of open files for quick access if they're rereferenced. Things in swap files represent memory addresses, not file pieces.
The behavior of the Win32 cache subsystem with regard to open files in a network environment is a different issue. if Windows can determine that a file is -ALWAYS- opened in Read-Only mode, it is safe to cache disk blocks locally, and Windows will do so. However, even if a file is opened for reading, if Windows can't determine that another system couldn't open it for writing, Windows won't cache it locally, because of cache coherency requirements - the local Windows cache needs a mechanism that will cause cache content to be invalidated if another system that is not a partt of the local Win environment does something to invalidate it.
We see some of these issues within VFP with table buffering; backing stores aren't updated until buffers are committed, and if a table is opened in a buffered fashion in multiple data sessions, the update of the backing store doesn't force the update of all opened buffers in all data sessions.
This is not the behavior I observe with VFP applications, .EXEs, .FXPs and .APPs alike - VFP treats portions of the executable P-Code not as memory-resident areas that reman permanently, but as swappable overlay segments, which are moved in and out of system memory as needed. This avoids many cache coherency issues, and allows very large VFP executables to operate even on memory-limited systems.
I'd love to have someone prove me wrong, but this is behavior I've been able to demonstrate pretty successfully in the past. Local copies of .EXEs and .APPs seem to make program transitions occur much faster, especially on heavily-loaded networks.
>
>Cheers,
>
>Jim N
>
>
>snippage
>>
>>The entire 3MB executable is not kept in memory; the .EXE file is referenced pretty frequently, in fact.
>>
>>Running a local copy of the executable, rather than the copy on the network, will remove the additional LAN traffic from VFP referencing the .EXE. A shortcut can be created that runs a local .EXE starting in a network directory; this approach is probably best, or at least easiest, to manage.
>>
>>The issue of keeping the .EXE up-to-date does surface when each station has its own local copy - you need to do more than simply copy the new executable in place where everyone can run it. One approach that I use is to have a loader; a small .EXE that checks a central network copy of the executable (or a .APP) against the copy on the local station. if the copy on the local station is less recent than the master copy, the master is copied over to the local machine. Once the examination and possible update have completed, the current local copy is fired via 'DO
'.
>>
>>This changes some things in VFP startup management. Since the actual .EXE or .APP isn't fired directly, it becomes necessary to move the CONFIG.FPW out of the compiled application itself, either to the loader, or preferably, to each local machine as an editable text file. The local CONFIG.FPW can be enabled by adding the -c command line switch to the shortcut firing the loader. The advantage of a local CONFIG.FPW, allowing you to tune the locations of temporary files and the like on a machine-by-machine basis, far outweigh the cost in creating it during installation and referencing it appropriately in shortcuts.
>>
>>>>
>>>>Kind regards,
>>>>
>>>>Kev
>>>>
>>>>BrainBashers: www.internet-uk.com/puzzles
>>>
>>>One common work-around for this problem is to install a 'loader' program on each workstation.
>>>
>>>When this runs, if there is no local copy of the executable, or the date of the local executable is earlier than the copy of the executable stored on the server, the loader program will copy the latest executable from the server to the workstation, The loader then runs the local copy of the executable.
