ReactOS compie 30 anni: perché il Windows open source non è morto (e perché conta ancora)

ReactOS compie 30 anni (il post di auguri) ed è uno di quei progetti che, più passa il tempo, più smette di essere giudicabile con i parametri classici del “successo” software. Non è mai uscito dalla fase alpha, non è un sistema operativo utilizzabile quotidianamente, non ha una base di utenti reale paragonabile ad altri sistemi operativi. Eppure è ancora lì, vivo, aggiornato, discusso. Questo dato, da solo, merita un’analisi più profonda di una semplice battuta sul “rilascio nel 2050”.

Il progetto ReactOS nasce nel 1996 con un obiettivo quasi provocatorio: creare un sistema operativo libero, open source e compatibile a livello binario con Windows NT. Una piattaforma in grado di eseguire driver e applicazioni Windows nativamente, senza emulazione. È una promessa immensa, soprattutto se si considera che i sistemi operativi della famiglia Windows NT (cui Windows 10 e Windows 11 appartengono) è una piattaforma in continua evoluzione, sviluppata da migliaia di ingegneri con budget miliardari. Il confronto con ReactOS è impari per definizione.

Ed è qui che molti critici fermano il ragionamento: “inseguire Windows è una battaglia persa“. Questa conclusione affrettata tralascia però un punto centrale: ReactOS (download) non è solo un prodotto finale, è il frutto di un pesante ed approfondito processo di reverse engineering di una delle architetture software più complesse mai realizzate. Ogni driver scritto, ogni sottosistema ricostruito, ogni chiamata di sistema documentata rappresenta conoscenza che altrimenti sarebbe rimasta chiusa in quel sorgente di Windows che soltanto Microsoft conosce (ehm…, a parte qualche eccezione).

Reverse engineering, Wine e il valore tecnico che non si vede

Il legame di ReactOS con Wine è emblematico. Da anni ReactOS e Wine condividono codice, test e risultati, pur con obiettivi diversi. Wine traduce le API Windows su kernel Unix-like, ReactOS implementa direttamente quelle API sopra un proprio kernel NT-like. Due strade parallele che si alimentano a vicenda.

Anche chi considera ReactOS “inutile nel mondo reale” spesso utilizza quotidianamente software che funziona meglio proprio grazie al lavoro fatto su ReactOS, anche se indirettamente. In questo senso, il progetto ha già vinto: ha prodotto valore tecnico reale.

Uno degli aspetti più sottovalutati è il rigore legale con cui ReactOS è stato sviluppato. Per evitare qualsiasi rischio di violazione del copyright Microsoft, il progetto ha imposto regole estremamente restrittive: contributi solo da sviluppatori che non abbiano avuto accesso a codice Windows non pubblico, auditing costante, esclusione di fonti potenzialmente “contaminate”.

Questa scelta ha rallentato enormemente lo sviluppo, ma ha anche reso ReactOS uno dei pochi esempi di clean-room reverse engineering su scala sistemica. Dal punto di vista giuridico e accademico, è un caso di studio straordinario.

Limiti attuali e segnali di maturazione tecnica di ReactOS

Dal punto di vista tecnico, è vero che ReactOS oggi è limitato: supporto hardware ristretto, assenza di SMP stabile, driver USB incompleti, niente WiFi, stabilità fragile. Ma è altrettanto vero che negli ultimi anni sono arrivati tasselli fondamentali: nuovo driver NTFS, miglioramenti nel sottosistema ATA, supporto UEFI di classe 3, ASLR sia in kernel che in userland, primi passi verso WDDM.

Ed è di gennaio 2026 l’annuncio dell’introduzione del supporto alle connessioni TCP asincrone. Dopo quasi dieci anni dall’apertura del ticket originale nel 2016, ReactOS ha finalmente integrato un’implementazione corretta delle socket in modalità non bloccante. È una di quelle funzionalità che l’utente finale raramente vede, ma che determinano in modo diretto la percezione di “usabilità” di un sistema operativo moderno.

