Nostalgia 2025 – Instalando o Windows NT 4.0 no Proxmox!

Pessoal,

Hoje vamos relembrar o Window NT 4.0. No final vamos instalar numa VM e no Proxmox, como fizemos nos posts desta versão da série Nostalgia 2025 (aqui). Pode se preparar, o post é longo e muito detalhado, tanto sobre o Windows NT 4.0 quanto sobre a instalação no Virtual Box e no Proxmox!

Para começar, vamos ver como era a caixa do Windows NT 4.0!

Esta primeira caixa é a da caixa original, para instalação “limpa”. É a versão “para PCs sem Windows NT Workstation”!

Já esta caixa abaixo é da verão de upgrade. É a versão para quem já tinha o Windows NT Workstation (3.51 ou anterior) e queria atualizar para o 4.0.

Outra opção comum eram versões já com updates instalados. Abaixo, é a versão com o Update 4 instalado. Repare que é avisado que estão incluídas as correções para o Euro, a moeda da União Europeia, e para o bug do milênio (Year 2000 Update). O IE 4.0 também já vinha instalado neste caso.

Repare que a parte de trás da caixa é diferente também, começando pelo aviso que o IE 4.0 já vem instalado (só o SP4, que incluía o IE 4.0, tinha mais de 400 MB e era considerado gigantesco para a época!)

Já as duas próximas fotos são de outra possibilidade de obtenção do Windows NT 4.0: versão OEM (ou Original Equipment Manufacturer), a versão que era distribuída pelos fabricantes para computadores novos e que era mais barata que as versões Retail (versões disponíveis para comprar em lojas, como as caixas das fotos acima!)

E abaixo estão as fotos do conteúdo das caixas das versões retail.

E por último, mas não menos importante, a versão “Server”, destinada a pequenas empresas.

O Windows NT 4.0 foi o sucessor do Windows NT 3.51 (que instalamos aqui).

Lançada em 31/07/1996, um ano após o Windows 95, esta versão é um dos marcos mais importantes (e talvez muito subestimado) na história do Windows, já que foi a primeira vez que a linha profissional e robusta do Windows NT ganhou a interface moderna e intuitiva do Windows 95, criando uma ligação entre dois mundos que pareciam irreconciliáveis: estabilidade empresarial e modo moderno de utilização.

Se o Windows 95 revolucionou a computação doméstica com sua interface revolucionária, o Windows NT 4.0 trouxe essa mesma revolução para o mundo corporativo, mantendo — e até melhorando — a estabilidade, segurança e escalabilidade que empresas, desenvolvedores e usuários profissionais exigiam.

Windows 9.x x Windows NT: Arquiteturas Diferentes

Para entender a importância do Windows NT 4.0, precisamos primeiro compreender o cenário fragmentado dos sistemas operacionais Microsoft nos anos 1990 (já contamos essa história várias e várias vezes, mas é importante a contextualização). A empresa mantinha duas linhas completamente distintas de sistemas operacionais, cada uma com filosofias arquiteturais radicalmente diferentes.

A linha Windows 9x (Windows 95 e posteriormente 98 e ME) era voltada exclusivamente para o consumidor doméstico. Sua arquitetura era baseada no MS-DOS 7.0, operando como uma camada gráfica híbrida de 16 e 32 bits sobre o sistema operacional de 16 bits que dominava os PCs desde 1981 (ainda que o Windows 95 tenha mudado bastante isso…).

Essa camada “híbrida 16/32 bits” permitia que os processadores da família Intel 80386 e posteriores (486, Pentium) fossem capazes de operar em dois modos distintos:

• Modo Real (16 bits): O modo original do 8086/8088, onde o processador trabalha com segmentos de memória de 64 KB e endereçamento limitado a 1 MB. É o modo em que o MS-DOS opera nativamente.
• Modo Protegido (32 bits): Introduzido com o 386, permite endereçamento linear de até 4 GB de memória, proteção entre processos, multitarefa preemptiva verdadeira e uma arquitetura muito mais robusta.

O Windows 95 tentava ter o melhor dos dois mundos, mas acabava sofrendo com as limitações de ambos. Ao inicializar, o sistema bootava em modo real DOS, carregava o IO.SYS (que continha o kernel básico do DOS embarcado), processava CONFIG.SYS e AUTOEXEC.BAT, e então carregava o VMM32.VXD (Virtual Machine Manager), que alternava o processador para modo protegido e iniciava o ambiente gráfico Windows.

O problema da arquitetura híbrida era que o Windows 95 rodava três tipos diferentes de código simultaneamente:

1. Código 32 bits protegido: Os componentes modernos do Windows 95 (kernel32.dll, user32.dll, gdi32.dll)
2. Código 16 bits protegido: Componentes legados do Windows 3.x (kernel.exe, user.exe, gdi.exe)
3. Código DOS em modo virtual 8086: Aplicações DOS rodando em máquinas virtuais

Essa mistura criava problemas sérios de estabilidade.

O Windows 95 usava multitarefa cooperativa para aplicações de 16 bits, onde cada aplicação deve voluntariamente “ceder” o controle do processador de volta ao sistema operacional chamando funções específicas como Yield() ou processando mensagens da fila de mensagens do Windows. Quando uma aplicação 16 bits entrava em um loop infinito, travava enquanto aguardava uma operação de disco lenta ou simplesmente tinha um bug que a impedia de processar mensagens, essa aplicação nunca mais iria ceder o controle voluntariamente de volta ao sistema. Assim, todo o subsistema de 16 bits travava. Pior ainda: como os componentes GDI (Graphics Device Interface) e USER (gerenciador de janelas) eram compartilhados entre aplicações 16 e 32 bits, um travamento no mundo de 16 bits frequentemente contaminava todo o sistema.

Mesmo aplicações 32 bits, que usavam multitarefa preemptiva (onde o sistema operacional força a alternância entre processos), não estavam totalmente isoladas. Um programa que corrompesse a memória ou fizesse chamadas inadequadas ao kernel podia facilmente derrubar o sistema inteiro com a temida tela azul da morte (BSOD ou Blue Screen of Death).

Mas por que diabos o Windows 95 era assim?

A resposta é compatibilidade. A Microsoft precisava que o Windows 95 rodasse jogos DOS que acessavam hardware diretamente, drivers VxD (Virtual Device Driver) de 16 bits de milhares de dispositivos, aplicações Windows 3.1 que milhões de usuários utilizavam, que trabalhasse com hardware antigo sem Plug and Play e tudo isso em sistemas com apenas 4-8 MB de RAM. Ufa!

Essa compatibilidade universal era o grande trunfo do Windows 95, mas vinha com o preço da instabilidade inerente à sua arquitetura híbrida. Ou seja, toda a família 9.x sofria deste mesmo mal 🙁

Do outro lado estava o Windows NT (New Technology). Desenvolvido desde 1989 sob a liderança de Dave Cutler, o engenheiro que havia criado o sistema operacional VMS (aqui e aqui) para a Digital Equipment Corporation (DEC), o NT foi projetado do zero para ser um sistema operacional moderno, robusto e escalável.

O modo de funcionamento do NT era completamente diferente do modo da família 9.x. 

• Modo protegido puro: Sem qualquer dependência do MS-DOS. O NT bootava diretamente através do NTLDR (NT Loader), que carregava o kernel NTOSKRNL.EXE em modo protegido 32 bits.
• Arquitetura em micronúcleo (modificada): O kernel do NT era minimalista, contendo apenas funcionalidades essenciais como escalonamento de threads, sincronização e gerenciamento básico de memória. Serviços mais complexos rodavam em modo usuário protegido.

• Memória virtual completa: Cada processo recebia seu próprio espaço de endereçamento virtual de 4 GB (2 GB para o processo, 2 GB para o sistema), completamente isolado de outros processos através de tabelas de páginas protegidas pela MMU (Memory Management Unit) do processador.
• Modelo de segurança baseado em objetos: Tudo no NT era um objeto seguro — arquivos, processos, threads, chaves de registro, até eventos de sincronização. Cada objeto tinha uma ACL (Access Control List) definindo exatamente quem podia fazer o quê com ele.
• Multitarefa preemptiva verdadeira: Tanto para aplicações 32 bits quanto 16 bits. O escalonador de threads do NT usava um sistema de prioridades de 32 níveis e garantia que nenhum processo pudesse monopolizar a CPU.

Tudo isso tornava o isolamento dos processos do Windows NT real e efetivo! Se uma aplicação travasse ou corrompesse sua própria memória, apenas aquele processo morria. O sistema operacional capturava o erro, terminava o processo problemático e continuava operando normalmente. Crashes de sistema eram extremamente raros e geralmente indicavam problemas sérios de hardware ou drivers mal escritos em modo kernel.

O Windows NT 3.x, lançados entre julho de 1993 e maio de 1995, eram sistemas operacionais extraordinariamente estáveis e confiáveis. Servidores NT 3.51 podiam rodar por meses sem necessidade de reboot. Hoje isso pode parecer normal com servidores Linux e processadores modernos 64 bits, mas lá atrás, quando isso aqui tudo era mato, era surreal!

Muitos usuários brincavam que o único defeito do Windows NT 3.x era a interface gráfica. Essa versão utilizava a mesma interface do Windows 3.1 (Program Manager para gerenciar aplicações, File Manager para navegar arquivos, e applets do Painel de Controle individuais). Era uma interface que já era datada em 1993, ficou completamene obsoleta após o lançamento do Windows 95.

Quando o Windows 95 chegou ao mercado com sua interface moderna e revolucionária (o menu Iniciar que organizava tudo hierarquicamente, a barra de tarefas mostrando janelas abertas, o Windows Explorer com visualização em árvore e detalhes, dentre outras centenas de inovações), a diferença ficou gritante e insustentável. Usuários corporativos, administradores de sistema e desenvolvedores que usavam NT por sua estabilidade olhavam com inveja para a interface moderna e intuitiva do Windows 95. 

Ficou claro para a Microsoft que o NT precisava evoluir. Usuários profissionais também precisavam de uma interface moderna e produtiva, mas sem abrir mão da robustez e segurança que oferecida pelo Windows NT.

Como o Windows NT 4.0 Foi Desenvolvido

Dizem que o desenvolvimento do Windows NT 4.0 começou no dia seguinte ao lançamento do Windows 95 já que a Microsoft tinha um desafio técnico enorme: pegar a interface completamente nova do Windows 95 (que tinha sido desenvolvida especificamente para a arquitetura híbrida 16/32 bits do Windows 9x) e integrá-la ao kernel 32 bits e arquitetura muito diferente do Windows NT, sem comprometer a estabilidade do sistema.

A equipe de desenvolvimento, liderada por Jim Allchin (que se tornaria uma figura central na Microsoft pelos próximos 15 anos), tomou uma decisão técnica ousada e controversa que mudaria fundamentalmente a arquitetura do Windows NT.

A Grande Mudança Arquitetural: GDI no Kernel

No Windows NT 3.x, todo o subsistema gráfico operava em modo usuário. Isso significava que:

• O GDI (Graphics Device Interface) — responsável por desenhar janelas, botões, texto, gráficos — rodava como um processo de usuário protegido
• O USER (gerenciador de janelas) — que controlava criação de janelas, mensagens, input de teclado e mouse — também rodava em modo usuário
• Drivers de vídeo também rodavam em modo usuário através do subsistema Win32

