Anteriores:
< Trilha Zero > |
|
|
30/11/1992
|
|
Um disco rígido é um dispositivo de armazenamento de arquivos. E tem que ser muito bem organizado. A coisa funciona como em uma biblioteca na qual os livros são manejados por um único funcionário. Quando alguém quer um livro, pede-o ao bibliotecário, que consulta uma lista de livros para ver se aquele que está sendo pedido consta do acervo. Se não acha, avisa que o livro não existe na biblioteca. Se acha, procura em um fichário para saber em que prateleira de que estante vai encontrá-lo. Só ele pode pegar o livro e entregar a quem o solicitou. Depois, na hora de guardar, a mesma coisa: entrega-se o livro ao bibliotecário, que bota no lugar certo. Isso garante que os livros serão sempre encontrados rapidamente, seja quem for o solicitante. Chegou um livro novo? O bibliotecário anota o nome na lista de livros, procura um lugar vago em uma estante, bota o livro lá e anota o local no fichário. E sabe exatamente onde encontrá-lo quando alguém pedir. Em sua máquina, a biblioteca é o disco rígido. O bibliotecário é o sistema operacional, os livros são os arquivos, a lista de livros é a árvore de diretórios e o fichário é a FAT, ou Tabela de Alocação de Arquivos. Um programa precisa de ler um arquivo do disco? Pede ao sistema operacional, que consulta o diretório. Se o arquivo não está lá, avisa com uma mensagem de "Arquivo não encontrado" ou algo semelhante. Se está, procura na FAT a trilha e setor (ou setores) onde está o arquivo e o "entrega" ao programa. Na hora de gravar, a mesma coisa: o programa avisa ao sistema operacional, que procura por setores livres, grava lá o arquivo e atualiza a FAT e o diretório. E todos vivem felizes para sempre, seguindo a sagrada ordem natural das coisas: os programas se entendem com o sistema operacional, que se entende com a máquina. Por outro lado, nós sabemos que o sistema operacional não é - nem pode ser - uma coisa estática. Senão, cada vez que se inventasse um novo dispositivo de armazenamento, haveria que alterar o sistema operacional para acessar seus arquivos (lembre-se que os CD-ROM, por exemplo, são dispositivos de armazenamento e só recentemente foram introduzidos no mercado). Pois para fazer face a este tipo de situação o DOS criou os gerenciadores de dispositivos, ou "device drivers". Que nada mais são que trechos de código incorporados ao sistema operacional no momento em que a máquina é ligada, com as rotinas necessárias ao gerenciamento do dispositivo. Pendurou um novo dispositivo em sua máquina? Inclua no Config.Sys uma linha para carregar o device driver correspondente. Que, a partir deste momento, vai funcionar como um intermediário entre os programas e o sistema operacional em tudo aquilo que se refere ao acesso ao novo dispositivo. Quando um programa quer ler um arquivo, age da forma habitual e o solicita ao sistema operacional. Só que o device driver agora está no caminho, vigilante, interceptando todas as solicitações de acesso a dispositivos. A cada uma, verifica se o acesso solicitado foi ao "seu" dispositivo. Se não, deixa passar para que o sistema atenda. Mas se o arquivo se encontra no dispositivo que ele está gerenciando, o device driver assume o controle no lugar do sistema operacional e se encarrega do assunto. O programa nem toma conhecimento de onde veio o arquivo, desde que ele chegue ileso às suas mãos. Não, eu não esqueci que estávamos discutindo os programas de compressão de arquivos em tempo real. Mas acontece que quando se instala um deles, Stacker ou SuperStor, tudo se passa como se na realidade se estivesse agregando um novo dispositivo de armazenamento à máquina. E nem poderia deixar de ser assim, pois aquele monte de arquivos comprimidos não fazem o menor sentido para o DOS. É preciso, então, incorporar o código para que eles possam ser acessados. O que, evidentemente, só pode ser feito mediante um device driver. Se você usa um programa destes, procure em seu arquivo Config.Sys pela linha correspondente, agregada automaticamente durante a instalação: ela forçosamente começa com o comando "device=" seguido pela via de diretório, nome do device driver e, eventualmente, alguns parâmetros. Se você usa o Stacker, o driver chama-se Stacker.Com. Se usa o SuperStore, chama-se Sstordrv.Sys. Quando um programa quer acessar um arquivo, age como de costume e solicita ao sistema operacional. O driver intercepta a solicitação e verifica se o arquivo encontra-se no trecho do disco onde estão armazenados os arquivos comprimidos. Se não, deixa a solicitação prosseguir para ser atendida pelo DOS. Caso contrário, assume o controle, vai buscar o arquivo comprimido, reconstitui o formato original e o repassa para o programa. Que segue contente, como se o tivesse recebido do DOS. O que é esse tal "trecho de disco onde estão os arquivos comprimidos" veremos adiante. Agora, o importante é saber que os arquivos que lá estão não são gerenciados pelo sistema operacional, mas pelo device driver. É como se, na nossa biblioteca, houvesse toda uma sessão de livros em sânscrito, manejada exclusivamente por um auxiliar de bibliotecário. Quando se solicita um destes livros, nem o bibliotecário chefe, o bom e velho DOS, sabe onde achá-lo. E não se intromete no assunto: chama seu auxiliar, o device driver, que vai buscar o livro onde só ele sabe e, rápido como um raio, traduz do sânscrito para o português e entrega ao solicitante apenas a tradução, o arquivo "descomprimido". Tudo isto tem um desdobramento importantíssimo para quem usa o Stacker ou SuperStore. Pois, quando o device driver não é carregado, tudo se passa como se o auxiliar do bibliotecário houvesse faltado ao serviço: os arquivos comprimidos não podem ser acessados. E é exatamente isto que acontece quando por uma razão qualquer se foi obrigado a dar um boot pelo drive A em uma máquina que usa um programa de compressão de arquivos em tempo real e onde não há, no Config.Sys, a linha que carrega o driver correspondente. O DOS, sem o driver, não consegue acessar os arquivos comprimidos e o usuário fica mais perdido que cego em tiroteio. Daí a regra número um: se você usa o Stacker ou SuperStore, não deixe de copiar para seu disquete de boot os arquivos Config.Sys e Autoxec.Bat do diretório raiz do drive C. Assim como todos os programas e drivers carregados pelo Config.Sys ou Autoexec.Bat e armazenados no diretório raiz do drive C (apenas aqueles que constam do Config.Sys e Autoexec.Bat e que estão gravados no diretório raiz do drive C). Ou, se não houver espaço para tanto no disquete de boot, edite seus arquivos Autoexec,Bat e Config.Sys fazendo com que as linhas que se referem àqueles programas ou drivers tenham os nomes de arquivos precedidos pela via de diretório correspondente. Pois quando de dá a partida na máquina, o DOS vai ler os arquivos Config.Sys e Autoexec.Bat no diretório raiz do disco de onde foi carregado o sistema. E só carrega os drivers que lá foram solicitados. Viu, Cláudia? B. Piropo |