Un programma "Win32 API" non dispone dei normali "servizi di sistema" cui un programma C può di solito fare riferimento (come, ad esempio, l'esistenza di file già aperti per standard input, standard output, e standard error); ne ha a disposizione, per contro, molti altri, appunto tutta la ricca interfaccia delle "Win32 API".
Volendo, potreste, per la maggior parte, continuare ad usare le funzioni della libreria Standard C (segnaleremo presto quelle poche che invece non si applicano), ma può essere che, così facendo, vi troviate ad avere un programma più grosso del necessario, poichè esso "re-implementa" (nelle librerie standard C che il vostro compilatore linka con esso) funzionalità già messe a disposizione dalle librerie di sistema di Windows, magari in modo molto simile. Ad esempio, per formattare un numero (intero) su di una stringa, potete, come sempre, scrivere:
wsprintf invece della sprintf dello
standard C, il programma compilato e linkato
sarà più piccolo, magari di vari
KByte. wsprintf non supporta tutti i formati della sprintf
dello standard C (ad esempio, mancano %f, %g,
e %e, quindi tutta la possibilità di formattare numeri a
virgola mobile), ma ne supporta alcuni altri, per tipi particolari,
importanti in Windows, come le stringhe UNICODE.
Win32 utilizza molte macro e typedef
(definite in windows.h, e/o nei
file che esso include a sua volta) per definire i tipi esatti
degli oggetti che tratta; ad esempio, viene regolarmente
usata ULONG invece di "unsigned long", eccetera. Noi
rispetteremo questa convenzione, anzitutto per chiarezza
e congruenza con altre pubblicazioni su Windows, e poi
per l'aiuto che essa può portare ad eventuali future
"migrazioni". Ad
esempio, è in corso di preparazione una versione a 64
bit di Windows; le applicazioni scritte interamente nel
rispetto delle convenzioni Microsoft saranno senza dubbio
più agevoli, dal punto di vista del
"porting" a questa futura "Win64", di
quelle scritte in termini di "veri" tipi C.
Un'altra convenzione Windows, che rispetteremo spesso
(ma non sempre!-), è quella della 'notazione ungherese', per
cui i primi caratteri del nome di una variabile codificano
il tipo della variabile stessa (ad esempio, lpszQualcosa
per una variabile che è un puntatore ad una stringa di
caratteri terminati da 0 binario, cioè normale stringa C).
Il risultato è certo "brutto", ma può aiutare a chiarire
quali tipi siano in gioco in una data operazione. Per altri
dettagli sulla notazione ungherese, si veda ad esempio il
testo originale di Charles Simonyi della Microsoft, che
introdusse il concetto.
Ci scuserete, infine, se occasionalmente ci capita di usare
un paio di cosette comodissime del linguaggio C++, non
supportate dal vecchio standard C (dovrebbero essere invece
supportate dalla nuova versione dello standard C, quando
essa verrà approvata): i commenti in-linea con // (che,
fortunatamente, sono supportati come estensioni anche da
molti compilatori C), e l'idea di dichiarare le variabili solo a
partire dal punto in cui servono davvero, invece di doverle
porre tutte a inizio blocco.
Se il vostro compilatore non è in grado di
accettare esempi che usano queste estensioni, cambiate i
commenti nella forma standard C /* ... */,
portate tutte le varie
dichiarazioni all'inizio di ciascun blocco, e tutto dovrebbe
andare! Tenete inoltre presente che, se il vostro compilatore
supporta sia il C, sia il C++, per usare queste comodissime e
semplici feature del C++ può essere sufficiente che voi
chiamiate un certo file sorgente "qualcosa.cpp" invece di
"qualcosa.c" (oppure, il compilatore potrebbe mettere a vostra
disposizione una opzione di configurazione, ovvero una opzione
di linea comandi, per ottenere lo stesso risultato; vi conviene
familiarizzarvi a fondo con queste caratteristiche del compilatore
che avete scelto, poichè conoscerne bene le possibilità
e le limitazioni vi risparmierà, "a corsa lunga", non
poco tempo e lavoro).
Capitolo 0: preliminari
Capitolo 2: disimparare ancora
Elenco dei capitoli