Rodar o subsistema gráfico em modo usuário significava isolamento máximo, já que se um driver de vídeo tinha um bug e travava, apenas esse subsistema gráfico morria. O kernel continuava rodando, outros processos continuavam operando, e o sistema podia se recuperar reiniciando apenas o subsistema Win32.

Só que isso cobrava caro da performance. Cada operação gráfica exigia múltiplas transições de contexto entre modo usuário e modo kernel. A aplicação chamava uma função GDI, ocorria uma transição de modo usuário para modo kernel (através de uma chamada de sistema), o kernel validava a chamada e repassava para o subsistema Win32 em modo usuário, ocorria transição de volta para modo usuário, o subsistema Win32 processava a chamada, o Win32 chamava o driver de vídeo, e mais transições entre modos aconteciam para acessar hardware. Cada transição de contexto entre modos levava centenas de ciclos de CPU. Em um Pentium 100 MHz (processador comum em 1995-1996), essas transições representavam microsegundos preciosos. Para operações gráficas intensivas, como redesenhar janelas, scrolling, arrastar janelas pela tela, etc, esses microsegundos acumulavam-se e a lentidão tornava-se perceptível.

O Windows 95, com seu GDI rodando diretamente em ring 0 (modo kernel), era significativamente mais rápido em operações gráficas, mesmo rodando no mesmo hardware. Benchmarks da época (aqui e aqui) mostravam que o Windows 95 era mais rápido que o NT 3.51 em algumas tarefas, ainda que menos estável (mas que viria a perder para o Windows NT 4 quando houvesse RAM suficiente). Visivelmente, o Windows 95 parecia mais rápido que o NT 3.x.

A equipe do NT 4.0 tomou uma decisão difícil: mover a GDI e o USER do modo usuário para o modo kernel. Assim, o WIN32K.SYS, um driver de modo kernel que continha todo o subsistema gráfico, foi introduzido. Agora a GDI rodava em ring 0 (modo kernel), o USER rodava em ring 0, os drivers de vídeo rodavam em ring 0 e as chamadas gráficas iam direto do espaço de usuário para o kernel, sem múltiplas transições.

O ganho de performance foi dramático. Benchmarks mostraram melhorias de significativas nas operações gráficas comparado ao NT 3.51. O NT 4.0 finalmente competia e frequentemente superava o Windows 95 em responsividade gráfica, principalmente se RAM não fosse limitante.

A velocidade entra por uma porta e a estabilidade sai por outra porta 🙁

Agora, um bug em um driver de vídeo podia travar o sistema inteiro. Um ponteiro inválido, um overflow de buffer, um acesso de memória mal alinhado no código do driver de vídeo agora executava em ring 0, com acesso irrestrito a toda memória do sistema. Um erro assim não derrubava apenas o subsistema gráfico — derrubava o kernel inteiro, resultando em tela azul da morte.

Puristas da arquitetura de sistemas operacionais criticaram duramente a decisão, argumentando que a Microsoft estava sacrificando a elegância e segurança arquitetural do NT em nome de performance gráfica. Dave Cutler, o arquiteto original do NT, era conhecido por ser extremamente protetor da integridade do design do sistema. Mas Jim Allchin e a liderança da Microsoft argumentavam que era uma concessão necessária. Usuários exigiam performance gráfica comparável ao Windows 95. Desenvolvedores de software corporativo precisavam de responsividade nas interfaces gráficas. E a realidade era que drivers de vídeo já eram a fonte número um de instabilidade em sistemas operacionais, ou seja, melhor reconhecer essa realidade e trabalhar com ela através de certificação rigorosa de drivers.

Assim, a Microsoft implementou controles rigorosos como:

1. Programa de certificação WHQL (Windows Hardware Quality Labs): Drivers precisavam passar por extensos testes automatizados e manuais antes de receberem a certificação Microsoft
2. Driver Verifier: Uma ferramenta que estressava drivers em desenvolvimento, simulando condições de baixa memória, interrupções frequentes, etc.
3. Crash dumps detalhados: Quando ocorria uma tela azul, o NT 4.0 gerava dumps de memória completos que permitiam aos desenvolvedores identificar exatamente qual instrução causou o crash

As Fases do Desenvolvimento

A fase Alpha (final de 1995 até início de 1996) viu as primeiras builds internas do que seria o NT 4.0 começarem a circular dentro da Microsoft. Essas builds iniciais eram híbridas curiosas: o kernel do NT 3.51 com componentes de interface do Windows 95 sendo portados gradualmente. Muitas funcionalidades não funcionavam, crashes eram frequentes, e a integração entre os mundos NT e Win95 era rudimentar. Tudo normal para fase Alfa!

O código do Windows 95 havia sido escrito assumindo certas “liberdades” arquiteturais do ambiente 9x: acesso direto a estruturas de dados do kernel, ponteiros compartilhados entre processos, comunicação direta entre DLLs sem validação adequada. Tudo isso precisava ser refatorado para funcionar no ambiente muito mais restrito e controlado do NT.

A Beta 1 (março de 1996) foi a primeira beta pública lançada para um grupo selecionado de testadores e parceiros OEM. Esta build finalmente mostrava a interface completa do Windows 95 rodando sobre o kernel NT. O menu Iniciar funcionava, a barra de tarefas estava lá, o Windows Explorer substituía o antigo File Manager. Mas era ainda instável. Aplicações travavam frequentemente, drivers de vídeo causavam telas azuis constantes, e a performance estava longe do ideal. A Microsoft distribuiu esta beta sabendo que era mais uma demonstração de conceito do que um produto usável.

A Beta 2 (maio de 1996) trouxe melhorias substanciais de estabilidade. O trabalho de integração do WIN32K.SYS estava mais maduro, os drivers certificados começavam a aparecer, e a experiência geral era muito mais polida. Empresas começaram a testar seriamente o NT 4.0 Beta 2 em ambientes de produção controlados. Esta build também introduziu melhorias importantes no suporte a hardware: melhor detecção Plug and Play (ainda limitada comparada ao Windows 95, mas significativamente melhor que o NT 3.51), suporte inicial a USB (extremamente básico), e drivers atualizados para controladoras SCSI e placas de rede.

Entre junho e agosto de 1996, a Microsoft lançou duas release candidates para testadores finais. A equipe de QA (Quality Assurance) rodou milhões de horas de testes automatizados, stress testing com cargas sintéticas de trabalho, testes de compatibilidade com milhares de aplicações...

No final de julho de 1996, o Windows NT 4.0 Build 1381 foi liberado para produção (versão RTM) e em apenas três semanas depois, em 24 de agosto de 1996, exatamente um ano após o lançamento do Windows 95, o Windows NT 4.0 estava nas prateleiras das lojas de todo o mundo!

Lançamento e Versões

A Microsoft organizou o lançamento do Windows NT 4.0 de maneira muito diferente do espetáculo hollywoodiano que foi o Windows 95. Não houve iluminação do Empire State Building e nem houve festivais de lançamento com bandas de rock. O NT 4.0 foi lançado com conferências técnicas, seminários para administradores de sistema, e apresentações para CIOs (Chief Information Officers) de grandes corporações. O público-alvo era completamente diferente: o Windows 95 precisava conquistar o consumidor médio em lojas de varejo, já o NT 4.0 precisava convencer diretores de TI, arquitetos de sistemas e administradores de infraestrutura de que era a plataforma certa para rodar os negócios críticos de suas empresas.

Foram lançadas quatro versões principais inicialmente, cada uma cuidadosamente segmentada para diferentes necessidades empresariais:

Windows NT 4.0 Workstation: versão destinada a estações de trabalho profissionais: máquinas de desenvolvedores escrevendo código complexo, designers gráficos trabalhando com arquivos pesados, engenheiros rodando softwares CAD, analistas financeiros executando modelos complexos em planilhas.

As especificações e limitações técnicas incluíam máximo de 2 processadores físicos (mas podia usar múltiplos cores/threads lógicos por processador), máximo de 4 GB de RAM (na prática, aproximadamente 3.5 GB utilizáveis devido ao mapeamento de hardware), máximo de 10 conexões de rede simultâneas (uma limitação artificial de licenciamento, não técnica, para diferenciar de Server), e otimização para aplicações em foreground, onde o escalonador priorizava o processo em primeiro plano para máxima responsividade interativa.

O preço da versão Workstation completa era de aproximadamente USD$319 no lançamento, com versões de upgrade para quem já tinha NT 3.51 custando $149.

Windows NT 4.0 Server: esta versão era o foco da oferta empresarial e foi projetada para rodar servidores de arquivos e impressão, servidores de aplicação, controladores de domínio (usando o Windows NT Domain model para gerenciamento centralizado de usuários), e servidores de banco de dados.

As diferenças técnicas em relação ao Workstation incluíam máximo de 4 processadores físicos na versão base, máximo de 4 GB de RAM (igual ao Workstation, mas com tuning diferente), conexões de rede ilimitadas, e otimização para aplicações em background, onde o escalonador tratava todos os processos de forma mais equitativa, sem dar prioridade especial ao foreground.

A versão incluía serviços adicionais: Internet Information Server 2.0 (servidor web), DNS Server, DHCP Server, WINS (Windows Internet Name Service), e suporte a Remote Access Service (RAS) para usuários discarem e se conectarem à rede corporativa.

O preço da versão Server base era de $809 para 5 conexões de cliente, com licenças adicionais de cliente (CALs – Client Access Licenses) vendidas separadamente.

Windows NT 4.0 Server, Enterprise Edition: lançada em 1997 (não no lançamento inicial), a Enterprise Edition era destinada a aplicações de missão crítica que exigiam máxima escalabilidade e disponibilidade.

As capacidades expandidas incluíam máximo de 8 processadores físicos (em sistemas SMP – Symmetric Multiprocessing), máximo de 3 GB de RAM por aplicação através de um switch especial /3GB no BOOT.INI que mudava o split de memória virtual de 2GB/2GB para 3GB/1GB, e suporte total a 4 GB de RAM física.

O Microsoft Cluster Server (MSCS) oferecia suporte a clustering ativo-passivo para alta disponibilidade. Dois servidores podiam ser configurados em cluster, onde um assumia automaticamente se o outro falhasse. A versão também suportava memória física além de 4 GB através de PAE (Physical Address Extension) em processadores Pentium Pro e posteriores que suportavam 36 bits de endereçamento físico. O preço era significativamente mais alto: $3.999 para 25 CALs incluídas.

Windows NT 4.0 Terminal Server Edition: também lançada em 1997, a Terminal Server Edition era baseada no código desenvolvido pela Citrix Systems em parceria com a Microsoft. Ela permitia que múltiplos usuários se conectassem remotamente ao servidor através de thin clients ou PCs com o cliente Terminal Server, cada um recebendo sua própria sessão Windows isolada.

O Terminal Server implementava sessões virtualizadas no nível do kernel. Cada usuário conectado recebia seu próprio conjunto de processos isolados, seu próprio registro virtual (a árvore HKEY_CURRENT_USER era específica da sessão), seu próprio conjunto de variáveis de ambiente, e isolamento de objetos de interface gráfica.

