Windows NT vs. Unix: comparación de diseño

• NT solía ser considerado un sistema operativo "muy avanzado", pero no estaba claro por qué.
  • A fines de 2023, al leer la 1.ª edición de 'Inside Windows NT', se decidió comparar NT con Unix.
  • Se comparan los diseños de NT (julio de 1993) y de los sistemas Unix de esa época (4.4BSD, Linux 1.0).
  • Como especialista en Unix, no conoce bien NT, así que se enfoca en describir principalmente las diferencias de NT.
  • Aborda la pregunta de en qué era mejor NT que Unix y si eso sigue siendo cierto hoy.

Misión

• La historia de Unix es mucho más antigua que la de NT.
  • El desarrollo de Unix comenzó en 1969 y su objetivo principal era ser una plataforma conveniente para programadores.
  • Unix se inspiró en Multics, pero lo superó al centrarse en la simplicidad.
  • La portabilidad y la multitarea no eran objetivos originales del diseño de Unix: esas funciones se añadieron años después en muchos "forks" y reinvenciones de Unix.
• La historia de Microsoft
  • La primera versión de MS-DOS salió en agosto de 1981, y la primera versión de "Legacy Windows" (las versiones basadas en DOS) se lanzó en noviembre de 1985.
  • MS-DOS tuvo un gran éxito, pero Windows no se volvió realmente importante hasta Windows 3.0, en mayo de 1990.
  • Windows NT se concibió en 1989 y apareció al mundo con el lanzamiento de NT 3.1 en julio de 1993.
• La ventaja de Microsoft
  • El diseño de NT comenzó 20 años después que el de Unix, lo que le dio una ventaja a Microsoft.
  • Microsoft ya contaba con una gran base de usuarios gracias a MS-DOS y Legacy Windows.
  • El equipo de Microsoft que diseñó NT tenía los aprendizajes de esos desarrollos, experiencia en el desarrollo de otros sistemas operativos y acceso a tecnología moderna, lo que le permitió "apuntar a la luna" al crear NT.

Kernel

• Unix, con algunas excepciones como Minix o GNU Hurd, se implementó como un kernel monolítico que expone un conjunto de llamadas al sistema para interactuar con las funciones que ofrece el sistema operativo.
• En cambio, NT es una forma intermedia entre un kernel monolítico y un microkernel: el componente privilegiado executive se presenta ante los subsystems en espacio de usuario como un conjunto de componentes modulares.
• Los subsystems en espacio de usuario son procesos especiales que "traducen" las API que usan las aplicaciones (POSIX, OS/2, etc.) en llamadas al sistema del executive.
• Una parte importante del NT executive es la HAL, que proporciona primitivas abstractas para acceder al hardware de la máquina y sirve como base para el resto del kernel.
  • Esta capa es clave para que NT pueda ejecutarse en distintas arquitecturas, incluidas i386, Alpha y PowerPC.
  • En ese momento, Unix estaba acoplado a arquitecturas específicas: el concepto de Unix era portable, pero su implementación no.
  • SunOS originalmente solo soportaba Motorola 68000, 386BSD fue el primer port de BSD a la arquitectura Intel, e IRIX era una variante de Unix para las estaciones de trabajo basadas en MIPS de Silicon Graphics.
• Otra parte importante del NT executive es su soporte para sistemas multiprocesamiento y para un kernel con desalojo preventivo.
  • El kernel tiene varios niveles de interrupción (SPL en la terminología de BSD) para decidir qué puede interrumpir a qué otra cosa, pero lo más importante es que un hilo del kernel puede ser desalojado preventivamente por otro hilo del kernel.
  • Hoy todos los sistemas Unix de alto rendimiento hacen esto, pero no fue así como comenzaron muchos Unix.
  • Esos sistemas empezaron con kernels que no soportaban desalojo preventivo ni multiprocesamiento, luego añadieron soporte de multiprocesamiento en espacio de usuario y después agregaron desalojo preventivo en el kernel.
  • Ese último paso es el más difícil, y la saga de FreeBSD 5.0 ilustra bien esa dificultad.
  • Por eso resulta interesante que NT haya partido desde el inicio con una base correcta.

Objetos

