Valkoinen kirja

Tämä dokumentti sukeltaa syvälle WSL Dashboardin arkkitehtuurisuunnitteluun, teknologiavalintoihin ja keskeisten toimintojen taustalla olevaan toteutuslogiikkaan, ja se on tarkoitettu tarjoamaan kehittäjille ja edistyneille käyttäjille tekninen syvyysnäkökulma.

1. Arkkitehtuurin yleiskatsaus

WSL Dashboard käyttää klassista responsiivinen UI-vetoinen + asynkroniset taustatehtävät -arkkitehtuuria ja hyödyntää Rust-kielen tyyppijärjestelmää ja omistajuusmallia muistiturvallisuuden ja korkean samanaikaisuuskyvyn varmistamiseksi.

Keskeiset komponentit

• Frontend (UI): Perustuu deklaratiiviseen käyttöliittymään Slint. UI-säie vastaa renderöinnistä ja käyttäjävuorovaikutuksesta.
• Backend (Runtime): Perustuu asynkroniseen suoritusympäristöön Tokio. Vastaa järjestelmäkomentojen (CLI) jakelusta ja suorituksesta, tiedostojen I/O:sta ja verkon kuuntelusta.
• Viestintä: UI-säie ja asynkroniset tehtävät viestivät tehokkaasti ja säieturvallisesti kanavan (MPSC) ja jaetun tilan (Arc/Mutex/RwLock) kautta.

2. Teknologiavalintojen perustelut

Miksi Rust?

• Suorituskyky: Nollakustannusabstraktiot, käännetään natiiviksi konekoodiksi, ei GC-pysähdyksiä.
• Muistiturvallisuus: Poistaa puskurin ylivuodot ja datakilpailut käännösaikana, mikä on ratkaisevan tärkeää järjestelmän lähellä toimiville työkaluille (kuten levyn siirto, verkkokokoonpano).
• Binäärin koko: Kaikki riippuvuudet linkitetään staattisesti, jolloin syntyy yksitiedostollinen kannettava suoritettava ohjelma.

Miksi Slint + Skia?

• Deklaratiivinen syntaksi: Käyttöliittymän kuvaus erotettu logiikasta, koodi helppo ylläpitää.
• Skia-renderöinti: Hyödyntää GPU-kiihdytystä suoraan (Skia-moottorin kautta), tarjoaa subpikselitarkkaa tekstiä ja sulavia animaatioita.
• Pieni kuormitus: Verrattuna Electroniin tai WPF:ään Slintin suoritusaikainen kuormitus on erittäin pieni.

3. Keskeiset tekniset toteutukset

3.1 WSL-esiintymien tunnistus ja jäsennys

Sovellus hakee esiintymän tilan reaaliajassa kutsumalla wsl.exe --list --verbose -komentoa ja jäsentämällä sen tulosteen (käsitellen UTF-16-koodauksen).

• Taustalla oleva dekoodaus: Itse kehitetty tehokas koodekki varmistaa tulosteen oikean jäsentämisen eri alueasetuksilla varustetuissa Windows-ympäristöissä.
• Tilan synkronointi: Käyttää kaksoissynkronointimekanismia: säännöllinen kysely + toiminnon käynnistämä synkronointi.

3.2 Levykuvan siirto (VHDX Move)

Siirtotoiminto hyödyntää WSL:n tuonti- ja vientimekanismia, mutta korkealla abstraktiotasolla ja atomisena käsittelynä.

• Transaktiovarmistus: Ennen siirron aloittamista sovellus lukitsee kohdejakelun mutexilla (Mutex) estääkseen samanaikaisten toimintojen aiheuttamat tietovahingot.
• Automaattinen rekisteröinti: Siirron jälkeen sovellus ohjaa VHDX-polun automaattisesti uudelleen ja rekisteröi jakelun uudelleen; käyttäjän ei tarvitse puuttua asiaan.

