Livre blanc

Ce document explore en profondeur la conception architecturale de WSL Dashboard, les choix technologiques et la logique d'implémentation sous-jacente des fonctionnalités clés, afin d'offrir une perspective technique approfondie aux développeurs et aux utilisateurs avancés.

1. Vue d'ensemble de l'architecture

WSL Dashboard adopte l'architecture classique de UI réactive comme moteur + tâches asynchrones en arrière-plan, exploitant le système de types et le modèle de propriété du langage Rust pour garantir la sécurité mémoire et les hautes performances concurrentes.

Composants principaux

• Frontend (UI) : interface déclarative basée sur Slint. Le thread UI est responsable du rendu et de l'interaction utilisateur.
• Backend (Runtime) : runtime asynchrone basé sur Tokio. Responsable de la répartition et de l'exécution des 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ûre via des Canaux (MPSC) et un État partagé (Arc/Mutex/RwLock).

2. Raisons des choix technologiques

Pourquoi Rust ?

• Performance : abstractions à coût zéro, compilation en code machine natif, sans à-coups de GC.
• Sécurité mémoire : élimine à la compilation les débordements de tampon et les courses de données, ce qui est crucial pour les outils impliquant des opérations système de bas niveau (comme la migration de disques ou la configuration réseau).
• Taille du binaire : lie statiquement toutes les dépendances, produisant un exécutable portable à fichier unique.

Pourquoi Slint + Skia ?

• Syntaxe déclarative : la description de l'interface est séparée de la logique ; le code est facile à maintenir.
• Rendu Skia : exploite directement l'accélération GPU (via le moteur Skia), offrant un texte d'une netteté subpixel et des animations fluides.
• Faible coût : par rapport à Electron ou WPF, le coût d'exécution de Slint est minimal.

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 (en gérant l'encodage UTF-16).

• Décodage sous-jacent : un codec propriétaire haute efficacité garantit une analyse correcte de la sortie dans des environnements Windows avec différents paramètres régionaux.
• Synchronisation d'état : mécanisme de double synchronisation par sondage périodique + déclenchement par opérations.

3.2 Migration des images disque (VHDX Move)

La fonction de migration exploite le mécanisme d'importation/exportation de WSL, mais avec une haute abstraction et un traitement atomique.

• Garantie transactionnelle : avant le début de la migration, l'application verrouille la distribution cible via un mutex (Mutex), empêchant les opérations concurrentes d'endommager les données.
• Enregistrement automatique : une fois la migration terminée, l'application redirige automatiquement le chemin VHDX et réenregistre la distribution ; aucune intervention manuelle n'est nécessaire.

3.3 Redirection de ports et automatisation du pare-feu

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

• Gestion du cycle de vie des règles : l'application détecte automatiquement les règles de pare-feu existantes. Lorsque l'utilisateur crée une redirection, l'application crée de manière synchrone la règle d'exception entrante via l'API ou la CLI Windows.
• Obtention automatique de l'IP : en analysant le résultat de wsl hostname -I, elle mappe automatiquement l'IP du réseau virtuel entre l'hôte et l'instance.

3.4 Intégration USBIP

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

• Gestion de l'élévation : l'opération de liaison nécessite des privilèges d'administrateur ; la logique du backend implémente un élégant transfert des demandes d'élévation UAC.
• Machine à états : maintient en interne une machine à états de connexion des périphériques USB, garantissant la traçabilité du processus Attach/Detach.

3.5 Surveillance des ressources et légèreté

L'application surveille sa propre utilisation des ressources via des API natives Windows (comme GetProcessMemoryInfo).

• Ultra-légèreté : en mode silencieux de barre système, l'application libère proactivement les ressources UI inutiles. Pour les jeux de caractères standard comme l'anglais, la consommation mémoire peut descendre à 10Mo ; pour les jeux complexes comme le chinois, le japonais et le coréen, nécessitant le chargement de grands caches de rendu de polices, la consommation est d'environ 38Mo.

4. Indicateurs d'optimisation des performances

Indicateur	Objectif/mesuré	Moyens d'optimisation
Vitesse de démarrage	< 500ms	Interface Slint précompilée, réduisant l'analyse à l'exécution.
Mémoire de base (barre système)	~10Mo	Minimiser la fréquence de sondage en arrière-plan, libérer les caches de rendu à la demande.
Utilisation CPU (au repos)	< 0.1%	Utiliser le modèle événementiel de Windows pour éviter les sondages en boucle vide.
Fréquence de rendu	60 FPS	Accélération GPU Skia, rendu anticrénelé subpixel.

5. Logique de répartition des tâches en arrière-plan

Pour garantir la fluidité de l'UI, toutes les opérations coûteuses (comme l'exportation VHDX) sont réparties via des tâches asynchrones :

1. Encapsulation de la demande : le thread UI encapsule l'action de l'utilisateur dans un message Command.
2. Canal de messages : envoyé au gestionnaire de tâches en arrière-plan via tokio::sync::mpsc.
3. Retour d'état : une fois la tâche en arrière-plan terminée, l'UI est mise à jour via des callbacks ou un état partagé. Cette conception garantit que, même lors du traitement de tâches de sauvegarde de plusieurs Go, l'interface reste réactive aux clics de l'utilisateur.

6. Considérations de sécurité

• Opérations atomiques : implémente des validations préalables pour la désinscription et la migration des instances critiques.
• Gestion de l'élévation UAC : ne demande des permissions que lorsque nécessaire (comme pour lier des périphériques USB), selon le principe du moindre privilège.
• Stockage local : la configuration est uniquement stockée localement dans ~\.wsldashboard, sans aucune synchronisation cloud, protégeant la vie privée des utilisateurs.