# Hoe ik Mole for Windows op een Mac heb gebouwd

Sinds Mole for Mac uitkwam, vroegen mensen steeds wanneer er een Windows-versie zou komen, en mijn antwoord was telkens dat de Mac-app eerst goed op orde moest zijn. Op 14 oktober is Mole for Windows eindelijk verschenen. Daarvoor ging het door meer dan 20 versies bij een kleine groep gebruikers en daarna door een paar dagen testen met de vroegste supporters van Mole, die ontzettend veel suggesties stuurden. Iedereen bedankt. Het bouwen bleek erg leuk, dus hier lees je hoe ik een Windows-app op een Mac heb gemaakt.

<figure class="blog-diagram">
  <img src="/img/windows/clean.webp" width="2584" height="1741" loading="lazy" alt="De pagina Opschonen van Mole for Windows, met bovenaan de navigatie tussen vijf pagina's en de aarde in het midden">
</figure>

## Bijna vanaf nul beginnen

Voor een betere ervaring en betere prestaties is deze versie geschreven in C# met WinUI 3, native voor Windows, zonder Electron. Windows en macOS verschillen ook in hoe het systeem werkt en in wat er op te ruimen valt, dus op het ontwerp en de teksten na kon er bijna niets van de meer dan 100.000 regels Swift van de Mac-app worden hergebruikt. Met alle heen en weer duurde het ongeveer een maand, goed voor zo'n 78.000 regels code en meer dan 4.000 tests.

## Eén Mac, één virtuele machine, één ThinkPad

Ontwikkelen en debuggen was veel lastiger dan op de Mac die ik goed ken, en een WinUI-interface compileert niet op een Mac. Daarom blijven de code en alle AI-context op één Mac. Daarop draait Parallels Desktop een virtuele Windows-machine om te debuggen, en een ThinkPad X1 staat dag en nacht aan om te laten zien wat een virtuele machine niet laat zien. Zo ziet mijn bureau er nu uit: de Mac in het midden, de ThinkPad X1 links en op elk scherm staat Mole open.

<figure class="blog-diagram">
  <img src="/img/windows/workspace.webp" width="1600" height="1200" loading="lazy" alt="Het bureau van de auteur: een Mac en een extern scherm in het midden, een ThinkPad X1 links, met Mole open op elk scherm">
</figure>

## Wat goed werkte

Een paar gewoonten uit deze maand Windows-software bouwen op een Mac werkten goed, voor als je hetzelfde moet doen:

- Deel de code op in lagen. De kernlogica, zoals opschonen en verwijderen, en de toestand van de interface staan in .NET-projecten die niet van Windows afhangen. De laag die systeem-API's aanroept zet `EnableWindowsTargeting` aan, zodat die ook op een Mac compileert. De meeste van de ruim 4.000 tests draaien op de Mac, en alleen de WinUI-laag moet op Windows worden gebouwd.
- Koppel de repository als gedeelde map van Parallels aan de virtuele machine. Je past aan op de Mac en bouwt en start meteen in de VM, zonder iets heen en weer te kopiëren. Houd de build-uitvoer van elke kant in een eigen map, anders overschrijven de absolute paden die in `obj` worden vastgelegd elkaar steeds.
- Bestuur de virtuele machine met scripts. `prlctl exec` voert er opdrachten in uit, en knoppen worden aangeklikt en vensters vastgelegd via hun toegankelijkheidsnaam met UI Automation, zodat de AI het juiste besturingselement raakt zonder coördinaten, ook als de indeling een beetje verschuift.
- Bereik de ThinkPad via UU Remote en ssh. Echte x64-hardware, schaling bij hoge DPI, de accu, SmartScreen en Defender worden daar gecontroleerd, en elke versie wordt daar vóór de release geïnstalleerd en doorgeklikt.
- Waar geen opdrachtregel komt, laat ik Claude via lcu de computer use van Codex aanroepen. Eerlijk gezegd is de computer use van Codex echt goed, maar een UAC-melding kan hij niet aanklikken, dus dat deel blijft mijn werk.

Meestal draaien er in Kaku 7 tot 10 tabbladen met agents tegelijk.

## Windows-ontwikkelaarscertificaten zijn een gedoe