3.3 Porttiohjaus ja palomuurin automatisointi

Verkkotoiminto ei ole pelkkä netsh interface portproxy-kutsu.

• Sääntöjen elinkaaren hallinta: Sovellus tunnistaa automaattisesti olemassa olevat palomuurisäännöt. Kun käyttäjä luo ohjauksen, sovellus luo samanaikaisesti saapuvat poikkeussäännöt Windows API:n tai CLI:n kautta.
• Automaattinen IP-haku: Jäsentämällä wsl hostname -I -tuloksen isäntäkoneen ja esiintymän väliset virtuaaliverkon IP-osoitteet kartoitetaan automaattisesti.

3.4 USBIP-integraatio

Hyödyntää usbipd-win-työkalun komentorivirajapintaa.

• Oikeuksien korotus: Sidontatoiminnot vaativat järjestelmänvalvojan oikeudet; taustalogiikka toteuttaa tyylikkään UAC-oikeuksien korotuspyyntöjen välityksen.
• Tilakone: Ylläpitää sisäisesti USB-laitteen yhteystilakoneen, mikä varmistaa Attach/Detach-prosessin jäljitettävyyden.

3.5 Resurssien seuranta ja kevyt rakenne

Sovellus seuraa omaa resurssinkulutustaan Windowsin natiivien API-kutsujen kautta (kuten GetProcessMemoryInfo).

• Äärimmäisen kevyt: Lokeron hiljaisessa tilassa sovellus vapauttaa aktiivisesti tarpeettomia UI-resursseja. Englannin kaltaisille vakiotekstijoukoille muistinkulutus voi laskea jopa 10MB; kiinan, japanin ja korean kaltaisille monimutkaisille merkistöille tarvitaan suurempia fonttirenderöintivälimuisteja, jolloin kulutus on noin 38MB.

4. Suorituskyvyn optimointimittarit

Mittari	Tavoite/toteutunut	Optimointikeino
Käynnistysnopeus	< 500ms	Esikäännetty Slint-käyttöliittymä, vähemmän suoritusaikaista jäsentämistä.
Perusmuisti (lokero)	~10MB	Minimoi taustakyselytiheyden, vapauttaa renderöintivälimuistit tarpeen mukaan.
CPU-kulutus (lepotila)	< 0,1%	Käyttää Windowsin tapahtumavetoista mallia, välttää tyhjät kyselysilmukat.
Renderöintinopeus	60 FPS	Skia GPU-kiihdytys, subpikselinen sahalaitasuodatus.

5. Taustatehtävien jakelulogiikka

UI:n sujuvuuden varmistamiseksi kaikki aikaa vievät toiminnot (kuten VHDX:n vienti) suoritetaan asynkronisten tehtävien kautta:

1. Pyynnön kapselointi: UI-säie kapseloi käyttäjän toiminnot Command-viesteiksi.
2. Viestikanava: Lähetetään taustatehtävien käsittelijälle tokio::sync::mpsc-kanavan kautta.
3. Tilan palautus: Taustatehtävän valmistuttua UI päivitetään takaisinkutsun tai jaetun tilan kautta. Tämä malli varmistaa, että käyttöliittymä reagoi reaaliajassa käyttäjän napsautuksiin, jopa useiden gigatavujen varmuuskopiointitehtävien aikana.

6. Turvallisuusnäkökohdat

• Atomiset toiminnot: Kriittisiä esiintymän poistoasennuksia ja siirtoja varten on toteutettu ennakkotarkistus.
• UAC-oikeuksien hallinta: Pyytää oikeuksia vain tarvittaessa (kuten USB-laitteiden sidonnassa) ja noudattaa vähimmäisoikeuden periaatetta.
• Paikallinen tallennus: Asetukset tallennetaan vain paikallisesti sijaintiin ~\.wsldashboard, ilman pilvisynkronointia, mikä suojaa käyttäjän yksityisyyttä.