Internamente, o kernel mantinha estruturas de dados separadas para cada sessão, identificadas por um Session ID. O código de desenho gráfico foi modificado para redirecionar operações GDI através do protocolo RDP (Remote Desktop Protocol) baseado no T.128 da ITU-T, que comprimia e transmitia as mudanças de tela pela rede.

Os casos de uso incluíam call centers com centenas de atendentes usando thin clients, ambientes educacionais com laboratórios de computadores baratos acessando aplicações centralizadas, acesso remoto corporativo para trabalhadores em campo ou teletrabalho, e centralização de aplicações para facilitar manutenção e atualizações.

O modelo de licenciamento era complexo, baseado em número de usuários simultâneos.

Windows NT 4.0 Embedded: versão menos conhecida mas amplamente utilizada era o NT 4.0 Embedded, destinada a dispositivos de propósito específico: caixas eletrônicos (ATMs), onde até meados dos anos 2010 muitos ATMs ao redor do mundo ainda rodavam NT 4.0 Embedded devido à sua estabilidade comprovada; terminais de ponto de venda (POS) em sistemas de checkout de supermercados e lojas de varejo; quiosques de informação em aeroportos, shoppings e museus; e sistemas industriais como controladores para manufatura e automação predial.

O Embedded era uma versão minimalista com componentes desnecessários removidos, footprint de instalação reduzido, e ferramentas especiais para criar imagens personalizadas bootáveis diretamente em ROM ou Flash.

Multi-Arquitetura: A Portabilidade como Filosofia

Uma das características mais fascinantes e tecnicamente impressionantes do Windows NT 4.0, e frequentemente esquecida atualmente, era seu suporte a múltiplas arquiteturas de processador completamente diferentes! Enquanto o Windows 95 estava “limitado” à arquitetura x86 da Intel, o NT 4.0 rodava nativamente em quatro arquiteturas de processador radicalmente distintas.

O segredo da portabilidade do NT estava na HAL, a Hardware Abstraction Layer, uma biblioteca de baixo nível que isolava o kernel do Windows NT das especificidades de cada plataforma de hardware.

O código do kernel do NT (NTOSKRNL.EXE) era escrito em C de forma portável, fazendo chamadas a funções abstratas da HAL quando precisava interagir com hardware específico da plataforma. A HAL implementaria essas funções de forma específica para cada arquitetura: na HAL x86 usava a instrução IN do x86, na HAL Alpha mapeava o endereço para memory-mapped I/O específico do Alpha, na HAL MIPS usava as instruções de I/O específicas do MIPS, e na HAL PowerPC usava as convenções de I/O do PowerPC.

O NT incluía múltiplas HALs diferentes até mesmo para a mesma arquitetura. A instalação detectava o tipo específico de motherboard (ISA, EISA, MCA, PCI single-processor, PCI multi-processor, etc.) e instalava a HAL apropriada.

Intel x86: A Arquitetura Dominante

Naturalmente, a arquitetura x86 (Intel 80386, 80486, Pentium, Pentium Pro, Pentium II) era de longe a mais comum. O NT 4.0 suportava desde o humilde 486DX até os mais modernos Pentium II de 1997.

Os requisitos mínimos para x86 incluíam processador 486DX/33 MHz ou superior e FPU (Floating Point Unit) obrigatória, o que significava que processadores 486SX sem FPU não eram suportados oficialmente.

Os processadores 386 deixaram de ser suportados a partir da Build 1130. O WINNT.EXE verificava a CPU e mostrava uma mensagem de erro: Windows NT requires an 80486 or later processor. Setup cannot continue. (Veja aqui).

Processadores típicos da era NT 4.0:

• Intel Pentium (60-200 MHz, 1993-1997): O modelo padrão. Arquitetura superscalar com dois pipelines, cache L1 de 16 KB, desempenho sólido para a maioria das cargas de trabalho.

• Intel Pentium Pro (150-200 MHz, 1995-1998): O processador favorito para servidores NT 4.0. Arquitetura P6 revolucionária com execução fora de ordem, renomeação de registradores, execução especulativa e cache L2 integrado no mesmo package (256 KB ou 512 KB rodando na velocidade total do processador). O Pentium Pro era significativamente mais rápido que o Pentium em código 32 bits, mas ironicamente mais lento em código 16 bits devido a otimizações específicas.

• Intel Pentium MMX (166-233 MHz, 1997-1998): Adicionava 57 instruções MMX para processamento multimídia SIMD, cache L1 expandido para 32 KB total. Útil para certas cargas de trabalho, mas o NT 4.0 não explorava MMX tão agressivamente quanto o Windows 98.

• Intel Pentium II (233-450 MHz, 1997-1999): A evolução do Pentium Pro com MMX integrado, cache L2 em cartridge SECC (Single Edge Contact Cartridge) rodando à metade da velocidade do core. Excelente desempenho geral.

• AMD K5 e K6 (75-266 MHz): Processadores compatíveis x86 da AMD que ofereciam boa relação custo-benefício. O K6 era particularmente popular em servidores de orçamento limitado.

• Cyrix 6×86 (100-200 MHz): Processador alternativo com desempenho por clock superior ao Pentium em instruções inteiras, mas FPU fraca que prejudicava certas cargas de trabalho.

Arquiteturas Alternativas: Alpha, MPIS e PowerPC

• DEC Alpha AXP: O Gigante RISC de 64 Bits

A arquitetura Alpha AXP da Digital Equipment Corporation era, em muitos aspectos, a mais impressionante tecnicamente das plataformas suportadas pelo NT 4.0.

A família Alpha foi desenvolvida pela DEC no final dos anos 1980 como sucessora da arquitetura VAX que havia dominado o mercado de minicomputadores por décadas. O objetivo era criar um processador RISC puro, de altíssimo desempenho, focado em workstations e servidores científicos e técnicos.

O primeiro processador Alpha, o 21064, foi lançado em 1992 rodando a 150-200 MHz quando processadores Intel da época mal chegavam a 66 MHz. O Alpha era um processador RISC genuíno de 64 bits desde o início.

Os processadores Alpha comuns na era NT 4.0 incluíam o 21064A (150-300 MHz, 1993-1994) com processo de fabricação de 0.75 micron depois 0.5 micron, cache L1 de 8 KB instruções mais 8 KB dados, pipeline de 7 estágios, duas unidades inteiras, uma FPU (Floating Point Unit), barramento de 128 bits para memória, e desempenho espetacular em operações de ponto flutuante.

O 21164 e 21164A (266-500 MHz, 1995-1997) usavam processo de 0.5 micron depois 0.35 micron, cache L1 de 8 KB mais 8 KB (21164) ou 16 KB mais 16 KB (21164A), suporte a cache L2 externo até 96 KB on-chip e depois MB externos, pipeline mais profundo, quatro instruções por ciclo (2 inteiras, 2 FP), Motion Video Instructions (extensões especiais para multimídia), e branch prediction melhorado. (Entenda mais sobre cache aqui, aqui e aqui).

As características arquiteturais únicas do Alpha incluíam pure 64-bit RISC, onde todas as instruções eram de 32 bits de tamanho fixo, todos os registradores eram de 64 bits, e o endereçamento de 64 bits era nativo. O conjunto de instruções era bem enxuto (apenas 136 instruções básicas) quando comparado às centenas do x86. Era a filosofia RISC levada ao extremo.

O processador tinha 31 registradores de propósito geral de 64 bits (R0-R30, sendo R31 sempre zero, um truque para simplificar códigos) e 31 registradores de ponto flutuante de 64 bits (F0-F30, F31 sempre zero).

Ao contrário do x86 que tem flags de carry, zero, sinal, etc., o Alpha não tinha registrador de flags. Comparações eram feitas explicitamente armazenando resultados em registradores. A execução fora de ordem era agressiva, com o 21164 podendo ter dezenas de instruções “em vôo” simultaneamente, reordenando dinamicamente para maximizar uso de unidades funcionais.

As vantagens do Alpha no NT 4.0 incluíam performance bruta, onde em cargas de trabalho bem otimizadas, especialmente operações de ponto flutuante (cálculos científicos, renderização 3D, processamento de sinais), o Alpha frequentemente era duas a três vezes mais rápido que Pentiums da mesma geração. A capacidade de endereçamento de 64 bits era nativa desde o início, enquanto x86 estava limitado a 32 bits (4 GB). O throughput de memória também era superior com barramentos mais largos e rápidos que sistemas x86 equivalentes.

As desvantagens incluíam o preço, com workstations Alpha custando $10.000 a $30.000 e servidores Alpha custando $50.000 ou mais. Pelo preço de um sistema Alpha, você comprava 5 a 10 sistemas Pentium. A compatibilidade de aplicações também era um problema, já que a vasta maioria do software comercial era compilado apenas para x86. Rodar binários x86 no Alpha exigia emulação via FX!32 (baixe aqui se quiser conhercer), um emulador dinâmico desenvolvido pela DEC que traduzia código x86 para Alpha em tempo de execução. Funcionava, mas com penalidade de performance. Os drivers também eram limitados, com fabricantes de hardware raramente fornecendo drivers Alpha para placas de expansão.

O declínio do Alpha começou quando a Compaq comprou a DEC em 1998. Inicialmente a Compaq manteve desenvolvimento do Alpha, mas em 2001 anunciou que descontinuaria a arquitetura em favor do Itanium da Intel/HP. O último processador Alpha, o 21364A a 1.3 GHz, foi lançado em 2003. O Windows NT 4.0 foi a última versão do Windows a suportar Alpha, já que o Windows 2000 removeu o suporte à plataforma.

MIPS: O RISC Acadêmico que Virou Produto

A arquitetura MIPS (Microprocessor without Interlocked Pipeline Stages) tinha origem acadêmica, desenvolvida inicialmente na Universidade de Stanford no início dos anos 1980 sob liderança de John Hennessy (que depois seria presidente de Stanford e chairman do conselho da Alphabet/Google).

O MIPS era o exemplo clássico de RISC “puro” usado para ensinar arquitetura de computadores: conjunto de instruções extremamente simples e regular, pipeline visível ao programador, sem interlock de pipeline automático (compilador tinha que inserir delays explicitamente), sem complexidade de microcódigo.

Os processadores MIPS na era NT 4.0 incluíam o R4000 e R4400 (100-250 MHz, 1991-1995) com processo de 0.6 micron, pipeline de 8 estágios (superpipeline), cache L1 de 8 KB ou 16 KB separados para instruções e dados, cache L2 integrado externamente até 4 MB, 64 bits nativo (registradores e barramento), e suporte a operações de ponto flutuante em hardware.

O R4600 (100-150 MHz) era uma versão simplificada do R4400 com pipeline de 5 estágios (mais tradicional), cache L1 de 16 KB mais 16 KB, e menor custo, voltado para workstations de entrada.

O R5000 (150-200 MHz, 1996) tinha cache L1 de 32 KB mais 32 KB, pipeline de 5 estágios, branch prediction estático, e performance superior ao R4400 em MHz comparáveis.

O R10000 (150-250 MHz, 1996) era o processador high-end para servidores, sendo superscalar com 4 unidades de execução, execução fora de ordem, cache L1 de 32 KB mais 32 KB, cache L2 de 1 a 4 MB externos, e desempenho excepcional para a época.