• NT es un kernel orientado a objetos.
  • Podría pensarse que Unix también lo es: los procesos se definen como struct y las implementaciones del sistema de archivos manejan vnode ("nodo virtual", no debe confundirse con inode).
  • Sin embargo, eso no es exactamente lo mismo que hace NT: NT obliga a que todos esos objetos distintos tengan una representación común dentro del sistema.
• Puede dudarse de cómo se puede ofrecer una abstracción significativa para cosas tan heterogéneas como procesos y handles de archivos.
• En la práctica eso no es posible, pero NT obliga a que todos hereden de un tipo de objeto común y, sorprendentemente, eso sí aporta algunas buenas propiedades.
• Control de acceso centralizado
  • Como los objetos solo pueden ser creados por el object manager, existe un único lugar en el código para aplicar políticas.
  • Semánticas como la verificación de permisos pueden definirse en un solo lugar y aplicarse de forma uniforme en todo el sistema, lo cual es potente.
  • NetBSD también concluyó que esta era una buena idea, pero no obtuvo el framework Kernel Authorization (kauth) hasta 2001.
• ID común
  • Los objetos tienen ID y todos se representan dentro de un único árbol.
  • Esto significa que existe un espacio de nombres unificado para todos los objetos, ya sean procesos, handles de archivos o pipes.
  • Los objetos del árbol pueden direccionarse por nombre (ruta), y distintas partes del árbol pueden pertenecer a distintos subsistemas.
  • Por ejemplo, una parte del árbol puede representar un sistema de archivos montado y, por lo tanto, al recorrer el nodo raíz de ese subárbol, el sistema de archivos resolverá el resto de la ruta.
  • Esto es similar a la capa VFS de los sistemas Unix, pero VFS solo trata con sistemas de archivos, mientras que el árbol de objetos cubre todos y cada uno de los objetos del kernel.
  • Unix intentó encajar tipos de objetos no basados en archivos dentro del sistema de archivos mediante /proc/, /sys/, etc., pero eso se siente como una solución posterior en comparación con lo que ofrece NT.
• Manejo unificado de eventos
  • Todos los tipos de objetos tienen un estado signaled, cuyo significado varía según el tipo de objeto.
  • Por ejemplo, un objeto de proceso pasa al estado signaled cuando el proceso termina, y un objeto de handle de archivo pasa al estado signaled cuando se completa una solicitud de I/O.
  • Esto hace que sea muy fácil escribir código basado en eventos (código async) en espacio de usuario, ya que una sola llamada al sistema de estilo wait puede esperar a que un grupo de objetos cambie de estado.
  • En sistemas Unix, esperar al mismo tiempo por I/O y por la finalización de procesos es una molestia.
• Los objetos son un componente propio de NT y no se generalizan bien a todas las API que NT quería soportar.
  • Por ejemplo, el subsistema POSIX: POSIX no tiene un concepto de objetos como NT, pero NT debía ofrecer algún tipo de compatibilidad para aplicaciones POSIX.
  • Por esta razón, mientras el subsistema POSIX asigna objetos en el executive, también debe mantener su propia contabilidad para representar esas entidades POSIX y realizar de inmediato una traducción lógica entre ambas entidades.
  • En cambio, el subsistema Win32 entrega objetos directamente al cliente sin intermediarios.

Procesos

• Los procesos son objetos comunes tanto en NT como en Unix, pero no son completamente iguales
  • En Unix, los procesos se representan como un árbol, por lo que cada proceso tiene un padre y puede tener cero o más hijos
  • Sin embargo, en NT no existe esa relación: un proceso puede "heredar" recursos de su creador, pero una vez creado es una entidad independiente
• Cuando se diseñó NT, los hilos no eran algo común:
  • Mach fue el primer kernel similar a Unix en integrar hilos, en 1985
  • Esto significa que otros Unix tuvieron que adoptar este concepto después y adaptarlo a sus diseños existentes
  • Linux eligió representar los hilos como procesos, cada uno con su propio PID, en la versión 2.0 lanzada en junio de 1996, y NetBSD no obtuvo hilos representados como una entidad separada de los procesos hasta la versión 2.0 en 2004
  • A diferencia de Unix, NT eligió soportar hilos desde el principio porque entendía que eran esenciales para la computación de alto rendimiento en máquinas SMP
