La funzione &xshutdown; mi ha richiesto molto lavoro, dato che da nessuna parte si trova documentato cosa effettivamente avviene durante il normale processo di chiusura.

&os2; per default riconosce due differenti API di chiusura:

Il problema Š che non c'Š una "via di mezzo" tra queste due API. Se si richiama DosShutdown la WPS non viene salvata. Se si richiama WinShutdownSystem si ha la normale chiusura del sistema, senza possibilit… alcuna di intervento. E' stato quindi sostanzialmente necessario scrivere uno WinShutdownSystem completamente nuovo che adesso spiegheremo nel dettaglio. E' stato un lavoro difficile dato che IBM non dice praticamente nulla di quanto avviene durante WinShutdownSystem.

Nota: in &xwp; le routine "Chiusura avanzata" e "Riavvio Scrivania" condividono lo stesso codice; la differenza sta in quello che succede quando tutte le finestre sono state chiuse. Di qui in avanti user• il termine "&xshutdown;" riferendomi ad entrambe le routine, eccetto dove esplicitamente indicato.

&xshutdown; Š integrato nella WPS e si basa strettamente sulle classi sostitutive &xwp;. Ho intenzionalmente evitato di mettere il codice &xshutdown; in un file .EXE separato per due ragioni: in primo luogo, &xshutdown; deve poter accedere ai dati interni della WPS, che sono disponibili solo nel contesto SOM; secondo, ho voluto evitare che qualcuno potesse cercare di usare &xshutdown; separatamente, senza aver installato le classi &xwp;; una cosa del genere potrebbe danneggiare gravemente la Workplace Shell! In dettaglio, &xshutdown; si basa sulla classe sostitutiva XFldObject e sul sottoprocesso Worker di &xwp;, che assieme tengono traccia dei dati interni alla WPS.

Per capire come funziona la &xshutdown; bisogna comprendere come la WPS gestisce internamente i suoi oggetti. Ogni oggetto "incontrato" dalla WPS durante il popolamento di una cartella o con la lettura delle sue impostazioni o all'avvio di un programma od altro ancora, per il sistema Š "svegliato" ("awakened", nella terminologia WPS): esiste cioŠ nella memoria del sistema come oggetto SOM.

Solo di rado la WPS rilascia gli oggetti "svegliati", liberando la memoria ad essi associata e salvando i dati relativi agli oggetti sul disco. Questo ha due conseguenze:

  1. Nel sistema ci sono sempre molti pi— oggetti "svegli" di quanto non si pensi, dato che la maggior parte di essi in quel dato momento non Š visibile. Anche dopo che si Š chiusa una cartella, gli oggetti al suo interno restano "svegli" (questo per poter popolare pi— rapidamente la cartella quando la si apre una seconda volta). La WPS quindi consuma sempre pi— memoria ad ogni nuova cartella che si apre. (Se si Š attivato il file log per la &xshutdown; si pu• vedere quanti sono gli oggetti "svegliati" che &xshutdown; deve salvare; saranno generalmente parecchie centinaia di oggetti, e questo anche se la &xshutdown; non salva tutti gli oggetti "svegliati" ma solo i discendenti delle classi WPFolder e WPAbstract. Dalla pagina "Stato XWorkplace" nell'oggetto "Impostazioni XWorkplace" si pu• vedere quanti sono gli oggetti "svegli" in un dato momento).
  2. Pu• capitare che un cambiamento nei dati di un oggetto abbia effetto solo sull'oggetto SOM nella memoria, ma non sempre sia salvato sul disco o nei file OS2.INI / OS2SYS.INI. E' per questo motivo che si possono avere problemi con la WPS se, per esempio, si sposta una cartella contenente molti oggetti astratti e poi non si chiude correttamente il sistema: i dati fisici relativi al file sul disco e quelli nella WPS differiscono.
E' a questo che serve alla &xshutdown; la classe XFldObject, che sostituisce quella WPObject. Ogni volta che un oggetto viene svegliato, la WPS richiama diversi metodi (tra gli altri wpInitData e wpObjectReady). XFldObject subentra a questi metodi segnalando l'indirizzo dell'oggetto in memoria al sottoprocesso Worker, che provvede a tenere opportunamente aggiornata una lista interna ad &xwp; di tutti gli oggetti "svegli" nel sistema. Per quanto ne so, non c'Š un'altra maniera per sapere quali oggetti sono "svegli" in un dato momento; per lo meno, non c'Š nessuna API documentata per conteggiarli.

Ora, quando si avvia la &xshutdown; per prima cosa vengono avviati due nuovi sottoprocessi, funzionanti parallelamente ai normali sottoprocessi WPS e specifici per le procedure di chiusura: il principale Š il sottoprocesso "Shutdown", con la coda messaggi per la finestra di stato, mentre l'altro Š il sottoprocesso "Update", che controlla l'Elenco Finestre &os2; ed invia messaggi al sottoprocesso di chiusura principale per aggiornare la finestra di stato. Chiudere tutte le finestre aperte Š quindi una complessa interazione tra questi due sottoprocessi: "Shutdown" chiude una finestra e poi si mette in attesa finch‚ "Update" non rileva un cambiamento nell'Elenco Finestre (che sta a significare la corretta chiusura della finestra) ed invia un messaggio di conferma a "Shutdown", che passa a chiudere la finestra successiva e cosŤ via finch‚ non sono state chiuse tutte le finestre.

Una volta chiuse tutte le finestre, il sottoprocesso "Update" termina mentre "Shutdown" passa a scorrere la lista (di cui si Š detto prima) di tutti gli oggetti "svegli" in quel dato momento e forza il salvataggio dei dati su disco o nei file INI, richiamando per ciascun oggetto il metodo wpSaveImmediate. Quest'ultimo punto Š eseguito solo per gli oggetti derivati di WPAbstract e WPFolder, dato che secondo la mia esperienza le altre classi salvano comunque i loro dati in maniera sincronizzata (ho provato una volta a salvare tutti gli oggetti discendenti di WPFileSystem, ma questo ha causato la creazione di una quantit… di attributi estesi per ogni singolo file svegliato dalla WPS. E, a parte questo, la chiusura richiedeva un tempo infinito).

Infine, a seconda dell'azione scelta all'inizio, il sottoprocesso "Shutdown" segue una delle due strade seguenti: