Whitepaper

Dette dokument giver et dybdegående kig på den arkitektoniske design, teknologivalg og underliggende implementeringslogik af nøglefunktioner i WSL Dashboard, beregnet til udviklere og avancerede brugere, der søger et teknisk perspektiv.

1. Arkitekturoversigt

WSL Dashboard adopterer en klassisk reaktiv UI-drevet + asynkron backend opgave arkitektur, der udnytter Rusts typesystem og ejerskabsmodel til at garantere hukommelsessikkerhed og høj-samtidighedsydelse.

Kernekomponenter

• Frontend (UI): Bygget på Slint deklarativt interface. UI-tråden er ansvarlig for rendering og brugerinteraktion.
• Backend (Runtime): Bygget på Tokio asynkron runtime. Ansvarlig for at sende og udføre systemkommandoer (CLI), fil-I/O og netværkslyttere.
• Kommunikation: UI-tråden og asynkrone opgaver kommunikerer effektivt og tråd-sikkert via Channels (MPSC) og Delt tilstand (Arc/Mutex/RwLock).

2. Teknologisk begrundelse

Hvorfor Rust?

• Ydeevne: Nul-omkostnings abstraktioner, kompileret til maskinkode, ingen GC-pauser.
• Hukommelsessikkerhed: Eliminerer bufferoverløb og dataløb ved kompilering — kritisk for et værktøj, der opererer på systemniveau (diskmigrering, netværkskonfiguration).
• Binær størrelse: Statisk linker alle afhængigheder for at producere en enkelt-fil portabel eksekverbar.

Hvorfor Slint + Skia?

• Deklarativ syntaks: Adskiller UI-beskrivelse fra logik og holder kodebasen ren og vedligeholdelig.
• Skia rendering: Udnytter GPU-acceleration direkte (via Skia-motoren), leverer sub-pixel tekstklarhed og smidige animationer.
• Lav overhead: Sammenlignet med Electron eller WPF er Slints runtime fodaftryk minimalt.

3. Nøgletekniske implementeringer

3.1 WSL-instansdetektering og -parsing

Appen henter realtids instansstatus ved at kalde wsl.exe --list --verbose og parse dens output (håndtering af UTF-16-kodning).

• Lav-niveau dekodning: En specialbygget, effektiv encoder/decoder sikrer korrekt output-parsing på tværs af Windows-miljøer med forskellige regionale indstillinger.
• Tilstandssynkronisering: Bruger en dobbelt-synkroniseringsmekanisme af tidsbestemt polling kombineret med operation-triggerede opdateringer.

3.2 Diskimagemigrering (VHDX-flytning)

Migreringsfunktionen udnytter WSL's import/export-mekanisme, men med et højt niveau af abstraktion og atomicitet.

• Transaktionsgaranti: Før migreringen begynder, låser appen måldistributionen via en Mutex for at forhindre samtidige operationer i at forårsage datakorruption.
• Automatisk registrering: Når migreringen er fuldført, omdirigerer appen automatisk VHDX-stien og genregistrerer distributionen — ingen manuel indgriben kræves.

3.3 Portvideresendelse og firewall-automatisering

Netværksfunktionen går ud over et simpelt netsh interface portproxy kald.

• Regel-livscyklusstyring: Appen registrerer automatisk eksisterende firewall-regler. Når en bruger opretter en videresendelsesregel, opretter den samtidig en indgående exceptionsregel via Windows API eller CLI.
• Automatisk IP-opløsning: Ved at parse outputtet fra wsl hostname -I mapper den automatisk de virtuelle netværks-IP'er mellem værten og instansen.

3.4 USBIP-integration

Udnytter usbipd-win kommandolinjeinterface.

• Privilegiehåndtering: Bind-operationer kræver administratorrettigheder. Backend implementerer elegant UAC-elevationsforespørgselvideresendelse.
• Tilstandsmaskine: Vedligeholder en intern USB-enhedsforbindelsestilstandsmaskine for at sikre fuld sporbarhed af Attach/Detach-operationer.

3.5 Ressourceovervågning og minimalt fodaftryk

Appen overvåger sit eget ressourceforbrug ved at kalde native Windows API'er (f.eks. GetProcessMemoryInfo).

• Ekstrem effektivitet: I lydløs tray-tilstand frigør appen proaktivt unødvendige UI-ressourcer. For standardtegnsæt (f.eks. engelsk) kan hukommelsesforbruget være så lavt som 10MB; for komplekse tegnsæt (f.eks. CJK) er det cirka 38MB på grund af den større font-renderingscache.

4. Ydelsesbenchmarks

Mål	Mål / Målt	Optimeringstilgang
Opstartstid	< 500ms	Forhåndskompileret Slint-interface, minimering af runtime-parsing.
Basis hukommelse (tray)	~10MB	Minimeret baggrunds-pollingfrekvens, on-demand frigivelse af render-cache.
CPU-brug (inaktiv)	< 0.1%	Windows event-drevet model, ingen busy-loop polling.
Renderingsbilledhastighed	60 FPS	Skia GPU-acceleration, sub-pixel anti-aliaset rendering.

5. Backend opgave-dispatsjering

For at sikre UI-responsivitet sendes alle tidskrævende operationer (f.eks. eksport af en VHDX) som asynkrone opgaver:

1. Forespørgselsindkapsling: UI-tråden indkapsler brugerhandlinger i Command-beskeder.
2. Beskedkanal: Sender dem til baggrundsopgavehandleren via tokio::sync::mpsc.
3. Tilstandscallback: Når baggrundsopgaven er fuldført, opdaterer den UI via en callback eller delt tilstand. Denne design sikrer, at selv under behandling af en multi-gigabyte backup-opgave forbliver interfacet fuldt responsivt over for brugerinput.

6. Sikkerhedsovervejelser

• Atomiske operationer: Pre-fly-validering er implementeret for kritiske instans-afregistrerings- og migrationsoperationer.
• UAC-elevationsstyring: Forhøjede rettigheder anmodes kun om nødvendigt (f.eks. ved binding af en USB-enhed), i overensstemmelse med princippet om mindste privilegier.
• Lokalt lager: Konfiguration gemmes kun i den lokale ~\.wsldashboard mappe uden nogen form for skylagring, der beskytter brugerens privatliv.