As máquinas rodando MIPS com NT incluíam Silicon Graphics (SGI) workstations, embora a SGI usasse principalmente IRIX (seu Unix proprietário), algumas máquinas podiam rodar NT.

Havia também MIPS Magnum workstations, máquinas específicas para NT desenvolvidas por parceiros MIPS, e NEC R4000 servers, servidores japoneses baseados em MIPS.

O suporte a MIPS foi descontinuado relativamente cedo. O último Service Pack do NT 4.0 a suportar MIPS foi o SP4 (1998). As razões incluíam mercado muito restrito (poucas empresas compravam workstations MIPS para rodar Windows NT), o foco da SGI no IRIX, competição acirrada (já que o Alpha era tecnicamente superior e tinha maior suporte), e o custo de manutenção era alto demais para para manter toda a cadeia (testar builds, certificar drivers, etc) para um mercado insignificante.

Já o IRIX morreu oficialmente em 16/08/2006, quando saiu sua última release (6.5.30), mas a comunidade ainda respira com auxílio de  aparelhos (veja aqui, aqui e aqui). Existe até emulador (aqui) dele para MAME (não, não testei e não tenho planos de testar).

PowerPC: A Arquitetura que Quase Dominou

A arquitetura PowerPC nasceu de uma aliança improvável em 1991: IBM, Motorola e Apple uniram forças para criar uma arquitetura RISC que pudesse competir com Intel. A aliança ficou conhecida como AIM alliance (Apple, IBM, Motorola).

As motivações de cada parceiro eram claras: a IBM queria uma arquitetura RISC moderna para suas workstations e servidores, substituindo seu antigo POWER; a Motorola precisava de um sucessor para a linha 680×0 que estava perdendo terreno para Intel; a Apple precisava substituir a linha 68040 que estava ficando para trás em performance.

O resultado foi o PowerPC, uma arquitetura RISC de 32 bits (com extensões de 64 bits planejadas) baseada na especificação POWER da IBM mas simplificada e modernizada.

Os processadores PowerPC na era NT 4.0 incluíam o PowerPC 601 (50-120 MHz, 1993-1995), o primeiro PowerPC, com processo de 0.6 micron, cache unificado de 32 KB, pipeline de 4 estágios, sendo uma bridge entre POWER e PowerPC que executava tanto instruções POWER quanto PowerPC, com três unidades de execução (1 inteira, 1 FP, 1 branch), usado nos primeiros Power Macs e algumas workstations IBM.

O PowerPC 603 e 603e (66-200 MHz, 1994-1997) era voltado para laptops e sistemas de baixo consumo, com processo de 0.5 micron depois 0.35 micron, cache de 8 KB mais 8 KB (603) ou 16 KB mais 16 KB (603e), pipeline de 5 estágios, superscalar com duas unidades inteiras, gerenciamento agressivo de energia, usado em PowerBooks e alguns clones Mac.

O PowerPC 604 e 604e (120-350 MHz, 1995-1998) era o chip high-performance para workstations e servidores, com processo de 0.5 micron depois 0.35 micron, cache de 16 KB mais 16 KB (604) ou 32 KB mais 32 KB (604e), pipeline de 6 estágios, superscalar com seis unidades de execução (2 unidades inteiras, 1 unidade de load/store, 1 unidade de branch, 1 unidade de FP multiply-add, 1 unidade de FP divide), branch prediction dinâmico, execução fora de ordem limitada, usado em Power Macs high-end e workstations IBM.

As características arquiteturais do PowerPC incluíam registradores abundantes com 32 registradores de propósito geral (GPRs) de 32 bits e 32 registradores de ponto flutuante (FPRs) de 64 bits. Era uma load-store architecture pura, onde apenas instruções LOAD e STORE acessam memória e todas as operações aritméticas ocorrem em registradores. O conjunto de instruções era fixo de 32 bits, como MIPS e Alpha, onde todas as instruções têm exatamente 32 bits. Havia um Condition Register especial, um registrador de 32 bits dividido em 8 campos de 4 bits cada, permitindo múltiplas comparações independentes. O AltiVec (em chips posteriores) eram extensões SIMD poderosas (128 bits) para multimídia, tentando competir com as extensões SSE dos X86mas vieram tarde demais para o NT 4.0.

As máquinas rodando PowerPC com NT incluíam a IBM Power Series 7xx, workstations baseadas em PowerPC 601/604 rodando AIX ou NT, máquinas FirePower, que eram clones de PC em arquitetura PowerPC feitos pela PowerComputing e outros, e alguns clones Mac, onde empresas licenciadas pela Apple fizeram clones que teoricamente podiam rodar NT, mas drivers eram escassos.

Fun fact 1: Houve rumores de que a Apple considerou abandonar o Mac OS clássico e adotar Windows NT. De fato, a Apple testou o NT em PowerPC com builds internas do NT rodando em protótipos Mac enquanto sua equipe de engenharia avaliava a viabilidade, porém a Apple perderia controle sobre o OS e ficaria dependente das decisões da Microsoft. A incompatibilidade de aplicações também era um problema sério, pois décadas de software Mac OS não rodariam e emulação seria necessária, negando vantagens de performance do PowerPC. A filosofia de design também era um obstáculo, já que o Mac OS tinha paradigmas de interface que não combinavam com o Windows. E havia orgulho ferido, pois seria admissão de derrota tecnológica adotar o sistema do arqui-rival Microsoft. No final, a Apple comprou NeXT em 1996, trazendo Steve Jobs de volta e eventualmente (em 2001), acabou criando Mac OS X baseado em NeXTSTEP/Unix para substituir o Mac OS 9. O suporte PowerPC no NT terminou no SP3 (1998), mesmo ano que a Apple começou trabalho sério no OS X.

Fun fact 2: O desenvolvimento do AVX (Advanced Vector Extensions) pela Intel e AMD dobrou os registradores para 256 bits, superando em muito o AltiVec; isso teria sido um dos fatores que convenceu a Apple a migrar dos PowerPCs para a Intel em 2006, um reconhecimento de que o ritmo de ganhos de desempenho do x86 se tornou insustentável para a arquitetura PowerPC no mercado de PCs.

O Fim da Era Multi-Arquitetura

Com o Windows 2000 (lançado em fevereiro de 2000, tecnicamente “Windows NT 5.0”), a Microsoft abandonou completamente todas as arquiteturas não-x86. Apenas processadores Intel Pentium e compatíveis eram suportados.

A Microsoft desistiu dessa portabilidade por várias razões. O domínio absoluto do x86 significava que em 2000 mais de 95% dos PCs e servidores usavam processadores x86 e o mercado para outras arquiteturas era insignificante. O custo de manutenção era insustentável, já que cada arquitetura adicional multiplicava o esforço de desenvolvimento, teste e suporte. Era necessário manter toolchains de compilação separadas, testar cada build em cada arquitetura, certificar drivers para cada plataforma, treinar suporte técnico em múltiplas arquiteturas, e manter documentação específica. A fragmentação de drivers era um grande maior problema prático, pois fabricantes de hardware simplesmente não forneciam drivers para Alpha, MIPS ou PowerPC.

Os avanços do x86 também foram um fator. Os processadores x86 tinham evoluído dramaticamente. O Pentium III (1999) com SSE e o Pentium 4 (2000) eram competitivos com RISC em muitas cargas de trabalho. A Intel e HP estavam desenvolvendo IA-64 (Itanium) como arquitetura de 64 bits do futuro, e a Microsoft decidiu focar recursos nisso (uma aposta que acabou sendo um fracasso espetacular).

Curiosamente, a arquitetura modular do NT que permitia essa portabilidade viveria novamente décadas depois. O Windows 10/11 hoje roda em ARM (Surface Pro X, tablets), e a arquitetura do NT continua limpa o suficiente para ser portada para novas plataformas quando economicamente justificável.

O Kernel do NT

Para entender o Windows NT 4.0 em sua plenitude, precisamos compreender a fundo a sua arquitetura interna. Diferente do Windows 95 que era essencialmente uma evolução incremental do Windows 3.x sobre MS-DOS, o NT foi projetado do zero com princípios modernos de design de sistemas operacionais.

O Modelo de Camadas e Modos de Operação

O NT 4.0 implementava uma separação rígida entre modo usuário (user mode, ring 3 na terminologia x86) e modo kernel (kernel mode, ring 0). Essa separação era imposta pela MMU (Memory Management Unit) do processador e era essencial para a segurança e estabilidade do sistema.

Modo Kernel (Ring 0) – No modo kernel rodavam os componentes mais privilegiados do sistema:

1. NTOSKRNL.EXE – O kernel executivo propriamente dito
2. HAL.DLL – A Hardware Abstraction Layer
3. WIN32K.SYS – O subsistema gráfico (movido para kernel no NT 4.0)
4. Drivers de dispositivo – Todos os drivers rodavam em ring 0

Códigos em modo kernel tinha acesso irrestrito a toda memória do sistema, podia executar instruções privilegiadas do processador e podia acessar hardware diretamente através de portas I/O ou memory-mapped I/O.

Modo Usuário (Ring 3) – No modo usuário rodavam todos os processos de aplicação e serviços do sistema:

1. Subsistemas de ambiente (Win32, POSIX, OS/2)
2. Aplicações (Word, Excel, SQL Server, etc.)
3. DLLs de sistema (KERNEL32.DLL, USER32.DLL, GDI32.DLL, NTDLL.DLL)
4. Serviços do Windows (services rodando como processos de usuário)

Processos em modo usuário operavam em um espaço de endereçamento virtual protegido. Cada processo via um espaço de endereçamento linear de 4 GB:

• 0x00000000 – 0x7FFFFFFF (0-2 GB): Espaço privado do processo
• 0x80000000 – 0xFFFFFFFF (2-4 GB): Espaço do kernel (acessível apenas em modo kernel)

Qualquer tentativa de um processo acessar memória fora de seu espaço alocado resultava em uma exceção de violação de acesso (access violation), capturada pelo kernel, que terminava o processo ofensor sem afetar o resto do sistema.

O Kernel Executivo: NTOSKRNL.EXE

O kernel do NT era estruturado como um grupo de gerenciadores (managers), cada um responsável por um aspecto do sistema.

O Object Manager implementava o modelo de segurança baseado em objetos. Tudo no sistema era representado como um objeto: arquivos, processos, threads, chaves de registro, eventos de sincronização. Cada objeto tinha um tipo, atributos, uma ACL (Access Control List) definindo permissões, e um security descriptor identificando o owner. O Object Manager mantinha um namespace hierárquico de objetos, similar a um sistema de arquivos, onde aplicações acessavam objetos abrindo handles através de chamadas como CreateFile(), CreateProcess(), CreateEvent().

O Process and Thread Manager gerenciava criação, agendamento e término de processos e threads. Um processo era essencialmente um container com espaço de endereçamento virtual, handle table, security token e threads. Uma thread era a unidade de execução contendo registradores do processador, stacks em modo kernel e usuário, contexto de segurança, e prioridade de agendamento.

O NT usava multitarefa preemptiva com escalonador baseado em 32 níveis de prioridade (0 para threads internas do kernel, 1-15 para prioridades dinâmicas, 16-31 para prioridades em tempo real). O escalonador operava em time slices (quantum) de aproximadamente 20 ms no Workstation e quanta mais longos no Server, garantindo que nenhum processo monopolizasse a CPU.

