# Come ho costruito Mole for Windows su un Mac

Da quando è uscito Mole for Mac, in tanti mi chiedevano quando sarebbe arrivata una versione per Windows, e la mia risposta era sempre che prima l’app per Mac doveva essere in buona forma. Mole for Windows è finalmente uscito il 14 ottobre. Prima di allora è passato per più di 20 versioni con un piccolo gruppo di utenti e poi per diversi giorni di test con i primi sostenitori di Mole, che hanno mandato tantissimi suggerimenti. Grazie a tutti. Svilupparlo è stato molto divertente, quindi ecco come ho costruito un’app per Windows su un Mac.

<figure class="blog-diagram">
  <img src="/img/windows/clean.webp" width="2584" height="1741" loading="lazy" alt="La pagina Pulizia di Mole for Windows, con la navigazione delle cinque pagine in alto e la Terra al centro">
</figure>

## Ripartire quasi da zero

Per un’esperienza e prestazioni migliori, questa versione è scritta in C# con WinUI 3, nativa per Windows, senza Electron. Windows e macOS sono diversi anche nel modo in cui funziona il sistema e in ciò che c’è da pulire, quindi, a parte il design e i testi, quasi nulla delle oltre 100.000 righe di Swift dell’app per Mac si è potuto riutilizzare. Tra un tentativo e l’altro ci è voluto circa un mese, per circa 78.000 righe di codice e più di 4.000 test.

## Un Mac, una macchina virtuale, un ThinkPad

Sviluppare e fare debug è stato molto più difficile che sul Mac che conosco bene, e un’interfaccia WinUI non si compila su Mac. Così tengo il codice e tutto il contesto dell’IA su un solo Mac. Lì Parallels Desktop fa girare una macchina virtuale Windows per il debug, e un ThinkPad X1 resta acceso giorno e notte per mostrare ciò che una macchina virtuale non mostra. Questa è la mia scrivania oggi: il Mac al centro, il ThinkPad X1 a sinistra e Mole aperto su ogni schermo.

<figure class="blog-diagram">
  <img src="/img/windows/workspace.webp" width="1600" height="1200" loading="lazy" alt="La scrivania dell’autore: un Mac e un monitor esterno al centro, un ThinkPad X1 a sinistra, con Mole aperto su ogni schermo">
</figure>

## Cosa ha funzionato

Alcune abitudini di questo mese passato a sviluppare software per Windows su un Mac si sono rivelate utili, nel caso dobbiate fare lo stesso:

- Dividere il codice in livelli. La logica principale, come pulizia e disinstallazione, e lo stato dell’interfaccia stanno in progetti .NET che non dipendono da Windows. Il livello che chiama le API di sistema attiva `EnableWindowsTargeting`, così compila anche su Mac. La maggior parte degli oltre 4.000 test gira su Mac, e solo il livello WinUI va compilato su Windows.
- Montare il repository nella macchina virtuale come cartella condivisa di Parallels. Si modifica sul Mac e si compila e avvia subito nella VM, senza copiare nulla avanti e indietro. Tenete l’output di compilazione di ciascun lato in una cartella separata, altrimenti i percorsi assoluti registrati in `obj` continuano a sovrascriversi a vicenda.
- Guidare la macchina virtuale con gli script. `prlctl exec` vi esegue i comandi, e i pulsanti si cliccano e le finestre si catturano tramite il loro nome di accessibilità con UI Automation: l’IA colpisce il controllo giusto senza coordinate, anche quando il layout si sposta un po’.
- Raggiungere il ThinkPad con UU Remote e ssh. L’hardware x64 reale, il ridimensionamento ad alti DPI, la batteria, SmartScreen e Defender si controllano lì, e ogni versione viene installata e provata lì prima del rilascio.
- Dove nessuna riga di comando arriva, faccio chiamare a Claude il computer use di Codex tramite lcu. Onestamente il computer use di Codex è davvero buono, ma non riesce a cliccare una richiesta UAC, e quella parte tocca ancora a me.

Di solito in Kaku ci sono da 7 a 10 schede di agenti al lavoro contemporaneamente.

