precauzioni per le funzioni In-Context hook

Per motivi di prestazioni, gli sviluppatori client registrano funzioni di hook nel contesto. Tuttavia, poiché queste funzioni di hook vengono mappate nello spazio indirizzi del server, gli sviluppatori client e server devono prendere precauzioni per garantire che l'elaborazione degli eventi vada senza problemi.

Precauzioni per gli sviluppatori client

Gli sviluppatori client devono essere consapevoli dei problemi seguenti:

• Le funzioni di hook nel contesto non devono usare molto tempo per il processore, perché la funzione hook deve restituire prima che l'applicazione server continui.
• Dopo aver attivato un evento, è possibile che la finestra associata a un evento non esista più per il momento in cui viene chiamata la funzione hook. I client devono verificare che la finestra associata a un evento esista ancora prima di eseguire qualsiasi altra azione correlata all'evento. Per assicurarsi che esista ancora una finestra, i client usano la funzione Microsoft Win32 IsWindow .
• Se la DLL in cui la funzione hook è definita collega a un'altra DLL, gli sviluppatori client devono assicurarsi che il sistema carica l'altra DLL. Se si collega in modo implicito (usando file con estensione def e importazioni), la DLL aggiuntiva deve trovarsi nella directory di Windows o in una delle directory di sistema, ad esempio Windows\System, Windows\System32 o Windows\SysWOW64. Se si collega in modo esplicito (usando LoadLibrary), il percorso completo della directory in cui risiede la DLL aggiuntiva deve essere specificata nella chiamata a LoadLibrary.
• Le funzioni di hook nel contesto possono causare un overflow dello stack quando la DLL che contiene la funzione hook viene caricata in un'applicazione a 16 bit. Questo problema si verifica perché le applicazioni a 16 bit usano dimensioni fisse dello stack che non sono sufficienti per soddisfare la catena di chiamate di funzione di sistema che generano una chiamata alla funzione hook.

Precauzioni per sviluppatori server

Gli sviluppatori del server devono tenere presente che le applicazioni client potrebbero registrare funzioni di hook nel contesto. Quando un server chiama NotifyWinEvent, deve essere preparato per gestire WM_GETOBJECT e altri metodi IAccessi .

Puntatori di interfaccia non validi

Quando un client chiama AccessibleObjectFromEvent all'interno di una funzione di hook nel contesto, il puntatore dell'interfaccia IAccessibile restituito punta direttamente al codice nello spazio indirizzi del server. Se il client chiama una proprietà di interfaccia usando questo puntatore, la libreria Component Object Model (COM) non è coinvolta nel marshalling (creazione di pacchetti e invio di parametri di interfaccia tra limiti di processo) o unmarshaling (parametri di decomprimemento inviati tra limiti di processo) e non rileva se un oggetto viene eliminato.

Se il client chiama una proprietà dell'interfaccia a un oggetto eliminato, il puntatore dell'interfaccia non valido causa un errore di protezione generale nello spazio indirizzi del server, a meno che il server non rilevi questa situazione.

Per proteggere i puntatori di interfaccia non validi, i server creano oggetti proxy che esegue il wrapping di oggetti accessibili e monitorano l'intervallo di vita degli oggetti accessibili. Ad esempio, quando un client chiama una proprietà IAccess per ottenere informazioni su un oggetto, il proxy verifica se l'oggetto accessibile è ancora disponibile e, in tal caso, inoltra la richiesta del client all'oggetto accessibile. Se l'oggetto accessibile viene eliminato, il proxy restituisce un errore al client.