Gerenciamento de Memória

O Memory Manager implementava memória virtual paginada. O processador não acessava memória RAM diretamente, mas através de endereços virtuais traduzidos pela MMU usando tabelas de páginas. O espaço virtual era dividido em páginas de tamanho fixo (4 KB no x86, MIPS e PowerPC e 8 KB no Alpha).

Páginas podiam estar em três estados: válidas (mapeadas para RAM física, acessíveis), paginadas para disco (gravadas no PAGEFILE.SYS), ou não alocadas (espaço virtual reservado sem backing storage). Quando uma thread acessava uma página ausente, ocorria page fault, o Memory Manager localizava ou alocava um frame na RAM, lia a página do disco se necessário, atualizava as tabelas de páginas, e retornava controle para a thread.

Cada processo tinha um working set, o conjunto de páginas residentes na RAM. O NT usava variação do algoritmo LRU (Least Recently Used) para substituição de páginas. Periodicamente, o Memory Manager identificava páginas não acessadas recentemente, movia-as para listas de standby ou modified, escrevia páginas modificadas para PAGEFILE.SYS, e liberava frames para reutilização.

I/O Manager e IRPs

O I/O Manager coordenava toda comunicação com dispositivos através de drivers organizados em pilhas. Quando uma aplicação chamava, por exemplo, ReadFile(), a chamada eventualmente chegava ao I/O Manager que criava um IRP (I/O Request Packet), uma estrutura de dados descrevendo a operação.

O IRP corria pela pilha de drivers: aplicação → KERNEL32.DLL → NTDLL.DLL → I/O Manager → driver de sistema de arquivos (NTFS.SYS) → driver de volume (FTDISK.SYS) → driver de classe (DISK.SYS) → driver de porta (ATAPI.SYS, SCSIPORT.SYS) → hardware. Cada driver processava o IRP e passava para o próximo ou completava a requisição.

O NT tinha suporte nativo a I/O assíncrono, permitindo que aplicações iniciassem operações sem bloquear, continuando processamento enquanto I/O ocorria em background. O Cache Manager implementava cache de arquivo unificado em memória, dinâmico e integrado com o Memory Manager, melhorando drasticamente performance de I/O.

Segurança: SRM e LSA

O Security Reference Monitor (SRM) implementava o modelo de segurança baseado no padrão C2 do Orange Book do Departamento de Defesa dos EUA. Cada processo tinha um Security Token contendo SID (Security Identifier) do usuário, SIDs de grupos, privilégios e Default DACL. Cada objeto tinha um Security Descriptor com DACL (quem pode fazer o quê) e SACL (auditoria).

Quando uma thread tentava acessar um objeto, o SRM verificava se o security token correspondia às permissões na DACL. Se encontrava DENY, acesso era negado. Se encontrava ALLOW com permissões suficientes, acesso era permitido. Sem ACE correspondente, acesso era negado por padrão.

O Local Security Authority (LSA) rodava como processo privilegiado (LSASS.EXE) e gerenciava autenticação de usuários, geração de security tokens, auditoria de eventos, e políticas de segurança local.

Subsistemas de Ambiente

O NT suportava múltiplos subsistemas de ambiente. O Client/Server Runtime Subsystem (CSRSS.EXE) era o subsistema Win32 principal. No NT 4.0, com o GDI movido para kernel, CSRSS ficou mais leve, gerenciando criação de processos/threads Win32, consoles, e shutdown do sistema.

O POSIX subsystem (PSXSS.EXE) implementava POSIX.1 (IEEE 1003.1-1990), exigido para certificação governamental, mas raramente usado devido a limitações. O OS/2 Subsystem (OS2SS.EXE) suportava aplicações OS/2 1.x em modo texto, um remanescente da parceria Microsoft-IBM.

NTVDM: Virtualização para DOS e Windows 16-bit

O NTVDM (NT Virtual DOS Machine) permitia rodar aplicações MS-DOS e Windows 3.x de 16 bits. Cada aplicação DOS rodava em processo NTVDM.EXE contendo a aplicação, DOS emulado (NTDOS.SYS), BIOS emulado (NTIO.SYS), e VDDs (Virtual Device Drivers).

O processador x86 rodava em modo virtual 8086 (V86 mode), onde instruções privilegiadas causavam traps capturados pelo kernel e acessos a hardware eram interceptados e emulados. Aplicações DOS que acessavam hardware diretamente (jogos) não funcionavam, e performance era inferior a DOS real, mas para aplicações corporativas típicas (software de contabilidade, databases antigos, utilitários) funcionava bem com isolamento completo.

NTFS: O Sistema de Arquivos Empresarial

O NTFS (New Technology File System) era — e continua sendo — um dos componentes mais sofisticados do Windows NT. Enquanto o Windows 95 estava limitado ao FAT16 (e posteriormente FAT32 no OSR2), o NT 4.0 oferecia NTFS como sistema de arquivos primário, trazendo recursos empresariais essenciais.

Arquitetura básica do NTFS

O NTFS era completamente diferente do FAT. Enquanto FAT era essencialmente uma tabela simples mapeando clusters para arquivos, o NTFS implementava um verdadeiro banco de dados transacional de metadados de arquivo.

O coração do NTFS era a Master File Table (MFT), um arquivo especial (chamado $MFT) contendo registros (file records) para cada arquivo e diretório no volume.

Cada registro na MFT tinha tamanho fixo: 1 KB (1024 bytes) por padrão no NT 4.0, podendo ser configurado para 2 KB ou 4 KB em volumes grandes.

A estrutura básica de um file record continha um header (42 bytes) com signature “FILE”, Update Sequence Array, Log File Sequence Number e Reference count; um atributo Standard Information com creation time, modification time, access time e file attributes (R/O, Hidden); um atributo File Name com nome do arquivo (Unicode) e parent directory reference; e um atributo Data com o conteúdo do arquivo OU ponteiros para clusters.

Arquivos residentes vs não-residentes

Para arquivos muito pequenos (geralmente menos de 700 bytes), os dados completos do arquivo podiam ser armazenados dentro do registro da MFT, chamados resident data. Isso era extremamente eficiente: um único acesso à MFT recuperava todos os metadados E o conteúdo, nenhum cluster adicional era alocado, e era ideal para arquivos de configuração pequenos, chaves de registro, etc.

Para arquivos maiores, o atributo Data continha run lists, listas de clusters onde o arquivo estava armazenado. Por exemplo, um Data Attribute (non-resident) poderia ter Run 1 com 150 clusters começando no cluster 45230, Run 2 com 75 clusters começando no cluster 89104, e Run 3 com 200 clusters começando no cluster 120500. Os arquivos podiam ser fragmentados (divididos em múltiplas runs), mas o NTFS mantinha metadados eficientes para acessá-los.

Atributos estendidos

Tudo no NTFS era um atributo. Um arquivo não era apenas “dados”, era uma coleção de atributos: $STANDARD_INFORMATION (timestamps, flags de atributo), $FILE_NAME (nome do arquivo; um arquivo podia ter múltiplos nomes, como um nome longo Windows mais nome 8.3 DOS), $DATA (o conteúdo do arquivo), $SECURITY_DESCRIPTOR (ACLs e permissões), $INDEX_ROOT e $INDEX_ALLOCATION (para diretórios, índices B-tree), $BITMAP (mapa de clusters alocados), e $REPARSE_POINT (para junction points e mount points).

Um arquivo podia ter múltiplos data streams, o conceito de Alternate Data Streams (ADS). Por exemplo, arquivo.txt (stream principal), arquivo.txt:metadata (stream alternativo), arquivo.txt:thumbnail (outro stream alternativo). Cada stream era independente, podia ter tamanho diferente, mas compartilhava os mesmos metadados de segurança.

Journaling: O Log File ($LogFile)

A implementação mais importante do NTFS para confiabilidade era o journaling através do $LogFile.

Resumidamente, o journaling é um “registro de intenções” antes de executar alguma alteração estrutural no disco. Assim, antes de modificar qualquer metadado no volume, o NTFS escrevia um registro no $LogFile descrevendo a mudança que seria feita, executava a modificação nos metadados reais (MFT, índices, bitmaps), e marcava a transação como completa no log.

Se o sistema travasse no meio de uma operação, durante o próximo boot, o NTFS rodava CHKDSK automaticamente, lia o $LogFile, revertia transações incompletas (rolled back) ou reaplicava transações completas mas não confirmadas (rolled forward). O resultado era que o sistema de arquivos nunca ficava em estado inconsistente. Não eram necessários aqueles scans completos de disco que o FAT16 exigia (e que podiam levar horas em discos grandes).

Segurança em Nível de Arquivo

Cada arquivo e diretório no NTFS tinha um Security Descriptor contendo a DACL (Discretionary Access Control List), que definia quem podia fazer o quê com o arquivo.

Por exemplo, um arquivo C:\Financeiro\relatorio.doc poderia ter uma DACL com ALLOW para Domain\GrupoFinanceiro com permissões Read, Write, Delete; ALLOW para Domain\Gerentes com permissões Read, Write; ALLOW para Domain\Funcionarios com permissão Read; e DENY para Domain\Estagiarios com ALL.

As permissões específicas incluíam Read Data (ler conteúdo do arquivo), Write Data (modificar conteúdo), Append Data (adicionar ao final sem modificar existente), Read Extended Attributes (ler atributos estendidos), Write Extended Attributes (modificar atributos), Execute/Traverse (executar arquivo ou atravessar diretório), Delete (remover arquivo), Read Permissions (ver as ACLs), Change Permissions (modificar ACLs), e Take Ownership (tornar-se dono do arquivo).

A SACL (System Access Control List) definia eventos de auditoria. Quando alguém acessava o arquivo, eventos eram gerados no Security Event Log para auditoria.

Herança de Permissões

Diretórios podiam marcar ACEs (Access Control Entries) como herdáveis. Por exemplo, um diretório C:\Projetos com uma ACE marcando ALLOW para Domain\Desenvolvedores com Full Control e Inheritance: CONTAINER_INHERIT_ACE | OBJECT_INHERIT_ACE faria com que qualquer arquivo ou subdiretório criado dentro de C:\Projetos automaticamente herdasse essa ACE, propagando permissões recursivamente.

Compressão Transparente

O NTFS suportava compressão transparente usando o algoritmo LZNT1 (variação de LZ77).

Quando habilitada em um arquivo ou diretório, os dados eram comprimidos em unidades de compressão de 16 clusters (64 KB com clusters de 4 KB), a compressão/descompressão ocorria automaticamente ao escrever/ler.

Havia ganhos de espaço (economia em arquivos texto/documentos) e performance (menos I/O de disco). Entretanto poderia ocorrer sobrecarga da CPU para comprimir/descomprimir, poderia ococrrer aumento da fragmentação (arquivos comprimidos tinham runs menores e mais espalhadas), e não valia a pena para arquivos já comprimidos (JPEG, MP3, ZIP, por exemplo).

O uso típico era ideal para logs de texto extensos, código-fonte (arquivos .c, .h, .cpp), documentos Word e relatórios, e diretórios de instalação de software raramente acessado.

Quotas de Disco

O NTFS implementava quotas de disco por usuário para controlar uso de espaço.