Fino a oggi, molte applicazioni di rete su ReactOS soffrivano di latenze, blocchi e comportamenti anomali, non per limiti intrinseci delle app, ma per una gestione incompleta del modello asincrono a livello dello stack di rete.

Browser, client FTP, downloader e in generale qualunque software che faccia uso intensivo di I/O ne risultava penalizzato. L’integrazione delle connessioni TCP asincrone rappresenta quindi un vero cambio di passo perché allinea ReactOS a un presupposto fondamentale del networking contemporaneo e migliora significativamente le prestazioni.

Il fatto che questa patch abbia richiesto anni, numerose riscritture e un processo di revisione lungo è, paradossalmente, un buon segno. Indica quanto sia difficile replicare correttamente il comportamento dello stack di rete Windows NT senza accesso al codice originale, e quanto cautamente il progetto proceda quando si tratta di componenti critici. Non a caso gli sviluppatori parlano apertamente di “substantial performance improvements”, perché il guadagno non è teorico ma misurabile.

ReactOS è sempre un progetto russo? Non c’è la possibilità che il codice possa contenere problemi?

ReactOS non è mai stato un progetto ufficialmente russo. È nato alla fine degli anni ’90 come iniziativa internazionale, con contributori sparsi tra Europa, USA e altri Paesi. È vero però che per molti anni una parte significativa dei core developer era dell’Europa dell’Est, inclusa la Russia. Così si è creata l’etichetta informale di “progetto russo”, che però è più una semplificazione mediatica che un dato reale.

Oggi lo sviluppo di ReactOS è distribuito, l’infrastruttura (repository, bug tracker, CI) è pubblica, non esiste una fondazione russa né un controllo statale sul progetto, i maintainer non sono concentrati in un singolo Paese. Non non c’è un “centro di comando” nazionale, tanto meno governativo.

Sul tema della fiducia nel codice, ReactOS è quasi un caso paradossale perché è uno dei progetti più “paranoici” in senso positivo quando si parla di purezza del codice.

Abbiamo già detto le cautele e le salvaguardie utilizzate per evitare qualunque contestazione legale da parte di Microsoft. Inoltre, il codice di ReactOS è pubblico, si tratta di un software libero (licenza GNU GPL 2.0), la community è piccola ma molto tecnica, molte parti vengono confrontate costantemente con Wine e descritte all’interno della documentazione pubblica.

Ovviamente, usare ReactOS in produzione o su macchine esposte su Internet è (ancora) una cattiva idea: ma non perché è un progetto russo (e non lo è) ma perché è sempre un progetto sperimentale (lo conferma lo stato “alpha”).

Differenze tra ReactOS, virtualizzazione, container, Wine e Proton

Quando si parla di alternative a ReactOS, il confronto è spesso ridotto a una questione di maturità o di affidabilità. In realtà, virtualizzazione, Wine e Proton, soluzioni ibride e ReactOS stesso affrontano il problema della compatibilità Windows da punti di attacco radicalmente diversi.

Non si tratta di varianti della stessa idea, ma di modelli architetturali distinti, che determinano in modo diretto comportamento delle applicazioni, superficie d’attacco, possibilità di debugging e persino i tipi di bug che emergono.

ReactOS tenta di replicare il modello di esecuzione di Windows NT dall’interno, implementando un kernel compatibile, un Object Manager, un I/O Manager, un Security Reference Monitor e un sottosistema Win32 nativo. Questo implica dover riprodurre fedelmente il comportamento di strutture come HANDLE, IRP, APC, DPC, token di sicurezza e meccanismi di sincronizzazione kernel-mode, senza poter contare sulle ottimizzazioni e sugli invarianti interni che Microsoft modifica a ogni release. Ogni deviazione, anche minima, può causare crash, deadlock o comportamenti non deterministici, soprattutto con driver o applicazioni che si servono ad esempio di API non documentate.

