Introdução ao Windows - Sistema Operacional Windows 9X

SISTEMA OPERACIONAL WINDOWS 9X

O Windows 9x foi realmente uma grande evolução comparado aos seus antecessores. Ele era muito mais fácil de usar e configurar. Entretanto, houve claramente um marketing exagerado, muitas vezes atribuindo-o características que não o possui.

Vamos a alguns exemplos:

Modo real e modo protegido

Processadores acima do 386 já possuam dois modos de operação bem distintos: o modo real e o modo protegido. No modo real o processador funcionava como se fosse um 8086, o processador utilizado no primeiro PC. Isto significava que ele utilizava instruções de 16 bits e, o que era pior, conseguiria acessar somente 1 MB de memória.

Era o caso do sistema MS-DOS: sua grande limitação era trabalhar apenas no modo real, o que fazia com que ele acesse somente 1 MB de memória (destes 1 MB, 640 KB era destinado à memória RAM).

No modo protegido, o processador conseguira trabalhar no topo de sua performance: além de instruções de 32 bits, conseguiu acessar a até 4 GB de memória, além de diversos outros recursos, em especial a multitarefa, a memória virtual e o modo virtual 8086.

O Windows 3.x trabalhava em modo protegido, e daí a sua grande vantagem: não possuir limitações de memória e poder contar com recursos avançados fornecidos pelo processador. Havia porem, um grande problema: Para o sistema operacional Windows 3.x e o MS-DOS. Qualquer operação de manipulação de arquivos necessitaria que o MS-DOS desempenhasse este papel; o Windows precisava do MS-DOS para funções básicas.

A idéia era escrever um sistema operacional de modo protegido, que não utilizasse o modo real ou o MS-DOS como base.

A Microsoft dizia que era assim que seria o Windows 95.

O Boot do Windows 9X

Porém era falsa a afirmação de que o Windows 9X não precisaria do MS-DOS. Ele passou a utilizar uma nova versão do MS-DOS (chamada de "MS-DOS 7") para o seu processo de boot e para algumas sub-rotinas não existentes em seu núcleo.

O "MS-DOS 7", porém, não trabalhava mais em modo real, mas sim no modo virtual 8086. Este modo de operação, presente no modo protegido dos processadores da época, permitiam que um processador 8086 com 1 MB fosse "simulado" em memória.

Várias sessões 8086 poderiam ser abertas simultaneamente, permitindo que vários programas escritos para o modo real fossem executados ao mesmo tempo. Havia também uma grande vantagem no modo virtual 8086: a área de memória da sessão virtual 8086 era isolada do restante da memória; era protegida. Isto evitaria que programas desastrados viessem a sobrepor sem querer.

Por que a Microsoft simplesmente não fez o Windows 9X totalmente em modo protegido? Compatibilidade.

Medo de que algum programa escrito para MS-DOS não "rodasse" no Windows 9X. Se você desse boot somente com o prompt do Windows 95 (pressionando a tecla [F8] quando aparecesse á mensagem "Iniciando Windows 95 ou 98..."), você teria carregado em seu micro uma nova versão do MS-DOS.

Pelo mesmo motivo, o arquivo que continha o código de carregamento do sistema operacional possuía o mesmo nome: IO.SYS. era neste arquivo que o "MS-DOS 7" estava armazenado. Este era o primeiro arquivo a ser carregado durante o boot do Windows 9X.

No MS-DOS, o segundo arquivo a ser carregado era o MSDOS.SYS. O "MS-DOS 7" estava totalmente dentro do arquivo IO.SYS, de forma que concluímos que o MSDOS.SYS não era necessário para o Windows 9X.

No entanto, alguns programas antigos escritos para MS-DOS poderiam verificar a presença deste arquivo no diretório raiz do primeiro disco rígido, podendo acusar uma mensagem de erro. Para isto não acontecer, a Microsoft criou um arquivo MSDOS.SYS "fantasma" que ficava armazenado no diretório raiz do disco rígido com Windows 9X. Para não desperdiçar espaço com um arquivo "fantasma", o MSDOS.SYS passou a ser um arquivo de configuração do Windows 9X.

Poderíamos editá-lo da mesma forma que editávamos um CONFIG.SYS ou AUTOEXEC.BAT.

Nesse caso, a sequência de boot do Windows 9X ficou assim:

