Hi Hilmar,
>I was just guessing. But your questions about large executables are making me change my mind - of course it won't be all in RAM if it doesn't fit. It will either be loaded from the server, or saved on virtual memory. I don't know for sure whether the OS (or VFP?) would load the entire EXE on startup, load individual parts as needed and then keep it in cache (virtual memory?), or reload more than once from the server.
>
>I still suspect that the fact of keeping an EXE on the server isn't a big deal for performance, but I am not sure.

I have no concrete knowledge of the inner workings of the running vfp (and I sometimes hate that fact <g>). So the following is mostly based on "guessstimation"...

If you remember the FPD 2.0 version, there was the option to either start the "extended" or normal version. Both versions would run against the same compiled app's. AFAIR was the non-extended version a special overlayed version, which would swap in modules as needed. So at least once there was an overlaying scheme. I haven't checked recently, but AFAIR there is only a size limit on the compiled code per function, not on the number of functions in a program or app. That makes me also believe, that there is a loading mechanism at work, which will only load the "currently asked for" part of the app into memory.

Also there is some evidence from some timing experiments, that vfp caches objects from the time on they are used explicitly from an open vcx. Since the vcx is just a dbf with another extension, I presume that behaviour to be the same when the vcx is included into the app/exe, which would translate into consecutively asking for single records of the vcx/scx part of the server file.

All of the above makes me assume that starting an exe from a network drive will not result in one call for a rather large amount of memory across the net, but possibly many minor calls. So the "danger" of having to wait for some other priorized call on the server is much higher: if the net hangs on program start, the users will mutter and be angry on the admins, but afterwards "the program is running, it must be written badly". A small degradation will surely follow just by throwing out not asked for parts of the exe out of the disk caching done by the server, which would probably not happen on the WS, since the chance of asking for other parts of the disk should be greater on the server. Since perception is most of the times more important than the real facts, I try to make myself as small a target as possible <g>.

I think the in other threads clearly desribed method of using a startup to check for and possibly download current versions has also more merits from a deployment point of view, so that alone would make me use that approach. I also believe that in a well running network the overhead of calling the apps/exe on the server is not all important. I doubt that the mechanism is the (from a network perfromance point of view) block loading of all the bytes in the exe, which was previously mentioned.

So at least for now I will stick to running the program files from a local disk if possible <g>. If anyone has more info on the actual workings or some experimental evidence, I'ld be glad to receive some lines about it. So: anybody out there with some network sniffing tools, a network based exe and some budget for optimization timing ? Can somebody point me to documentation about the mechanisms at work for app running (or write a few lines from a MS/VFPTeam - point of view, if it isn't sensitve information) ?

my 0.02 EUR

thomas