Zitat:
Normalerweise sollte das Laden jedoch länger dauern, weil ja erst alles rüberkopiert und in die Auslagerungsdatei gestellt wird.
Nein.
Rüberkopiert muß es so oder so werden.
* OHNE wird es vom Share in den
RAM geladen
* auch MIT wird es vom Share in den
RAM geladen
aber gibt es zu wenig speicher, dann wird
RAM ausgelagert
* OHNE wird es einfach freigegeben und beim nächsten Zugriff (PageFault) erneut vom Share geholt
. (genauso wie normal auch, bei EXE/
DLL/
BPL auf der Festplatte, da wird es auch von dort geholt)
* MIT wird es in die Auslagerungsdatei entladen und dann von dort zurückgeholt
Damit bei IMAGE_FILE_NET_RUN_FROM_SWAP, wenn der Share nicht mehr erreichbar ist, es dennoch verfügbar bleibt (oder auch wenn Share langsam ist, damit es von lokal schneller geht)
bzw. bei IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP, wenn USBStick oder externe Festplatte abgezogen wurden.
Blöd an IMAGE_FILE_NET_RUN_FROM_SWAP und IMAGE_FILE_REMOVABLE_RUN_FROM_SWAPist, dass es nicht an der EXE hängt und für alle DLLs verwendet wird,
sondern man es für jede einzelne
DLL/
BPL setzen soll ... besonders unpraktisch, bei Fremdcode (vorallem wenn auch noch signiert).
Was wir mitbekommen haben, was ihr also besser niemals machen solltet:
Die EXE/
DLL im Rootverzeichnis eines Shares ablegen, sondern immer in einem Unterverzeichnis ... Windows ist doof und hat da eine teilweise sehr extrem bremsende Eigenart, wenn die $
IPC-Freigabe fehlt oder nicht richtig arbeitet.
Wir haben an die 80-100 EXE/
DLL/
BPL und dann noch die Millionen BPLs von DevExpress und Co.
Ist besonders geil, wenn beim Laden Windows pro Datei 15 Sekunden braucht. (der Timeout beim Zugriff auf diesen $
IPC)