Whitepaper

Ez a dokumentum részletesen tárgyalja a WSL Dashboard architektúratervezését, technológiaválasztását és a kulcsfontosságú funkciók mögötti megvalósítási logikáját, technikai mélységi nézőpontot nyújtva fejlesztőknek és haladó felhasználóknak.

1. Architektúra áttekintése

A WSL Dashboard a klasszikus reaktív UI-vezérlés + aszinkron háttérfeladatok architektúrát alkalmazja, kihasználva a Rust nyelv típusrendszerét és tulajdonjogi modelljét a memóriabiztonság és a magas konkurenciás teljesítmény biztosításához.

Alapvető összetevők

• Frontend (UI): Slint alapú deklaratív felület. Az UI szál felelős a megjelenítésért és a felhasználói interakciókért.
• Backend (Runtime): Tokio aszinkron futási környezet. A rendszerparancsok (CLI) kiosztásáért, végrehajtásáért, a fájl I/O-ért és a hálózati figyelésért felel.
• Kommunikáció: Az UI szál és az aszinkron feladatok Channel (MPSC) és megosztott állapot (Arc/Mutex/RwLock) révén kommunikálnak hatékonyan és szálbiztosan.

2. A technológiaválasztás indoklása

Miért a Rust?

• Teljesítmény: Nulla költségű absztrakció, natív gépi kódra fordítás, GC-rángás nélkül.
• Memóriabiztonság: A puffertúlcsordulások és adatversenyek fordítási időben kiküszöbölésre kerülnek; ez elengedhetetlen olyan eszközöknél, amelyek alacsony szintű rendszerműveleteket végeznek (pl. lemezmigrálás, hálózati konfiguráció).
• Bináris méret: Az összes függőség statikus linkelése, egyetlen fájlos hordozható futtatható program előállítása.

Miért a Slint + Skia?

• Deklaratív szintaxis: A felületleírás elválik a logikától, a kód könnyen karbantartható.
• Skia renderelés: Közvetlen GPU-gyorsítást (a Skia motorkeresztül), szubpixel-pontosságú szöveget és selymes animációkat biztosít.
• Alacsony terhelés: Az Electronhoz vagy WPF-hez képest a Slint futásidejű terhelése rendkívül alacsony.

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

3.1 WSL-példányok felderítése és elemzése

Az alkalmazás a wsl.exe --list --verbose meghívásával és kimenetének elemzésével (UTF-16 kódolás kezelése) valós időben szerzi meg a példányok állapotát.

• Alacsony szintű dekódolás: Saját fejlesztésű, hatékony kódoló/dekódoló, amely biztosítja a kimenet helyes értelmezését különböző regionális beállítású Windows környezetekben is.
• Állapotszinkron: Időzített lekérdezés + művelet által kiváltott kettős szinkronizációs mechanizmus.

3.2 Lemezképmigrálás (VHDX Move)

A migrálási funkció a WSL import/export mechanizmusát használja, de magas szintű absztrakcióval és atomi kezeléssel.

• Tranzakciós garancia: A migrálás megkezdése előtt az alkalmazás kölcsönös kizárással (Mutex) zárolja a cél-disztribúciót, megelőzve a párhuzamos műveletek által okozott adatsérülést.
• Automatikus regisztráció: A migrálás befejezése után az alkalmazás automatikusan átirányítja a VHDX útvonalat, és újraregisztrálja a disztribúciót, kézi beavatkozás nélkül.

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

A hálózati funkció nem csupán egy egyszerű netsh interface portproxy hívás.

• Szabály-életciklus-kezelés: Az alkalmazás automatikusan észleli a meglévő tűzfalszabályokat. Amikor a felhasználó továbbítást hoz létre, az alkalmazás a Windows API vagy CLI segítségével szinkron módon hozza létre a bejövő kivételszabályokat.
• Automatikus IP-lekérés: A wsl hostname -I kimenetének elemzésével automatikusan leképezi a gazdagép és a példány közötti virtuális hálózati IP-ket.

3.4 USBIP integráció

A usbipd-win parancssori felületének kihasználása.

• Jogosultság-emelés kezelése: A kötési művelet rendszergazdai jogosultságot igényel; a háttérlogika elegáns UAC jogosultság-emelési kérelem-továbbítást valósít meg.
• Állapotgép: A rendszer belsőleg egy USB-eszköz kapcsolati állapotgépet tart fenn, biztosítva az Attach/Detach folyamatok nyomon követhetőségét.

3.5 Erőforrás-figyelés és könnyűsúlyú kialakítás

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

• Extrém könnyűsúly: Tálcás csendes módban az alkalmazás aktívan felszabadítja a felesleges UI-erőforrásokat. A latin betűs karakterkészleteknél a memóriafoglalás akár 10MB is lehet; a CJK jellegű összetett karakterkészleteknél a nagyobb betűtípus-renderelési gyorsítótár betöltése miatt a foglalás körülbelül 38MB körül mozog.

4. Teljesítmény-optimalizálási mutatók

Mutató	Cél/mért érték	Optimalizálási eszközök
Indítási sebesség	< 500ms	Előre lefordított Slint felület, kevesebb futásidejű elemzés.
Alapmemória (tálca)	~10MB	Minimális háttér-lekérdezési gyakoriság, igény szerinti renderelési gyorsítótár-felszabadítás.
CPU-használat (tétlen)	< 0.1%	Windows eseményvezérelt modell, üres ciklusú lekérdezés nélkül.
Renderelési képkockasebesség	60 FPS	Skia GPU-gyorsítás, szubpixel szintű élsimítás.

5. Háttérfeladat-kiosztási logika

A UI folyékonyságának biztosítása érdekében minden időigényes művelet (pl. VHDX export) aszinkron feladatokon keresztül fut:

1. Kérelem becsomagolása: Az UI szál a felhasználói műveletet Command üzenetbe csomagolja.
2. Üzenetcsatorna: A tokio::sync::mpsc-n keresztül küldi a háttérfeladat-feldolgozónak.
3. Állapotvisszaküldés: A háttérfeladat befejezése után visszahíváson vagy megosztott állapoton keresztül frissíti az UI-t. Ez a kialakítás biztosítja, hogy a felület még több GB-os biztonsági mentési feladatok feldolgozása közben is valós időben reagáljon a felhasználói kattintásokra.

6. Biztonsági megfontolások

• Atomi műveletek: Kulcsfontosságú példány-eltávolításhoz és migráláshoz előzetes ellenőrzés valósul meg.
• UAC jogosultság-emelés kezelése: Csak szükség esetén (pl. USB-eszköz kötése) kér jogosultságot, a legkisebb jogosultság elvét követve.
• Helyi tárolás: A konfiguráció kizárólag a helyi ~\.wsldashboard mappában tárolódik, felhőszinkron nélkül, védve a felhasználó adatvédelmét.