O Windows 95 é um sistema operacional verdadeiramente de 32 bits?
Vimos que o boot do Windows 95 é feito por uma nova versão do MS-DOS trabalhando no modo virtual 8086. Do ponto de vista prático, este procedimento não acarreta nenhum problema, pois após a carga do VMM32.VXD o Windows 95 permanece inteiramente em modo protegido e, teoricamente, trabalhando com um novo código de 32 bits.
Nesta afirmação "com um novo código de 32 bits" é que está a chave de tudo. A Microsoft deveria ter escrito inteiramente o Windows 95 a partir do zero. Mas ela não fez isto, por um motivo bem simples: ela queria que o Windows 95 funcionasse em um micro com apenas 4 MB de memória RAM. Como um código de 32 bits é bem mais complexo e maior que um código de 16 bits, o Windows 95 precisaria de muita memória RAM para "rodar" caso fosse um sistema inteiramente compilado para o modo protegido de 32 bits.
Tanto o Windows 3.x quanto o Windows 95 possuem três núcleos básicos:
- Kernel - O núcleo do sistema propriamente dito. É o Kernel que controla o acesso a memória, gerencia a memória virtual, controla os aplicativos, gerencia arquivos, etc.
- GDI - Graphics Device Interface. É a parte do Windows responsável pela apresentação de tudo aquilo que está na tela. Todas as janelas e ícones são desenhados pelo GDI.
- User - Controla a interface do Windows com o usuário, como entrada de comandos e documentos abertos.
No Windows 3.x, estes três núcleos possuem código de 16 bits, como é de se supor, e estão armazenados nos arquivos KRNL386.EXE, GDI.EXE e USER.EXE. O Windows 95 possui esses três núcleos compilados para o modo protegido de 32 bits, estando armazenados nos arquivos KERNEL32.DLL, GDI32.DLL e USER32.DLL. Apesar disto, o Windows 95 continua possuindo os três arquivos contendo o mesmo código de 16 bits presente no Windows 3.11.
O Windows 95 funciona da seguinte forma: quando um aplicativo de 32 bits é executado, ele utiliza única e exclusivamente o núcleo 32 bits - o Kernel32, o GDI32 e o User32. Já um aplicativo de 16 bits, porém, tem um pequeno problema. Como ele foi escrito de modo a utilizar os arquivos do núcleo de 16 bits (afinal o núcleo de 32 bits não estava presente no Windows 3.x), o núcleo de 16 bits do Windows 95 tem que ser especialmente qualificado. Quando um aplicativo de 16 bits faz uma chamada a uma subrotina presente no núcleo de 16 bits, este redireciona esta chamada ao núcleo de 32 bits.
Teoricamente este processo funcionaria maravilhosamente bem, mas não é bem assim o andar da carruagem. Como a Microsoft decidiu não compilar totalmente os três núcleos do Windows 95 para o modo protegido de 32 bits por causa das exigências de memória RAM, estes núcleos não possuem todas as subrotinas necessárias para a execução dos programas em 32 bits, com exceção do Kernel - que é o núcleo básico e mais importante, tendo sido totalmente reescrito para o modo protegido de 32 bits.
Quando um programa chama uma subrotina do GDI ou do User, caso esta subrotina não esteja presente no núcleo de 32 bits porque não foi implementada, o núcleo de 32 bits chama a subrotina necessária no núcleo de 16 bits.
O problema deste processo é claro: mesmo aplicativos de 32 bits uma vez ou outra utilizarão código de 16 bits, porque o GDI32 e o User32 não possuem todas as subrotinas necessárias implementadas em modo protegido de 32 bits.
O problema é maior ainda, pois o código de 16 bits é um tipo de código não-reentrante: ele foi escrito sem se preocupar com multitarefa. Por este motivo, um código de 16 bits não pode ser executado simultaneamente por mais de um programa. Ou seja, tudo pára quando o núcleo de 16 bits é acessado. E vimos que mesmo aplicativos de 32 bits acessam indiretamente o núcleo de 16 bits do Windows 95...
É por este motivo, por exemplo, que às vezes quando você maximiza e minimiza programas no Windows 95 a janela do programa demora um pouco para ser formada, mesmo quando estamos trabalhando somente com aplicativos de 32 bits e mesmo com um micro com dezenas de MB de memória RAM: o GDI32 (que é o núcleo responsável por desenhar as janelas) de vez em quando acessa subrotinas presentes no núcleo de 16 bits. E neste instante tudo pára, pois o código de 16 bits não pode ser acessado simultaneamente por mais de um aplicativo.
Não parece que tudo isto importe tanto, afinal afirmamos anteriormente que o núcleo básico do Windows 95 - o Kernel32 - foi totalmente compilado para o modo protegido de 32 bits e, por este motivo, o sistema estaria totalmente a salvo destes problemas.
Há, no entanto, um detalhe importante: tanto o GDI quanto o User acessam o Kernel. E vice-e-versa. Desta forma, o Kernel32 acessa de vez em quando o User32 ou o GDI32. E vimos que o User32 e o GDI32 de vez em quando acessam o User16 e o GDI16, sendo que estes dois acessam o Kernel16 (KRNL386)...
Não importa que você tenha somente aplicativos de 32 bits nem que você tenha centenas de MB de RAM em seu micro. O Windows 95 é um sistema operacional híbrido que ainda acessa código de 16 bits. Como este código não pode ser acessado por mais de um programa ao mesmo tempo, tudo pára até que o código seja "liberado" por quem o esteja acessando.
Por outro lado, é importante enfatizarmos que o Windows 95 somente protege em memória aplicativos de 32 bits. Se você utilizar ao menos um aplicativo de 16 bits, o esquema de proteção de memória é deixado de lado e a multitarefa passa a ser igual à multitarefa utilizada pelo Windows 3.x. Em outras palavras, quando um aplicativo de 16 bits é aberto, o Windows 95 "se transforma" em Windows 3.11 para executá-lo, sendo os demais aplicativos que porventura estejam abertos prejudicados por esta mudança. | 
