Un primo approccio a questo progetto è stato utilizzando l'opzione Default short integers 
(Options -> Compiler -> General), attivato. Il file .PRJ si presenta così:

	GRPMOUSE.PRG
	.C	[-b4 -r6 -v -w -d2 -m0 -rs -ce -ct -q- -fm]
	.S	[-m0]
	=
	CS.O
	GRPMOUSE.C	(GRPHMS.H)
	LCGS.LIB
	LCS.LIB

l'opzione -w viene scritta tra le opzione di compilazione e automaticamente vengono 
proposte le versioni di libreria che trattano appunto questo approccio: CS.O, LCGS.LIB e 
LCS.LIB. 
Questo primo modo di compilare il programma inibiva però la possibilità di utilizzare la 
funzione file creat(select, 0); la quale come valore di ritorno necessita di un int. 
Ho provato a sostituire int ad altri tipi (come unsigned short che ha un ampizza doppia 
rispetto a short visto che per dafult è considerato signed), ma senza successo.

Ho pensato quindi di "convertire" il programma affinchè possa utilizzare anche il tipo 
int. Ho disattivato la casella di selezione inerente alla voce Default short integers. 
Il file .PRJ ora si presenta così:

	GRPMOUSE.PRG
	.C	[-b4 -r6 -v -d2 -m0 -rs -ce -ct -q- -fm]
	.S	[-m0]
	=
	C.O
	GRPMOUSE.C	(GRPHMS.H)
	LCG.LIB
	LC.LIB

disattivando l'opzione -w, automaticamente l'editor di Lattice C v5.60 toglie il -w tra 
le opzioni di compilazione e aggiorna le librerie di riferimento in C.O, LCG.LIB e LC.LIB.
Per far funzionare correttamente le funzioni AES ho dovuto riscrivere i prototipi delle 
funzioni usate (trovate nella documentazione ufficiale di Lattice C) affinchè il compilatore mi potesse dare indicazioni su quale tipo errato ho usato in fase di stesura del progetto.
Per attivare l'avviso di tutti i warning ho attivato la casella Enable all warnings 
(Options, Compiler, Errors).


In un momento strano ho ricevuto anche questo errore:

undefined symbols __CXV35

generalmente questo errore avvisa l'utente che si sta utilizzando una funzione dove non 
è stato predisposto una adeguata istruzione include per includere la libreria dove questa 
funzione ne fa parte.
Ho commentato le varie funzioni per arginare il problema. Quindi ho eseguito una 
compilazione di volta in volta che andavo ad attivare le funzioni commentate fino ad 
arrivare alla visualizzazione dell'errore; ciò significava che la funzione poco prima 
attivata, in essa, c'era la causa del problema. Alla fine mi sono trovato con tutte le 
funzioni attive e senza errore. Questa cosa non l'ho capita... !


In fase di compilazione attivando tutti i warning (Enable all warning), ottengo 
un'infinità di avvisi che si riassumono in:

Assignment to shorter data type (precision may be lost)
C++-style comment derected

Ho provato a convertire in qualche modo i short in int, per non generare questo tipo di 
avviso (ho visto che al compilatore non piace fare calcoli, anche solo su piccoli valori, 
con il tipo short), ma ottengo ancora più problemi, quindi ho deciso di tenermi questo 
avviso, anche perchè sono più che sicuro che le operazioni che vado ad effettuare con 
questo tipo sono dentro il range dei valori supportati.

Per quanto riguarda il C++-style comment derected, il compilatore si riferisce al 
commenti fatti così:

// in questo modo

che sinceramente io preferisco ai commenti così:

/* in quest'altro modo */

Questo perchè posso disabilitare una funzione con due soli blocchi di commento /**/, 
altrimenti difficile da fare se all'interno di questa ci sono commenti dello stesso tipo.

Ho dovuto commentare il prototipo di funzione:

//int wind_set(int, int, int, int, int, int);

perchè il compilatore (se tolgo il commento è rendo attivo il prototipo), mi da il 
seguente errore:

Error 72: external item attribute mismatch
Warning 87: argument count incorrect

dove al primo messaggio di errore si riferisce al prototipo e il secondo (warning) alla 
riga:

wind_set(w_handle, WF_NAME, ADDR("GraphMouse v1.0"), 0, 0, 0);


mah....