Diciassette giorni fa ho fatto il primo commit di PDF Side Viewer. Oggi il programma è alla 0.9.0, sono circa quattordicimila e ottocento righe di C++ divise in trentanove file, e da stamattina sa mostrare tre documenti affiancati invece di due.

La domanda che mi farei se leggessi questo post da fuori è perché mai, nel 2026, uno si metta a scrivere un’applicazione desktop in Win32 puro con Direct2D per il disegno, C++20 e la libreria di rendering PDF compilata dentro l’eseguibile. Non c’è un framework, non c’è un runtime da installare, non c’è uno strato web da nessuna parte.

La ragione tecnica onesta è che questo programma fa una cosa sola e la fa mentre l’utente scorre. Due o tre viste di documento che devono restare allineate mentre le muovi sono un problema di latenza, e la latenza si controlla molto meglio quando tra la tua chiamata e la superficie di disegno non c’è niente. La seconda ragione è che l’oggetto che consegno è un eseguibile che apri e funziona, senza prerequisiti, il che per un accessorio da scrivania conta più di quanto si ammetta.

La terza ragione è che mi diverto, e questa la dico senza giri di parole.

Il prezzo lo pago in cose che altrove sono gratis. Non ho una libreria di controlli: ogni barra degli strumenti, ogni menu contestuale, ogni pannello laterale è codice mio. Non ho neanche una suite di unit test, il che è una scelta discutibile che ho fatto consapevolmente: quasi tutto quello che vale la pena verificare qui riguarda il comportamento della finestra, non una funzione pura. La verifica gira quindi dall’esterno, pilotando l’eseguibile con i messaggi di Windows da uno script PowerShell che apre documenti veri, scorre, aggancia i due riquadri e controlla dove sono finiti. È collaudo end-to-end su un oggetto grafico, e per questo programma è l’unica cosa che misuri davvero qualcosa.

Ci sono poi due decisioni che non riguardano le prestazioni ma la prudenza, e sono quelle di cui vado più fiero.

La prima. Il visualizzatore parla con l’editor di testo: da una formula nel PDF salto alla riga di sorgente che l’ha generata, e viceversa. Per fare il salto all’indietro deve lanciare un comando, e il modello di quel comando sta in un file di configurazione che qualunque processo dell’utente può riscrivere. Se il visualizzatore girasse con privilegi elevati, obbedire a quel file significherebbe eseguire ad alta integrità un comando scritto da chiunque. Perciò, se rileva di essere elevato, si rifiuta e basta. E si rifiuta anche quando non riesce a stabilire con certezza se lo è.

La seconda. L’integrazione con il menu contestuale di Esplora risorse è registrata solo per l’utente corrente, in un ramo che per costruzione non può rendere il programma il gestore predefinito dei PDF. Un accessorio che si prende il doppio clic su tutti i PDF del sistema è un accessorio maleducato, e di quelli ne ho installati abbastanza da sapere quanto dà fastidio.

Sul terzo riquadro, invece, non c’è nessuna motivazione architetturale. Ho tre edizioni dello stesso libro, italiano, inglese e ungherese, e la settimana scorsa mi sono accorto che continuavo ad aprire e chiudere la stessa coppia per guardare la terza. Il codice era già pronto a generalizzare, perché la sincronizzazione lavora su una catena di corrispondenze e non su una coppia speciale, quindi il lavoro vero è stato tutto nell’interfaccia.

È buffo ripercorrere la catena. Sono tornato all’università per una laurea, dalla laurea è uscito un libro, dal libro sono uscite tre edizioni, e dalle tre edizioni è uscito un visualizzatore PDF con tre riquadri. Nessuno di questi passaggi era nel piano, e sono l’unico responsabile di tutti.

Ultima modifica 27/07/2026