Comparação: NTFS vs FAT16 vs FAT32

Uma tabela comparativa ajuda a entender as vantagens do NTFS:

Recurso	FAT16	FAT32	NTFS 3.0
Tamanho máximo de volume	2 GB (4 GB com clusters grandes)	2 TB (32 GB pelo Windows)	2 TB (teoricamente 256 TB)
Tamanho máximo de arquivo	2 GB	4 GB	16 TB
Segurança em nível de arquivo	❌ Não	❌ Não	✅ Sim (ACLs)
Compressão transparente	❌ Não	❌ Não	✅ Sim
Quotas de disco	❌ Não	❌ Não	✅ Sim
Journaling	❌ Não	❌ Não	✅ Sim (recuperação rápida)
Nomes longos	Não nativo (VFAT hack)	Sim (VFAT)	Sim (nativo Unicode)
Fragmentação	Alta	Alta	Moderada (melhor alocação)
Overhead	Baixo	Baixo	Moderado (metadados extras)
Compatibilidade DOS	✅ Total	⚠️ DOS 7+ apenas	❌ Não (NT apenas)

Para ambientes corporativos, a escolha pelo NTFS era óbvia já que oferecia a segurança, confiabilidade e escalabilidade que o FAT não podia igualar.

O Modelo de Drivers e Hardware

Um dos aspectos mais complexos e frustrantes do Windows NT 4.0 era o suporte a hardware através de drivers.

Drivers no NT 4.0 eram kernel-mode drivers (rodavam em ring 0 com acesso total ao hardware e memória do sistema). Eram arquivos com extensão .SYS carregados durante o boot ou conforme necessário.

Os tipos principais de drivers incluíam os Drivers de Barramento ou Bus Drivers, que detectavam e enumeravam dispositivos conectados a um barramento específico, como PCI.SYS para barramento PCI, ISAPNP.SYS para dispositivos ISA Plug and Play, e ACPI.SYS para dispositivos ACPI. Quando o sistema bootava, esses drivers escaneavam seus respectivos barramentos e reportavam dispositivos encontrados ao Plug and Play Manager.

Os Drivers de Classe ou Class Drivers implementavam funcionalidade comum para uma classe de dispositivos, como DISK.SYS para os discos rígidos (IDE, SCSI), CDROM.SYS para CD-ROMs, MODEM.SYS para modems, e TAPE.SYS para drives de fita. Esses drivers lidavam com operações genéricas (ler setor, escrever setor) e delegavam operações específicas de hardware para port drivers.

Os Drivers de Porta (Port/Miniport Drivers) lidavam com hardware específico, como ATAPI.SYS para controladoras IDE/ATA, AIC78XX.SYS para controladoras SCSI Adaptec 7800 series, NCR810.SYS para controladoras SCSI NCR/Symbios, e SERIAL.SYS para portas seriais.

Os Drivers de Filtro (Filter Drivers) interceptavam requisições entre camadas para adicionar funcionalidade, como FTDISK.SYS para volumes espelhados/striped (RAID software), drivers de antivírus operando como filter drivers do sistema de arquivos, e drivers de criptografia inserindo-se como filtros.

Uma pilha de drivers típica para um disco SCSI começava com a aplicação em modo usuário, passava pelo I/O Manager no kernel, depois pelo NTFS.SYS (filesystem driver), FTDISK.SYS (volume manager se usando RAID software), DISK.SYS (class driver), SCSIPORT.SYS (SCSI port driver, camada genérica SCSI), AIC78XX.SYS (miniport específico para controladora Adaptec), até chegar ao hardware (controladora SCSI Adaptec 7880). Ufa.

Plug and Play no NT 4.0

O suporte a Plug and Play no Windows NT 4.0 era limitado comparado ao Windows 95. Enquanto o 95 tinha PnP profundamente integrado desde o início, o NT foi projetado antes do PnP ser padrão e teve o suporte ao PnP adicionado mais tarde. Dispositivos PCI eram bem suportados (placa de rede PCI, placa de vídeo PCI eram detectadas e configuradas automaticamente). Dispositivos ISA PnP com suporte básico e modems PnP geralmente funcionavam bem. Já o hot-plugging (conectar/desconectar dispositivos com sistema ligado) era instável ou não funcionava, USB tinha suporte extremamente básico e bugado até Service Packs posteriores (SP3+), PC Cards (PCMCIA) tinham suporte limitado (especialmente em laptops) e dispositivos legados ISA exigiam configuração manual de IRQ, DMA e endereços de I/O.

O processo de detecção durante o boot começava com NTDETECT.COM (rodando em modo real antes do kernel carregar) detectando hardware básico via BIOS, passando informações para o kernel. Bus drivers escaneavam seus barramentos, o Plug and Play Manager recebia lista de dispositivos, e para cada dispositivo, o PnP Manager alocava recursos (IRQ, DMA, I/O ports, memory ranges), carregava driver apropriado (se disponível), e iniciava o dispositivo. Os problemas mais comuns incluíam conflitos de IRQ, drivers ausentes (muitos fabricantes não forneciam drivers NT 4.0) e detecção falha (quando o hardware não era reconhecido e tinha que ser instalado manualmente via Control Panel).

Drivers Problemáticos e o Movimento para WIN32K.SYS

A decisão de mover GDI e USER para o kernel (WIN32K.SYS) teve consequências profundas para drivers de vídeo.

No NT 3.x, o modo usuário tinha GDI32.DLL e driver de display (.DLL) em modo usuário, enquanto o modo kernel tinha apenas o kernel básico e miniport de vídeo (.SYS) para inicialização de hardware. Um bug no driver de display travava apenas o subsistema Win32, não o kernel. Já no NT 4.0, o modo kernel passou a ter WIN32K.SYS (GDI mais USER), driver de display completo (.DLL carregado em kernel), e miniport de vídeo (.SYS). Agora, um bug no driver de vídeo travava todo o sistema com BSOD.

Nos primeiros meses após lançamento do NT 4.0, telas azuis causadas por drivers de vídeo foram a reclamação número um de usuários (falamos disso mais cedo, né). Placas de vídeo comuns da época tinham drivers NT 4.0 de qualidade variável. Os drivers problemáticos notórios incluíam S3 Trio64 com bugs causando crashes ao minimizar/maximizar janelas, Matrox Millennium com driver inicial tendo vazamentos de memória graves, ATI Mach64 com conflitos com DirectDraw causando crashes em jogos, e Cirrus Logic com performance terrível e crashes frequentes. Já os drivers confiáveis incluíam Number Nine Imagine 128 com driver bem escrito e estável, Diamond Stealth 64 relativamente estável após updates, e placas de vídeo profissionais (Matrox depois de updates, algumas 3D Labs) com melhor qualidade.

A Microsoft respondeu com o programa WHQL (Windows Hardware Quality Labs) para certificação rigorosa de drivers, Driver Verifier como ferramenta para detectar bugs em drivers durante desenvolvimento, e Service Packs com drivers atualizados para hardware comum. Pelos Service Packs 3 e 4 (1997-1998), a situação havia melhorado substancialmente. Drivers maduros para hardware comum eram geralmente estáveis.

Drivers SCSI: Um Mundo à Parte

Controladoras SCSI (Small Computer System Interface) eram comuns em servidores e workstations profissionais. O NT 4.0 tinha excelente suporte SCSI através de uma arquitetura miniport bem projetada. 

Os fabricantes principais incluíam a Adaptec com o driver AIC78XX.SYS, a Symbios/NCR com os drivers NCR810.SYS/SYMC810.SYS e a BusLogic. Todas tinham excelente performance e popularidade em servidores high-end.

Requisitos de Hardware Mínimos e Recomendados

Mínimos oficiais (x86):

• CPU: 486DX/33 MHz
• RAM: 12 MB (Workstation) ou 16 MB (Server)
• Disco: 110-150 MB livre
• Vídeo: VGA (640×480)
• Unidade: CD-ROM ou rede

Recomendados para uso real:

• CPU: Pentium 90 MHz ou superior
• RAM: 32 MB (Workstation), 64-128 MB (Server)
• Disco: 500 MB-1 GB livre
• Vídeo: SVGA (800×600 ou superior) com 2 MB VRAM
• Placa de rede se aplicável

Observações importantes incluíam FPU obrigatória, já que 486SX sem coprocessador matemático não era suportado. A RAM era crítica, pois com menos de 24 MB, sistema era praticamente inutilizável devido a paging excessivo. Para disco, o NTFS ocupava mais espaço que FAT devido aos metadados.

Mídia de Instalação

O NT 4.0 podia ser instalado de várias formas. O CD-ROM bootável era a forma mais comum, com CD tendo um setor de boot El Torito permitindo boot direto, contendo versões para múltiplas arquiteturas (x86, Alpha, etc.) em diretórios separados. Era também possível utilizar disquetes de boot (3 discos com Boot, Setup Loader e drivers) e CD, além de instalação por rede (a instalação de rede permitia bootar com disquetes de rede e conectar a um share de rede contendo arquivos de instalação)

Service Packs e Atualizações

Como qualquer sistema operacional complexo, o Windows NT 4.0 teve bugs descobertos após o lançamento e novas funcionalidades foram adicionadas ao longo de sua vida útil através de Service Packs.

Service Pack 1 (Outubro de 1996): Lançado apenas dois meses após o RTM, o SP1 foi basicamente um pacote de correções  de bugs críticos de estabilidade, especialmente relacionados a drivers de rede e sistema de arquivos, melhorava compatibilidade com  alguns hardware específico e corrigia problemas de instalação reportados por early adopters.

Service Pack 2 (Dezembro de 1996): Lançado três meses após o SP1, trazia melhorias importantes como correções adicionais de drivers de vídeo ( já que drivers de vídeo continuavam sendo a fonte número um de BSODs). Havia melhorias no TCP/IP stack (correções de bugs de rede) e no NTFS (correções para corrupção de dados em situações específicas). Também incluía patches de segurança iniciais.

Service Pack 3 (Maio de 1997): Foi o primeiro Service Pack com novas funcionalidades além de correções. Introduziu suporte melhorado a USB (mais funcional que no RTM), suporte a processadores MMX (Pentium MMX havia sido lançado em janeiro de 1997), drivers atualizados para hardware mais recente (placas de rede Gigabit Ethernet iniciais, controladoras SCSI Ultra Wide), e Internet Explorer 3.0 integrado (versão atualizada).

O SP3 foi o último Service Pack a suportar arquiteturas MIPS e PowerPC. Versões posteriores eram apenas para x86 e Alpha.

Service Pack 4 (Outubro de 1998): Foi um marco importante e é frequentemente considerado o Service Pack que “amadureceu” o NT 4.0. Trouxe Internet Explorer 4.0 integrado (opcional, podia-se instalar versão sem IE4), com Active Desktop e shell enhancements. A Microsoft oferecia duas versões do SP4: uma com IE4 integrado e outra sem. Incluía patchs para o bug do milênio (Y2K), suporte ao Euro (nova moeda europeia lançada em 1999), melhorias substanciais no suporte a USB (finalmente mais utilizável), e DCOM (Distributed COM) melhorado para aplicações distribuídas.

Havia correções de segurança acumuladas (centenas de patches de segurança de 1996-1998) e melhorias gerais de estabilidade e performance.

