- O NT era frequentemente avaliado como um sistema operacional "muito avançado", mas não estava claro o motivo
- No fim de 2023, ao ler a 1ª edição de 'Inside Windows NT', decidiu-se comparar NT e Unix
- Trata-se de uma comparação entre o design do NT (julho de 1993) e dos sistemas Unix da época (4.4BSD, Linux 1.0)
- Como especialista em Unix, o autor não conhece tão bem o NT, então o texto foca principalmente nas diferenças do NT
- O texto aborda a pergunta sobre em que aspectos o NT era melhor que o Unix, e se isso ainda continua sendo verdade
Missão
- A história do Unix é muito mais antiga que a do NT
- O desenvolvimento do Unix começou em 1969, e o principal objetivo era ser uma plataforma conveniente para programadores
- O Unix foi inspirado no Multics, mas o superou ao focar na simplicidade
- Portabilidade e multitarefa não eram objetivos originais do design do Unix: esses recursos foram adicionados anos depois em muitos "forks" e reinvenções do Unix
- A história da Microsoft
- A primeira versão do MS-DOS foi lançada em agosto de 1981, e a primeira versão do "Windows legado" (versões baseadas em DOS) foi lançada em novembro de 1985
- O MS-DOS teve grande sucesso, mas o Windows só realmente se tornou importante a partir do Windows 3.0, em maio de 1990
- O Windows NT foi concebido em 1989 e apareceu ao mundo com o lançamento do NT 3.1 em julho de 1993
- A vantagem da Microsoft
- O design do NT começou 20 anos depois do Unix, o que deu uma vantagem à Microsoft
- A Microsoft já havia garantido uma grande base de usuários graças ao MS-DOS e ao Windows legado
- A equipe da Microsoft que projetou o NT tinha os insights desses desenvolvimentos, experiência no desenvolvimento de outros sistemas operacionais e acesso às tecnologias mais recentes, podendo "mirar na lua" ao criar o NT
Kernel
- O Unix foi implementado como um kernel monolítico, com algumas exceções como Minix e GNU Hurd, expondo um conjunto de chamadas de sistema para interagir com as funções oferecidas pelo sistema operacional
- Já o NT é uma forma intermediária entre kernel monolítico e microkernel: o componente privilegiado executive se apresenta aos subsystems em espaço de usuário como um conjunto de componentes modulares
- Os subsystems em espaço de usuário são processos especiais que "traduzem" as APIs usadas pelas aplicações (POSIX, OS/2 etc.) em chamadas de sistema do executive
- Uma das partes importantes do NT executive é a HAL, que fornece primitivas abstratas para acessar o hardware da máquina e serve de base para o restante do kernel
- Essa camada é central para permitir que o NT rode em várias arquiteturas, incluindo i386, Alpha e PowerPC
- Na época, o Unix era acoplado a arquiteturas específicas: o conceito de Unix era portável, mas a implementação não
- O SunOS originalmente suportava apenas Motorola 68000; o 386BSD foi o primeiro port do BSD para a arquitetura Intel; e o IRIX era uma variante de Unix para as workstations baseadas em MIPS da Silicon Graphics
- Outra parte importante do NT executive é o suporte a sistemas multiprocessados e a um kernel preemptivo
- O kernel tem vários níveis de interrupção para decidir o que pode interromper o quê (SPL, na terminologia do BSD), mas o mais importante é que threads do kernel podem ser preemptadas por outras threads do kernel
- Isso é algo que todos os sistemas Unix de alto desempenho fazem hoje, mas não era assim que muitos Unix começaram
- Esses sistemas começaram com kernels que não suportavam preempção nem multiprocessamento, depois adicionaram suporte a multiprocessamento em espaço de usuário e, em seguida, acrescentaram a preempção do kernel
- A última etapa é a mais difícil, e a saga do FreeBSD 5.0 ilustra essas dificuldades
- Por isso, é interessante que o NT tenha começado desde o início com a base certa
Objetos
- O NT é um kernel orientado a objetos
- Pode-se pensar que o Unix também é: processos são definidos como
struct, e implementações de sistema de arquivos lidam com vnode ("nó virtual", não confundir com inode)
- Mas isso não é exatamente a mesma coisa que o NT faz: o NT força todos esses objetos diferentes a terem uma representação comum no sistema
- Pode haver dúvida sobre como oferecer uma abstração significativa para coisas tão heterogêneas como processos e handles de arquivo
- Na prática, isso não é possível, mas o NT força todos eles a herdarem de um tipo de objeto comum e, surpreendentemente, isso traz algumas boas propriedades
- Controle de acesso centralizado
- Como os objetos só podem ser criados pelo object manager, existe um único ponto no código para aplicar políticas
- Semânticas como verificação de permissões podem ser definidas em um único lugar e aplicadas de forma uniforme em todo o sistema, o que é poderoso
- O NetBSD também concluiu que isso era uma boa ideia, mas só ganhou o framework Kernel Authorization (kauth) em 2001
- ID comum
- Objetos têm IDs e todos são representados em uma única árvore
- Isso significa que existe um namespace único para todos os objetos, sejam processos, handles de arquivo ou pipes
- Objetos na árvore podem ser endereçados por nome (caminho), e partes diferentes da árvore podem pertencer a subsistemas diferentes
- Por exemplo, parte da árvore pode representar um sistema de arquivos montado e, assim, ao percorrer o nó raiz dessa subárvore, o sistema de arquivos resolve o restante do caminho
- Isso é semelhante à camada VFS dos sistemas Unix, mas a VFS lida apenas com sistemas de arquivos, enquanto a árvore de objetos cobre todos os objetos individuais do kernel
- O Unix tentou encaixar tipos de objetos não relacionados a arquivos em sistemas de arquivos por meio de
/proc/, /sys/ etc., mas isso parece um remendo posterior em comparação com o que o NT oferece
- Tratamento unificado de eventos
- Todo tipo de objeto tem um estado signaled, cujo significado varia conforme o tipo de objeto
- Por exemplo, um objeto de processo entra em estado signaled quando o processo termina, e um objeto de handle de arquivo entra em estado signaled quando uma requisição de I/O é concluída
- Isso torna muito fácil escrever código orientado a eventos (código assíncrono) em espaço de usuário, porque uma única chamada de sistema no estilo wait pode esperar que um grupo de objetos mude de estado
- Em sistemas Unix, esperar ao mesmo tempo por I/O e pela conclusão de processos é algo doloroso
- Objetos são componentes próprios do NT e não se generalizam bem para todas as APIs que o NT pretende suportar
- Por exemplo, o subsystem POSIX: POSIX não tem um conceito de objeto como o NT, mas o NT precisa oferecer algum tipo de compatibilidade para aplicações POSIX
- Por isso, enquanto o subsystem POSIX aloca objetos no executive, ele precisa manter seu próprio registro interno para representar essas entidades POSIX e imediatamente realizar a conversão lógica entre as duas entidades
- Já o subsystem Win32 entrega objetos diretamente ao cliente, sem intermediário
Processos
- Os processos são objetos em comum entre NT e Unix, mas não são totalmente idênticos
- No Unix, os processos são representados como uma árvore, de modo que cada processo tem um pai e pode ter zero ou mais filhos
- No NT, porém, essa relação não existe: os processos podem "herdar" recursos de quem os criou, mas, depois de criados, são entidades independentes
- Quando o NT foi projetado, threads não eram comuns:
- O Mach foi o primeiro kernel semelhante ao Unix a integrar threads, em 1985
- Isso significa que outros Unix tiveram de adotar esse conceito depois e adaptá-lo aos projetos já existentes
- O Linux escolheu representar threads como processos, cada um com seu próprio PID, no lançamento da versão 2.0 em junho de 1996, e o NetBSD só passou a ter threads representadas como entidades separadas dos processos no lançamento da versão 2.0 em 2004
- Ao contrário do Unix, o NT optou por oferecer suporte a threads desde o início, sabendo que elas eram essenciais para computação de alto desempenho em máquinas SMP
- O NT não tem sinais no sentido tradicional do Unix
- Em vez disso, há alerts, que podem existir em modo kernel e em modo usuário
- Alertas em modo usuário precisam ser aguardados como qualquer outro objeto, e alertas em modo kernel não são visíveis para o processo
- O subsistema POSIX usa alertas em modo kernel para emular sinais
- Sinais muitas vezes eram chamados de verruga no Unix por causa da forma como interrompem a execução do processo: como tratá-los corretamente exige um esforço realmente difícil, a alternativa do NT parece mais elegante
- Um desenvolvimento interessante mais recente no NT foi a introdução dos picoprocessos
- Até esse recurso ser adicionado, os processos do NT eram consideravelmente pesados: um novo processo recebia, na inicialização, um conjunto de bibliotecas de runtime do NT mapeadas em seu espaço de endereçamento
- Nos picoprocessos, o processo tem uma associação mínima com a arquitetura do Windows, e isso foi usado para implementar processos compatíveis com Linux no WSL 1
- Em certo sentido, os picoprocessos são mais próximos dos processos Unix do que os processos nativos do Windows, mas, com a migração para o WSL 2, eles não são mais muito usados, apesar de existirem desde agosto de 2016
- Por mais que se culpem os problemas de segurança do Windows, o NT começou com um projeto de segurança avançado para os padrões iniciais da internet, no sentido de que o sistema funciona, por padrão, como um sistema baseado em capacidades
- O primeiro processo de usuário iniciado após o logon recebe do kernel um token de acesso que representa as permissões da sessão do usuário, e o processo e seus subprocessos precisam apresentar esse token ao kernel para reivindicar privilégios
- Isso difere do Unix, em que os processos simplesmente têm identificadores e o kernel precisa acompanhar, na tabela de processos, o que cada processo pode fazer
Compatibilidade
- Um dos principais objetivos do NT era ser compatível com aplicações escritas para Windows legado, DOS, OS/2 e POSIX
- Uma razão para isso era técnica, pois isso forçou o sistema a ter um projeto elegante
- A outra razão era política: o NT foi desenvolvido em conjunto com a IBM e, embora no fim tenha se tornado o Windows, ele precisava oferecer suporte a aplicações de OS/2
- Essa necessidade de compatibilidade fez com que o projeto do NT fosse muito diferente do Unix
- No Unix, aplicações em espaço de usuário se comunicam diretamente com o kernel por meio da interface de chamadas de sistema, e essa interface é a interface Unix
- A biblioteca C fornece a cola para chamar o kernel, e as aplicações não executam chamadas de sistema diretamente, mas isso é um detalhe trivial
- No NT, as aplicações não se comunicam diretamente com o executive (kernel)
- Em vez disso, cada aplicação se comunica com um subsistema protegido específico, e esses subsistemas implementam as APIs dos vários sistemas operacionais com os quais o NT pretende ser compatível
- Esses subsistemas são implementados como servidores em espaço de usuário (não dentro do "microkernel" do NT)
- O suporte a aplicações Windows é fornecido pelo servidor Win32, que é especial por ser o único servidor que o usuário pode ver diretamente: ele controla programas de console e terminais DOS e tem certos privilégios por motivos de desempenho
- Em comparação com o Unix tradicional, o projeto do NT é bem diferente porque BSD e Linux têm kernels monolíticos
- Esses kernels expõem uma interface de chamadas de sistema que as aplicações em espaço de usuário usam para interagir diretamente com o sistema
- No entanto, o BSD há muito tempo oferece suporte à execução alternativa de binários dentro de um kernel monolítico: isso funciona expondo ao espaço de usuário diferentes tabelas de chamadas de sistema conforme o binário em execução e, em seguida, convertendo essas chamadas de sistema "externas" em algo que o kernel entende
- O Linux também oferece suporte limitado a isso por meio de personalities
- Embora a abordagem do BSD seja muito diferente da forma como o NT dá suporte a outros sistemas, o WSL 1 é muito semelhante e não é um subsistema no sentido originalmente definido
- No WSL 1, o kernel NT marca processos Linux como picoprocessos e, a partir daí, expõe uma interface diferente de chamadas de sistema
- Dentro do kernel NT, essas chamadas de sistema relacionadas ao Linux são convertidas em operações do NT e fornecidas dentro do mesmo kernel, exatamente como na compatibilidade Linux do BSD
- O único problema é que, como o NT não é Unix, a "emulação" de Linux é complicada e muito mais lenta do que o BSD consegue oferecer
- É uma pena que o WSL 2 tenha perdido a essência desse projeto e passado para um desenho baseado em VM completa
- Detalhes interessantes do projeto do NT
- Um objetivo do projeto do NT era permitir redirecionamento de I/O contínuo entre subsistemas dentro de um único shell
- Os subsistemas são expostos às aplicações por meio de ports, que são objetos do NT e se parecem com a forma como o Mach permite a comunicação entre processos e servidores
Memória virtual
- Assim como o Unix, o NT depende de uma Memory Management Unit (MMU) com paginação para fornecer proteção entre processos e memória virtual
- A paginação de processos em espaço de usuário é o mecanismo usual para oferecer um espaço de endereçamento maior do que a quantidade de memória física da máquina
- No entanto, uma coisa que colocava o NT à frente dos sistemas Unix da época era o fato de que o próprio kernel também podia ser paginado para disco
- Se o kernel inteiro pudesse ser paginado, haveria a possibilidade de cair numa situação em que seria necessário o código de um driver de sistema de arquivos paginado para resolver uma page fault do kernel, mas uma parte considerável do kernel pode ser paginada
- Hoje em dia isso não é especialmente interessante, porque o kernel é pequeno em comparação com a quantidade de memória normalmente instalada na máquina, mas, no passado, isso fazia grande diferença, porque cada byte era valioso
- Hoje em dia tomamos como garantida a forma como memória virtual e paginação funcionam, mas isso era uma grande área de pesquisa quando o NT foi projetado
- Implementações anteriores de Unix tinham caches de memória separados para sistema de arquivos e memória virtual, e só em 1987 o SunOS implementou uma arquitetura de memória virtual unificada para reduzir a sobrecarga do projeto anterior
- O NT, por outro lado, começou com uma arquitetura de memória unificada desde o início
- Pode-se dizer que isso foi mais fácil de fazer porque já havia entendimento sobre as ineficiências encontradas no Unix e porque foi possível ver a solução implementada pelo SunOS antes do início do projeto do NT
- Ainda assim, vale notar que isso tornou o NT "mais avançado" do que muitos outros sistemas operacionais da época, e outros sistemas só foram alcançá-lo em 2002, com a implementação do Unified Buffer Cache (UBC) no NetBSD 1.6
- Uma diferença interessante entre NT e Unix é a forma como gerenciam e representam memória compartilhada
- No NT, seções de memória compartilhada são objetos e, portanto, passam exatamente pelas mesmas verificações de validade de acesso que todos os outros objetos
- Além disso, elas fazem parte de uma única árvore de objetos, então podem ser endereçadas da mesma forma que todos os demais objetos
- No Unix, isso foi acoplado depois: objetos de memória compartilhada têm outro namespace e outra API para todos os demais tipos de entidade, então as permissões gerais não se aplicam
Subsistema de I/O
- As primeiras versões do Unix suportavam apenas um único sistema de arquivos
- Por exemplo, o BSD só foi ganhar a abstração Virtual File System (VFS) para suportar mais do que o UFS no 4.3BSD, em abril de 1990
- Já o NT começou com um design que permitia vários sistemas de arquivos
- Para suportar vários sistemas de arquivos, o kernel precisa expor esse namespace de alguma forma
- O Unix combina sistemas de arquivos em uma única hierarquia de arquivos por meio de pontos de montagem: a camada VFS fornece um mecanismo para identificar o nó correspondente à raiz do sistema de arquivos e redirecionar requisições ao driver daquele sistema de arquivos ao percorrer um caminho
- O NT tem um design semelhante, embora na interface padrão ao usuário os sistemas de arquivos apareçam como unidades separadas: internamente, o executive representa os sistemas de arquivos como objetos em uma árvore de objetos, e cada objeto é responsável por analisar o restante do caminho
- Esses objetos de sistema de arquivos são remapeados como unidades DOS para ficarem acessíveis ao espaço do usuário
- As unidades DOS também são objetos em uma subárvore separada que redireciona o I/O para o sistema de arquivos ao qual fazem referência
- O NT acabou sendo lançado com o NTFS
- Embora o NTFS goste de ser criticado por supostamente ter desempenho ruim (uma alegação incorreta), ele era um sistema de arquivos realmente avançado para a época
- O subsistema de I/O do NT, combinado com o NTFS, oferecia endereçamento de 64 bits, journaling e até nomes de arquivo em Unicode
- O Linux só foi receber suporte a arquivos de 64 bits no fim da década de 1990, e só ganhou journaling com o lançamento do ext3 em 2001
- O Soft updates, um mecanismo alternativo de tolerância a falhas, só apareceu no FreeBSD em 1998
- O Unix representa nomes de arquivos como arrays de bytes terminados em null, e não em Unicode
- Outros recursos incluídos no lançamento do NT eram striping e espelhamento de disco (hoje conhecidos como RAID), além de hot-plug de dispositivos
- Esses recursos não eram novidade, já que o SunOS incluía suporte a RAID desde o começo dos anos 1990, mas o interessante é que todos eles foram considerados parte do design original
- Em um nível mais alto, o que torna o subsistema de I/O do NT muito mais avançado que o do Unix é o fato de sua interface ser inerentemente assíncrona, e ter sido assim desde o início
- Para colocar isso em perspectiva, o FreeBSD só foi ter suporte a
aio(7) no FreeBSD 3.0 em 1998, e o Linux só foi ver isso no Linux 2.5 em 2002
- Apesar de o suporte a I/O assíncrono existir em sistemas Unix há mais de 20 anos, ele ainda não é amplamente usado: quase ninguém conhece essas APIs, a maioria dos aplicativos não as usa e o desempenho é ruim
- O
io_uring do Linux é uma adição relativamente recente para melhorar o I/O assíncrono, mas tem sido uma fonte importante de vulnerabilidades de segurança e não é amplamente utilizado
Redes
- Hoje a internet está em toda parte, mas não era assim quando o NT foi projetado
- Olhando para o ecossistema da Microsoft, o DOS 3.1 (1987) incluía a base para compartilhamento de arquivos no sistema de arquivos FAT, mas o próprio "SO" não oferecia recursos de rede: um produto separado chamado Microsoft Networks (MS-NET) fazia isso
- O Windows 3.0 (1990) incluía suporte ao NetBIOS, que permitia compartilhamento básico de impressoras e arquivos em rede local, mas não havia sinal de suporte a TCP/IP
- Em contraste, o Unix era a própria internet: todos os protocolos básicos da internet foram escritos em Unix e com Unix
- Durante o design do NT, era importante considerar um bom suporte de rede, e de fato o NT foi lançado com recursos de rede
- Como resultado, o NT suportava tanto os protocolos de internet quanto os protocolos LAN tradicionais usados no ambiente legado da Microsoft, o que colocou o NT à frente do Unix em ambientes corporativos
- Um exemplo disso são os domínios de rede do NT
- No Unix, administradores de rede normalmente sincronizavam manualmente as contas de usuário entre máquinas
- Sistemas como o SunOS podiam usar o protocolo de diretório X.500 (1988) e o Kerberos (anos 1980) para autenticação de usuários, mas essas tecnologias não eram exatamente simples
- Em vez disso, o NT oferecia domínios desde o início, integrando diretório e autenticação, o que aparentemente fez com que ele "vencesse" nas redes corporativas, por ser muito mais fácil de configurar e já vir embutido no sistema
- O objetivo de contas de usuário sincronizadas é compartilhar recursos entre máquinas, principalmente arquivos, e nesse contexto a forma de representar permissões é importante
- Por muito tempo, o Unix ofereceu apenas um conjunto simples de permissões de leitura/gravação/execução para cada arquivo
- Já o NT vinha desde o início com ACLs avançadas, algo que ainda é um ponto sensível no Unix
- Linux e BSD agora também têm ACLs, mas as interfaces variam entre sistemas e elas parecem um acréscimo estranho ao design do sistema
- No NT, as ACLs operam no nível de objeto, então se aplicam de forma consistente a todas as funcionalidades do kernel
- Ao falar de compartilhamento de arquivos, é preciso falar sobre sistemas de arquivos de rede
- No Unix, o sistema de arquivos de rede de fato era o NFS; no NT, era o SMB
- O SMB foi herdado do MS-NET e do LAN Manager, e é implementado no kernel por meio de um componente chamado redirector
- Em essência, o redirector é apenas mais um sistema de arquivos "simples" que intercepta operações de arquivo e as transmite pela rede, assim como o NFS faz no Unix
protobuf e gRPC são tão usados hoje que podem parecer ideias novas, mas se baseiam em ideias antigas
- No Unix, o Sun RPC era usado desde o início dos anos 1980, principalmente para dar suporte ao NFS
- Da mesma forma, o NT vinha com suporte embutido a RPC, por meio de sua própria DSL (conhecida como MIDL para especificar definições de interface e gerar código para procedimentos remotos) e de seus próprios recursos para implementar clientes e servidores RPC
- Sistemas Unix não davam muita ênfase a suporte arbitrário a drivers: em geral, eles vinham atrelados a máquinas e fornecedores específicos
- Já o NT queria ser um SO para "todas" as máquinas e era vendido por uma empresa de software, então o suporte a drivers escritos por terceiros era importante
- Como resultado, o NT trouxe a Network Driver Interface Specification (NDIS), uma abstração para facilitar o suporte a drivers de placas de rede
- Até hoje, drivers fornecidos por fabricantes não são algo tão comum no Linux, o que levou ao surgimento de soluções curiosas como o
ndiswrapper, muito popular no começo dos anos 2000 por permitir reaproveitar drivers do Windows para placas Wi‑Fi no Linux
- Por fim, outra diferença entre NT e Unix está na implementação de pipes nomeados
- No Unix, pipes nomeados são um componente local: fornecem um mecanismo para que dois processos na mesma máquina se comuniquem entre si por meio de um nome de arquivo persistente no disco
- O NT tem essa mesma funcionalidade, mas os pipes nomeados podem funcionar pela rede
- Ao colocar pipes nomeados em um sistema de arquivos compartilhado, dois aplicativos em computadores diferentes podem se comunicar sem precisar se preocupar com detalhes de rede
Espaço do usuário
- Configuração:
- O NT centralizou as configurações do sistema e dos aplicativos em um banco de dados chamado Registro, afastando-se do antigo CONFIG.SYS, AUTOEXEC.BAT e dos inúmeros arquivos INI usados no Windows legado
- Isso deixou algumas pessoas muito irritadas, mas no fim uma interface de configuração unificada é benéfica para todos: fica mais fácil escrever aplicativos porque há uma única base para oferecer suporte, e os usuários conseguem ajustar o sistema com mais facilidade porque existe apenas um lugar para examinar
- Em contraste, o Unix ainda sofre com dezenas de DSLs e locais de arquivos inconsistentes
- Cada programa que oferece suporte a arquivos de configuração tem sua própria sintaxe, e é difícil saber onde o programa lê esses arquivos, além de isso nem sempre ser bem documentado
- O ecossistema Linux tentou promover uma abordagem semelhante à do NT com XDG e dconf (antes, GConf), mas os componentes de desktop usam essas tecnologias de forma exclusiva enquanto os componentes básicos do sistema não as adotam, deixando uma bagunça inconsistente
- Internacionalização:
- A Microsoft, como uma grande empresa que já estava lançando o Windows 3.x no mundo todo, entendia a importância da localização e fez com que o NT oferecesse esse suporte desde o início
- Compare isso com o Unix, cujo suporte a UTF só começou a aparecer no fim dos anos 1990 e que oferecia suporte a outros idiomas por meio da adição opcional do gettext
- Linguagem C:
- Uma coisa com que sistemas Unix como FreeBSD e NetBSD sonham há algum tempo é criar seus próprios dialetos de C para implementar o kernel de uma forma mais segura
- Isso não levou a lugar nenhum, exceto no Linux, que depende de extensões exclusivas do GCC
- A Microsoft, por outro lado, tinha o privilégio de possuir seu próprio compilador C, então fez isso no NT escrito em Microsoft C
- Por exemplo, o NT depende de Structured Exception Handling (SEH), um recurso que adiciona cláusulas try/except para lidar com exceções de software e hardware
- Não diria que isso é uma grande vantagem, mas de fato é uma diferença
Conclusão
- O NT era uma tecnologia revolucionária quando foi lançado
- Como descrito acima, muitos recursos que hoje consideramos naturais no design de sistemas já existiam no NT desde o começo, enquanto quase todos os outros sistemas Unix tiveram de adquirir esses recursos lentamente ao longo do tempo
- Como resultado, esses recursos nem sempre se integram suavemente à filosofia Unix
- No entanto, não está claro se hoje o NT é realmente "mais avançado" do que Linux ou FreeBSD
- O NT tinha princípios de design mais sólidos desde o início e mais recursos do que os sistemas operacionais contemporâneos, mas hoje em dia a diferença é nebulosa
- Ou seja, o NT evoluiu, mas não a ponto de ser significativamente mais avançado do que o Unix moderno
- Apesar de o NT ter todos esses princípios sólidos de design, é frustrante que o design não consiga brilhar por causa do inchaço da UI
- Mesmo em máquinas extremamente poderosas, a lentidão do OS pode ser dolorosa de testemunhar e pode até levar ao fim deste OS
Resumo do GN⁺
- Este texto compara as diferenças de design entre NT e Unix para explicar quão avançado era o design inicial do NT
- O NT foi projetado desde o início com portabilidade, suporte a multiprocessamento e compatibilidade como objetivos, e essa é uma diferença importante em relação ao Unix
- O kernel orientado a objetos do NT, a arquitetura de memória unificada e a interface de I/O assíncrona oferecem recursos mais avançados do que o Unix
- No entanto, hoje a diferença entre sistemas NT e Unix não é grande, e o inchaço da UI do NT causa degradação de desempenho
1 comentários
Opiniões do Hacker News
O kernel NT é excelente, mas tem um projeto antigo
A maior diferença entre NT e Unix está na abordagem de drivers
No WinNT moderno, o Direct3D é uma parte essencial do kernel
O kernel NT executa threads, não processos
O WindowsNT, no início, era um sistema muito melhor projetado do que o Linux
O NT, como terceiro sistema, evitou a síndrome do segundo sistema
Há diferenças entre Windows e Linux do ponto de vista do desenvolvedor
wchar_tno Win32 é um problemaO kernel NT tem elegância, mas não é open source
Houve convergência com algo como o FUSE do Linux