# Wie ich Mole for Windows auf einem Mac gebaut habe

Seit Mole for Mac erschienen ist, wurde ich immer wieder gefragt, wann eine Windows-Version kommt, und meine Antwort war jedes Mal, dass die Mac-App erst gut dastehen muss. Am 14. Oktober ist Mole for Windows endlich erschienen. Davor lief es durch mehr als 20 Versionen bei einer kleinen Gruppe von Nutzern und danach durch mehrere Tage Test mit den frühesten Unterstützern von Mole, die sehr viele Vorschläge geschickt haben. Vielen Dank an alle. Die Entwicklung hat viel Spaß gemacht, deshalb steht hier, wie ich eine Windows-App auf einem Mac gebaut habe.

<figure class="blog-diagram">
  <img src="/img/windows/clean.webp" width="2584" height="1741" loading="lazy" alt="Die Seite Bereinigen von Mole for Windows mit der Navigation der fünf Seiten oben und der Erde in der Mitte">
</figure>

## Fast bei null anfangen

Für ein besseres Erlebnis und mehr Leistung ist diese Version nativ für Windows in C# mit WinUI 3 geschrieben, ohne Electron. Windows und macOS unterscheiden sich außerdem darin, wie das System arbeitet und was es aufzuräumen gibt. Abgesehen von Design und Texten ließ sich deshalb von den über 100.000 Zeilen Swift der Mac-App fast nichts wiederverwenden. Mit allem Hin und Her hat es etwa einen Monat gedauert, am Ende waren es rund 78.000 Zeilen Code und über 4.000 Tests.

## Ein Mac, eine virtuelle Maschine, ein ThinkPad

Entwickeln und Debuggen war viel schwieriger als auf dem Mac, den ich gut kenne, und eine WinUI-Oberfläche lässt sich auf dem Mac nicht kompilieren. Deshalb bleiben Code und der gesamte KI-Kontext auf einem einzigen Mac. Darauf läuft in Parallels Desktop eine virtuelle Windows-Maschine zum Debuggen, und ein ThinkPad X1 ist rund um die Uhr an, um zu zeigen, was eine virtuelle Maschine nicht zeigt. So sieht mein Schreibtisch heute aus: der Mac in der Mitte, das ThinkPad X1 links und auf jedem Bildschirm Mole.

<figure class="blog-diagram">
  <img src="/img/windows/workspace.webp" width="1600" height="1200" loading="lazy" alt="Der Schreibtisch des Autors: ein Mac und ein externer Bildschirm in der Mitte, ein ThinkPad X1 links, auf jedem Bildschirm ist Mole geöffnet">
</figure>

## Was gut funktioniert hat

Ein paar Gewohnheiten aus diesem Monat Windows-Entwicklung auf dem Mac haben sich bewährt, falls Sie vor derselben Aufgabe stehen:

- Den Code in Schichten teilen. Die Kernlogik wie Bereinigen und Deinstallieren sowie der Zustand der Oberfläche liegen in .NET-Projekten, die nicht von Windows abhängen. Die Schicht, die System-APIs aufruft, schaltet `EnableWindowsTargeting` ein und kompiliert so auch auf dem Mac. Die meisten der über 4.000 Tests laufen auf dem Mac, nur die WinUI-Schicht muss unter Windows gebaut werden.
- Das Repository als freigegebenen Parallels-Ordner in die virtuelle Maschine einbinden. Auf dem Mac ändern, in der VM sofort bauen und starten, ohne etwas hin und her zu kopieren. Die Build-Ausgabe jeder Seite gehört in ein eigenes Verzeichnis, sonst überschreiben sich die absoluten Pfade, die unter `obj` gespeichert werden, gegenseitig.
- Die virtuelle Maschine per Skript steuern. `prlctl exec` führt darin Befehle aus, und Schaltflächen werden über ihre Barrierefreiheitsnamen mit UI Automation geklickt und Fenster aufgenommen. So trifft die KI das richtige Steuerelement ohne Koordinaten, auch wenn sich das Layout etwas verschiebt.
- Das ThinkPad über UU Remote und ssh erreichen. Echte x64-Hardware, hohe DPI-Skalierung, Akku, SmartScreen und Defender werden dort geprüft, und jede Version wird vor der Veröffentlichung dort installiert und durchgeklickt.
- Wo keine Befehlszeile hinkommt, lasse ich Claude über lcu die Computer Use von Codex aufrufen. Ehrlich gesagt ist die Computer Use von Codex wirklich gut, aber eine UAC-Abfrage kann sie nicht anklicken, das bleibt meine Aufgabe.

Meistens laufen in Kaku 7 bis 10 Tabs mit Agents gleichzeitig.

## Windows-Entwicklerzertifikate sind mühsam

