Microsoft 365 su Linux: Bottles prepara l'installer che funziona davvero

Portare Microsoft 365 su Linux senza sfruttare una macchina virtuale (ad esempio con l’ottimo WinBoat) non è più soltanto uno degli esperimenti ricorrenti della comunità Wine. Mirko Brombin, fondatore e principale sviluppatore di Bottles, sta preparando un installer capace di configurare automaticamente una versione desktop di Microsoft 365 all’interno di Linux, utilizzando Soda come livello di compatibilità.

Come Brombin racconta, il lavoro ha già superato alcuni ostacoli non banali: installazione della suite, accesso all’account Microsoft, autenticazione a due fattori, riconoscimento della licenza e avvio di Word hanno funzionato nelle prove pubblicate dallo sviluppatore.

Wine permette dal 1993 di eseguire applicazioni Windows sui sistemi Unix-like traducendo le chiamate alle API Microsoft nelle corrispondenti funzioni disponibili sul sistema host. Con le vecchie edizioni di Office i risultati sono stati alterni: Office 2007, 2010 e alcune configurazioni di Office 2013 o 2016 possono funzionare con opportuni accorgimenti, mentre le moderne Microsoft 365 Apps hanno rappresentato un problema decisamente più impegnativo. Il modello Click-to-Run, l’autenticazione online, le librerie integrate con Windows, WebView e i continui aggiornamenti complicano parecchio il lavoro di Wine.

Microsoft 365 su Linux: cosa ha ottenuto finora Bottles

L’ideatore di Bottles spiega di essere alle prese con gli ultimi “aggiustamenti” prima dell’apertura dei test pubblici con Microsoft 365 su Linux.

Microsoft non offre una versione desktop di Word, Excel, PowerPoint e Outlook per Linux. I requisiti ufficiali di Microsoft 365 continuano a indicare Windows e macOS come piattaforme desktop supportate, oltre a citare la disponibilità delle applicazioni mobili Android e iOS.

Su Linux rimangono quindi le versioni eeb oppure soluzioni alternative come LibreOffice e OnlyOffice. Il progetto di Brombin diventa interessante perché non punta a ricreare Office, ma a eseguire il software Windows originale con un livello di compatibilità sufficientemente affidabile.

Sotto la superficie, la piattaforma inventata da Brombin deve costruire una bottle, cioè un ambiente Wine separato con il proprio registro, le proprie directory Windows virtuali, librerie, impostazioni e versione del runner. È un principio simile ai tradizionali Wine prefix, ma Bottles automatizza una parte considerevole della configurazione e consente di associare impostazioni differenti a ogni applicazione.

Soda non è Wine con un nome diverso

Il componente decisivo è Soda, il runner mantenuto dal progetto Bottles. Chiamarlo soltanto “fork di Wine” aiuta a capire l’idea generale, ma non descrive bene il lavoro che c’è dietro. La versione attuale di Soda 11 usa come base il Wine di Valve e integra patch selezionate provenienti da diversi progetti della comunità.

Tra queste rientrano patch nate attorno a Proton, il livello di compatibilità sviluppato da Valve per eseguire giochi Windows su Linux tramite Steam, ma anche interventi adottati nelle build personalizzate Wine-TKG e Wine-GE.

TKG è soprattutto un insieme di script, configurazioni e patch con cui costruire versioni di Wine molto personalizzate; GE, invece, indica le build curate da GloriousEggroll, note per integrare rapidamente correzioni, componenti multimediali e modifiche utili per software che con Wine standard presentano ancora problemi.

Soda seleziona parte di questo lavoro e lo combina in un runner pensato specificamente per Bottles, senza limitarsi all’ambito gaming.

Cosa fa Bottles e perché semplifica un problema molto complesso

Bottles nasce per evitare all’utente di amministrare manualmente decine di Wine prefix. Ogni ambiente contiene il proprio disco C: virtuale, il Registro di sistema di Windows, le librerie installate e le configurazioni specifiche dell’applicazione. Il programma mette poi a disposizione runner differenti, dipendenze, backup, snapshot delle configurazioni e installer automatizzati.

Per le normali applicazioni Windows esiste, ad esempio, un ambiente Application che prepara diverse componenti utili, installa font come Arial, Times e Courier e mette a disposizione Wine Mono per i programmi che possono utilizzarlo al posto del .NET Framework originale. L’utente può comunque cambiare runner e dipendenze in qualsiasi momento.

Con Microsoft 365 la situazione richiede qualcosa di ancora più mirato. Le schermate pubblicate da Brombin mostrano infatti una procedura nella quale Bottles installa prima il runner necessario e successivamente il pacchetto Microsoft 365 Apps. L’obiettivo dichiarato è arrivare a un installer semplice, non a una guida di parecchie pagine piena di DLL override, chiavi di registro e comandi da terminale.

Il vero banco di prova saranno gli aggiornamenti di Microsoft 365

Una volta pubblicato l’installer, sarà interessante capire cosa succede dopo settimane o mesi di utilizzo.

Microsoft 365 segue la Modern Lifecycle Policy e riceve continuamente correzioni, modifiche funzionali e nuove build. Una soluzione di compatibilità può quindi funzionare perfettamente con una release e rompersi con quella successiva. Brombin e gli sviluppatori Wine saranno costretti a inseguire regressioni che non dipendono da Bottles stesso.

C’è poi la possibilità che parte delle modifiche sviluppate per Soda possa arrivare nel progetto Wine principale.

Sarebbe lo scenario migliore: una correzione stabile e approvata potrebbe così introdurre benefici non solo in Bottles ma anche sugli altri strumenti basati su Wine.

Al momento, è opportuno limitarci a dire che Microsoft 365 desktop sta diventando concretamente eseguibile su Linux attraverso Bottles, ma il progetto si trova ancora nella fase in cui bisogna misurare affidabilità, compatibilità delle singole applicazioni e resistenza agli aggiornamenti. Il balzo in avanti rispetto ai vecchi esperimenti manuali è comunque evidente.