Tutoriais

Kernel no MS-DOS

Um dos modelos de sistemas operacionais mais simples é o antigo MS-DOS / PC-DOS. A dupla era, basicamente, o mesmo sistema, apesar dos nomes dos arquivos serem completamente diferentes. Ambos foram desenvolvidos pela Microsoft a partir do QDOS (Quick and Dirty Operating System), adquirido pela então pequena empresa do estado de Washington para atender ao pedido da IBM – um sistema operacional para seu novíssimo IBM-PC.
O princípio de funcionamento do MS-DOS é extremamente simples. Baseia-se em cinco arquivos: IO.SYS, MSDOS.SYS, CONFIG.SYS, COMMAND.COM e AUTOEXEC.BAT. No PC-DOS, os mesmos arquivos têm nomes diferentes, mas desempenham as mesmas funções: IBMBIOS.SYS, IBMBIOS.COM, CONFIG.SYS, COMMAND.COM e AUTOEXEC.BAT.
O próximo da lista era o COMMAND.COM. Esse era, propriamente, o Shell do sistema. Nele estavam embutidos alguns comandos básicos como COPY, DEL e MD e algumas extensões de E/S não presentes no MSDOS.SYS.
O próprio COMMAND.COM encarrega-se de ler e executar a lista de comandos presentes no arquivo AUTOEXEC.BAT. Esse arquivo define o ambiente de software, variáveis, caminhos (path), carrega programas que devem ser executados na inicialização e alguns drivers de dispositivo incompatíveis com o CONFIG.SYS.
Apesar de ser parte do processo de boot, CONFIG.SYS e AUTOEXEC.BAT não são arquivos obrigatórios. Os únicos arquivos realmente necessários para que um sistema DOS dê boot e esteja minimamente operacional são o IO.SYS, o MSDOS.SYS e o COMMAND.COM (ou IBMBIOS.SYS, IBMBIOS.COM e COMMAND.COM, respectivamente, para sistemas PC-DOS).
Depois do prompt Uma vez carregado o sistema, aparecerá um prompt esperando que o usuário digite alguma coisa. Quando o usuário digita um nome qualquer, o COMMAND.COM procura no caminho especificado em AUTOEXEC.BAT (ou no que o usuário digitou) se o programa existe. Caso exista, trata de carregá-lo na memória usando os serviços do MSDOS.SYS. Depois disso, o próprio programa carregado pode usar os serviços do MSDOS.SYS para comunicar-se com o usuário e com o hardware. O MSDOS.SYS “conversa”, então, com a BIOS do computador (quando aplicável) e com o IO.SYS, que por sua vez “conversa” com a máquina.
Observe que o MS-DOS era um sistema que, por sua simplicidade, não isolava os programas do hardware. Portanto era possível (e até mais fácil) escrever programas que “ tomassem conta” da máquina, contornando (e solenemente ignorando) o IO.SYS e o MSDOS.SYS.
Essas “ligações clandestinas” estão mostradas em linhas tracejadas.

Do POST ao PROMPT

Após o Power On Self Test (POST), o sistema padrão IBM-PC entrega o controle à BIOS, que detecta todos os discos do sistema e carrega o sistema operacional a partir da trilha zero do disco marcado como inicializável (boot disk). Por uma limitação da BIOS (existente até hoje) este setor de inicialização contém um registro de apenas 512 bytes. Nesse espaço exíguo deve, então, haver um sistema operacional.
Hoje em dia, na trilha zero é instalado apenas um programa inicializador, que trata de carregar na memória o resto do sistema. Na época, entretanto, haviam dois arquivos guardados nesse espaço exíguo. Eles formavam, praticamente, todo o sistema. O primeiro a ser carregado era o IO.SYS. Esse arquivo era uma rudimentar interface de controle entre o sistema operacional e o hardware. De fato, todas as requisições ao hardware (essencialmente interrupções, CPU e memória) passavam por ele.
O próximo arquivo carregado era o MSDOS.SYS. Enquanto o IO.SYS “mexia”
diretamente com o hardware, perfazendo tarefas de leitura e escrita de baixo nível, o MSDOS.SYS comunicava-se com a BIOS e gerenciava coisas como interrupções, representação amigável do sistema de arquivos (C:, diretórios, nomes de arquivo) e execução de programas.
Depois do MSDOS.SYS, o arquivo-texto de configuração CONFIG.SYS era lido. Nele estavam definidos os drivers de dispositivos (seu CD-ROM, sua placa de som, sua impressora) que eram carregados na memória. Outros ajustes como configuração de memória extendida e expandida e do sistema de arquivos também era objeto do CONFIG.SYS.

O próximo da lista era o COMMAND.COM. Esse era, propriamente, o Shell do sistema. Nele estavam embutidos alguns comandos básicos como COPY, DEL e MD e algumas extensões de E/S não presentes no MSDOS.SYS.
O próprio COMMAND.COM encarrega-se de ler e executar a lista de comandos presentes no arquivo AUTOEXEC.BAT. Esse arquivo define o ambiente de software, variáveis, caminhos (path), carrega programas que devem ser executados na inicialização e alguns drivers de dispositivo incompatíveis com o CONFIG.SYS.
Apesar de ser parte do processo de boot, CONFIG.SYS e AUTOEXEC.BAT não são arquivos obrigatórios. Os únicos arquivos realmente necessários para que um sistema DOS dê boot e esteja minimamente operacional são o IO.SYS, o MSDOS.SYS e o COMMAND.COM (ou IBMBIOS.SYS, IBMBIOS.COM e COMMAND.COM, respectivamente, para sistemas PC-DOS).
Depois do prompt Uma vez carregado o sistema, aparecerá um prompt esperando que o usuário digite alguma coisa. Quando o usuário digita um nome qualquer, o COMMAND.COM procura no caminho especificado em AUTOEXEC.BAT (ou no que o usuário digitou) se o programa existe. Caso exista, trata de carregá-lo na memória usando os serviços do MSDOS.SYS. Depois disso, o próprio programa carregado pode usar os serviços do MSDOS.SYS para comunicar-se com o usuário e com o hardware. O MSDOS.SYS “conversa”, então, com a BIOS do computador (quando aplicável) e com o IO.SYS, que por sua vez “conversa” com a máquina.

Observe que o MS-DOS era um sistema que, por sua simplicidade, não isolava os programas do hardware. Portanto era possível (e até mais fácil) escrever programas que “ tomassem conta” da máquina, contornando (e solenemente ignorando) o IO.SYS e o MSDOS.SYS.
Essas “ligações clandestinas” estão mostradas em linhas tracejadas.

Fonte: CD Universidade Hacker

Quer enviar seu Tutorial?

Envie um e-mail para thorking@gmail.com sem anexos mande no corpo do e-mail.

Obrigado!

Concurso de sites Top30 Brasil.