Il curioso amore di uno sviluppatore, ovvero: come ho imparato a non preoccuparmi e ad amare Windows

1. Prima la conclusione

Quando si sviluppano applicazioni Windows, c’è molto di cui preoccuparsi.

Si avvierà su questo PC? Funzionerà anche in un ambiente senza privilegi di amministratore? Si romperà per la differenza tra 32 bit e 64 bit? Percorsi in giapponese, percorsi lunghi, unità di rete, vecchie DLL, componenti COM, ActiveX, stampanti, comunicazione seriale, antivirus, Windows Update.

Appena si comincia a pensarci, le preoccupazioni non finiscono più.

Ma a un certo punto ho iniziato a vedere le cose diversamente.

Forse non è un difetto, ma la prova che Windows ha portato sulle spalle il lavoro reale.

Windows non è un’utopia immacolata. Ma porta con sé il software, le apparecchiature, i flussi di lavoro e le abitudini umane che continuano a funzionare sul campo da decenni.

È proprio quel caos a rendere Windows interessante, e a renderlo, per uno sviluppatore, degno di essere affrontato.

2. Lo sviluppo di applicazioni Windows porta con sé molte preoccupazioni

Nello sviluppo di applicazioni Windows, non basta che “il codice sia corretto”.

Funziona nell’ambiente locale. Funziona sul PC dello sviluppatore. Funziona anche sulla VM di collaudo.

Eppure, non c’è alcuna garanzia che funzioni sul PC del cliente.

Per esempio, possono succedere cose come queste:

• Una DLL non viene trovata
• Il runtime Visual C++ non è installato
• La versione del .NET Framework non corrisponde
• Il caricamento di una DLL a 32 bit da un processo a 64 bit fallisce
• La registrazione COM è danneggiata
• Si confondono le versioni a 32 e 64 bit di regsvr32.exe
• Codice che presuppone una directory corrente fissa si rompe sotto l’Utilità di pianificazione
• Un tentativo di scrittura sotto Program Files genera un errore di autorizzazione
• AppData\Roaming e AppData\Local vengono usate al contrario
• Va in crash con nomi utente o nomi di cartelle in giapponese
• Non si riescono ad aprire file con percorsi lunghi
• Funziona su un’unità di rete mappata ma non tramite percorso UNC
• L’interfaccia si rompe in ambienti ad alto DPI
• I calcoli delle coordinate si sfasano con più monitor
• Il risultato di stampa cambia a seconda del driver della stampante
• Dispositivi USB, videocamere, strumenti di misura e comunicazione seriale non vengono riconosciuti a seconda dell’ambiente
• L’antivirus blocca parte dell’elaborazione
• Il comportamento cambia dopo un Windows Update

Elencate così, danno quasi le vertigini.

I problemi che in un’applicazione web restano confinati tra browser e server, in un’applicazione Windows si estendono a tutto il PC. File system, registro di sistema, profili utente, stampanti, dispositivi, rete, criteri di sicurezza, programmi di installazione, runtime.

L’applicazione non si limita a “girare sopra il sistema operativo”: viene collocata dentro un vero e proprio ambiente di lavoro reale.

Per questo lo sviluppo di applicazioni Windows è difficile. Ma liquidarlo semplicemente con “Windows fa schifo” mi sembra fuori bersaglio.

Ciò che vi si appoggia sopra è la complessità del mondo reale.

3. Windows è il sistema operativo del campo

Windows non è un sistema operativo che esiste solo per la tecnologia più recente.

Fabbriche, ospedali, uffici pubblici, scuole, laboratori, emittenti televisive, apparecchiature di ispezione, terminali di accoglienza, terminali per la stampa di moduli, magazzini, negozi, contabilità, buste paga, gestione del magazzino. In luoghi come questi, ancora oggi funzionano innumerevoli PC Windows.

E lì non ci sono solo i servizi web più recenti.

Ci sono macro Excel. C’è Access. Ci sono vecchie applicazioni VB. Ci sono applicazioni aziendali basate su .NET Framework. Ci sono applicazioni residenti scritte in C++. Ci sono componenti COM. C’è ActiveX. Ci sono connessioni ODBC. Ci sono driver di stampanti. Ci sono lettori di codici a barre. Ci sono strumenti di misura con comunicazione seriale. Ci sono SDK forniti dai produttori.

E per di più, nessuno di questi esiste in isolamento.

Le persone li usano, stampano moduli, cambiano dispositivi USB, depositano file CSV in cartelle condivise; di notte girano elaborazioni batch, e la mattina dopo ricomincia il lavoro. Tutto questo funziona all’interno di quel flusso continuo.

Windows non è semplicemente una base su cui avviare applicazioni. È una piattaforma che accoglie il lavoro quotidiano sul campo, gli asset esistenti, le periferiche e persino le abitudini delle persone.

Per questo a volte sembra vecchio. A volte è complicato. A volte ci si chiede perché una certa cosa esista ancora.

Ma questo significa anche che non ha mai gettato via il vecchio con noncuranza.