• NT no tiene señales en el sentido tradicional de Unix
  • En su lugar tiene alerts, que pueden ser de modo kernel o de modo usuario
  • Las alertas de modo usuario deben esperarse como cualquier otro objeto, y las alertas de modo kernel no son visibles para el proceso
  • El subsistema POSIX usa alertas de modo kernel para emular señales
  • Las señales a menudo se consideraban una verruga en Unix por la forma en que interrumpen la ejecución del proceso: manejarlas correctamente requiere un esfuerzo realmente difícil, así que la alternativa de NT parece más elegante
• Un desarrollo reciente interesante en NT fue la introducción de los picoprocesos
  • Hasta que se añadió esta función, los procesos de NT eran bastante pesados: un proceso nuevo recibía al iniciarse un conjunto de bibliotecas de tiempo de ejecución de NT mapeadas en su espacio de direcciones
  • En los picoprocesos, el proceso tiene una relación mínima con la arquitectura de Windows, y eso se usa para implementar procesos compatibles con Linux en WSL 1
  • En cierto sentido, los picoprocesos están más cerca de los procesos Unix que de los procesos nativos de Windows, pero debido al paso a WSL 2 ya no se usan mucho, aunque existen desde agosto de 2016
• Por más que se culpe a Windows por problemas de seguridad, NT comenzó con un diseño de seguridad avanzado para los estándares tempranos de internet, en el sentido de que el sistema funciona esencialmente como un sistema basado en capacidades
  • El primer proceso de usuario que se inicia después del inicio de sesión recibe del kernel un token de acceso que representa los privilegios de la sesión del usuario, y el proceso y sus subprocesos deben presentar ese token al kernel para reclamar privilegios
  • Esto es distinto de Unix, donde un proceso simplemente tiene un identificador y el kernel debe rastrear en la tabla de procesos lo que cada proceso puede hacer

Compatibilidad

• Uno de los principales objetivos de NT era ser compatible con aplicaciones escritas para Windows heredado, DOS, OS/2 y POSIX
  • Una de las razones era técnica, ya que esto obligaba al sistema a tener un diseño elegante
  • La otra razón era política: NT fue desarrollado en conjunto con IBM y, aunque NT terminó convirtiéndose en Windows, tenía que soportar aplicaciones de OS/2
• Esta necesidad de compatibilidad hizo que el diseño de NT fuera muy distinto al de Unix
  • En Unix, las aplicaciones en espacio de usuario se comunican directamente con el kernel a través de la interfaz de llamadas al sistema, y esa interfaz es la interfaz Unix
  • La biblioteca C proporciona el pegamento para invocar al kernel y las aplicaciones no ejecutan llamadas al sistema directamente, pero eso es un detalle menor
• En NT, las aplicaciones no se comunican directamente con el executive (kernel)
  • En su lugar, cada aplicación se comunica con un subsistema protegido específico, y estos subsistemas implementan las API de los distintos sistemas operativos con los que NT busca ser compatible
  • Estos subsistemas se implementan como servidores en espacio de usuario (no dentro del "microkernel" de NT)
  • El soporte para aplicaciones de Windows lo proporciona el servidor Win32, que es especial porque es el único servidor que el usuario puede ver directamente: controla los programas de consola y las terminales DOS, y tiene ciertos privilegios por motivos de rendimiento
• En comparación con Unix tradicional, BSD y Linux tienen kernels monolíticos, por lo que el diseño de NT es muy distinto
  • Estos kernels exponen una interfaz de llamadas al sistema que las aplicaciones en espacio de usuario aprovechan para interactuar directamente con el sistema
  • Sin embargo, BSD ha soportado durante mucho tiempo la ejecución de binarios alternativos dentro del kernel monolítico: esto funciona exponiendo distintas tablas de llamadas al sistema al espacio de usuario según el binario que se esté ejecutando, y luego traduciendo esas llamadas al sistema "externas" a algo que el kernel entienda
  • Linux también ofrece soporte limitado para esto mediante las personalities
