Whitepaper

Dit document biedt een diepgaande kijk op het architectonisch ontwerp, technologische keuzes en de onderliggende implementatielogica van sleutelfuncties in WSL Dashboard, bedoeld voor ontwikkelaars en gevorderde gebruikers die een technisch perspectief zoeken.

1. Architectuuroverzicht

WSL Dashboard hanteert een klassieke reactieve UI-gestuurde + asynchrone backend taak architectuur, gebruikmakend van Rust's type systeem en eigendomsmodel om geheugenveiligheid en hoge gelijktijdigheidsprestaties te garanderen.

Kerncomponenten

• Frontend (UI): Gebouwd op de Slint declaratieve interface. De UI-thread is verantwoordelijk voor weergave en gebruikersinteractie.
• Backend (Runtime): Gebouwd op de Tokio asynchrone runtime. Verantwoordelijk voor het verzenden en uitvoeren van systeemcommando's (CLI), bestands-I/O en netwerkluisteraars.
• Communicatie: De UI-thread en asynchrone taken communiceren efficiënt en thread-safe via Kanalen (MPSC) en Gedeelde status (Arc/Mutex/RwLock).

2. Technologische rationale

Waarom Rust?

• Prestaties: Nulkostabstracties, gecompileerd naar native machinecode, geen GC-pauzes.
• Geheugenveiligheid: Elimineert bufferoverlopen en dataraces bij compilatie — cruciaal voor een tool die op systeemniveau werkt (sijlmigratie, netwerkconfiguratie).
• Binaire grootte: Statisch koppelt alle afhankelijkheden om een enkel draagbaar uitvoerbaar bestand te produceren.

Waarom Slint + Skia?

• Declaratieve syntaks: Scheidt UI-beschrijving van logica en houdt de codebase schoon en onderhoudbaar.
• Skia-weergave: Maakt direct gebruik van GPU-versnelling (via de Skia-engine), levert sub-pixel teksthelderheid en vloeiende animaties.
• Lage overhead: Vergeleken met Electron of WPF is Slint's runtime footprint minimaal.

3. Belangrijkste technische implementaties

3.1 WSL-instantiedetectie en -parsing

De app haalt real-time instantiestatus op door wsl.exe --list --verbose aan te roepen en de uitvoer te parsen (UTF-16-codering afhandeling).

• Laag-niveau decodering: Een op maat gemaakte, efficiënte encoder/decoder zorgt voor correcte uitvoerparsing in Windows-omgevingen met verschillende regionale instellingen.
• Statussynchronisatie: Gebruikt een dubbel synchronisatiemechanisme van getimede polling gecombineerd met operatie-getriggerde updates.

3.2 Schijfmigratie (VHDX-verplaatsing)

De migratiefunctie maakt gebruik van WSL's import/export-mechanisme, maar met een hoog abstractieniveau en atomiciteit.

• Transactiegarantie: Voordat de migratie begint, vergrendelt de app de doeldistributie via een Mutex om te voorkomen dat gelijktijdige operaties gegevenscorruptie veroorzaken.
• Automatische registratie: Na voltooiing van de migratie leidt de app automatisch het VHDX-pad om en herregistreert de distributie — geen handmatige interventie nodig.

3.3 Poortdoorverwijzing en firewall-automatisering

De netwerkfunctie gaat verder dan een eenvoudige netsh interface portproxy aanroep.

• Levenscyclusbeheer van regels: De app detecteert automatisch bestaande firewallregels. Wanneer een gebruiker een doorverwijzingsregel aanmaakt, maakt deze tegelijkertijd een inkomende uitzonderingsregel aan via Windows API of CLI.
• Automatische IP-resolutie: Door de uitvoer van wsl hostname -I te parsen, worden automatisch virtuele netwerk-IP's tussen host en instantie in kaart gebracht.

3.4 USBIP-integratie

Maakt gebruik van de usbipd-win commandoregelinterface.

• Verhogingsbeheer: Bind-operaties vereisen beheerdersrechten. Het backend implementeert elegante UAC-verhogingsverzoek-doorverwijzing.
• Toestandsmachine: Handhaaft een interne USB-apparaatverbindingstoestandsmachine om volledige traceerbaarheid van Attach/Detach-operaties te waarborgen.

3.5 Bronmonitoring en minimale footprint

De app bewaakt zijn eigen resourcegebruik door native Windows API's aan te roepen (bijv. GetProcessMemoryInfo).

• Extreme efficiëntie: In stille tray-modus geeft de app proactief onnodige UI-bronnen vrij. Voor standaard tekensets (bijv. Engels) kan het geheugengebruik zo laag zijn als 10MB; voor complexe tekensets (bijv. CJK) is het ongeveer 38MB vanwege de grotere lettertype-renderingcache.

4. Prestatiebenchmarks

Metriek	Doel / Gemeten	Optimalisatieaanpak
Opstarttijd	< 500ms	Vooraf gecompileerde Slint-interface, minimalisatie van runtime-parsing.
Basisgeheugen (tray)	~10MB	Geminimaliseerde achtergrond-pollingfrequentie, on-demand vrijgave van rendercache.
CPU-gebruik (inactief)	< 0.1%	Windows event-gestuurd model, geen busy-loop polling.
Renderframerate	60 FPS	Skia GPU-versnelling, sub-pixel anti-aliasing rendering.

5. Backend taak-dispatchlogica

Om UI-reactiviteit te garanderen, worden alle tijdrovende operaties (bijv. VHDX-export) verzonden als asynchrone taken:

1. Verzoekincapsulatie: De UI-thread incapsuleert gebruikersacties in Command-berichten.
2. Berichtenkanaal: Verzendt ze naar de achtergrondtaakhandler via tokio::sync::mpsc.
3. Statuscallback: Zodra de achtergrondtaak is voltooid, werkt deze de UI bij via een callback of gedeelde status. Dit ontwerp garandeert dat zelfs tijdens het verwerken van een back-uptaak van meerdere gigabytes, de interface volledig reactief blijft op gebruikersinvoer.

6. Beveiligingsoverwegingen

• Atomaire operaties: Pre-validatie is geïmplementeerd voor kritieke instantie-afmeldings- en migratieoperaties.
• UAC-verhogingsbeheer: Verhoogde rechten worden alleen aangevraagd wanneer nodig (bijv. het binden van een USB-apparaat), volgens het principe van minimale rechten.
• Lokale opslag: Configuratie wordt alleen opgeslagen in de lokale ~\.wsldashboard map zonder enige cloudsynchronisatie, ter bescherming van de privacy van de gebruiker.