4. La retrocompatibilità come forma d’amore

Se l’obiettivo fosse solo far apparire bello un sistema operativo, sarebbe più semplice tagliare via i vecchi meccanismi.

Eliminare le API vecchie. Eliminare i runtime vecchi. Eliminare le schermate di configurazione vecchie. Trattare le vecchie applicazioni come qualcosa che semplicemente non funziona più.

Facendo così, forse il progetto diventerebbe più pulito. Forse la documentazione si accorcerebbe. Forse gli sviluppatori si sentirebbero un po’ più leggeri.

Ma dietro a tutto ciò ci sarebbero applicazioni aziendali che smetterebbero di funzionare. Ci sarebbero apparecchiature ferme. Ci sarebbero realtà in difficoltà.

La retrocompatibilità di Windows è, tecnicamente, una vera scocciatura. C’è WOW64, per far funzionare applicazioni a 32 bit su Windows a 64 bit. Il registro di sistema e le DLL possono apparire in modo diverso al codice a 32 e a 64 bit. C’è quella struttura, spiazzante a prima vista, in cui C:\Windows\System32 è il lato a 64 bit e C:\Windows\SysWOW64 è il lato a 32 bit.

Anche COM è una scocciatura. Non basta depositare la DLL: a volte serve la registrazione. La registrazione è per utente o per macchina? È COM a 32 o a 64 bit? Servono privilegi di amministratore?

Con .NET Framework è lo stesso. Oggi esiste la possibilità di usare un .NET moderno come .NET 8 o .NET 9. Ma sul campo esistono ancora applicazioni basate su .NET Framework 4.x. Non si tratta semplicemente di vecchiaia: significa che quella versione ha sostenuto un lavoro reale per molti anni.

La retrocompatibilità non è un concetto solo bello. È, piuttosto, una pesante responsabilità.

Continuare a far funzionare cose vecchie significa portarsi dietro un debito tecnico. Ma allo stesso tempo è anche una forma di onestà: quella di non fermare il lavoro di chi usa il sistema.

Credo che sia proprio qui che risieda ciò che rende Windows amabile.

5. Windows è un sistema operativo fatto di strati geologici

In Windows, le tecnologie di ogni epoca si sono accumulate come strati geologici.

Win32. COM. ActiveX. Windows Forms. WPF. .NET Framework. UWP. WinUI. Windows App SDK. MSIX. PowerShell. Windows Terminal. WSL.

Ognuna ha avuto la propria epoca di comparsa, i propri punti di forza, e i luoghi in cui è stata usata.

Guardando solo al nuovo, il vecchio può sembrare un ostacolo. Ma nello sviluppo di applicazioni Windows ci sono spesso situazioni in cui non si possono ignorare gli strati più vecchi.

Per esempio, anche costruendo un’applicazione WPF, la stampa può portare a contatto con problemi di GDI e di driver delle stampanti. Anche scrivendo in C#, se l’SDK di un fornitore è una DLL nativa, si finisce a che fare con P/Invoke e problemi di bitness. Anche costruendo nuove schermate, a volte bisogna mantenere componenti COM esistenti o l’integrazione con Excel.

Windows non è un giardino perfettamente curato. È più vicino a un’immensa città rimaneggiata e ricostruita più volte nel tempo.

Ci sono grandi viali. Ci sono passaggi sotterranei. Ci sono vecchi vicoli. Ci sono nuovi grattacieli.

Ci si perde facilmente. Ma in fondo a quei vicoli, ancora oggi, gira un lavoro importante.

Ciò di cui uno sviluppatore ha bisogno non è il giudizio “vecchio significa inutile”. È la capacità di distinguere quale strato tecnologico sostiene quale attività.

6. Trasformare la scocciatura in progettazione

Nel titolo si parla di “smettere di preoccuparsi”.

Ma smettere di preoccuparsi non significa diventare superficiali. Non significa nemmeno fingere di non vedere i problemi.

Smettere di preoccuparsi significa trasformare la preoccupazione in progettazione.

Per esempio, se non si è sicuri che l’applicazione si avvii, si trasforma il controllo dell’avvio in uno smoke test.

Start-Process .\MyApp.exe

E non ci si limita a verificare l’avvio: si prova anche senza file di configurazione, senza cartella dei log, con privilegi utente standard, senza connessione di rete, senza stampante configurata, ad alto DPI, con percorsi lunghi e con percorsi in giapponese.

Se le DLL preoccupano, si verificano le dipendenze. Se serve il runtime Visual C++, si decide se includerlo nel programma di installazione o dichiararlo esplicitamente come prerequisito. Se si usano DLL native, non si lascia ambigua la relazione tra x86, x64 e AnyCPU.

Se COM preoccupa, si mette per iscritto la procedura di registrazione e la si riproduce da zero su un PC di collaudo.

# Esempio: registrazione di una DLL COM a 64 bit
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# Esempio: registrazione di una DLL COM a 32 bit
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

