Whitepaper

Ce document explore en profondeur la conception architecturale, la sélection technologique et la logique d'implémentation sous-jacente des fonctionnalités clés de WSL Dashboard, dans le but de fournir une perspective technique approfondie pour les développeurs et les utilisateurs avancés.

1. Vue d'ensemble de l'architecture

WSL Dashboard adopte une architecture classique UI réactive + tâches backend asynchrones, exploitant le système de types et le modèle de propriété du langage Rust pour garantir la sécurité de la mémoire et de hautes performances concurrentielles.

Composants core

• Frontend (UI) : Basé sur l'interface déclarative Slint. Le thread UI est responsable du rendu et de l'interaction utilisateur.
• Backend (Runtime) : Basé sur l'environnement d'exécution asynchrone Tokio. Chargé de la distribution, de l'exécution de commandes système (CLI), des E/S de fichiers et de l'écoute réseau.
• Communication : Le thread UI et les tâches asynchrones communiquent de manière efficace et sécurisée entre threads via Channel (MPSC) et Shared State (Arc/Mutex/RwLock).

2. Raisons de la sélection technologique

Pourquoi Rust ?

• Performance : Abstractions à coût zéro, compilé en code machine natif, sans gigue de GC.
• Sécurité de la mémoire : Élimine les dépassements de tampon et les courses de données au moment de la compilation, ce qui est crucial pour les outils impliquant des opérations système de bas niveau (comme la migration de disque, la configuration réseau).
• Taille du binaire : Lie statiquement toutes les dépendances, produisant un programme exécutable portable à un seul fichier.

Pourquoi Slint + Skia ?

• Syntaxe déclarative : Sépare la description de l'interface et la logique, code facile à maintenir.
• Rendu Skia : Utilise directement l'accélération GPU (via le moteur Skia), fournissant du texte avec une clarté subpixel et des effets d'animation fluides.
• Faible surcharge : Par rapport à Electron ou WPF, Slint a une surcharge d'exécution minimale.

3. Implémentation technique clé

3.1 Détection et analyse des instances WSL

L'application obtient l'état des instances en temps réel en appelant wsl.exe --list --verbose et en analysant sa sortie (traitement de l'encodage UTF-16).

• Décodage sous-jacent : Un décodeur d'encodage efficace développé en interne, assurant que la sortie est analysée correctement dans des environnements Windows avec différentes configurations régionales.
• Synchronisation d'état : Adopte un mécanisme de synchronisation double de sondage programmé + activation par opération.

3.2 Migration d'images de disque (VHDX Move)

La fonction de migration exploite le mécanisme d'importation et d'exportation de WSL, mais avec un traitement hautement abstrait et atomisé.

• Garantie transactionnelle : Avant de commencer la migration, l'application verrouillera la distribution cible avec un mutex pour éviter les dommages de données causés par des opérations concurrentes.
• Enregistrement automatique : Après la migration, l'application redirigera automatiquement le chemin VHDX et réenregistrera la distribution, sans intervention manuelle de l'utilisateur.

3.3 Transfert de ports et automatisation du pare-feu

La fonctionnalité réseau n'est pas seulement un appel simple à netsh interface portproxy.

• Gestion du cycle de vie des règles : L'application détectera automatiquement les règles de pare-feu existantes. Lorsque l'utilisateur crée un transfert, l'application utilisera l'API Windows ou la CLI pour créer同步 des règles d'exception d'entrée.
• Obtention automatique d'IP : En analysant le résultat de wsl hostname -I, mappe automatiquement l'IP réseau virtuel entre l'hôte et l'instance.

3.4 Intégration USBIP

Utilise l'interface en ligne de commande de usbipd-win.

• Traitement de l'élévation : L'opération de liaison nécessite des droits d'administrateur, et la logique backend implémente une redirection élégante de la demande d'élévation UAC.
• Machine d'état : Maintient en interne une machine d'état de connexion de périphériques USB, garantissant la traçabilité du processus Attach/Detach.

3.5 Surveillance des ressources et légèreté

L'application surveille son propre usage de ressources en appelant les API natives Windows (comme GetProcessMemoryInfo).

• Légèreté extrême : En mode silencieux de la tray, l'application libère activement les ressources UI inutiles. Pour les jeux de caractères standard comme l'anglais, l'utilisation mémoire peut être aussi basse que 10MB ; pour les jeux de caractères complexes comme le chinois, japonais et coréen, en raison de la nécessité de charger des caches de rendu de polices plus volumineux, l'utilisation est d'environ 38MB.

4. Métriques d'optimisation des performances

Métrique	Objectif/Mesuré	Méthode d'optimisation
Vitesse de démarrage	< 500ms	Précompiler l'interface Slint, réduire l'analyse au moment de l'exécution.
Mémoire de base (tray)	~10MB	Minimiser la fréquence de sondage en arrière-plan, libérer les caches de rendu au besoin.
Utilisation CPU (statique)	< 0.1%	Utiliser le modèle d'événements Windows, éviter le sondage de boucle vide.
Taux de rendu	60 FPS	Accélération GPU Skia, rendu avec anti-aliasing subpixel.

5. Logique de distribution des tâches backend

Pour garantir la fluidité de l'UI, toutes les opérations consommatrices de temps (comme l'exportation VHDX) sont distribuées via des tâches asynchrones :

1. Encapsulation de la demande : Le thread UI encapsule l'opération utilisateur en un message Command.
2. Canal de messages : Envoyé via tokio::sync::mpsc au processeur de tâches en arrière-plan.
3. Retransmission d'état : Une fois la tâche arrière-plan terminée, l'UI est mise à jour via des callbacks ou un partage d'état. Cette conception garantit que l'interface reste responsive en temps réel aux clics de l'utilisateur, même lors du traitement de tâches de sauvegarde de plusieurs Go.

6. Considérations de sécurité

• Opérations atomiques : Pour la désinstallation et la migration d'instances critiques, des vérifications préalables sont mises en œuvre.
• Gestion de l'élévation UAC : Demande des permissions uniquement quand nécessaire (comme lors de la liaison de périphériques USB), suivant le principe des permissions minimales.
• Stockage local : La configuration n'est sauvegardée que localement dans ~\.wsldashboard, sans synchronisation cloud, protégeant la vie privée de l'utilisateur.