>Ed,
>
>This feels like it is starting to get nasty, and there is no reason for that. I have freely admitted that I am speculating based on reasonably intimate knowledge of *other* system and that I am expecting to find similar conventions in WIN.
>
>>>Actually, as I think back more regarding OS/2, it was only for **re-entrant** programs that the mechanism (of going back to the EXE to 'refresh' needed RAM) was operational.
>>>
>>>I don't know if VFP EXEs or other WIN EXEs, for that matter, are re-entrant or if they employ some other scheme to achieve a similar status.
>>
>>Jim, are you aware of what reentrant means? Reentrant code usually means code segments that can be safely shared and executed; each instance provides its own context of execution independent of other instances while executing in the same code segment. Reentrance is an indication that multiple threads/processes can access the same code segment without interfering with other chains of execution in the same code segment in other processes or threads.
>>
>
>Yes, I know precisely the definition of REENTRANT. What have I written that leads you to believe otherwise?????

Perhaps that VFP is known not to be reentrant; each instance runs its own copy of the runtime engine, and with multiple copies of the runtime engine operating in some environments, they step on each others' global settings.

>
>>>
>>>There could be a few other reasons, besides 'refreshing RAM when required', why WIN keeps the EXE "open". Something to do with RECOVERY, perhaps, or something like 'insurance' to ensure that all users on a network are using the same program at the same time, or who knows what else.
>>>
>>>I simply have to believe, at this point, that "refreshing program RAM (because it has been 'given' to another program that needs some)" would be about LAST on the list of reasons.
>>>
>>>I come back to: the assertion that WIN *must* be going back to the EXE to "refresh" clobbered (by design) RAM is fallacious. It is a modern equivalent of 'based on all observable conditions, the sun revolves around the earth' which, by hte way, was basically believed world-wide for thousands of years.
>>>
>>
>>Obviously, I'm a flat-earther. I just know enough about Win internals to know that your hypotheses and conjectures about system behavior don't match my observations of what happens internally. And that you don't understand the relation between swap file space and cache, or the logic behind what is held in both, and the logic that determines how long things are held in each, and their management algorithms.
>>
>
>I don't know how cache has even gotten into this discussion. Nothing that I have said has any implications regarding caching. Yes, I do also know the definition of cache. Since you have brought it into the discussion, is it possible that you have some misconceptions here?

Not really. If you examine the behavior of the Windows loader functions, you'll discover that not all of an .EXE file is necessarily loaded into system RAM at startup. .EXE files an have embedded overlays which are paged on demand from the file, not loaded to system memory and then paged out to the swap file, where they would be held as active code pages.

>
>>I'd recommend doing some research, starting with the canonical Win programming guides from Petzold and Richter. A better understanding of the Windows architecture might be helpful.
>>
>
>A good recommendation, to be sure. But, frankly, I just don't have the time.
>But there is a good chance that I was using SWAP files while you were still in kindergarten, and this was in a day when the vendors told you the intimate internal details, and provided the actual code to let one see for one's self, and I spent lots of time in that code.

It's possible - I did most of my early programming on small DEC lab systems in the late 60s, and didn't work as a systems programmer on IBM's SVS and MVS operating systems or the Xerox Sigma systems until about 1976. I did spent my time in the trenches as a systems programmer, though. And I'm still there - most of the software patents that I hold now are in the areas of persistent object namespaces and active object buffer management. It might be that I've picked up a little bit about caching and virtual memory management in the last 20 years, but I could be wrong. I certainly don't have the intimate details of the internal memory management scheme for VFP to know whether VFP's p-code managmement behavior is a result of VFP's internal buffering or Windows Swap file behavior.

>Before you dismiss me with your superior knowledge you should allow that I may have something relevant to say here.

I'm not claiming superior knowledge, Jim, just that you seem to have some misconceptions about what happens when an .EXE file loads, and whether the code is brought into physical RAM from the swap file by memory address or as an overlay from the file space of the executable. Since much of a VFP executable is not actual machine code, but either p-code or embedded database images for class libraries, forms, reports and the like, and that excluding some of these items from the executable image doesn't significantly affect performance of a compiled app, I'd conjecture that VFP's behavior is more akin to a partial load of executable code segments, with inactive portions of executable code, p-code and objects loaded as overlay components on a demand basis, than it would be to loading all of the executable image to virtual memory and then addressing p-code and code objects as offsets in the process' memory address space.

>
>
>>
>>>Cheers,
>>>
>>>Jim N
>>>
>>>>Hi Evan,
>>>>
>>>>As I tried to say earlier, this *could* be because WIN, recognizing an EXE and knowing that such are read-only when executing, "knows" it can refresh code from the EXE rather than placing it on the SWAP.
>>>>
>>>>IBM used to do that in earlier OS/2, but learned that that was the obtuse way to do it. It 'locked' the EXE and took lots of specialized and slow-executing code to achieve the desired result. It (more or less) had to 'virtually' re-run the load process so that code would be sequenced correctly and so that addresses could be resolved correctly.
>>>>
>>>>It was far better to simply load the whole EXE and let the regualr SWAP mechanism work on it too. SWAP was (is) highly debugged, highly optimized, high(est?) priority, etc.
>>>>
>>>>Personally, I had thought that WIN did the 'load it all' thing too, and I am not convinced that being unable to overwrite an executing EXE "proves" the case that it does not. On the other hand, the earlier OS/2 which operated as earlier described may well have been written by MS, since that was from the days when it was still a joint project. Possibly IBM moved on while MS stayed with what it had already designed.
>>>>
>>>>If MS is doing this, you can bet on a change some day, as trhis is simply the worst way to accomplish the desired result.
>>>>
>>>>Cheers,
>>>>
>>>>Jim N
>>>>
>>>>>>>
>>>>>>>Actually I had the opposite. (I was not allowed to rename or delete either file). One interesting thing though, we are running different servers. I am using Netware 4.10.
>>>>>>>
>>>>>>>Let me research how Windows loads and EXE file into memory and I will get back to you.
>>>>>>
>>>>>>Awwww....Netware....no wonder. I think you should switch to Windows NT.
>>>>>
>>>>>I know. :-)
>>>>>
>>>>>FYI. I just tried the same experiment on my Windows NT workstation c drive. I load both the Notepad and an VFP EXE... I can't delete either while they are running.
>>>>>
>>>>>The search continues...