Per entrambi i toolkit, il sistema di gestione delle finestre sottostante (X-Window per Motif e MS Windows per MFC – Microsoft Foundation Classes), fornisce al software applicativo indicazioni molto “primitive” delle interazioni con l’utente. Ad esempio, le informazioni riportate possono essere del tipo: “l’utente ha premuto il tasto T”, oppure, “l’utente ha premuto il bottone sinistro del mouse alle coordinate 320, 320”. Come si può capire, partendo da queste informazioni basilari, costruire un’applicazione dotata di interfaccia uomo macchina molto complessa, richiede un tempo notevole ed inoltre tenere sotto controllo un numero elevato di dettagli di basso livello, dovuti alla natura della piattaforma sottostante, è spesso causa di errori e inevitabilmente si traduce in tempi di sviluppo (e debugging) molto lunghi.
L’esigenza di semplificare la programmazione della piattaforma grafica (il window manager) ha portato quindi alla creazione dei due toolkit prima citati, che sono divenuti nel tempo il riferimento per il mondo Windows e il mondo UNIX. Ciascun toolkit ha presentato la propria soluzione ai problemi tipici di programmazione di una interfaccia grafica e come spesso accade, nessuno sforzo è stato compiuto per uniformare i due ambienti. Come risultato, abbiamo ora due toolkit grafici completamente svincolati e incompatibili tra loro, per cui scrivere un’applicazione per entrambi i sistemi operativi (MS Windows e UNIX-Motif) richiede la stesura di due interfacce utentie completamente diverse, con grande spreco di risorse per lo sviluppo e il test.
Per dare un esempio tangibile di questa diversità, vediamo come è stato risolto dai due toolkit il problema della comunicazione e vedremo infine come è stato risolto il problema dai Troll in modo elegante e “platform-independent” (indipendente dalla piattaforma).

Motif
Motif implementa la comunicazione tramite il meccanismo detto a “callback”. Le callback sono funzioni C, dotate di argomenti di chiamata predefiniti e vengono “registrate” (in pratica si registra il puntatore alla funzione callback da chiamare a fronte di un evento del mouse) all’interno di ogni componente grafico (o widget, nella terminologia Motif). Chiaramente, ogni widget Motif, deve riconoscere un preciso numero di callback, così come deve conoscerne il tipo e tutti i parametri (compreso il tipo dei parametri stessi). Tornando al nostro esempio di partenza, un bottone Motif riconoscerà quindi le funzioni di callback per gli eventi di pressione, rilascio e click del mouse.
Supponiamo ora che un bottone Motif venga premuto, il codice al suo interno andrà a verificare di quale evento si tratta, lo riconoscerà e chiamerà la funzione di callback associata o meglio la chiamerà usando il suo puntatore a funzione (il cui indirizzo è stato memorizzato in precedenza durante l’operazione di registrazione). Lo svantaggio principale di questa implementazione è che se la funzione callback (scritta dal programmatore applicativo e quindi situato sopra il toolkit stesso) non è perfettamente in linea con quanto si attende il toolkit, supponiamo ad esempio che un parametro sia un array e che il numero di elementi non sia uguale tra quanto si attende il toolkit e quanto è stato scritto dal programmatore applicativo, allora l’applicazione potrebbe bloccarsi e andare in crash (sappiamo infatti che i compilatori C non eseguono controlli sulle dimensioni degli array)
MFC
MFC impiega invece delle macro precostruite per realizzare il collegamento tra gli eventi forniti dal gestore delle finestre, chiamati anche messaggi nella terminologia Windows, con i metodi C++ (che sono praticamente funzioni callback) per la gestione degli eventi. Uno degli svantaggi principali che tutti i programmatori MFC hanno sperimentato è la complessità del “message system” di MS Windows, anche quando ci si avvale degli ambienti di sviluppo integrato e dei wizard per la creazione di finestre di dialogo basandosi su template.