Whitepaper

Dit document gaat dieper in op de architectuur, technische keuzes en de onderliggende implementatielogica van de kernfuncties van WSL Dashboard en biedt ontwikkelaars en gevorderde gebruikers een technisch verdiepend perspectief.

1. Architectuuroverzicht

WSL Dashboard gebruikt de klassieke responsieve UI-driven + asynchrone backend-taken-architectuur en benut het typesysteem en het eigendomsmodel van de Rust-taal om geheugenveiligheid en hoge concurrency-prestaties te garanderen.

Kerncomponenten

• Frontend (UI): declaratieve interface op basis van Slint. De UI-thread verzorgt rendering en gebruikersinteractie.
• Backend (Runtime): asynchrone runtime op basis van Tokio. Verantwoordelijk voor het distribueren en uitvoeren van systeemopdrachten (CLI), bestands-I/O en netwerk-luistertaken.
• Communication: de UI-thread en asynchrone taken communiceren efficiënt en thread-safe via Channel (MPSC) en Shared State (Arc/Mutex/RwLock).

2. Redenen voor technische keuzes

Waarom Rust?

• Prestaties: zero-cost abstracties, compileert naar native machinecode, geen GC-schokken.
• Geheugenveiligheid: elimineert bufferoverflows en dataraces tijdens de compilatie; cruciaal voor tools die met systeemlagen op laag niveau te maken hebben (zoals schijfmigratie, netwerkconfiguratie).
• Binaire grootte: statisch gelinkt met alle afhankelijkheden, levert een enkel, draagbaar uitvoerbaar bestand.

Waarom Slint + Skia?

• Declaratieve syntaxis: scheiding van interfacebeschrijving en logica; code is eenvoudig te onderhouden.
• Skia-rendering: maakt rechtstreeks gebruik van GPU-versnelling (via de Skia-engine) voor subpixel-nauwkeurige tekst en vloeiende animaties.
• Lage overhead: vergeleken met Electron of WPF is de runtime-overhead van Slint minimaal.

3. Belangrijke technische implementaties

3.1 WSL-instance-detectie en -parsing

De app haalt de instance-status in real-time op door wsl.exe --list --verbose aan te roepen en de uitvoer te parseren (met verwerking van UTF-16-codering).

• Decodering op laag niveau: een zelf ontwikkelde efficiënte codec zorgt voor correcte parsing van de uitvoer op Windows-systemen met verschillende landinstellingen.
• Statussynchronisatie: dubbele synchronisatiemechanismen: periodieke polling + door bewerkingen geactiveerde synchronisatie.

3.2 Migratie van schijfimages (VHDX Move)

De migratiefunctie gebruikt het import-/exportmechanisme van WSL, maar is sterk geabstraheerd en atomair gemaakt.

• Transactionele garantie: vóór de migratie vergrendelt de app de doeldistributie via een mutex (Mutex) om gegevensbeschadiging door gelijktijdige bewerkingen te voorkomen.
• Automatische registratie: na voltooiing van de migratie verwijst de app automatisch het VHDX-pad om en registreert de distributie opnieuw; de gebruiker hoeft niets handmatig te doen.

3.3 Poortdoorschakeling en firewallautomatisering

De netwerkfunctie is meer dan een simpele aanroep van netsh interface portproxy.

• Levenscyclusbeheer van regels: de app detecteert automatisch bestaande firewallregels. Wanneer de gebruiker een doorschakeling maakt, maakt de app via Windows-API of CLI automatisch inkomende uitzonderingsregels aan.
• Automatisch IP ophalen: door het resultaat van wsl hostname -I te parseren, worden de virtuele netwerk-IP's tussen host en instance automatisch toegewezen.

3.4 USBIP-integratie

Gebruikt de opdrachtregelinterface van usbipd-win.

• Rechtenverhoging: bindbewerkingen vereisen beheerdersrechten; de backend-logica implementeert een elegante doorzending van UAC-verhogingsverzoeken.
• Statussmachine: intern wordt een statusmachine voor USB-apparaatverbindingen bijgehouden om de traceerbaarheid van het Attach/Detach-proces te garanderen.

3.5 Resourcemonitoring en lichtgewicht ontwerp

De app monitort zijn eigen resourcegebruik via native Windows-API's (zoals GetProcessMemoryInfo).

• Extreem lichtgewicht: in de stille tray-modus geeft de app actief onnodige UI-bronnen vrij. Voor standaardtekensets zoals Engels kan het geheugengebruik dalen tot 10MB; voor complexe tekensets zoals Chinees, Japans en Koreaans, vanwege de benodigde grotere lettertype-rendercaches, ligt het gebruik rond 38MB.

4. Prestatieoptimalisatiemetrieken

Metriek	Doel/gemeten	Optimalisatiemethode
Opstartsnelheid	< 500 ms	Voorgecompileerde Slint-interface, minder runtime-parsing.
Baseline geheugen (tray)	~10 MB	Minimale achtergrond-pollingfrequentie, rendercaches op aanvraag vrijgeven.
CPU-gebruik (inactief)	< 0,1%	Gebruikt het Windows-gebeurtenisgestuurde model, geen lege polling-loops.
Rendertempo	60 FPS	Skia-GPU-versnelling, rendering met subpixel-anti-aliasing.

5. Backend-taakdistributielogica

Om de vloeiendheid van de UI te garanderen, worden alle tijdrovende bewerkingen (zoals het exporteren van VHDX) via asynchrone taken gedistribueerd:

1. Verzoekverpakking: de UI-thread verpakt gebruikersacties als Command-berichten.
2. Berichtenkanaal: verzending naar de achtergrond-taakverwerker via tokio::sync::mpsc.
3. Statusterugkoppeling: na voltooiing van de achtergrondtaak wordt de UI bijgewerkt via callbacks of gedeelde status. Dit ontwerp zorgt ervoor dat de interface zelfs tijdens het verwerken van back-uptaken van meerdere GB direct reageert op gebruikersklikken.

6. Beveiligingsoverwegingen

• Atomaire bewerkingen: voorafgaande validatie is geïmplementeerd voor kritieke instance-ontkoppeling en -migratie.
• UAC-rechtenbeheer: vraagt alleen rechten wanneer noodzakelijk (bijv. bij het binden van USB-apparaten), volgens het principe van minimale rechten.
• Lokale opslag: configuratie wordt alleen lokaal opgeslagen in ~\.wsldashboard, zonder enige cloud-synchronisatie, ter bescherming van de privacy van de gebruiker.