Home
Corso di Visual C++ (parte 3)

03 Dicembre 1999

Corso di Visual C++ (parte 3)

di

Il Sistema di smistamento dei messaggi

Questa puntata sul sistema di gestione dei messaggi di Windows è purtroppo più teorica che pratica, ma è assolutamente necessario comprenderla bene per proseguire con il corso.
Avete già letto la prima parola nuova: messaggi. Infatti il SO (Sistema Operativo) Windows basa il suo funzionamento sull’invio e la ricezione di messaggi che si verificano in seguito all’interazione tra voi e la macchina.

Ad esempio, la pressione di un tasto invierà un messaggio alla finestra attiva in quel momento, idem per i movimenti del mouse e i relativi clic; meno ovvio è invece che vengano mandati dei messaggi dal vostro programma al SO; ciò si verifica ad esempio quando voi nascondete una finestra e una volta che questa riappare ha bisogno di essere ridisegnata, oppure quando il vostro programma richiede dei dati relativi allo schermo o allo screensaver.

Quindi, mentre con il modello di programmazione tradizionale eravate abituati alla funzione main(), ora con Windows ve ne dovrete dimenticare. Prima era possibile sapere esattamente cosa faceva il programma in ogni istante, infatti main () poteva richiamare delle funzioni e queste ancora altre, ma tutto seguiva un preciso iter logico che dipendeva solo dall’interazione con l’utente; in Windows, invece, è il sistema operativo che determina cosa eseguire in un determinato istante e cosa in quello successivo.

Ovviamente molte di queste operazioni avvengono a causa dell’utente, ma per voi è impossibile ipotizzare che subito dopo, ad esempio, un clic del mouse venga richiamata la vostra funzione che se ne occupa. Infatti il SO potrebbe decidere di finire prima lo scandisk, di rigenerare la finestra di un’altra applicazione, di chiudere lo screensaver e mille altre cose.

I programmi Windows utilizzano un modo di operare definito event-driven (guidato dagli eventi) e si occupano quindi solo di gestire i messaggi che vengono inviati loro dal SO e non sanno a priori cosa fare quando hanno ultimato tale compito. Questo modo di procedere è dovuto al fatto che Windows è un ambiente multiprocessing e multitasking; è cioè capace di eseguire più operazioni contemporaneamente e in modo del tutto trasparente per l’utente. Come potrete intuire ciò non può essere del tutto vero (in particolare in sistemi single-processor), ma l’effetto finale è quello; infatti il SO si occupa di gestire il tempo della Cpu e di ripartirlo tra le varie applicazioni aperte in un dato momento.

É per questo motivo che un programma non ha un singolo cammino di esecuzione, ma deve aspettare che il sistema operativo gli dica cosa fare, e con Windows a 32 bit (i successori della versione 3.11) non può neanche fare in modo che una funzione impieghi troppi cicli macchina perché senza che se ne accorga verrà interrotto e ripreso più tardi quando le altre applicazioni avranno finito il loro compito.

Tutto questo processo noto come Scheduling è molto complesso e deve tenere in considerazione anche il fatto che ogni programma ha delle priorità in base alla sua importanza e in base al tempo che è trascorso da quando è stato messo in pausa; tutto ciò è anche alla base delle differenze, con sistemi multi-processing, tra Windows 95-98 ed NT.

D’ora in poi quando un programma è in esecuzione, lo chiameremo processo, e non ci occuperemo del fatto che è attualmente in esecuzione o in pausa, dato che ciò non è da noi rilevabile (non siamo ancora dei GURU); infatti se dal programma chiedessimo se è attualmente in esecuzione mentre è in pausa, dovremmo aspettare che si riattivi per avere la risposta.

Ritorniamo a cose meno teoriche
Un programma va in esecuzione richiamando la funzione WinMain, questa a sua volta si occupa della creazione di una “pompa dei messaggi” che si occupa di recuperare i messaggi mandati da Windows, eleborarli e poi richiamare le funzioni del nostro programma che si occupano della loro gestione.

Questa “pompa dei messaggi” è implementata in una funzione definita WindowProcedure e normalmente si chiama WndProc; ad essa vengono passati come parametri un puntatore alla finestra destinataria, un identificativo del messaggio più altri parametri che serviranno per interpretare il comportamento del messaggio.

Tutto ciò fortunatamente ci è nascosto da MFC, ma lo avremmo dovuto conoscere bene se stessimo programmando con le API. Ci è comunque necessario conoscere questi aspetti nascosti per capire bene come funziona Windows e come sfruttarlo appieno.

Iscriviti alla newsletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.