• Aunque el enfoque de BSD es muy distinto de la manera en que NT soporta otros sistemas, WSL 1 es muy similar y no es un subsistema en el sentido originalmente definido
  • En WSL 1, el kernel de NT marca los procesos Linux como picoprocesos y a partir de ahí expone una interfaz distinta de llamadas al sistema
  • Dentro del kernel de NT, esas llamadas al sistema relacionadas con Linux se traducen a operaciones de NT y se ofrecen dentro del mismo kernel, igual que en la compatibilidad con Linux de BSD
  • El único problema es que, como NT no es Unix, la "emulación" de Linux es complicada y mucho más lenta de lo que BSD puede ofrecer
  • Es una lástima que WSL 2 haya perdido la esencia de este diseño y haya pasado a un diseño de VM completo
• Detalles interesantes del diseño de NT
  • El objetivo del diseño de NT era permitir redirección de E/S fluida entre subsistemas desde un solo shell
  • Los subsistemas se exponen a las aplicaciones mediante puertos, que son objetos de NT y son similares a la forma en que Mach permite la comunicación entre procesos y servidores

Memoria virtual

• NT, al igual que Unix, depende de una Memory Management Unit (MMU) con paginación para proporcionar protección entre procesos y ofrecer memoria virtual
  • La paginación de procesos en espacio de usuario es el mecanismo habitual para ofrecer un espacio de direcciones mayor que la cantidad de memoria física de la máquina
  • Sin embargo, algo que puso a NT por delante de los sistemas Unix de su época fue que el propio kernel también podía paginarse al disco
  • Si todo el kernel pudiera paginarse, podría darse la situación de tener que resolver un fallo de página del kernel que requiere código de un controlador del sistema de archivos que fue paginado fuera, pero una parte considerable del kernel sí puede paginarse
  • Hoy en día esto no resulta especialmente interesante porque el kernel es pequeño en comparación con la memoria típica instalada en una máquina, pero antes cada byte era valioso, así que marcaba una gran diferencia
• Hoy damos por sentado cómo funcionan la memoria virtual y la paginación, pero cuando NT fue diseñado era un área importante de investigación
  • Implementaciones anteriores de Unix tenían cachés de memoria separadas para el sistema de archivos y para la memoria virtual, y no fue sino hasta 1987 cuando SunOS implementó una arquitectura de memoria virtual unificada para reducir la sobrecarga del diseño anterior
  • En cambio, NT empezó con una arquitectura de memoria unificada desde el principio
  • Se podría decir que esto fue más fácil de hacer porque ya existía comprensión sobre las ineficiencias encontradas en Unix y porque antes de iniciar el diseño de NT ya se podía ver la solución implementada por SunOS
  • Sin embargo, hay que notar que esto hizo a NT "más avanzado" que muchos otros sistemas operativos de la época, y que otros sistemas no se pusieron al día hasta 2002 con la implementación de Unified Buffer Cache (UBC) en NetBSD 1.6
• Una diferencia interesante entre NT y Unix es cómo gestionan y representan la memoria compartida
  • En NT, las secciones de memoria compartida son objetos, así que reciben exactamente las mismas comprobaciones de validez de acceso que cualquier otro objeto
  • También forman parte de un único árbol de objetos, así que pueden direccionarse del mismo modo que cualquier otro objeto
  • En Unix, esta funcionalidad está añadida a posteriori: los objetos de memoria compartida tienen otro espacio de nombres y una API distinta a la de todas las demás entidades, por lo que no se aplican permisos generales

Subsistema de E/S

• Las primeras versiones de Unix solo admitían un único sistema de archivos
  • Por ejemplo, BSD no obtuvo la abstracción de Virtual File System (VFS) para soportar más allá de UFS hasta 4.3BSD en abril de 1990
  • En cambio, NT empezó con un diseño que permitía varios sistemas de archivos
• Para admitir varios sistemas de archivos, el kernel tiene que exponer de alguna manera ese espacio de nombres
  • Unix combina sistemas de archivos dentro de una sola jerarquía de archivos mediante puntos de montaje: la capa VFS proporciona un mecanismo para identificar el nodo correspondiente a la raíz del sistema de archivos y redirigir solicitudes al driver de ese sistema de archivos al recorrer una ruta
  • NT tiene un diseño similar, aunque en la interfaz estándar de usuario los sistemas de archivos aparezcan como unidades separadas: internamente, el executive representa los sistemas de archivos como objetos dentro de un árbol de objetos, y cada objeto es responsable de analizar el resto de la ruta
  • Luego esos objetos de sistema de archivos se vuelven a mapear como unidades DOS para que el espacio de usuario pueda acceder a ellos
  • Las unidades DOS también son objetos bajo un subárbol separado que redirige la E/S al sistema de archivos al que hacen referencia
