Whitepaper

Dieses Dokument untersucht eingehend das Architekturdesign von WSL Dashboard, die Technologieauswahl sowie die zugrunde liegende Implementierungslogik der Schlüsselfunktionen und bietet Entwicklern und fortgeschrittenen Benutzern eine technische Tiefenperspektive.

1. Architekturübersicht

WSL Dashboard verwendet die klassische Architektur reaktive UI als Treiber + asynchrone Backend-Aufgaben und nutzt das Typsystem und das Ownership-Modell der Sprache Rust, um Speichersicherheit und hohe Parallelleistung zu gewährleisten.

Kernkomponenten

• Frontend (UI): deklarative Oberfläche basierend auf Slint. Der UI-Thread ist für Rendering und Benutzerinteraktion verantwortlich.
• Backend (Runtime): asynchroner Laufzeit basierend auf Tokio. Verantwortlich für die Verteilung und Ausführung von Systembefehlen (CLI), Datei-I/O und Netzwerk-Listener.
• Kommunikation: Der UI-Thread und die asynchronen Aufgaben kommunizieren über Kanäle (MPSC) und geteilten Zustand (Arc/Mutex/RwLock) effizient und threadsicher.

2. Gründe für die Technologieauswahl

Warum Rust?

• Leistung: Zero-Cost-Abstraktionen, Kompilierung in nativen Maschinencode, kein GC-Jitter.
• Speichersicherheit: eliminiert Pufferüberläufe und Datenwettläufe bereits zur Kompilierzeit – entscheidend für Tools mit systemnahen Operationen (wie Datenträgermigration, Netzwerkkonfiguration).
• Binärgröße: statisches Linken aller Abhängigkeiten, Ergebnis ist ein portables Einzeldatei-Programm.

Warum Slint + Skia?

• Deklarative Syntax: Oberflächenbeschreibung und Logik getrennt, Code leicht wartbar.
• Skia-Rendering: nutzt direkt die GPU-Beschleunigung (über die Skia-Engine) für subpixelgenaue Schriftdarstellung und flüssige Animationen.
• Geringer Overhead: Im Vergleich zu Electron oder WPF ist der Laufzeit-Overhead von Slint minimal.

3. Wichtige technische Implementierungen

3.1 WSL-Instanz-Erkennung und -Analyse

Die Anwendung ruft wsl.exe --list --verbose auf und analysiert dessen Ausgabe (mit Verarbeitung der UTF-16-Kodierung), um den Instanzstatus in Echtzeit zu erhalten.

• Low-Level-Dekodierung: ein selbst entwickelter hocheffizienter Codec stellt die korrekte Analyse der Ausgabe in Windows-Umgebungen mit unterschiedlichen Regionaleinstellungen sicher.
• Statussynchronisierung: doppelter Synchronisationsmechanismus aus zeitgesteuertem Polling + operationsausgelöstem Update.

3.2 Datenträger-Imagemigration (VHDX Move)

Die Migrationsfunktion nutzt den Import/Export-Mechanismus von WSL, jedoch mit hoher Abstraktion und atomarer Verarbeitung.

• Transaktionsgarantie: Vor Beginn der Migration sperrt die Anwendung die Ziel-Distribution über einen Mutex, um Datenschäden durch parallele Operationen zu verhindern.
• Automatische Registrierung: Nach Abschluss der Migration leitet die Anwendung den VHDX-Pfad automatisch um und registriert die Distribution neu; kein manueller Eingriff erforderlich.

3.3 Portweiterleitung und Firewall-Automatisierung

Die Netzwerkfunktion ist kein einfacher netsh interface portproxy-Aufruf.

• Regel-Lebenszyklusverwaltung: Die Anwendung erkennt automatisch vorhandene Firewall-Regeln. Wenn der Benutzer eine Weiterleitung erstellt, erstellt die Anwendung über die Windows-API oder CLI synchron die eingehende Ausnahmeregel.
• Automatische IP-Ermittlung: durch Analyse des Ergebnisses von wsl hostname -I wird die virtuelle Netzwerk-IP zwischen Host und Instanz automatisch zugeordnet.

3.4 USBIP-Integration

Nutzt die Befehlszeilenschnittstelle von usbipd-win.

• Berechtigungserhöhung: Die Bind-Operation erfordert Administratorrechte; die Backend-Logik implementiert eine elegante UAC-Erhöhungsanfrage-Weiterleitung.
• Zustandsautomat: Intern wird eine USB-Geräteverbindungs-Zustandsmaschine gepflegt, die die Nachvollziehbarkeit des Attach/Detach-Prozesses gewährleistet.

3.5 Ressourcenüberwachung und Leichtgewichtigkeit

Die Anwendung überwacht ihren eigenen Ressourcenverbrauch über native Windows-APIs (wie GetProcessMemoryInfo).

• Extreme Leichtigkeit: Im stillen Tray-Modus gibt die Anwendung unnötige UI-Ressourcen proaktiv frei. Für Standardsatz-Zeichensätze wie Englisch kann der Speicherverbrauch auf 10MB sinken; für komplexe Zeichensätze wie Chinesisch, Japanisch und Koreanisch, die größere Schrift-Rendering-Caches laden müssen, liegt er bei etwa 38MB.

4. Leistungsoptimierungskennzahlen

Kennzahl	Ziel/gemessen	Optimierungsmittel
Startgeschwindigkeit	< 500ms	vorkompilierte Slint-Oberfläche, reduziert Laufzeit-Analyse.
Basisspeicher (Tray)	~10MB	Minimierung der Hintergrund-Polling-Frequenz, bedarfsgesteuerte Freigabe von Rendering-Caches.
CPU-Auslastung (im Ruhezustand)	< 0.1%	Verwendung des Windows-Ereignismodells, Vermeidung von Leerlauf-Polling-Schleifen.
Render-Framerate	60 FPS	Skia-GPU-Beschleunigung, subpixelgenaues Antialiasing-Rendering.

5. Verteilungslogik der Backend-Aufgaben

Zur Gewährleistung der UI-Flüssigkeit werden alle zeitintensiven Operationen (wie VHDX-Export) über asynchrone Aufgaben verteilt:

1. Anfrageverkapselung: Der UI-Thread kapselt die Benutzeraktion als Command-Nachricht.
2. Nachrichtenkanal: Senden an den Hintergrund-Task-Handler über tokio::sync::mpsc.
3. Statusrückgabe: Nach Abschluss der Hintergrundaufgabe wird die UI über Callbacks oder geteilten Zustand aktualisiert. Dieses Design stellt sicher, dass die Oberfläche auch bei der Verarbeitung von Backups im GB-Bereich in Echtzeit auf Benutzerklicks reagiert.

6. Sicherheitsüberlegungen

• Atomare Operationen: für kritische Instanz-Deregistrierungen und -Migrationen werden Vorabvalidierungen implementiert.
• UAC-Berechtigungsverwaltung: fordert Berechtigungen nur bei Bedarf an (z. B. beim Binden von USB-Geräten) und folgt dem Prinzip der geringsten Privilegien.
• Lokale Speicherung: Die Konfiguration wird nur lokal in ~\.wsldashboard gespeichert; keine Cloud-Synchronisierung, schützt die Privatsphäre der Benutzer.