All'interno del PM (come anche in Windows) le finestre comunicano tra loro attraverso messaggi. Il sistema invia automaticamente messaggi alle finestre per ogni genere di evento. Anche le finestre comunicano tra loro attraverso l'invio di messaggi. Ci sono centinaia di differenti messaggi di sistema, ai quali vanno aggiunti quelli definiti dalle singole applicazioni.

Per esempio: cliccando su una finestra con il tasto sinistro del mouse, il sistema invia a quella finestra il messaggio WM_BUTTON1CLICK. Ci• che succede poi dipende dal tipo di finestra (in PM: dalla classe): una finestra di controllo con contenitori verificher… se sotto al puntatore del mouse c'Š un campo e, se sŤ, lo attiver…. Una finestra di Netscape controller… se sotto al mouse c'Š un collegamento e se sŤ lo seguir…, caricando una nuova pagina HTML.

I messaggi di sistema "importanti" sono numerosi, ad esempio WM_CHAR (per l'input da tastiera), WM_SIZE (quando si ridimensiona una finestra), WM_PAINT (quando Š necessario che la finestra sia aggiornata) e WM_DESTROY (quando la finestra dev'essere distrutta). E' questo che all'apparenza rende la programmazione PM tanto complicata: programmare per il PM significa in gran parte preoccuparsi di reagire a messaggi, il che Š molto differente dalla programmazione "normale", dove il programma ha solo da eseguire dei compiti in sequenza. Con il PM, se alla finestra non viene accodato nessun messaggio il programma generalmente non fa nulla. I suoi sottoprocessi resteranno bloccati in attesa di un messaggio.

Quando si registra nel sistema una funzione hook globale per i messaggi, tutti i messaggi passano attraverso tale funzione hook prima di arrivare alla finestra cui sono destinati. In questo modo la funzione hook pu• modificare il messaggio, ridirezionarlo verso un'altra finestra, fare qualcosa di completamente diverso o anche "ingoiarsi" il messaggio, impedendo di fatto alla finestra cui era destinato di riceverlo.

E' in questa maniera che funzionano tutte le note utilit… PM hook (NPS WPS, FeelX, ProgramCommander/2, X-it, Styler/2 e naturalmente anche lo hook PM di &xwp;): esse intercettano determinati messaggi e li manipolano.

Facciamo un esempio: ogni volta che lo hook PM di &xwp; incontra un messaggio WM_CHAR (quando cioŠ un tasto della tastiera viene premuto o rilasciato) viene effettuato un controllo per verificare se il tasto Š o meno nell'elenco delle scorciatoie da tastiera. Se lo Š, il messaggio viene annullato (in modo che la finestra cui sarebbe stato destinato non lo possa ricevere) e viene attivata invece l'opportuna parte del codice WPS &xwp;, che provvede ad aprire l'oggetto specificato dall'utente per quel dato tasto rapido.

La maniera in cui Š implementato lo &xwp; differisce dall'implementazione abituale di questo genere di utilit…: la maggior parte di questi programmi registrano la propria funzione hook quando vengono avviati e la deregistrano alla chiusura (quando, per es., si sceglie "chiusura" dall'elenco finestre).

Lo hook PM di &xwp;, invece, viene registrato da uno speciale programma che non appare nell'elenco finestre -- il demone &xwp;, XWPDAEMN.EXE. E' possibile vederlo solo usando WatchCat o un analogo gestore di task. Chiudendo tale programma si perdono subito tutte le funzionalit… garantite dallo hook.

XWPDAEMN.EXE viene lanciato da &xwp; quando la WPS si avvia la prima volta, dopodich‚ continua a funzionare finch‚ il sistema non viene chiuso. Il demone, quindi, sopravvive anche ai riavvii della Scrivania.

Anche se il demone Š un programma PM, esso non crea nessuna finestra (eccetto quella dell'&pgr;; vedi pi— sotto).

Nel dettaglio questo meccanismo Š in realt… molto complesso, perch‚ Š necessario l'uso di memoria condivisa e attente tecniche di serializzazione, come semafori mutex condivisi e messaggi ad elaborazione incrociata, specie quando lo hook Š controllato da pagine impostazioni WPS che girano all'interno del processo WPS. Spero comunque di avere almeno reso l'idea dell'insieme.

Ci sono diverse ragioni che mi hanno portato a scegliere questo approccio:

1. Avviare hook dal processo PMSHELL.EXE non Š generalmente una buona idea, dato che tutte le classi WPS girano al suo interno. Se la WPS crolla, diventa molto pi— complicato eliminare gli hook installati, proprio a causa della complessit… della WPS stessa.

2. Dato che il demone continua a funzionare durante il riavvio della Scrivania, esso Š in grado di conservare dati importanti ai fini del riavvio stesso. Per esempio, la cartella avvio &xwp; non viene nuovamente riprocessata al riavvio della WPS, a meno che l'utente non l'abbia richiesto esplicitamente. Provare Š semplice: se si uccide il demone e poi si riavvia la Scrivania, la cartella avvio &xwp; verr… processata nuovamente, perch‚ le classi WPS &xwp;, non rilevando la presenza del demone, riterranno che la WPS stia venendo avviata per la prima volta.

3. &pgr; Š parte del demone ed Š perci• anch'esso indipendente dalla WPS. &pgr; richiede che sia controllata una gran quantit… di messaggi e ha bisogno di essere informato sulla creazione o distruzione di finestre. In qualsiasi momento &pgr; deve conoscere lo stato di ogni finestra nel sistema. Funzionando come processo separato, per &pgr; Š pi— facile tenere le proprie finestre distinte dal resto del sistema.

   Ulteriori dettagli su &pgr; si possono trovare alla pagina "Funzionamento" nella sezione dedicata a &pgr;.