• NT finalmente se lanzó con NTFS
  • Aunque a NTFS le encanta que lo critiquen por un supuesto mal rendimiento (una afirmación errónea), para su época era realmente un sistema de archivos avanzado
  • El subsistema de E/S de NT, combinado con NTFS, ofrecía direccionamiento de 64 bits, journaling e incluso nombres de archivo en Unicode
  • Linux no tuvo soporte para archivos de 64 bits hasta finales de los años 90, y no tuvo journaling hasta el lanzamiento de ext3 en 2001
  • Soft updates, un mecanismo alternativo de tolerancia a fallos, no apareció en FreeBSD hasta 1998
  • Unix representa los nombres de archivo como arreglos de bytes terminados en null, no como Unicode
• Otras funciones incluidas en el lanzamiento de NT eran disk striping y mirroring (hoy conocidos como RAID), además de hot-plugging de dispositivos
  • Estas funciones no eran nuevas, ya que SunOS incluía soporte para RAID desde principios de los años 90, pero lo interesante es que todas fueron consideradas parte del diseño original
  • En un nivel más alto, lo que hace al subsistema de E/S de NT mucho más avanzado que el de Unix es que su interfaz es esencialmente asíncrona, y lo fue desde el principio
  • Para ponerlo en perspectiva, FreeBSD no vio soporte para aio(7) hasta FreeBSD 3.0 en 1998, y Linux no lo vio hasta Linux 2.5 en 2002
  • Aunque el soporte para E/S asíncrona ha existido en sistemas Unix por más de 20 años, sigue sin usarse ampliamente: casi nadie conoce esas API, la mayoría de las aplicaciones no las usan y su rendimiento es deficiente
  • io_uring de Linux es una adición relativamente reciente para mejorar la E/S asíncrona, pero ha sido una causa importante de vulnerabilidades de seguridad y no se usa ampliamente

Redes

• Hoy Internet está en todas partes, pero cuando se diseñó NT no era así
  • Si miramos el ecosistema de Microsoft, DOS 3.1 (1987) incluía la base para compartir archivos en el sistema de archivos FAT, pero el propio "OS" no ofrecía funciones de red: eso lo hacía un producto aparte llamado Microsoft Networks (MS-NET)
  • Windows 3.0 (1990) incluía soporte para NetBIOS, permitiendo compartir impresoras y archivos de forma básica en redes locales, pero no había soporte para TCP/IP
• En cambio, Unix era prácticamente Internet mismo: todos los protocolos base de Internet fueron escritos en Unix y junto con Unix
  • Durante el diseño de NT era importante considerar un buen soporte de red, y de hecho NT se lanzó con funciones de red
  • Como resultado, NT soportaba tanto los protocolos de Internet como los protocolos LAN tradicionales usados en el entorno heredado de Microsoft, lo que le dio ventaja sobre Unix en entornos empresariales
• Un ejemplo son los dominios de red de NT
  • En Unix, los administradores de red normalmente sincronizaban manualmente las cuentas de usuario entre máquinas
  • Podían haber usado el protocolo de directorio X.500 (1988) y Kerberos (años 80), implementados por sistemas como SunOS, para la autenticación de usuarios, pero estas tecnologías no eran especialmente simples
  • En cambio, NT ofrecía desde el inicio dominios que integraban funciones de directorio y autenticación, y esto parece haber "ganado" en redes corporativas porque era mucho más fácil de configurar y venía integrado en el sistema
• El objetivo de las cuentas de usuario sincronizadas es compartir recursos entre máquinas, principalmente archivos, y al hacerlo importa cómo se representan los permisos
  • Durante mucho tiempo, Unix solo ofreció un conjunto simple de permisos de lectura/escritura/ejecución para cada archivo
  • En cambio, NT venía desde el principio con ACL avanzadas, algo que sigue siendo un punto débil en Unix
  • Linux y BSD ahora también tienen ACL, pero las interfaces no son consistentes entre sistemas y se sienten como una adición ajena al diseño del sistema
  • En NT, las ACL operan a nivel de objeto, así que se aplican de forma consistente a todas las funciones del kernel