Se i permessi preoccupano, si evitano progetti che funzionano solo con privilegi di amministratore. Le impostazioni per utente si mettono in AppData, quelle per l’intera macchina in ProgramData. Si evitano progetti che scrivono log sotto Program Files.

Se i percorsi preoccupano, si includono nei test caratteri giapponesi, spazi, nomi di cartelle lunghi e percorsi UNC.

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

Se il DPI preoccupa, si verifica al 100%, 125%, 150% e 200%. Con più monitor, si verifica che nulla si rompa passando tra schermi con fattori di scala diversi. Poiché WinForms, WPF e WinUI affrontano il DPI in modo diverso l’uno dall’altro, si verifica separatamente per ciascuna tecnologia di interfaccia.

Se la memoria e gli handle preoccupano, si usano Application Verifier, WinDbg, ProcDump, Process Explorer e strumenti simili. Se i crash preoccupano, si conservano log degli eventi, dump e log applicativi.

Get-EventLog -LogName Application -Newest 20

Oppure, in ambienti più recenti, si controlla il log degli eventi così:

Get-WinEvent -LogName Application -MaxEvents 20

Se preoccupano i difetti che non si riproducono sul campo, si alza la granularità dei log. “Si è verificato un errore” non basta. Quale file si stava cercando di aprire? Quale dispositivo si stava cercando? Con quale utente veniva eseguito? In quale percorso si stava cercando di scrivere? Quale DLL non è stato possibile caricare?

Trasformare la preoccupazione in qualcosa di osservabile.

Nello sviluppo di applicazioni Windows, questo è estremamente importante.

7. “Funziona sul PC del cliente” è l’obiettivo finale

Che funzioni nell’ambiente di sviluppo è importante. Che i test passino in CI è importante. Che funzioni su una VM pulita è importante.

Ma per un’applicazione Windows, l’ostacolo finale è sempre “funziona sul PC del cliente?”.

Su quel PC c’è già qualcosa installato. Potrebbe esserci un vecchio driver di stampante. Potrebbe esserci un software di sicurezza proprietario. Potrebbero essere mappate unità di rete. L’utente potrebbe non avere privilegi di amministratore. Potrebbero esserci motivi per cui Windows Update non può essere applicato subito. Potrebbe essere un ambiente senza accesso a Internet.

Per questo conta anche il metodo di distribuzione.

Basta semplicemente consegnare un exe? Deve essere un MSI? ClickOnce? MSIX? Si può distribuire tramite winget? Passerà per un sistema di distribuzione interno? Serve un programma di installazione offline? Serve la firma del codice? SmartScreen o l’antivirus bloccheranno l’applicazione?

Solo includendo, oltre all’applicazione stessa, l’installazione, l’aggiornamento, la disinstallazione, la raccolta dei log e le procedure di ripristino, ci si avvicina davvero a uno stato “utilizzabile sul campo”.

Nello sviluppo di applicazioni Windows, il software non finisce con la consegna. Deve avviarsi nell’ambiente del cliente, oggi come domani.

8. Perché amo comunque Windows

Windows ha i suoi lati scomodi. Questo è un fatto.

Le DLL. COM. Il registro di sistema. UAC. DPI. Le stampanti. I runtime. 32 bit / 64 bit. Le unità di rete. I percorsi lunghi. Gli ambienti in lingua giapponese. I software di sicurezza. Windows Update.

A elencare le scocciature, non si finisce più.

Ma gran parte di quella scocciatura deriva dal fatto che Windows ha portato sulle spalle, per moltissimo tempo, un lavoro reale.

Non butta via gli asset vecchi pur assorbendo le nuove tecnologie; ha sia una GUI che una CLI; accoglie sia le applicazioni locali che il web, sia le periferiche che i terminali aziendali, sia i PC personali che quelli aziendali.

Non è una bella filosofia unica.

Ma è forte.

E, come sviluppatore, vale la pena affrontarla.

Costruire software che funzioni in modo affidabile su Windows non significa semplicemente chiamare delle API. Significa leggere i vincoli del campo, comprendere gli asset esistenti, individuare i punti fragili, testare, osservare e correggere dove necessario.

È un lavoro poco appariscente. Ma ha valore.

9. Conclusione

Nello sviluppo di applicazioni Windows, le preoccupazioni non finiscono mai.

Ma gran parte di quelle preoccupazioni è anche il risultato del fatto che Windows, come sistema operativo, ha assorbito per moltissimo tempo un lavoro reale, luoghi reali, apparecchiature reali, gesti umani reali.

Per questo non considero Windows semplicemente un vecchio sistema operativo.

È una piattaforma enorme, complessa, un po’ goffa, che ha continuato a funzionare venendo a patti con la realtà.

E costruire software che vi funzioni in modo affidabile ha, ancora oggi, un grande valore.

Smettere di preoccuparsi.

Ma questo non significa abbassare la guardia.

Trasformare la preoccupazione in progettazione, test e osservazione.

Così, poco a poco, sono arrivato ad amare Windows.

Link di riferimento

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.