Service Pack 5 (Maio de 1999): Lançado já perto do final da vida útil do NT 4.0. Trouxe correções de segurança críticas acumuladas desde o SP4, melhorias no suporte a hardware mais recente (processadores Pentium III com SSE, placas de rede mais modernas), correções adicionais de Y2K (descobertas após SP4), e melhorias de estabilidade geral.

Service Pack 6 (Novembro de 1999): O SP6 foi o penúltimo Service Pack e trouxe preparações para transição ao Windows 2000, que seria lançado em fevereiro de 2000. Incluía correções finais de segurança, compatibilidade aprimorada com aplicações modernas (muitas aplicações já estavam sendo desenvolvidas visando Windows 2000), melhorias no Active Directory Client para NT 4.0 (permitindo clientes NT 4.0 em domínios Windows 2000), e ferramentas de migração para Windows 2000. Havia melhorias finais de driver (últimas atualizações de drivers inbox antes do fim do suporte mainstream) e otimizações de performance.

Service Pack 6a (Junho de 2000): Foi o Service Pack final para Windows NT 4.0 e foi lançado após o Windows 2000 já estar no mercado. A principal razão para o SP6a foi corrigir um problema de segurança crítico descoberto no SP6 original relacionado a criptografia. A Microsoft recomendou que todos que haviam instalado SP6 instalassem SP6a sobre ele. Para novas instalações, podia-se ir direto para SP6a.

Post-Service Pack Hotfixes: Security Rollup Package (SRP)

Mesmo após SP6a, a Microsoft continuou lançando correções de segurança críticas para NT 4.0 durante o período de extended support. Em 2002, Microsoft lançou o Security Rollup Package (SRP), um pacote não oficial que agregava todas as correções de segurança críticas lançadas após SP6a. O SRP incluía patches críticos de segurança de 2000-2002 e correções para vulnerabilidades de rede descobertas após SP6a. Não era um “Service Pack 7” oficial, mas funcionava como tal na prática.

O Fim do Suporte

O suporte mainstream do Windows NT 4.0 terminou em 30 de junho de 2002 e o suporte estendido (apenas correções de segurança críticas) terminou em 31 de dezembro de 2004. Após essa data, nenhuma correção de segurança adicional foi lançada, mesmo para vulnerabilidades críticas. Sistemas NT 4.0 conectados à internet tornaram-se progressivamente mais vulneráveis a ataques.

A Herança do Windows NT 4.0

O Windows NT 4.0 deixou um legado profundo e duradouro que influenciou a evolução do Windows. Foi o primeiro sistema NT com interface moderna, já que os sistemas operacionais robustos tinham interfaces antiquadas (Unix com X11 e o NT 3.x com interface do Windows 3.1). Com o NT 4.0, a Microsoft mostrou que estabilidade e usabilidade não eram mutuamente exclusivas.

A partir do NT 4.0, a linha NT tornou-se a escolha padrão para servidores corporativos, superando o Unix em muitos ambientes e substituindo Novell NetWare como servidor de arquivos primário e dominando o mercado de servidores até a ascensão do Linux neste segmento, entre os anos 2005-2010.

A arquitetura do NT 4.0 é a base do Windows moderno. O Windows XP (2001) era essencialmente NT 5.1 com interface Luna. O Windows Vista/7/8/10/11 são todos descendentes diretos da arquitetura NT. O kernel NTOSKRNL.EXE ainda existe no Windows 11. O NTFS continua sendo o sistema de arquivos padrão. O modelo de segurança baseado em ACLs permanece fundamentalmente o mesmo. A separação modo usuário/modo kernel é idêntica conceitualmente.

A decisão de mover GDI para o kernel, embora controversa, provou ser pragmática e viável com drivers bem escritos e certificados e a Microsoft aprendeu lições valiosas sobre a qualidade de drivers que aplicou em versões posteriores.

O NT 4.0 popularizou conceitos que hoje são dados como garantidos, como a multitarefa preemptiva verdadeira (cada aplicação recebe fatia de tempo CPU garantida), isolamento de processos real (crash de aplicação não afeta outras aplicações ou sistema), segurança em nível de arquivo (permissões NTFS por usuário/grupo) e servidor de arquivos robusto (SMB/CIFS que ainda é usado hoje).

Impacto Cultural e Histórico

Para administradores de sistema e profissionais de TI da época, o NT 4.0 representou uma mudança de paradigma. Pela primeira vez, havia um sistema operacional Microsoft que podia realmente competir com Unix em termos de estabilidade e segurança, mas com interface familiar e vasta compatibilidade de aplicações.

Muitos profissionais de TI começaram suas carreiras administrando servidores NT 4.0, aprendendo conceitos de domínios Windows (precursor do Active Directory), controladores de domínio primários e de backup (PDC/BDC), políticas de grupo primitivas (System Policies) e gerenciamento de usuários corporativos em larga escala.

O NT 4.0 também foi importante academicamente. Era usado em cursos de sistemas operacionais para ensinar conceitos modernos de OS design, arquitetura de kernel, gerenciamento de memória virtual e sistemas de arquivos transacionais.

Comparação com Contemporâneos

Em 1996-2000, o NT 4.0 competia com vários outros sistemas operacionais. O Unix (Solaris, HP-UX, AIX, IRIX) dominava em workstations de alto desempenho e servidores enterprise, mas tinha custo proibitivo e interfaces arcaicas. O NT 4.0 oferecia alternativa mais acessível e amigável.

O Linux estava emergindo em 1996-2000 (kernels 2.0-2.2), mas ainda era considerado hobbyist/experimental. Faltava suporte corporativo, certificação de hardware e aplicações comerciais. O NT 4.0 tinha vantagem significativa nessa época, apesar de perder essa luta entre os anos 2005 e 2010.

O Novell NetWare dominava servidores de arquivos em 1996, mas estava em declínio. NetWare 4.x tinha excelente performance de file serving, mas interface limitada e falta de versatilidade. O NT 4.0 gradualmente substituiu NetWare na maioria das empresas.

O OS/2 Warp da IBM (1994-1996) era tecnicamente impressionante e mais estável que Windows 95, mas tinha pouco suporte de aplicações, o marketing da IBM não era bom o suficiente e perdeu o timing. O NT 4.0 enterrou qualquer chance de ressurgimento do OS/2.

O Mac OS clássico (System 7.x) em 1996-1999 era direcionado a criativos e publicações, não a servidores ou ambientes corporativos multi-usuário. Multitarefa cooperativa e falta de proteção de memória eram limitações fundamentais. O NT 4.0 não competia diretamente, mas demonstrou a superioridade da arquitetura NT que eventualmente influenciaria o Mac OS X.

Sistemas Legados: NT 4.0 Vivendo em 2025

Surpreendentemente, instalações do Windows NT 4.0 ainda existem em alguns contextos específicos.

Sistemas industriais embarcados mantêm o NT 4.0 rodando controladores de manufatura e máquinas CNC (Computer Numerical Control). Em 2008, uma grande fabricante automotiva ainda confiava em sistemas NT 4.0 rodando controladores de produção críticos no chão de fábrica. Um relato de 2008 descreveu um sistema de controle NT 4.0 rodando uma fábrica de papel inteira, onde a falha daquele sistema significaria tempo de inatividade de produção completo. O custo de substituição pode ser proibitivo, especialmente quando o software legado não tem atualização ou exige equipamentos proprietários caros. É a mentalidade “se está funcionando, não mexa”.

ATMs (caixas eletrônicos) representam outro nicho significativo. O Windows NT 4.0 Embedded foi projetado especificamente para ATMs, máquinas de venda automática e outros dispositivos que não podiam ser considerados computadores de propósito geral. Alguns foruns de meados dos anos 2000 confirmam ATMs rodando NT 4.0 Workstation (SP6), com a atualização lenta devido a rigorosas certificações bancárias. O fato de estarem isolados de redes externas torna a configuração mais segura apesar da falta de patches.

Sistemas de transporte também preservaram o NT 4.0. Em sistemas de manuseio de bagagem de aeroportos, PCs rodando Windows NT eram usados para análise de bagagem, gerenciamento de carga e controle de feedback via redes TCP/IP Ethernet. Sistemas de sinalização ferroviária implementaram ferramentas de teste e verificação no ambiente Microsoft Windows NT para sistemas de controle centralizadode tráfego (CTC). A integração profunda com hardware específico torna a migração complexa e cara.

Sistemas militares e governamentais são talvez os mais resistentes à mudança. Instrumentos científicos custando $30.000 ou mais dependem de computadores com o NT rodando software e placas de interface proprietárias, onde atualizar o sistema operacional torna-o incompatível com a interface do instrumento (aqui). Sistemas certificados e validados exigem re-certificação extremamente cara para qualquer atualização. Além disso, muito desse hardware proprietário simplesmente não possui drivers para sistemas operacionais modernos, tornando a migração tecnicamente inviável sem substituição completa do equipamento.

Passo-a-Passo: Instalação do Windows NT 4.0 no Virtual Box

Já falamos muito. Agora vamos instalar o Windows NT 4.0. Eu optei por usar a versão Workstation (faça o download aqui) e depois instalar o SP6a. A imagem já é bootável e não precisaremos de disquetes aqui!

Primeiro vou instalar no VirtualBox, tentar configurar som, video e rede e, depois, ir pro Proxmox (mais abaixo). As recomendações para a criação da VM é escolher versão Windows NT 4 (pois algumas otimizações serão automáticas), 128MB de RAM, HD 2GB (pode ir até 4GB se quiser), desativar VT-x/AMD-V e Paging Aninhado, áudio SoundBlaster 16 e controlador IDE PIIX3 ou PIIX4.

Após colocar o CD e iniciar a VM, começa a instalação:

Lá em cima da tela: Build 1381!

Pressione ENTER para continuar com a instalação.

Pressione ENTER se a instalação for padrão. Caso esteja em alguma máquina real ou queria adicionar algum outro hardware para complicar sua vida, pressione S…

Sim, vamos apagar tudo o que não existe nesse HD virtual.

Aqui você tem que pressionar F8 para aceitar os termos e continuar a instalação. Como meu teclado é o do Mac e o F8 não funciona para isso, use o teclado virtual para pressionar esse maldito F8 (Input -> Keyboard -> Soft Keyboard…).

Sim, vamos usar esse espaço para instalar o Windows NT 4.0.

Detalhe importante: escolha NTFS para aumentar a compatibilidade da VM.

Pronto. Agora a gente tira o CD e continua com ENTER.

A VM vai reiniciar uma ou duas vezes na tela abaixo e depois entra para continuar a instalação:

Coloque o CD novamente e vá em frente!

Como não é produção e não vou usar depois, vou deixar sem senha mesmo.

Também não vou criar disco de reparo!

Sim, a minha rede é cabeada e não discada!

Agora o Windows vai pedir para você escolher a placa de rede. Esse adaptador AMD PCNET Family Ethernet Adapter deve ser compatível com o mais compatível do VirtualBox e NT 4.0, o AMD PCNet FAST III (Am79C973). Caso a gente precise de algum driver em especial, aqui ou aqui deve ter!

Acho que só TCP/IP é suficiente. Esses outros protocolos nem existem mais hoje em dia!