• Al hablar de compartir archivos, hay que hablar de sistemas de archivos de red
  • En Unix, de facto el sistema de archivos era NFS, y en NT era SMB
  • SMB fue heredado de MS-NET y LAN Manager, y se implementa en el kernel mediante un componente llamado redirector
  • En esencia, el redirector es "simplemente" otro sistema de archivos que intercepta operaciones de archivo y las envía por la red, igual que NFS en Unix
• protobuf y gRPC se usan ampliamente hoy y pueden parecer ideas nuevas, pero se basan en ideas antiguas
  • En Unix, Sun RPC se usaba desde principios de los años 80, principalmente para soportar NFS
  • Del mismo modo, NT venía con soporte RPC integrado, con su propio DSL (conocido como MIDL para especificar definiciones de interfaz y generar código para procedimientos remotos) y sus propias capacidades para implementar clientes y servidores RPC
• Los sistemas Unix no ponían mucho énfasis en el soporte para drivers arbitrarios: normalmente estaban ligados a una máquina y proveedor específicos
  • En cambio, NT buscaba ser un OS para "todas" las máquinas y se vendía como producto de una empresa de software, así que era importante admitir drivers escritos por terceros
  • Como resultado, NT incluía Network Driver Interface Specification (NDIS), una abstracción pensada para facilitar el soporte de drivers de tarjetas de red
  • Hasta hoy, los drivers proporcionados por fabricantes no son algo tan común en Linux, y esto dio lugar a curiosidades como ndiswrapper, un hack muy popular a principios de los 2000 que permitía reutilizar drivers de Windows para tarjetas WiFi en Linux
• Por último, otra diferencia entre NT y Unix está en la implementación de las named pipes
  • En Unix, las named pipes son un componente local: proporcionan un mecanismo para que dos procesos en la misma máquina se comuniquen entre sí usando un nombre de archivo persistente en disco
  • NT tiene esta misma capacidad, pero sus named pipes pueden funcionar a través de la red
  • Si colocas named pipes en un sistema de archivos compartido, dos aplicaciones en computadoras distintas pueden comunicarse sin preocuparse por los detalles de red

Espacio de usuario

• Configuración:
  • NT centralizó la configuración del sistema y de las aplicaciones en una base de datos llamada registro, alejándose de los antiguos CONFIG.SYS, AUTOEXEC.BAT y de los innumerables archivos INI usados en Windows heredado
  • Esto enfureció mucho a algunas personas, pero al final una interfaz de configuración unificada beneficia a todos: es más fácil escribir aplicaciones porque hay una sola base que soportar, y los usuarios pueden ajustar el sistema más fácilmente porque solo hay un lugar que revisar
  • En cambio, Unix sigue sufriendo por decenas de DSL y ubicaciones de archivos inconsistentes
  • Cada programa que soporta archivos de configuración tiene su propia sintaxis, y es difícil saber dónde lee el programa, además de que no siempre está bien documentado
  • El ecosistema Linux impulsó un enfoque similar al de NT mediante XDG y dconf (antes GConf), pero mientras los componentes de escritorio usan estas tecnologías de forma exclusiva, los componentes base del sistema no las adoptaron, dejando un desastre inconsistente
• Internacionalización:
  • Microsoft, como gran empresa que ya estaba lanzando Windows 3.x en todo el mundo, entendía que la localización era importante e hizo que NT soportara estas capacidades desde el principio
  • Contrástese esto con Unix, donde el soporte para UTF recién empezó a aparecer hacia finales de los años noventa y el soporte para otros idiomas llegó mediante complementos opcionales de gettext
