L’industria informatica sta celebrando l’arrivo dei processori Snapdragon sui PC Windows come una rivoluzione, ma sotto il cofano si sta consumando un disastro logico. Microsoft ha compiuto uno sforzo ingegneristico titanico per ricompilare Windows 11 per architettura Arm, solo per paralizzarlo un istante dopo con la zavorra della retrocompatibilità.

Il problema non è l’hardware. I chip Arm sono freddi, efficienti e mostruosamente veloci. Il problema è l’illusione commerciale che Microsoft vuole vendere: far credere all’utente che nulla sia cambiato, permettendogli di fare doppio clic su un file eseguibile x86 scritto quindici anni fa e vederlo partire come per magia.

L’inganno dell’emulazione in tempo reale

Per mantenere in piedi questa farsa, Windows 11 su Arm utilizza un livello di traduzione in tempo reale. Questo software prende le istruzioni x86 pensate per processori Intel e AMD e le traduce, ciclo di clock dopo ciclo di clock, nel linguaggio nativo di Arm. È un processo logorante. Si brucia la potenza di calcolo e l’efficienza termica del nuovo silicio per tappare i buchi del vecchio software. Il risultato è un paradosso: l’utente acquista una macchina di ultima generazione, avvia il suo vecchio gestionale e lo vede girare più lentamente rispetto a un PC obsoleto di cinque anni fa. La conclusione del mercato non sarà un’analisi tecnica sull’overhead della traduzione, ma una sentenza sommaria: i PC Arm sono lenti.

L’alibi perfetto per gli sviluppatori

Questa scelta di Microsoft ha innescato un circolo vizioso fatale. Garantendo un’emulazione trasparente di sistema, hanno fornito alle software house l’alibi perfetto per non lavorare. Nessuna azienda investirà tempo e denaro per riscrivere e compilare i propri programmi in modo nativo per Arm se il sistema operativo si fa carico del lavoro sporco. L’ecosistema ristagna. Le applicazioni rimangono gonfie e obsolete, e l’hardware Arm viene condannato a fare da traduttore a vita, impedendo a questa piattaforma di esprimere il suo reale potenziale.

L’alternativa: rottura strutturale e consapevolezza

Esisteva un’alternativa chiara, tecnicamente logica e intellettualmente onesta. Microsoft avrebbe dovuto rilasciare un sistema operativo per Arm puro, nativo, privo di layer di traduzione sempre attivi in background. Un sistema concettualmente diverso, destrutturato in blocchi modulari, capace di sfruttare ogni singolo transistor del nuovo hardware per garantire un’efficienza assoluta.

E per il software legacy? Niente emulazione occulta, ma esecutori virtuali isolati a chiamata.

Se un utente ha bisogno di far girare un vecchio applicativo a 32 bit o persino un programma DOS a 16 bit, il sistema nativo non deve infettare il proprio nucleo per assecondarlo. Deve istanziare un ambiente virtuale chiuso, un container dedicato esclusivamente a quel singolo compito. Il programma vecchio gira lì dentro. L’utente ha la piena consapevolezza che sta utilizzando un software obsoleto all’interno di un recinto isolato. Nel momento in cui il programma viene chiuso, l’esecutore virtuale viene distrutto, liberando istantaneamente la memoria e le risorse, senza lasciare processi latenti in background.

Il coraggio di demolire

Sviluppare un sistema a esecutori virtuali on-demand era un problema tecnico ampiamente superabile, infinitamente più logico rispetto allo sviluppo di un traduttore globale integrato nel kernel. Ma richiedeva il coraggio di educare l’utente e di costringere il mercato a evolversi. Microsoft ha scelto la via della vigliaccheria commerciale. Ha preferito soffocare l’innovazione hardware pur di non ammettere che il software obsoleto va demolito e ricostruito dalle fondamenta. Fino a quando non si accetterà la necessità di questo taglio netto, la transizione verso Arm rimarrà solo una costosa illusione.