Virtualizzazione

La virtualizzazione opera all’estremo opposto. In una macchina virtuale il sistema guest esegue il vero kernel Windows, con il suo scheduler, il suo memory manager e il suo modello di sicurezza intatto. L’hypervisor si limita a mediare l’accesso alle risorse hardware tramite appositi meccanismi per la memoria e device virtuali per I/O e rete. Dal punto di vista della compatibilità, se un’applicazione o un driver funziona su un’installazione “fisica” di Windows, funzionerà anche nella macchina virtuale. Il prezzo da pagare è l’overhead strutturale e la dipendenza totale dal ciclo di vita di Windows, inclusi aggiornamenti, end-of-life e politiche di licensing.

Nel caso di Wine e Proton, l’approccio non consiste nel replicare il comportamento interno di Windows, né nell’eseguire il suo kernel, ma nel sostituire le API di Windows con implementazioni funzionalmente equivalenti che traducono le chiamate Win32 e Win64 in primitive offerte dal kernel Linux.

Ogni funzione esposta da DLL come kernel32.dll, ntdll.dll, user32.dll o gdi32.dll è reimplementata affinché produca un risultato osservabile compatibile, anche quando il meccanismo sottostante è radicalmente diverso. Il modello privilegia il risultato finale rispetto alla fedeltà interna.

WinBoat: KVM e containerizzazione Docker

Una soluzioni ibrida come WinBoat permette di installare Windows su Linux e avviare le applicazioni come se fossero native. WinBoat non tenta di reimplementare Windows né di tradurne le API, ma esegue una macchina virtuale Windows completa sfruttando la virtualizzazione hardware KVM, incapsulata all’interno di un container Docker.

Dal punto di vista della compatibilità, ciò significa esecuzione del kernel Windows autentico, con driver, comportamenti non documentati e stack di sicurezza intatti. La novità non sta quindi nella compatibilità, che è totale, ma nel modello di esposizione del sistema guest.

L’integrazione grafica tramite FreeRDP consente di mostrare le singole applicazioni Windows come finestre “seamless” sul desktop Linux, eliminando la necessità di interagire con l’intera shell di Windows. In questo modello, Windows smette di essere un ambiente operativo primario e diventa un provider di applicazioni on-demand, avviato solo quando necessario e confinato in un perimetro controllato.

Conclusioni

Forse ReactOS non arriverà mai a una “1.0” nel senso tradizionale. Forse resterà per sempre un sistema operativo incompleto, fragile, sperimentale. Ma ridurlo a una barzelletta è un errore di prospettiva. ReactOS è la dimostrazione che anche inseguire l’impossibile può produrre risultati concreti: codice, conoscenza, libertà tecnologica.

In un’epoca in cui i sistemi operativi diventano sempre più servizi e sempre meno strumenti, ReactOS resta una forma di resistenza culturale. Non contro Windows in sé, ma contro l’idea che certe piattaforme debbano essere per sempre opache, incontestabili, irreplicabili.

Guardando al futuro, ReactOS sembra aver abbandonato da tempo l’illusione di un “arrivo imminente” a una versione 1.0, concentrandosi invece su un lavoro di consolidamento silenzioso ma rilevante. I progetti in sviluppo fuori dall’albero principale – dal nuovo ambiente di build RosBE ai driver NTFS e ATA riscritti, fino al supporto SMP, UEFI di classe 3, ASLR a livello kernel e user-mode e ai primi passi verso WDDM – indicano una direzione chiara: ridurre le lacune architetturali storiche piuttosto che inseguire feature immediatamente visibili.

In definitiva, ReactOS probabilmente non vincerà la battaglia dell’uso quotidiano, ma potrebbe continuare a vincere quella più sottile e più rara: dimostrare che anche un sistema operativo dominante, complesso e in continua evoluzione come Windows può essere studiato, compreso e – almeno in parte – ricostruito in modo aperto.