• Lenguaje C:
  • Algo con lo que sistemas Unix como FreeBSD y NetBSD han soñado durante un tiempo es con idear su propio dialecto de C para implementar el kernel de una forma más segura
  • Esto no llegó a ninguna parte, salvo en Linux, que depende de extensiones exclusivas de GCC
  • Microsoft, en cambio, tenía el privilegio de ser dueña de su compilador de C, así que hizo esto en NT, escrito con Microsoft C
  • Por ejemplo, NT depende de Structured Exception Handling (SEH), una capacidad que añade cláusulas try/except para manejar excepciones de software y hardware
  • No diría que esto sea una gran ventaja, pero sí es una diferencia real

Conclusión

• NT fue una tecnología revolucionaria en el momento de su lanzamiento
• Como se explicó arriba, muchas funciones que hoy damos por sentadas en el diseño de sistemas ya estaban presentes en NT desde el principio, mientras que casi todos los demás sistemas Unix tuvieron que incorporarlas lentamente con el tiempo
• Como resultado, estas funciones no siempre se integran de manera fluida con la filosofía Unix
• Sin embargo, hoy no está claro si NT es realmente "más avanzado" que Linux o FreeBSD
  • NT tenía desde el inicio principios de diseño más sólidos y más funciones que los sistemas operativos de su época, pero hoy en día la diferencia es difusa
  • Es decir, NT evolucionó, pero no llegó a ser sustancialmente más avanzado que los Unix modernos
• Aun con todos estos sólidos principios de diseño en NT, resulta decepcionante que el diseño no pueda lucirse debido al exceso de peso de la UI
  • Incluso en máquinas ultrapotentes, la lentitud del SO puede ser dolorosa de presenciar, e incluso podría llevar al fin de este sistema operativo

Resumen de GN⁺

• Este artículo compara las diferencias de diseño entre NT y Unix para explicar cuán avanzado era el diseño inicial de NT
• NT fue diseñado desde el principio con objetivos de portabilidad, soporte de multiprocesamiento y compatibilidad, y esa es una diferencia clave frente a Unix
• El kernel orientado a objetos de NT, su arquitectura de memoria unificada y su interfaz de I/O asíncrona ofrecen funciones más avanzadas que Unix
• Sin embargo, hoy la diferencia entre NT y los sistemas Unix no es grande, y el exceso de peso de la UI de NT provoca una degradación del rendimiento

[GN⁺]

Opiniones de Hacker News

• El kernel NT es excelente, pero su diseño es antiguo

  • El OS de Windows tiene muchos elementos obsoletos apilados sobre el kernel NT, lo que causa problemas
  • Microsoft debería considerar un nuevo diseño de OS basado en NT, alejándose del paradigma de Win32 y MS-DOS

• La mayor diferencia entre NT y Unix es el enfoque hacia los drivers

  • NT fue diseñado para resolver los problemas de drivers de Windows 3.x/95/98
  • Unix considera a los drivers como componentes de alta confiabilidad y son escritos por desarrolladores del kernel

• En WinNT moderno, Direct3D es una parte esencial del kernel

  • D3D11 puede usarse incluso sin GPU y ofrece una alternativa por software llamada WARP
  • Linux carece de una función similar

• El kernel NT ejecuta hilos, no procesos

  • Los hilos pueden crearse en unos pocos milisegundos, mientras que los procesos son pesados
  • La historia de NT tiene sus raíces en los principios fundamentales de VMS

• WindowsNT, al principio, era un sistema mucho mejor diseñado que Linux

  • NT podía ejecutar Win32, OS/2 y POSIX
  • POSIX se agregó para grandes contratos de software del gobierno de EE. UU., pero luego perdió relevancia

• NT, como tercer sistema, evitó el síndrome del segundo sistema

  • OS/2 resolvió problemas técnicamente equivocados y también fracasó organizacionalmente
  • NT no fue ampliamente usado hasta Windows XP

• Hay diferencias entre Windows y Linux desde la perspectiva del desarrollador

  • Windows es superior en la línea de comandos y en la forma de hacer globbing
  • El uso de wchar_t en Win32 es un problema

• El kernel NT tiene elegancia, pero no es open source

  • Sería interesante un Windows con otro espacio de usuario y otro entorno de escritorio

• Hubo una convergencia similar a FUSE en Linux

  • El enfoque del sistema de archivos de Win NT hace que muchas operaciones de archivos sean muy lentas
  • Microsoft abandonó WSL1 y usa contenedores como SQLLite o archivos ZIP