>Mainly, Ed, it seems you like to argue (and maybe I do too).
>
>Let me re-phrase my prior (though I tought it wouldn't be necessary for the drift to be caught!). . .
>
>IF one has marked the program as REENTRANT, it is because the program has been written to not self-modify nor to reference variable (my term) RAM unless it has been getmained and addressed indirectly.
>A program which is not marked as reentrant cannot be trusted to remain wholly identical throughout its lifetime.

Unfortunately, that isn't the definition of reentrant. I'm not going to waste time arguing with you on this - I'd suggest a course in systems programming. Reentrant means that more than one instance of execution (fiber/thread/process) can be active in the same code segfment (in fact, in the same routine in a common code segment) simultaneously, without interfering with each others execution context. One of the characteristics of reentrant code is that each execution instances' state is independant of any other instance. This implies that the shared code segment cannot be modified. However, that is not enough to make a piece of code reentrant.

Reentrance also requires that execution instances have completely independant context, and that their context is reestablished when their instance is activated. This implies that any writable segment be context-specific; memory need not be, as you put it, getmained and addressed indirectly; for example, storage allocated on the stack or on a local heap that is not shared can be directly addressed as a 32 bit address in the 32 bit x86 environment; the MMU takes the responsibility for resolving the context of an address in the linear address space without the need for indirection or visible mapping through segment registers. It is equally important that the state of common system resources, such as system registers, be restored when context is shifted; if thread of execution doesn't cause the hardware to save and restore register states, the code can't make use of the system registers! There have been flaws in some of the Intel processors' state maintenance in this regard; one that pops to mind is a flaw in the early MMX state maintenance logic, which did not save the state of FP registers properly when an MMX instruction was in progress during a state transition.

Read Richter's Advanced Windows, or Oney's Systems programming for Windows 95; both books deal in detail with the issues of execution context, address resolution, and reentrance. For a more general view, Lorin & Deitel's Operating Systems is a great reference that isn't Wintel specific; they examine a very broad range of concepts, and cover a wide range of operating system case studies, including the IBM big-iron perspectives (they cover both MVS and VM/CMS conceptually in some detail).


>
>A program can, of course, be inaccurately marked as reentrant, in which case trouble will likely ensue.
>
>Hope that comes closer
>
>Jim N
>
>>>Ed,
>>>
>>>I'm sorry, but I cannot agree that reentrancy is *not* a requirement.
>>>
>>>A non-reentrant program does, by definition, modify some portion of *ITSELF* (in RAM, of course).
>>>This being the case, the version which is the EXE *cannot* be trusted to be exactly identical in all respects to the one currently executing in RAM (which has probably changed some piece of itself).
>>>It would mean havoc to bring in the EXE piece of code in such a case.
>>
>>Not really. A trivial example of such would be code that references statics or globals in shared data segments; even though the code segments are not altered, each executing instance is not isolated from other instances in its data segments - a change in a shared static or global affects all running instances that share that data item. Even though the code isn't self modifying, and in fact, the code segment is static and not modified in any way. Reentrance is not equivalent to not self modifying.
>>
>>
>>>
>>>Jim N
>>>
>>>>>Kevin,
>>>>>
>>>>>Unfortunalely, this is *not* the answer to your query.
>>>>>
>>>>>Assuming that you are talking VFP 5 or later, MS should have removed any 'overlays' which might previously have been incoroprated into the VFP EXE. One could then assume that EXEs built by VFP would have the same characteristic.
>>>>>
>>>>>Notwithstanding this, it seems plausible (Ed R. who surely knows more actual details than me on this issue) that bits given up to other active programs in RAM *might* be re-loaded from the EXE. I feel that, to do so, the EXE generated by VFP would have to be re-entrant, and I am not so sure that this would be the case.
>>>>
>>>>Reentrance is not a requirement here. Multiple instances of VFP could easily be active and loading in sections ofd the executable file at will without reentrance; they each have their own addrss space, and their own code segments, and are simply dealing with offswets in a file that isn't changing. Reentrance is an issue where the same code segment (the code in memory) is being shared among several processes, each with their own data and system context. It's no different than sharing any other read-only data source. Even if there were sharing of the code segments taking place, the p-code isn't real native machine code...
>>>>
>>>>>
>>>>>Have you tried to get more absolute information as to exactly what is being referenced on the Server that is creating the troublesome traffic?
>>>>>
>>>>>Good luck,
>>>>>
>>>>>Jim N
>>>>>
>>>>>>>So Kevin, look what you started...
>>>>>>>
>>>>>>>I am just wondering what you are going to do. Can you go with local EXEs on each machine?
>>>>>>>
>>>>>>
>>>>>>I might, however, the actual question has not yet been answered.
>>>>>>
>>>>>>My clients load the 3 meg exe in the morning once only, so I will not reduce afternoon traffic this wasy.
>>>>>>
>>>>>>That is unless the system will keep reloading bits from the server as needed.
>>>>>>
>>>>>>I really want to know if once a section has been loaded from the server (or all of it) does it get reloaded again later.
>>>>>>
>>>>>>Any further ideas?
>>>>>>
>>>>>>Kind regards,
>>>>>>
>>>>>>Kev
>>>>>>
>>>>>>BrainBashers: www.internet-uk.com/puzzles