Subsistema de Windows para Linux

LXSS Manager Service es el servicio encargado de interactuar con el subsistema (a través de los drivers lxss.sys y lxcore.sys), y la forma en cómo Bash.exe (no confundir con las Shell provistas por las distribuciones Linux instaladas) lanza los procesos de Linux, así como también manejar las llamadas al sistema de Linux y el bloqueo de los binarios mientras la operación de ejecución está en curso.[24]

Todos los procesos Linux invocados por un usuario en particular van dentro de una "Instancia de Linux" (usualmente, el primer proceso invocado es init). Una vez que todas las aplicaciones son cerradas, se cierra la instancia (de ser necesario, se deberá cerrar forzadamente el proceso init).

Como no hay emulación/virtualización de hardware (a diferencia de otros proyectos como coLinux), WSL hace uso directo del sistema de archivos anfitrión (a través de VolFS y DrvFS)[25] y parte del hardware, como la red (los servidores web por ejemplo, podrán ser accedidos a través de las mismas interfaces y direcciones IP configuradas en el host, y comparte las mismas restricciones de uso de puertos que requieren permisos administrativos, o puertos ya ocupados por otras aplicaciones), lo que garantiza la interoperabilidad.[25]

Hay ciertas ubicaciones (como las carpetas del sistema) y configuraciones cuyo acceso/modificación está restringido, incluso ejecutando sudo desde la shell. Se debe lanzar una instancia con privilegios elevados para obtener un "sudo real" y permitir dicho acceso.[26]

Este subsistema no es capaz de correr todo el software Linux, como los binarios de 32 bits,[27][28] o esos que requieren servicios específicos del núcleo Linux sin implementar en WSL. Dado que no existe un núcleo Linux "real" en WSL, tampoco se han lanzado las cabeceras del kernel, lo que impide construir controladores y otros programas que dependen del kernel (como drivers, o contenedores como Docker).

Es posible ejecutar algunas aplicaciones gráficas (como Mozilla Firefox) instalando un servidor X11 dentro del entorno de Windows (como Xming),[29] aunque no exento de problemas, como la falta de soporte de audio o aceleración por hardware (dando como resultado un pobre rendimiento gráfico). El soporte para OpenCL y CUDA tampoco está implementando, aunque planificado para futuros lanzamientos.[30][31]

Dado lo anterior, Microsoft indica explícitamente que WSL está orientado al desarrollo de aplicaciones, y no como un entorno de escritorio o servidor de producción, recomendando el uso de máquinas virtuales (Hyper-V o Kubernetes) y Azure para esos propósitos.[26]

La versión 2 introduce cambios radicales en la arquitectura. Microsoft ha optado por la virtualización a través de un subconjunto de características de Hyper-V, junto con un núcleo Linux real altamente optimizado (basado en la rama principal 4.19),[4] lo que habilita acceso completo a la API de Linux, permitiendo ejecutar servicios como Docker.[32] Los desarrolladores no necesitan hacer cambios en sus distribuciones, manteniendo la compatibilidad con WSL 1. A diferencia de una máquina virtual, las instancias de WSL2 arrancan instantáneamente.^{[cita requerida]}

La instalación de la distribución reside en su propia imagen de disco virtual con formato ext4, y el acceso al sistema de archivos anfitrión se lleva a cabo de manera transparente a través del protocolo 9P.[33] Se promete un incremento sustancial en el rendimiento de lectura y escritura.[17]