Ein unsigniertes Installationsprogramm wird unter Windows beim Öffnen sofort von „Der Computer wurde durch Windows geschützt“ gestoppt, und die intelligente App-Steuerung von Windows 11 lässt es gar nicht erst laufen. Vor der Veröffentlichung musste ich also ein Codesignaturzertifikat kaufen. Beim Recherchieren stellte sich heraus, dass ein EV-Zertifikat bei SmartScreen keinen Vorteil mehr bringt: Auch ein neu signiertes Programm gilt als unbekannt, bis genug Leute es installiert haben. Microsofts eigenes Azure Artifact Signing für unter 10 Dollar im Monat wäre am einfachsten gewesen, steht Einzelpersonen aber nur in den USA und Kanada offen, also nicht mir, und das günstige Open-Source-Zertifikat von Certum erlaubt keine kommerzielle Nutzung.

Gekauft habe ich schließlich das Cloud-OV-Zertifikat von Certum, für ein- bis zweihundert Dollar im Jahr. Der Schlüssel liegt in dessen Cloud-HSM, jede Signatur braucht einen Einmalcode aus der SimplySign-App auf meinem Handy, und der Name im Zertifikat ist der geprüfte rechtliche Name, unter dem sich auch die SmartScreen-Reputation aufbaut. Ein paar Mal ist die SimplySign-Sitzung nach einigen Stunden Leerlauf abgebrochen und die Signatur mitten im Paketieren fehlgeschlagen, deshalb signiere ich jetzt vor jedem Build zuerst eine Testdatei.

## Am meisten Zeit kostete das Testen von Apps

Das Schlimmste, was ein Bereinigungstool tun kann, ist das Falsche zu löschen, und unter Windows hat jedes Installations- und Deinstallationsprogramm seine eigenen Eigenheiten. Es bleibt nur, sie eines nach dem anderen zu installieren. Ich habe eine Liste von Apps zusammengestellt, die Entwickler in China und anderswo häufig nutzen: Editoren, IDEs, Browser, Chat, Cloudspeicher, Datenbanken und KI-Werkzeuge. Jede wird installiert und geöffnet, dann prüfe ich, ob Deinstallieren, Updates, das Aufräumen von Resten und die Autostartliste von Mole sie erkennen. Bisher wurden 372 Apps getestet, bei 72 zeigte sich ein Problem, das jeweils in derselben Runde behoben, mit einem Test abgesichert und erneut getestet wurde. Manche Probleme kamen aus meiner eigenen Umgebung: Beim ersten Test wurde VS Code eine gleichnamige Verknüpfung zugeordnet, die Parallels für die Mac-Version von VS Code angelegt hatte, und sie wäre beinahe versehentlich entfernt worden.

<figure class="blog-diagram">
  <img src="/img/windows/uninstall.webp" width="2584" height="1741" loading="lazy" alt="Die Seite Apps von Mole for Windows mit den installierten Apps und ihrer Größe">
</figure>

Der Funktionsumfang entspricht weitgehend der Mac-App: die fünf Seiten Bereinigen, Apps (Deinstallieren und Updates), Optimieren, Analyse und Status, dazu das Infobereich-Panel, Bildschirm anlassen und Bildschirm wischen. Unterstützt werden Windows 10 22H2 und Windows 11, mit nativen Installationsprogrammen für x64 und ARM64.

## Es gibt auch eine Befehlszeilenversion

Neben der Desktop-App gibt es seit Jahresbeginn die Windows-Version der Mole-CLI. Die erste Anfrage kam von einem Entwickler aus Indien, der mir nebenbei auch einen PR geschickt hat, vielen Dank dafür. In neuneinhalb Monaten sind neun Versionen erschienen, und im letzten Monat habe ich viel daran gearbeitet, sodass Befehle und Bedienung jetzt weitgehend der Mac-CLI entsprechen. Sie ist kostenlos und quelloffen, wer die Befehlszeile mag, kann sie direkt von [GitHub](https://github.com/tw93/Mole/tree/windows) nutzen. [Dieser Beitrag](/de/windows/blog/mole-cli-vs-windows-app) erklärt, worin sie sich von der Desktop-App unterscheidet.

<figure class="blog-diagram">
  <img src="/img/windows/cli-menu.webp" width="1814" height="741" loading="lazy" alt="Das Hauptmenü von Mole CLI for Windows in PowerShell mit Bereinigen, Deinstallieren, Optimieren, Analyse und Status">
</figure>

Download und Preis der Desktop-App finden Sie unter [mole.fit/windows](/windows), und jede Funktion lässt sich vor der Entscheidung zweimal kostenlos nutzen. Wenn Sie einen Windows-PC haben, probieren Sie es aus.


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