Documento técnico

Este documento analiza en profundidad el diseño de la arquitectura de WSL Dashboard, la selección de tecnologías y la lógica de implementación subyacente de las funciones clave, con el objetivo de ofrecer una perspectiva técnica profunda a desarrolladores y usuarios avanzados.

1. Resumen de la arquitectura

WSL Dashboard adopta la arquitectura clásica de UI reactiva como controlador + tareas asíncronas en segundo plano, aprovechando el sistema de tipos y el modelo de propiedad del lenguaje Rust para garantizar la seguridad de memoria y el alto rendimiento concurrente.

Componentes principales

• Frontend (UI): interfaz declarativa basada en Slint. El hilo de la UI se encarga del renderizado y la interacción del usuario.
• Backend (Runtime): runtime asíncrono basado en Tokio. Se encarga de despachar y ejecutar comandos del sistema (CLI), E/S de archivos y escucha de red.
• Comunicación: el hilo de la UI y las tareas asíncronas se comunican de forma eficiente y segura mediante Canales (MPSC) y Estado compartido (Arc/Mutex/RwLock).

2. Razones de la selección tecnológica

¿Por qué Rust?

• Rendimiento: abstracciones de costo cero, compilación a código máquina nativo, sin fluctuaciones de GC.
• Seguridad de memoria: elimina en tiempo de compilación los desbordamientos de búfer y las condiciones de carrera; es crucial para herramientas que implican operaciones de bajo nivel del sistema (como migración de discos o configuración de red).
• Tamaño del binario: enlaza estáticamente todas las dependencias, produciendo un programa ejecutable portátil de un solo archivo.

¿Por qué Slint + Skia?

• Sintaxis declarativa: la descripción de la interfaz se separa de la lógica; el código es fácil de mantener.
• Renderizado con Skia: aprovecha directamente la aceleración por GPU (mediante el motor Skia), ofreciendo texto de nitidez subpixel y animaciones fluidas.
• Bajo coste: en comparación con Electron o WPF, el coste de runtime de Slint es mínimo.

3. Implementación técnica clave

3.1 Detección y análisis de instancias WSL

La aplicación obtiene el estado de las instancias en tiempo real invocando wsl.exe --list --verbose y analizando su salida (gestionando la codificación UTF-16).

• Decodificación subyacente: un codificador/decodificador propio de alta eficiencia garantiza el análisis correcto de la salida en entornos Windows con diferentes configuraciones regionales.
• Sincronización de estado: mecanismo dual de sincronización mediante sondeo periódico + disparo por operaciones.

3.2 Migración de imágenes de disco (VHDX Move)

La función de migración aprovecha el mecanismo de importación/exportación de WSL, pero con una alta abstracción y un tratamiento atómico.

• Garantía transaccional: antes de iniciar la migración, la aplicación bloquea la distribución de destino mediante un mutex (Mutex), evitando que las operaciones concurrentes corrompan los datos.
• Registro automático: al terminar la migración, la aplicación redirige automáticamente la ruta del VHDX y vuelve a registrar la distribución; el usuario no necesita intervención manual.

3.3 Reenvío de puertos y automatización del firewall

La función de red no es una simple llamada a netsh interface portproxy.

• Gestión del ciclo de vida de las reglas: la aplicación detecta automáticamente las reglas de firewall existentes. Cuando el usuario crea un reenvío, la aplicación crea sincrónicamente la regla de excepción de entrada mediante API o CLI de Windows.
• Obtención automática de IP: analizando el resultado de wsl hostname -I, mapea automáticamente la IP de la red virtual entre el host y la instancia.

3.4 Integración de USBIP

Utiliza la interfaz de línea de comandos de usbipd-win.

• Gestión de elevación de privilegios: la operación de vinculación requiere permisos de administrador; la lógica del backend implementa una elegante transferencia de solicitudes de elevación de UAC.
• Máquina de estados: mantiene internamente una máquina de estados de conexión de dispositivos USB que garantiza la trazabilidad del proceso Attach/Detach.

3.5 Supervisión de recursos y ligereza

La aplicación supervisa su propio uso de recursos mediante API nativas de Windows (como GetProcessMemoryInfo).

• Ligereza extrema: en el modo silencioso de bandeja, la aplicación libera proactivamente los recursos de UI innecesarios. Para conjuntos de caracteres estándar como el inglés, el consumo de memoria puede reducirse hasta 10MB; para conjuntos complejos como chino, japonés y coreano, al necesitar cargar cachés de renderizado de fuentes más grandes, el consumo ronda los 38MB.

4. Métricas de optimización del rendimiento

Métrica	Objetivo/medición	Medios de optimización
Velocidad de inicio	< 500ms	Interfaz Slint precompilada para reducir el análisis en tiempo de ejecución.
Memoria base (bandeja)	~10MB	Minimizar la frecuencia de sondeo en segundo plano y liberar las cachés de renderizado bajo demanda.
Uso de CPU (en reposo)	< 0.1%	Usar el modelo de eventos de Windows para evitar sondeos en bucle vacío.
Frecuencia de renderizado	60 FPS	Aceleración por GPU de Skia, renderizado antialias subpixel.

5. Lógica de despacho de tareas en segundo plano

Para garantizar la fluidez de la UI, todas las operaciones costosas (como exportar VHDX) se despachan mediante tareas asíncronas:

1. Encapsulado de la solicitud: el hilo de la UI encapsula la operación del usuario como un mensaje Command.
2. Canal de mensajes: se envía al procesador de tareas en segundo plano mediante tokio::sync::mpsc.
3. Devolución de estado: al terminar la tarea en segundo plano, la UI se actualiza mediante callbacks o estado compartido. Este diseño garantiza que, incluso al procesar tareas de copia de seguridad de varios GB, la interfaz siga respondiendo en tiempo real a los clics del usuario.

6. Consideraciones de seguridad

• Operaciones atómicas: implementa validaciones previas para el desregistro y la migración de instancias críticas.
• Gestión de elevación de UAC: solo solicita permisos cuando es necesario (como al vincular dispositivos USB), siguiendo el principio del menor privilegio.
• Almacenamiento local: la configuración solo se guarda localmente en ~\.wsldashboard; no se realiza ninguna sincronización en la nube, protegiendo la privacidad del usuario.