Chi si diverte ad aprire un file eseguibile Windows con un editor esadecimale (HxD va benissimo, per dire) si ritrova davanti qualcosa di inaspettato. Ogni file .exe, anche quelli più moderni, comincia con una firma che arriva dritta da un’epoca ormai lontanissima. Le prime due lettere sono MZ, e subito dopo compare un piccolo programma DOS che stampa il messaggio “This program cannot be run in DOS mode”. No, non è un errore e nemmeno un residuo dimenticato da qualche sviluppatore distratto. È una scelta progettuale precisa, che risale ai primi anni Ottanta e che ancora oggi ha un peso concreto su strumenti, loader e persino su alcune tecniche di sicurezza.
Per capire come mai questa struttura sia sopravvissuta fino a oggi, bisogna fare un salto indietro nel tempo. Quando MS-DOS era la piattaforma dominante su PC, gli eseguibili utilizzavano un formato piuttosto semplice, identificato proprio dalla firma MZ. Quelle due lettere sono le iniziali di Mark Zbikowski, uno degli ingegneri Microsoft che contribuì alla definizione del layout binario. Poi Windows ha cominciato a diffondersi, prima come ambiente che girava sopra DOS e poi come sistema operativo autonomo. Il problema era chiaro: serviva un modo per mantenere la compatibilità senza mandare in frantumi il funzionamento degli strumenti già in circolazione. La soluzione? Inserire un programma DOS valido, quello che viene chiamato DOS stub, all’inizio di ogni eseguibile Windows.
Come è fatto davvero un eseguibile Windows moderno
La parte iniziale di un file si chiama header, ed è fondamentale. Senza header, un eseguibile sarebbe solo una sequenza di byte senza senso. Si tratta di un blocco di metadati che descrive il tipo di file, la sua organizzazione interna e le istruzioni necessarie per interpretarlo nel modo giusto. Nel caso degli eseguibili, l’header fa da interfaccia tra il file e il loader del sistema operativo. È quello che permette a Windows di capire come caricare il programma in memoria, da dove iniziare l’esecuzione e quali dipendenze risolvere.
Un file .exe moderno segue il formato Portable Executable, noto come PE. Però la parte PE non si trova all’inizio del file. Il loader di Windows individua l’header vero e proprio tramite un offset specificato dentro la struttura DOS iniziale, chiamata IMAGEDOSHEADER. In particolare, il campo e_lfanew indica dove cominciano la firma PE e il resto delle intestazioni. Il codice DOS che sta all’inizio dell’eseguibile non viene mai eseguito da Windows, ma resta formalmente valido.
Una precisazione che vale la pena fare: il DOS non esiste più in Windows. Le versioni della famiglia NT, da Windows NT 3.1 in poi, quindi anche Windows 10 e Windows 11, non includono alcun kernel DOS. Il sistema operativo usa un’architettura completamente diversa, basata su un kernel ibrido, gestione della memoria protetta e un modello a processi isolati. In passato esisteva un sottosistema chiamato NTVDM (NT Virtual DOS Machine) che permetteva di eseguire applicazioni DOS a 16 bit sui sistemi a 32 bit. Non era un vero DOS, però: simulava un ambiente compatibile. Con l’arrivo dei sistemi a 64 bit, NTVDM è stato eliminato del tutto. Oggi, su Windows x64, il codice DOS non può girare nativamente.
E poi c’è un equivoco che resiste da anni: il prompt dei comandi non è DOS. cmd.exe è un’applicazione Win32 che gira sopra il kernel Windows e utilizza le API di sistema. Sembra DOS per ragioni storiche e di abitudine, ma il funzionamento sotto è totalmente diverso. Lo stesso vale per PowerShell, che rappresenta un’evoluzione ancora più distante dal modello DOS, basata su .NET e completamente integrata con il sistema operativo.
Perché il DOS stub esiste ancora nei file .exe
La presenza del DOS stub all’inizio di ogni eseguibile PE non ha nulla a che fare con l’esecuzione reale di codice DOS sui sistemi Windows moderni. È una questione legata alla specifica del formato Portable Executable, punto. Può sembrare strano leggere ancora “This program cannot be run in DOS mode” nell’header di ogni eseguibile, ma quello stub funziona come contenitore iniziale allineato alle specifiche di formato. Su Windows moderno quel codice viene puntualmente ignorato.
I linker moderni, compresi quelli di Visual Studio, continuano a inserire automaticamente lo stub dentro gli eseguibili compilati. Esiste anche un’opzione, spesso chiamata /stub, che consente di sostituire quel codice con uno personalizzato. Qualcuno ha sfruttato proprio questa possibilità per costruire eseguibili ibridi: un singolo file che contiene sia un programma DOS sia uno Windows. In passato tecnologie come i DOS extender permettevano di avviare codice più complesso partendo da questa sezione iniziale. Lo stesso meccanismo è diventato protagonista di una ricerca portata avanti dalla sviluppatrice Kamila Szewczyk, che ha realizzato un unico file da 13 KB compatibile con Windows, Linux e browser Web.
Eliminare completamente il blocco MZ sarebbe tecnicamente possibile, ma significherebbe aggiornare specifiche, loader e tool esistenti. Il beneficio reale sarebbe minimo, mentre il rischio di incompatibilità non trascurabile. Microsoft ha sempre privilegiato una compatibilità molto ampia, sia verso il passato sia verso il futuro. Il risultato è che un frammento di codice DOS sopravvive in ogni applicazione Windows, anche sui sistemi a 64 bit: non serve più allo scopo originale, ma continua ad assicurare stabilità agli strumenti che vengono usati ogni giorno.