Eu deixei assim mesmo.

Bom, não deu erro. Vou considerar que deu certo!

Veja que já é possível aumentar de 640×480 para 800×600. Após a instalação ser concluída, vamos ver o que podemos fazer para tentar aumentar ainda mais!

Pronto, acabou a primeira parte da guerra instalação!

Para passar aqui, no Mac, é a hostkey (no meu caso Command esquerdo) + Delete.

Não coloquei senha, então é só dar ENTER!

Pronto! Windows NT 4.0 instalado com 800×600 sem nenhum, absolutamente nenhum problema! Agora é configurar tudo!

Pegamos IP e já resolvemos nomes! Temos internet!!!

Sim, temos internet!

Sim, temos Internet Explore 2.0! Vamos rodar o SP6a (aqui) e atualizar essa bagaça!

É só colocar o CD que automaticamente já entra na atualização. Vá em “Install Service Pack 6” para continuar.

Veja que o IE 5 também já está disponível para instalação!

E após reiniciar:

Agora vamos atualizar o IE do 2.0 para o 5.0!

E após reiniciar:

IE 5.0! E até o ícone do IE mudou:

Usar o VirtualBox tem uma vantagem: o Guest Addition! Após inserir o disco e executar:

1024×768 com cores reais (True Color)!

O Windows NT 4.0 não detecta a Sound Blaster 16 automaticamente e o Virtual Box não fornece um driver de som no Guest Additions, então a gente tem que instalar manualmente. Vá em Control Panel -> Multimedia -> Devices -> Add e procure por Creative Labs Sound Blaster 16. O NT 4.0 tem um driver genérico que vamos usar para instalar.

Geralmente deixar o MPU401 I/O ativado pode resultar em erro. Aconteceu comigo. Se aconter com você, desabilite.

Deu certo! Após reiniciar:

Repare no ícone amarelo de caixa de som no canto esquerdo da barra de tarefas: temos som!

Muito, muito fácil! Achei até mais fácil que no Windows 95!

Passo-a-Passo: Instalação do Windows NT 4.0 no Proxmox

Agora vamos para o Proxmox. Vou instalar direto no Proxmox, assim como fiz com o Windows 95 e também não vou ficar colocando muitas prints, apenas os mais relevantes (já que o sistema é o mesmo, né?). Também deixei as configurações da VM muito parecidas com a do Windows 95 (128MB de RAM, 2GB de HD, SCSI controller LSI53C895A, processador Pentium, Machine Type PC-1440fx-2.11). Apesar que o Pentium 2 era um processar da época, como falamos antes, o Proxmox cria caso se ele for escolhido, então deixei o Pentium normal mesmo.

Outra coisa recomendada é trocar o HD de SCSI para IDE (e já estava em IDE mesmo, estava em ide0) e colocar cache do HD em Write Back (para melhorar um pouco a performance), assim como fizemos na instalação do Windows 95 no Proxmox (veja aqui)

Ao contrário das versões anteriores do Windows, aqui já temos uma grande vantagem: o CD é bootável! (Tá, vamos sofrer de novo para instalar o Windows 98 no Proxmox, mas isso é problema para o Jayme do futuro!).

A primeira coisa que notei é que o Windows NT 4 identifica o processador com “MPS Uniprocessor PC” e no Virtual Box mostra como “Standard PC”.

MPS é Multiprocessor Specification. O HAL (Hardware Abstraction Layer do NT) identificou que o Machine Type escolhido (PC-i440fx) tem suporte a multiprocessadores mas está usando apenas uma CPU. Assim, ele utiliza o arquivo HALMPS.DLL ao invés do habitual HAL.DLL. O arquivo da HAL instalada fica em:

<span style="font-size: 16px;">C:\WINNT\SYSTEM32\HAL.DLL</span>

Mas na verdade é um link simbólico para:

<span style="background-color: rgba(0, 0, 0, 0); font-family: georgia, palatino, serif; font-size: 1em;">C:\WINNT\SYSTEM32\HALMPS.DLL</span> (seria o HAL.DLL se fose o standard PC)

Provavelmente esse grau de profundidade de trabalho do Proxmox faz a emulação mais compatível e com melhor performance geral quando comparado com o Virtual Box (que faz uma emulaçào mais “genérica”). A VM lidará melhor com gerenciamento de interrupções (IRQs) e suportaria recursos mais avançados como uma segunda CPU, ou seja, mais próxima de uma máquina real. Ponto para o Proxmox!

Outra diferença que observei foi a instalação do adaptador de rede. Ele perguntou muito mais coisa aqui no Proxmox (deixei tudo como Auto Scan e Default, como sugerido!).

Outra diferença é que o Proxmox, por algum motivo, carrega um driver de vídeo compatível com as placas Cirrus. Isso é ótimo, porque de cara já teremos True Color (16M cores) com 1024×768 ou 64k cores com até 1280×1024! Easy peasy! Certo? Desta vez não vai dar erro!

Pra usar essa placa tem que testar antes! E aí trava nisso aqui:

Alegria de pobre retrocomputeiro dura pouco!!! Então, ao invés de mandar testar, saia da detecção apertando Cancel e a instalação progredirá normalmente. Depois de tudo instalado a gente resolve isso.

Na hora de iniciar a primeira vez, recebemos esta calorosa mensagem:

Como recusamos a instalação da placa Cirrus, o Windows instalou um driver VGA genérico:

Antes de qualquer coisa, instalei o SP6 e o IE 5.0. Vamos deixar tudo atualizado par arrumar o vídeo e a rede.

Rede deu um bom trabalho para resolver, mais por ter que achar um driver compatível. No Hardware Mode, no Proxmox, deixe o Realtek 8139 (rtl8139) e na VM, em Start -> Settings -> Control Panel -> Network -> Adapters, apague o que tiver sido instalado e instale o driver RTL8139 (baixe aqui).

Uma vez baixado o driver (um .ZIP de menos de 500KB), extraia ele e coloque eu uma pasta (dei o nome de RTL8139 e deixei em Downloads). Depois criei uma imagem .ISO com essa pasta com o comando:

hdiutil makehybrid -iso -joliet -o ~/Desktop/rtl8139.iso ~/Downloads/rtl8139

Isso cria um .ISO que, no meu caso, está na Mesa do Mac. Subi esse ISO pro Proxmox e abri no Windows para usar o driver do adaptador de rede. Caso o Windows peça o endereço, o driver está dentro de:

D:\WINNT40\

Só isso e ele vai instalar o adaptador “TRENDnet TE100-PCIWA/TE100-PCIWN 10/100Mbps PCI Fast Ethernet Card“

Na hora da instalação ele pediu o MAC Address do adaptador, mas isso você pode deixar em branco. Pediu também o valor “Early Tx Threshold” e deixei esse valor em “36”. Pronto. Depois de reiniciar, pegou IP e pingou corretamente!

Como o Remote Desktop só virá no Windows 2000 e XP Profissional, nada de som!

Então vamos tentar melhora a tela. Muitos blogs e foruns recomendam trocar o Hardware Mode no Proxmox para Standard VGA ou VMWare Compatible ou ainda VirtIO GPU. Em todos esses casos resultava nessa imagem aqui pra mim, ao entrar no Windows:

Tela bugadaça, né?

Então resolvi peitar e deixar em “Default” mesmo. Neste site o autor apresenta uma ampla explicação sobre os drivers VESA para vários sistemas (desde o NT 3.51 até o XP e 2003, passando pelo NT 4.0) e apresenta a sua solução: o VBEMP.

O VBEMP é um invólucro de software (wrapper) que serve como a camada Miniport Driver (a parte do driver que se comunica com o hardware). Serve para traduzir os comandos de vídeo do Windows NT para o padrão VBE (VESA BIOS Extensions), que é o que o hardware virtual (Proxmox/QEMU) consegue entender. É uma solução freeware que permite que sistemas antigos usem recursos gráficos modernos (como altas resoluções e cores) em ambientes virtualizados.

Especificamente os drivers para o Windows NT estão aqui, no Internet Archive. É uma ISO cheia de arquivos. O significado das letras nos pacotes VBEMP é:

• VBE → VESA BIOS Extension (o padrão que o driver usa)
• MP → MiniPort (é um driver de vídeo do tipo “miniport” para Windows NT/2000/XP

A letra final indica a versão/build do driver (em sequência de desenvolvimento):

E a ISO é criada na Mesa do Mac, contendo APENAS a pasta/pacote com os arquivos que a gente precisa! É só fazer o upload desta imagem pro Proxmox e subir ela na VM.

Na VM, dentro do NT 4.0, vá em Start -> Settings -> Control Panel -> Display -> Settings -> Display Type -> Change -> Have Disk e aí aponte o drive D:\. Ele vai mostar que instalará o driver “AnaPA Corp VBE Miniport”.

Esse “AnaPA Corp VBE Miniport” é simplesmente o nome do fornecedor listado para o driver de vídeo VBEMP (VBE Miniport Driver) no Windows NT 4.0. 

Aceite esse driver para instalação e depois reinicie a VM. Pronto! É só ajustar as cores e a resolução!

Rede e vídeo no máximo no Windows NT 4 no Proxmox!

A última coisa a ser resolvida é um problema comum em virtualização onde aparecem dois ponteiros de mouse (mouse ghosting).

Nos prints acima você, leitor, não consegue ver o ponteiro do Mac, apenas o ponteiro do Windows. Quando a gente usa o RDP, isso se resolve, mas no noVNC isso acontece. Veja no video abaixo o que é o mouse ghosting!

Percebeu o ponteiro branco do Windows e o preto do Mac, não? A causa é que o sistema operacional host (macOS) e o sistema operacional guest (Windows NT 4.0 na VM) estão a gerir o cursor de forma independente, e o driver de integração do Proxmox/QEMU não está a funcionar corretamente para sincronizá-los. Como o Windows NT 4 é um sistema operacional muito antigo e não suporta drivers modernos, o ideal seria forçar a VM a usar um dispositivo de entrada genérico que o Proxmox consegue emular e controlar melhor. Na prática, acabar totalmente é nem difícil, mas dá pra melhorar significativamente.

Pra isso, baixe o VMWare Tools 3.5.0 diretamente do VMWare (aqui). Monte essa ISO no computador e vá em Program Files -> VMware -> VMware Tools -> Drivers -> Mouse -> winnt e copie os dois arquivos desta pasta (vmmouse.inf e vmmouse.sys) para uma pasta. Eu criei uma chamada vmmouse em Downloads e dei o comando abaixo para criar a ISO na Mesa do Mac:

<span class="s1">hdiutil makehybrid -iso -joliet -o ~/Desktop/vmmouse.iso ~/Downloads/vmmouse </span>

Coloque essa ISO no Proxmox e, na VM, vá em Start -> Settings -> Control Panel -> Mouse -> General -> Change -> Have Disk e aponte para D:\. Selecione o “VMware Pointing Device” e reinicie a VM. Fica assim depois:

Resolveu? Não. Mas melhorou MUITO!

Então, pra mim, tá instalado: mouse ghosting resolvido, rede funcionando e cores/resolução da tela no máximo! Trabalho concluído!

Em breve faremos a instalação do Windows 95 no Proxmox!

Deixe um comentário com suas dúvidas!

Até o próximo post, pessoal!