Bootstrap do Bios (Setor de boot do disco rígido) carregava e executava IO.SYS

Era feita a leitura da configuração contida em MSDOS.SYS

CONFIG.SYS era lido e executado, caso existisse, se existisse o arquivo AUTOEXEC.BAT, o COMMAND.COM era executado de modo que os comandos do AUTOEXEC conseguissem ser executados

AUTOEXEC.BAT era lido e executado, caso existisse. Caso não existisse: o COMMAND.COM não era executado.

WIN.COM era executado. Este arquivo era um mero "chamador" do Windows 9X. Caso você tivesse dado boot com a opção "somente prompt", o processo de boot terminava no passo anterior.

WINSTART.BAT era lido e executado.

VMM32.VXD era executado. Este era um dos arquivos mais importantes do Windows 9X, pois era o Gerenciador de Máquinas Virtuais. Neste momento o processador passava para o modo protegido.

Kernel32.dll e Kernel386.exe

GDI32.dll e GDI.exe

User32.dll e User.exe

Fontes e outros recursos

Win.ini

A interface Gráfica

Componentes da área de trabalho e daí por diante, a carga do Windows 9X variava um pouco de sistema para sistema, sobretudo pelas configurações que estivessem presentes no registro do Windows 9X e nos arquivos SYSTEM.INI e WIN.INI, responsáveis pelas configurações básicas do sistema.

O DOS no Windows 9X

Entre as inúmeras vantagens do Windows 9X sobre o DOS estava a sua capacidade de suporte a periféricos. O Windows 9X detectava e gerenciava qualquer periférico instalado em seu micro, coisa que o MS-DOS não fazia. Não havia mais a necessidade de colocarmos drivers de periféricos no CONFIG.SYS ou no AUTOEXEC.BAT como fazíamos no MS-DOS, pois o Windows 9X gerenciava periféricos automaticamente.

Dentro do Windows 9X havia duas formas básicas de se acessar o MS-DOS: saindo-se do Windows 9X com a opção "Desligar", "Reiniciar o computador em modo MS-DOS" ou abrindo-se uma sessão MS-DOS através de um atalho ou do ícone "Prompt do MS-DOS". Independentemente da maneira que você optasse para chamar o MS-DOS, uma coisa era certa: o ambiente seria igual ao boot do "MS-DOS 7" antes da carga do núcleo do Windows 9X (ou seja, antes da execução do WIN.COM).

O primeiro caso equivale a dar boot somente com o prompt do DOS, o que poderia ser feito pressionando-se a tecla [F8] durante o boot, porém com um detalhe: quando você executava este procedimento, o arquivo DOSSTART.BAT presente no diretório C:\WINDOWS era executado.

No segundo caso, a história era outra: uma sessão virtual 8086 era aberta, simulando um processador 8086 com 640 KB de RAM e com o "MS-DOS 7". Esta sessão estaria protegida em memória e o Windows 9X continuaria carregado.

A multitarefa

Todos os processadores a partir do 386 já faziam multitarefa automaticamente quando estavam em modo protegido. Para isto, no entanto, era necessário que cada aplicativo estivesse protegido em memória, ou seja, isolado em sua própria área na memória.

Mais uma vez por motivos de compatibilidade, o Windows 3.x não poderia proteger seus aplicativos em memória. Para o processador, havia uma única área sendo utilizada pelo Windows e seus aplicativos; não havia divisão. Logo concluímos que não pode existir multitarefa naquele ambiente.

A Microsoft, porém, queria porque queria que o Windows 3.x fosse multitarefa. Como o processador não poderia comandar a multitarefa (já que os programas não estavam protegidos em memória), a solução encontrada foi fazer com que os próprios aplicativos a controlassem, criando o termo multitarefa cooperativa.

Neste caso, o próprio aplicativo era quem comandaria a alternância para o próximo aplicativo da lista de tarefas. Se o aplicativo simplesmente "empacasse" ou demorasse para chavear para o próximo aplicativo, a "multitarefa" pararia. O que era extremamente comum de ocorrer (quem trabalhou nessa época deve lembrar muito bem quando se tentava imprimir um documento grande e a impressão empacava, ou se a proteção de tela entrasse em ação quando você tentava abrir um outro aplicativo).

(Estes eram sintomas típicos da multitarefa cooperativa).

