Anteriores:
< Trilha Zero >

< ANSI.SYS >

Vimos que gerenciadores de dispositivos, ou device drivers, são trechos de código que permitem ao sistema operacional manejar os dispositivos de entrada e saída (na verdade, reduzidas as coisas à sua expressão mais simples, o BIOS pouco mais é que uma coleção de device drivers). E gerenciadores instaláveis são os que não fazem parte originalmente do BIOS mas que podem ser incorporados a ele durante o boot por meio do uso do comando "device" no arquivo Config.sys. Agora começaremos a examinar os drivers mais comuns, especialmente aqueles que são fornecidos com o DOS. E justamente pelo mais antigo, o Ansi.sys, que acompanha o DOS desde março de 83 quando foi lançada a versão 2.0.

Ao contrário dos demais, cujo nome indica sua finalidade (é verdade que por vezes de forma bastante obliqua), ele teve o seu derivado da instituição que o padronizou, o ANSI (American National Standards Institute), ou Instituto Nacional Americano para Padronização. E não dá a menor pista de sua serventia. Então vamos esclarecer: o Ansi.Sys é um gerenciador de console.

Na mesma? Tudo bem, eu explico. Começando pelo conceito de console. Os dispositivos de entrada e saída mais evidentes são o teclado o vídeo, respectivamente. Que o DOS trata como uma entidade única que chama de "console" e apelida de CON. Experimente o seguinte: coloque um disco formatado no drive A e do prompt do DOS (sem esquecer do ":" e dos espaços depois do CON e do A) digite:

copy con: a:teste.txt

seguido de ENTER. O cursor começa a piscar uma linha abaixo do prompt. Digite "Teste de console" seguido de ENTER. O cursor muda de linha. Digite "Control+Z" (mantenha a tecla Control apertada e tecle "Z") e mais um ENTER. Veja a luz do drive A: se acender, o DOS responder que um arquivo foi copiado e o prompt se restabelecer. Peça então o diretório do disco no drive A e repare que lá consta um novo arquivo Teste.Txt. Se tudo ocorreu conforme acima descrito, ainda com o mesmo disco no drive A, digite do prompt:

copy a:teste.txt con:

seguido de ENTER e veja aparecer na tela o conteúdo de Teste.Txt seguido novamente do aviso de que um arquivo foi copiado.

Agora vamos analisar o que aconteceu. O primeiro comando "copy" nada mais fez que copiar o arquivo Teste.Txt de um dispositivo para outro. O dispositivo para qual o arquivo foi copiado (dispositivo de saída) foi o drive A e o dispositivo de onde o arquivo foi copiado (de entrada, portanto) foi CON, ou seja, o console. Como você criou o arquivo diretamente do teclado, fica claro que o DOS encarou seu teclado como o dispositivo CON. A propósito: o Control+Z que você digitou nada mais é que o código de final de arquivo usado pelo DOS e os ":" (dois-pontos) são a forma de dizer ao DOS que se trata de um dispositivo. O segundo "copy" fez exatamente o oposto: copiou o arquivo do drive A para o console. Como o arquivo foi exibido em seu vídeo, fica igualmente claro que desta vez o DOS encarou seu vídeo como o console. E não se preocupe que, embora acessados pelo mesmo nome, o DOS jamais confundirá vídeo com teclado: quando o dado vem de CON, o DOS busca no teclado. Quando vai para CON ele manda para o vídeo. E temos conversado.

Agora dá para entender que sendo o Ansi.Sys um driver de console, ele nada mais é que um driver de teclado e vídeo. E algo soa mal. Pois os drivers instaláveis não existem para manejar dispositivos que o DOS normalmente não gerencia? Então para que fazer um justamente para os mais óbvios, aqueles que o sistema operacional tem a obrigação mais elementar de gerenciar? Parece estranho, pois não? E é mesmo. Mas tem suas razões.

Como já explicamos sobejamente, o DOS é constituído de duas partes. Uma delas oferece serviços que os programas usam para tarefas gerais. A outra, chamada BIOS, cuida da comunicação com o mundo exterior, ou seja, da interação com os dispositivos de entrada e saída. Manda a boa técnica de programação que os programas usem os serviços gerais do sistema para suas tarefas e que apenas este último se entenda com o BIOS. Em outras palavras: se o programa precisa, digamos, gravar um arquivo em disco, ele usa um dos serviços gerais do DOS, que por sua vez aciona as rotinas correspondentes do BIOS. Isto foi feito para garantir compatibilidade entre máquinas distintas: como o BIOS faz a ponte entre a CPU e as placas controladoras de dispositivos, ele depende do hardware e é diferente para cada máquina. Isto permite que a parte que contém as rotinas gerais seja sempre igual e os programas não tenham que se preocupar com as peculiaridades de cada máquina ou de cada dispositivo. Por exemplo: quando um programa pede que um trecho de arquivo seja lido para a memória tudo o que ele tem que fazer é informar ao sistema a especificação do arquivo, o número de bytes a serem lidos e o local onde devem ser copiados na memória. Se o arquivo está em disco RAM, disco flexível de 360K ou em um HD de 200Mb, em que setor e de que trilha, é assunto do BIOS. Com isto as coisas se simplificam e se tornam independentes do hardware. O que é uma idéia excelente e eficaz. Menos, infelizmente, no que toca à interação com tela e teclado.

Pois ocorre que os serviços gerais que o DOS oferece para gerenciar vídeo e teclado são paupérrimos. Se limitam a enviar caracteres para a tela, incluindo retorno de carro, avanço de linha, retorno do cursor e sinal sonoro (aquele bip chato, que pode ser acionado "escrevendo" no vídeo o caractere de código 7). E c'est finí. Isto quer dizer que para uma simples limpeza de tela o programa teria que recorrer ao BIOS, o que não teoricamente não é recomendável. Sem falar em coisas mais complexas, porém não menos essenciais, como colocar o cursor em uma dada posição na tela, mudar as cores ou o modo de vídeo.

Sendo as rotinas gerais assim tão limitadas no que toca ao acesso ao vídeo, não é de se admirar que a maioria dos programadores passassem a se entender diretamente com o BIOS. Afinal, suas poderosas rotinas que permitem fazer maravilhas com o vídeo e teclado lá estavam disponíveis, documentadas e facilmente acessíveis. Em princípio isto nada tinha de errado. Mas contrariava a boa norma de usar os serviços gerais do sistema, e não os do BIOS. Foi para contornar este problema que o driver Ansi.Sys foi desenvolvido. Se resolveu ou não, e o que se pode fazer com ele, vamos ver logo.

B. Piropo