Whitepaper

Dette dokument dykker ned i WSL Dashboards arkitekturdesign, teknologivalg og den underliggende implementeringslogik for nøglefunktioner, med det formål at give udviklere og avancerede brugere et teknisk dybdegående perspektiv.

1. Arkitekturoversigt

WSL Dashboard anvender den klassiske arkitektur responsiv UI-drevet + asynkrone backend-opgaver, og bruger Rust-sprogets typesystem og ejerskabsmodel til at sikre hukommelsessikkerhed og høj samtidighedsydelse.

Kernekomponenter

• Frontend (UI): Baseret på det deklarative interface Slint. UI-tråden håndterer rendering og brugerinteraktion.
• Backend (Runtime): Baseret på den asynkrone runtime Tokio. Håndterer udsendelse og udførelse af systemkommandoer (CLI), fil-I/O og netværkslytning.
• Kommunikation: UI-tråden og asynkrone opgaver kommunikerer effektivt og trådsikkert via Channel (MPSC) og delt tilstand (Arc/Mutex/RwLock).

2. Begrundelse for teknologivalg

Hvorfor Rust?

• Ydelse: Nul-omkostningsabstraktioner, kompileres til native maskinkode, ingen GC-stød.
• Hukommelsessikkerhed: Eliminerer bufferoverløb og datakonkurrencer på kompileringstidspunktet, hvilket er afgørende for værktøjer, der arbejder tæt på systemet (f.eks. disk-migrering, netværkskonfiguration).
• Binær størrelse: Statisk linkning af alle afhængigheder producerer en enkeltfil, bærbar eksekverbar fil.

Hvorfor Slint + Skia?

• Deklarativ syntaks: Interfacebeskrivelse adskilt fra logik, nemt vedligeholdelig kode.
• Skia-rendering: Udnytter GPU-acceleration direkte (via Skia-motoren) og giver subpixel-klar tekst og glidende animationer.
• Lave omkostninger: Sammenlignet med Electron eller WPF er Slints runtime-omkostninger ekstremt lave.

3. Vigtige tekniske implementeringer

3.1 Registrering og parsing af WSL-instanser

Applikationen henter instansstatus i realtid ved at kalde wsl.exe --list --verbose og parse outputtet (håndterer UTF-16-kodning).

• Underliggende afkodning: En selvudviklet effektiv kodec sikrer korrekt parsing af output i Windows-miljøer med forskellige regionsindstillinger.
• Statussynkronisering: Anvender en dobbeltsynkroniseringsmekanisme med periodisk polling + handlingsudløsning.

3.2 Migrering af diskbilleder (VHDX Move)

Migreringsfunktionen udnytter WSL's import/eksportmekanisme, men med høj abstraktion og atomisk behandling.

• Transaktionsgaranti: Før migreringen starter, låser applikationen måldistributionen via en mutex (Mutex) for at forhindre, at samtidige operationer beskadiger data.
• Automatisk registrering: Efter migreringen omdirigerer applikationen automatisk VHDX-stien og genregistrerer distributionen; ingen manuel indgriben nødvendig.

3.3 Portvideresendelse og firewallautomatisering

Netværksfunktionen er ikke blot et netsh interface portproxy-kald.

• Livscyklusstyring af regler: Applikationen registrerer automatisk eksisterende firewallregler. Når brugeren opretter en videresendelse, opretter applikationen samtidig indgående undtagelsesregler via Windows API eller CLI.
• Automatisk IP-hentning: Ved at parse resultatet af wsl hostname -I mappes de virtuelle netværks-IP'er mellem vært og instans automatisk.

3.4 USBIP-integration

Udnytter kommandolinjegrænsefladen fra usbipd-win.

• Rettighedsforhøjelse: Bindningsoperationer kræver administratorrettigheder; backend-logikken implementerer en elegant videresendelse af UAC-rettighedsanmodninger.
• Statustilstandsmaskine: Vedligeholder internt en USB-enhedsforbindelsestilstandsmaskine for at sikre sporbarhed i Attach/Detach-processen.

3.5 Ressourceovervågning og letvægtsdesign

Applikationen overvåger sit eget ressourceforbrug via native Windows-API'er (f.eks. GetProcessMemoryInfo).

• Ekstremt letvægts: I bakkens stille tilstand frigiver applikationen aktivt unødvendige UI-ressourcer. For standardtegnsæt som engelsk kan hukommelsesforbruget komme ned på 10MB; for komplekse tegnsæt som kinesisk, japansk og koreansk kræves større fontrenderingscaches, hvilket giver et forbrug på omkring 38MB.

4. Ydelsesoptimeringsmålinger

Måling	Mål/faktisk	Optimeringsmetode
Starthastighed	< 500ms	Prækompileret Slint-interface, reducerer runtime-parsing.
Grundlæggende hukommelse (bakke)	~10MB	Minimerer baggrundspolling-frekvensen, frigiver renderingscaches efter behov.
CPU-forbrug (i ro)	< 0,1%	Bruger Windows' begivenhedsdrevne model, undgår tomme polling-sløjfer.
Rendering-rammehastighed	60 FPS	Skia GPU-acceleration, subpixel anti-aliasing-rendering.

5. Logik for udsendelse af backend-opgaver

For at sikre en glidende UI udsendes alle tidskrævende operationer (f.eks. eksport af VHDX) via asynkrone opgaver:

1. Anmodningsindkapsling: UI-tråden indkapsler brugerhandlinger som Command-meddelelser.
2. Meddelelseskanal: Sendes til backend-opgavens processor via tokio::sync::mpsc.
3. Statusretur: Når backend-opgaven er færdig, opdateres UI via callback eller delt status. Dette design sikrer, at grænsefladen reagerer i realtid på brugerklik, selv under backup-opgaver på flere GB.

6. Sikkerhedsovervejelser

• Atomiske operationer: For kritiske instans-afmonteringer og migreringer implementeres prævalidation.
• UAC-rettighedsstyring: Anmoder kun om rettigheder, når det er nødvendigt (f.eks. binding af USB-enheder), og følger princippet om mindst privilegium.
• Lokal lagring: Konfiguration gemmes kun lokalt i ~\.wsldashboard uden nogen cloudsynkronisering, hvilket beskytter brugerens privatliv.