## I certificati da sviluppatore Windows sono una seccatura

Su Windows un programma di installazione non firmato viene fermato appena lo si apre da «Windows ha protetto il PC», e il Controllo intelligente delle app di Windows 11 non lo lascia proprio eseguire, quindi prima di pubblicare ho dovuto comprare un certificato di firma del codice. Informandomi ho scoperto che un certificato EV non dà più alcun vantaggio con SmartScreen: anche un programma appena firmato resta non riconosciuto finché non lo installano abbastanza persone. Azure Artifact Signing di Microsoft, a meno di 10 dollari al mese, sarebbe stato il più comodo, ma per i privati è disponibile solo negli Stati Uniti e in Canada, quindi non per me, e il certificato open source economico di Certum non consente l’uso commerciale.

Alla fine ho comprato il certificato OV in cloud di Certum, da cento a duecento dollari l’anno. La chiave sta nel suo HSM in cloud, ogni firma richiede un codice monouso dall’app SimplySign sul telefono, e il nome sul certificato è la denominazione legale verificata, sotto cui si accumula anche la reputazione SmartScreen. Qualche volta la sessione di SimplySign si è interrotta dopo alcune ore di inattività e la firma è fallita a metà del pacchetto, così ora prima di ogni build firmo un file di prova.

## Testare le app ha richiesto più tempo di tutto

La cosa peggiore che un programma di pulizia possa fare è cancellare ciò che non deve, e su Windows ogni programma di installazione e disinstallazione ha le sue abitudini, quindi l’unico modo è installarli uno per uno. Ho preparato un elenco di app usate spesso dagli sviluppatori, in Cina e altrove: editor, IDE, browser, chat, archivi cloud, database e strumenti di IA. Ognuna viene installata e aperta, poi controllo se la disinstallazione, gli aggiornamenti, la pulizia dei residui e l’elenco di avvio di Mole la riconoscono. Finora sono state testate 372 app, e in 72 è emerso un problema, ogni volta risolto nello stesso giro, coperto da un test e ritestato. Alcuni problemi venivano dalla mia stessa configurazione: al primo test, a VS Code è stato attribuito un collegamento con lo stesso nome che Parallels aveva creato per la copia Mac di VS Code, che stava quasi per essere rimosso per errore.

<figure class="blog-diagram">
  <img src="/img/windows/uninstall.webp" width="2584" height="1741" loading="lazy" alt="La pagina App di Mole for Windows, con le app installate e le loro dimensioni">
</figure>

Le funzioni corrispondono in gran parte all’app per Mac: le cinque pagine Pulizia, App (disinstallazione e aggiornamenti), Ottimizza, Analizza e Stato, più il pannello nell’area di notifica, Schermo acceso e Pulisci schermo. Supporta Windows 10 22H2 e Windows 11, con programmi di installazione nativi per x64 e ARM64.

## C’è anche una versione a riga di comando

Oltre all’app desktop, la versione Windows della CLI di Mole è iniziata all’inizio dell’anno. La prima richiesta è arrivata da uno sviluppatore in India, che mi ha anche mandato una PR, grazie. In nove mesi e mezzo ha avuto nove versioni, e nell’ultimo mese ci ho lavorato molto, tanto che comandi e sensazioni d’uso ora corrispondono in gran parte a quelli della CLI per Mac. È gratuita e open source: se vi piace la riga di comando, potete usarla direttamente da [GitHub](https://github.com/tw93/Mole/tree/windows). [Questo articolo](/it/windows/blog/mole-cli-vs-windows-app) spiega in cosa si differenzia dall’app desktop.

<figure class="blog-diagram">
  <img src="/img/windows/cli-menu.webp" width="1814" height="741" loading="lazy" alt="Il menu principale di Mole CLI for Windows in PowerShell, con Pulisci, Disinstalla, Ottimizza, Analizza e Stato">
</figure>

Download e prezzo dell’app desktop sono su [mole.fit/windows](/windows), e ogni funzione si può usare gratis due volte prima di decidere. Se avete un PC Windows, provatela.


Canonical: https://mole.fit/it/windows/blog/building-mole-for-windows-on-a-mac