Op Windows wordt een niet-ondertekend installatieprogramma meteen bij het openen tegengehouden door 'Uw pc is beveiligd door Windows', en Slim app-beheer in Windows 11 laat het helemaal niet draaien, dus vóór de release moest ik een certificaat voor codeondertekening kopen. Bij het uitzoeken bleek dat een EV-certificaat bij SmartScreen geen voordeel meer geeft: ook een net ondertekend programma blijft onbekend tot genoeg mensen het hebben geïnstalleerd. Azure Artifact Signing van Microsoft zelf, voor minder dan 10 dollar per maand, was het makkelijkst geweest, maar staat voor particulieren alleen open in de VS en Canada, dus niet voor mij, en het goedkope opensourcecertificaat van Certum staat geen commercieel gebruik toe.

Uiteindelijk kocht ik het cloud-OV-certificaat van Certum, voor honderd tot tweehonderd dollar per jaar. De sleutel staat in hun cloud-HSM, elke handtekening vraagt een eenmalige code uit de SimplySign-app op mijn telefoon, en de naam op het certificaat is de gecontroleerde wettelijke naam, waaronder ook de SmartScreen-reputatie wordt opgebouwd. Een paar keer viel de SimplySign-sessie weg na een paar uur niets doen en mislukte het ondertekenen halverwege het verpakken, dus nu onderteken ik voor elke build eerst een testbestand.

## Apps testen kostte de meeste tijd

Het ergste wat een opschoonprogramma kan doen is het verkeerde verwijderen, en op Windows heeft elk installatie- en verwijderprogramma zijn eigen gewoonten, dus zit er niets anders op dan ze een voor een te installeren. Ik maakte een lijst van apps die ontwikkelaars in China en daarbuiten vaak gebruiken: editors, IDE's, browsers, chat, cloudopslag, databases en AI-tools. Elke app wordt geïnstalleerd en geopend, en dan kijk ik of het verwijderen, de updates, het opruimen van restanten en de opstartlijst van Mole hem herkennen. Tot nu toe zijn er 372 apps getest, en bij 72 kwam een probleem boven, dat telkens in dezelfde ronde werd opgelost, met een test werd afgedekt en opnieuw werd getest. Sommige problemen kwamen uit mijn eigen opstelling: bij de eerste test kreeg VS Code een snelkoppeling met dezelfde naam toegeschreven die Parallels voor de Mac-versie van VS Code had gemaakt, en die was bijna per ongeluk verwijderd.

<figure class="blog-diagram">
  <img src="/img/windows/uninstall.webp" width="2584" height="1741" loading="lazy" alt="De pagina Apps van Mole for Windows, met de geïnstalleerde apps en hun grootte">
</figure>

De functies komen grotendeels overeen met de Mac-app: de vijf pagina's Opschonen, Apps (verwijderen en updates), Optimaliseren, Analyse en Status, plus het paneel in het systeemvak, Scherm aan houden en Scherm schoonmaken. Het werkt op Windows 10 22H2 en Windows 11, met native installatieprogramma's voor x64 en ARM64.

## Er is ook een opdrachtregelversie

Naast de desktopapp bestaat sinds begin dit jaar de Windows-versie van de Mole-CLI. Het eerste verzoek kwam van een ontwikkelaar uit India, die me meteen ook een PR stuurde, dank je wel. In negenenhalve maand zijn er negen versies verschenen, en de afgelopen maand heb ik er veel aan gewerkt, zodat de opdrachten en het gebruik nu grotendeels gelijk zijn aan die van de Mac-CLI. Hij is gratis en open source: hou je van de opdrachtregel, dan kun je hem direct vanaf [GitHub](https://github.com/tw93/Mole/tree/windows) gebruiken. [Dit artikel](/nl/windows/blog/mole-cli-vs-windows-app) legt uit hoe hij verschilt van de desktopapp.

<figure class="blog-diagram">
  <img src="/img/windows/cli-menu.webp" width="1814" height="741" loading="lazy" alt="Het hoofdmenu van Mole CLI for Windows in PowerShell, met Opschonen, Verwijderen, Optimaliseren, Analyseren en Status">
</figure>

Downloaden en de prijs van de desktopapp vind je op [mole.fit/windows](/windows), en elke functie kun je twee keer gratis gebruiken voordat je beslist. Heb je een Windows-pc, probeer het dan eens.


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