Whitepaper

Ez a dokumentum részletes betekintést nyújt a WSL Dashboard építészeti tervezésébe, technológiai választásaiba és a kulcsfontosságú funkciók mögöttes megvalósítási logikájába, fejlesztők és haladó felhasználók számára, akik technikai perspektívát keresnek.

1. Építészeti áttekintés

A WSL Dashboard egy klasszikus reaktív UI-vezérelt + aszinkron backend feladat építészetet alkalmaz, kihasználva a Rust típusrendszerét és tulajdonlási modelljét a memóriabiztonság és a nagy teljesítményű párhuzamosság garantálására.

Fő komponensek

• Frontend (UI): A Slint deklaratív felületére építve. Az UI szál felelős a megjelenítésért és a felhasználói interakcióért.
• Backend (Runtime): A Tokio aszinkron futtatókörnyezetre építve. Felelős a rendszerparancsok (CLI), fájl I/O és hálózati figyelők küldéséért és végrehajtásáért.
• Kommunikáció: Az UI szál és az aszinkron feladatok hatékonyan és szálbiztosan kommunikálnak Csatornákon (MPSC) és Megosztott állapoton (Arc/Mutex/RwLock) keresztül.

2. Technológiai indoklás

Miért Rust?

• Teljesítmény: Nulla költségű absztrakciók, natív gépi kódra fordítás, nincs GC szünet.
• Memóriabiztonság: Megszünteti a puffer túlcsordulást és az adatversenyeket fordítási időben — kritikus egy olyan eszköznél, amely rendszerszinten működik (lemez migráció, hálózat konfiguráció).
• Bináris méret: Statikusan linkeli az összes függőséget, egyetlen fájlú hordozható futtatható állományt hozva létre.

Miért Slint + Skia?

• Deklaratív szintaxis: Elválasztja az UI leírást a logikától, tisztán és karbantarthatóan tartva a kódbázist.
• Skia megjelenítés: Közvetlenül kihasználja a GPU gyorsítást (a Skia motoron keresztül), szub-pixel szöveg tisztaságot és sima animációkat biztosítva.
• Alacsony terhelés: Az Electronnal vagy WPF-fel összehasonlítva a Slint futtatókörnyezeti lábnyoma minimális.

3. Kulcsfontosságú technikai megvalósítások

3.1 WSL példányok észlelése és elemzése

Az alkalmazás valós idejű példányállapotot kér le a wsl.exe --list --verbose hívásával és kimenetének elemzésével (UTF-16 kódolás kezelése).

• Alacsony szintű dekódolás: Egy egyedi, hatékony encoder/decoder biztosítja a helyes kimenet elemzését a különböző Windows környezetekben eltérő regionális beállításokkal.
• Állapot szinkronizálás: Kettős szinkronizálási mechanizmust használ — időzített pollert kombinálva művelet-indított frissítésekkel.

3.2 Lemezkép migráció (VHDX áthelyezés)

A migrációs funkció a WSL import/export mechanizmusát használja, de magas absztrakciós szinttel és atomikussággal.

• Tranzakciós garancia: A migráció megkezdése előtt az alkalmazás Mutex-en keresztül zárolja a céldisztribúciót, megakadályozva a párhuzamos műveletek okozta adatkorruptálódást.
• Automatikus regisztráció: A migráció befejezése után az alkalmazás automatikusan átirányítja az VHDX elérési utat és újra regisztrálja a disztribúciót — nincs szükség kézi beavatkozásra.

3.3 Porttovábbítás és tűzfal automatizálás

A hálózati funkció túlmutat egy egyszerű netsh interface portproxy híváson.

• Szabályok életciklus-kezelése: Az alkalmazás automatikusan észleli a meglévő tűzfalszabályokat. Amikor a felhasználó továbbítási szabályt hoz létre, egyidejűleg bejövő kivételszabályt is létrehoz Windows API-n vagy CLI-n keresztül.
• Automatikus IP feloldás: A wsl hostname -I kimenetének elemzésével automatikusan leképezi a virtuális hálózati IP-ket a gazdagép és a példány között.

3.4 USBIP integráció

Kihasználja a usbipd-win parancssori felületet.

• Jogosultság kezelés: A bind műveletek adminisztrátori jogosultságot igényelnek. A backend elegáns UAC emelési kérelem továbbítást valósít meg.
• Állapotgép: Belső USB eszköz csatlakozási állapotgépet tart fenn az Attach/Detach műveletek teljes nyomon követhetőségének biztosítására.

3.5 Erőforrás figyelés és minimális lábnyom

Az alkalmazás natív Windows API hívásokkal (pl. GetProcessMemoryInfo) figyeli saját erőforrás-felhasználását.

• Extrém hatékonyság: Csendes tray módban az alkalmazás proaktívan felszabadítja a felesleges UI erőforrásokat. Szabványos karakterkészletekhez (pl. angol) a memóriahasználat 10MB-ig is csökkenhet; összetett karakterkészletekhez (pl. CJK) körülbelül 38MB a nagyobb betűtípus renderelési gyorsítótár miatt.

4. Teljesítmény benchmarkok

Metrika	Cél / Mért	Optimalizálási megközelítés
Indítási idő	< 500ms	Előre fordított Slint felület, futtatókörnyezeti elemzés minimalizálása.
Alap memória (tray)	~10MB	Minimalizált háttér polling frekvencia, szükség szerinti gyorsítótár felszabadítás.
CPU használat (üresjárat)	< 0.1%	Windows eseményvezérelt modell, nincs busy-loop polling.
Renderelési képfrissítés	60 FPS	Skia GPU gyorsítás, szub-pixel anti-aliasing renderelés.

5. Backend feladat diszpécser logika

Az UI válaszkészség biztosítása érdekében minden időigényes művelet (pl. VHDX export) aszinkron feladatként kerül elküldésre:

1. Kérelem becsomagolás: Az UI szál a felhasználói műveleteket Command üzenetekbe csomagolja.
2. Üzenetcsatorna: Elküldi őket a háttérfeladat kezelőnek a tokio::sync::mpsc segítségével.
3. Állapot visszahívás: Miután a háttérfeladat befejeződik, frissíti az UI-t visszahívás vagy megosztott állapot segítségével. Ez a tervezés biztosítja, hogy még több gigabájtos biztonsági mentési feladat feldolgozása közben is az interfész teljes mértékben válaszkész maradjon a felhasználói bevitelre.

6. Biztonsági megfontolások

• Atomikus műveletek: Előzetes validáció került bevezetésre a kritikus példány kijelentkeztetési és migrációs műveleteknél.
• UAC emelés kezelés: Emelt jogosultságokat csak szükség esetén kérnek (pl. USB eszköz kötése), a legkisebb jogosultság elvét betartva.
• Helyi tárolás: A konfiguráció csak a helyi ~\.wsldashboard könyvtárba kerül mentésre, felhőszinkronizálás nélkül, védve a felhasználó adatvédelmét.