Um sistema operacional decente deveria ter uma multitarefa que funcionasse, e, para isto, necessitava que seus aplicativos fossem protegidos em memória. A vantagem de um aplicativo protegido em memória não estava só no fato dele usufruir a verdadeira multitarefa - chamada multitarefa preemptiva.

Estando protegido em memória, um aplicativo estava isolado dos demais.

Caso ocorresse algum problema neste aplicativo, o próprio processador era capaz de reportar esta condição ao sistema operacional, que tratava de remover o aplicativo integralmente da memória. O sistema operacional tornava-se mais seguro.

No modelo utilizado pelo Windows 3.x, onde não havia proteção de memória, um programa facilmente invadia a área ocupada por outro programa, ocasionando o temível erro de Falha Geral de Proteção, o GPF - o que normalmente obrigava o usuário a sair do Windows e chamá-lo novamente, de modo a "limpar" a memória.

Ao contrário do Windows 3.x, o Windows 9X já protegia seus aplicativos em memória, o que, além de torná-lo menos propenso a erros de GPF, permitia a utilização da verdadeira multitarefa, a multitarefa preemptiva.

Porém nem tudo era um mar de rosas. O esquema de proteção de memória do Windows 9X só funcionava para aplicativos escritos para o Windows 9X ("aplicativos de 32 bits"). Aplicativos escritos para Windows 3.x ("aplicativos de 16 bits") não eram protegidos em memória no Windows 9X.

Se aplicativos de 16 bits fossem executados no Windows 9X, dois grande problemas ocorriam.

O primeiro era a fragilidade do sistema. Sem proteção de memória erros de Falha Geral de Proteção eram muito mais frequentes.

O segundo grande problema era a não existência da multitarefa. Como os aplicativos de 16 bits foram escritos não tendo em vista a multitarefa preemptiva mas sim a cooperativa, o Windows 9X entrava numa espécie de "modo de compatibilidade" para conseguir executar esses aplicativos.

O Windows 9X se transformava "por debaixo dos panos", em Windows 3.11, o que fazia com que toda a multitarefa parece, mesmo que você tivesse uma porção de aplicativos de 32 bits sendo executados e apenas um aplicativo de 16 bits.

Em outras palavras, o esquema de multitarefa do Windows 9X só funcionava se você estivesse executando exclusivamente aplicativos escritos para Windows 9X ("aplicativos de 32 bits"). Bastava abrir um único aplicativo escrito para Windows 3.x ("aplicativo de 16 bits") que o esquema de multitarefa passava de preemptiva para cooperativa, transformando o Windows 9X em um Windows 3.11 "de luxo", não importando a quantidade de aplicativos de 32 bits que estivessem abertos.

O Windows 9X era um sistema operacional verdadeiramente de 32 bits?

Vimos que o boot do Windows 9X era feito por uma nova versão do MS-DOS trabalhando no modo virtual 8086. Do ponto de vista prático, este procedimento não acarretava nenhum problema, pois após a carga do VMM32.VXD o Windows 9X permanecia 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 9X a partir do zero. Mas ela não fez isto, por um motivo bem simples: ela queria que o Windows 9X 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 9X 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 9X possuía 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 9X 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 9X continuou com os três arquivos contendo o mesmo código de 16 bits presente no Windows 3.11.

O Windows 9X funcionava da seguinte forma: quando um aplicativo de 32 bits era executado, ele utilizava única e exclusivamente o núcleo 32 bits - o Kernel32, o GDI32 e o User32. Já um aplicativo de 16 bits, porém, tinham 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 9X teria que ser especialmente qualificado. Quando um aplicativo de 16 bits fazia uma chamada a uma sub-rotina presente no núcleo de 16 bits, este redirecionava esta chamada ao núcleo de 32 bits.

Teoricamente este processo funcionava maravilhosamente bem, mas não era bem assim o andar da carruagem. Como a Microsoft decidiu não compilar totalmente os três núcleos do Windows 9X para o modo protegido de 32 bits por causa das exigências de memória RAM, estes núcleos não possuíam todas as sub-rotinas 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.

No Windows 9X quando um programa chamava uma sub-rotina do GDI ou do User, caso esta sub-rotina não estivesse presente no núcleo de 32 bits porque não foi implementada o núcleo de 32 bits chamava a sub-rotina necessária no núcleo de 16 bits.

O problema deste processo é que: mesmo aplicativos de 32 bits uma vez ou outra utilizavam código de 16 bits, porque o GDI32 e o User32 não possuíam todas as sub-rotinas necessárias “implementadas” em modo protegido de 32 bits.

O código de 16 bits era 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 poderia ser executado simultaneamente por mais de um programa. Ou seja, tudo para, quando o núcleo de 16 bits é acessado.

É por este motivo, que às vezes quando você maximizava e minimizava programas no Windows 9X a janela do programa demorava um pouco para ser formada, mesmo quando estávamos trabalhando somente com aplicativos de 32 bits e mesmo com um micro com dezenas de MB de memória RAM: o GDI32 (que era o núcleo responsável por desenhar as janelas) de vez em quando acessava sub-rotinas presentes no núcleo de 16 bits.

Não parece que tudo isto importe tanto, afinal afirmamos anteriormente que o núcleo básico do Windows 9X - 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 acessavam o Kernel E vice-e-versa. Desta forma, o Kernel32 acessava de vez em quando o User32 ou o GDI32. E vimos que o User32 e o GDI32 de vez em quando acessavam o User16 e o GDI16, sendo que estes dois acessavam o Kernel16 (KRNL386)...

Não importava se você tivesse somente aplicativos de 32 bits nem que você tivesse centenas de MB de RAM em seu micro. O Windows 9X era um sistema operacional híbrido que ainda acessava código de 16 bits. Como este código não poderia ser acessado por mais de um programa ao mesmo tempo, tudo parava até que o código fosse "liberado" por quem estivesse acessando. Por outro lado, é importante enfatizarmos que o Windows 9X somente protegia em memória aplicativos de 32 bits. Se você utilizasse ao menos um aplicativo de 16 bits, o esquema de proteção de memória era deixado de lado e a multitarefa passaria a ser igual à multitarefa utilizada pelo Windows 3.x. Em outras palavras, quando um aplicativo de 16 bits era aberto, o Windows 9X "se transformava" em Windows 3.11.

Adonel  Bezerra

Pós-graduado em Teoria em Educação a Distância e Docência do Ensino Superior;

MBA Executivo em Coaching;

Coordenador de cursos de pós-graduação.

Experiência em Gestão de Negócios, envolvendo-se com as áreas administrativa, financeira, comercial, produção e logística;

Experiência de mais de 20 anos como professor conferencista na área de segurança da informação;

Sólida experiência na gestão de negócios e tecnologia da informação;

Sólida experiência no meio acadêmico; 

Consultor de Segurança da informação com mais de vinte anos de experiência;

Treinamentos e palestras ministrados para milhares de profissionais em todo o Brasil;

Livro publicado pela Editora Ciência Moderna e diversos artigos publicados.

 

ALGUMAS PARTICIPAÇÕES COMO CONFERENCISTA OU PALESTRANTE

Centro Universitário do Maranhão – UniCeuma/2009 – Apresentação “O MERCADO DE CONSULTORIA EM SEGURANÇA DE INFORMAÇÃO. 

Universidade de Fortaleza|UNIFOR – Apresentação “TÉCNICAS HACKERS PARA TESTES DE INVASÃO”.

Faculdades Integradas do Ceará – FIC/2010 – Apresentação “ SEGURANÇA DA INFORMAÇÃO”.

Escola de Gestão Pública do Estado do Ceará – /2012 – Apresentação “ SEGURANÇA DA INFORMAÇÃO COM SOFTWARE LIVRE”.

Faculdade La Salle – 2013 – Apresentação “ESPIONAGEM INTERNACIONAL”.

Estácio|FIC/2013 – Apresentação “ ANÁLISE DE VULNERABILIDADES COMO FATOR PRIMORDIAL NAS ORGANIZAÇÕES”.

Estácio|FIC/2015 – Apresentação “PROVA DE CONCEITO”.

Devry Brasil|FANOR Salvador/BA, Fortaleza/CE, Belém/PA, Caruaru/PE, Recife/PE, Teresina/PI    - Apresentação “ VULNERABILIDADES DE SISTEMAS COMPUTACIONAIS”.

 

PROJETO PESSOAL – 1998 – Até o momento

- Fundador e Mantenedor de um dos maiores portais de Segurança de sistema do Brasil, o portal Clube do Hacker; www.clubedohacker.com.br

Fundador e mantenedor da Academia Linux www.academialinux.com.br

Fundador da BUCOIN – www.bucoin.com.br