Anteriores:
< Trilha Zero >

< Quando Copiar Arquivos Era DOSe... >

Antigamente os micros tinham um só drive de disquetes e nenhum disco rígido. E, antes de prosseguir: já repararam como o sentido de "antigamente" muda quando se fala de computadores? Este aí quer dizer não mais que sete ou oito anos...

Pois é. Nestes tempos remotos, copiar um arquivo de um disquete para outro era uma dificuldade. Se você nunca trabalhou com um destes micros caolhos, talvez nem imagine como isto é possível. Mas o DOS é ardiloso e tem solução para tudo (bem, não vamos exagerar: quase tudo). Ele trata o único drive como se fossem dois: ora o chama de A, ora de B. Para copiar o arquivo Texto.Txt, por exemplo, de um disquete para outro em um único drive você faz de conta que tem dois drives, mandando a linha de comando:

copy texto.txt a: b:

O DOS, por sua vez, finge que acredita e emite a mensagem "Insert SOURCE disk into drive A:", pedindo que você ponha o disquete "fonte", ou seja, aquele onde está o arquivo, no seu único drive, que naquele momento é "enxergado" como A, e lê para a memória o conteúdo do arquivo. Depois, gentilmente, emite nova mensagem, desta vez "Insert TARGET disk into drive B:". Você então troca o disco, colocando o disquete "destino", e lá se vai o arquivo para o novo disco no mesmo drive, que agora é visto pelo sistema como B. O teor das mensagens varia de versão para versão (as citadas são do MS DOS 5.0), mas o mecanismo sempre foi este.

Simples, mas altamente inconveniente. Copiar todo o conteúdo de um disquete é uma tortura: quando havia pouca memória (o que era comum naquelas priscas eras), o DOS lia o que podia do disco fonte para a memória, pedia para trocar pelo disco destino, copiava o que havia conseguido ler, pedia novamente para trocar, lia mais um tanto, trocava de novo, copiava mais um pedaço e assim por diante, até copiar o disco todo. Uma chateação. Sem contar que se, durante o processo, você se enganasse e quando o sistema pedisse o disco destino colocasse o fonte ou vice versa, acabava por perder dados. Foi por uma destas fatalidades que fui levado a comprar o segundo drive para meu primeiro micro.

Hoje em dia é raro encontrar um micro com um só drive. Mas o exemplo acima é ótimo para ilustrar algo que confunde muita gente: a diferença entre drive físico e drive lógico. Pois o que o DOS faz é tratar o único drive físico como dois drives lógicos, ora reconhecendo-o como drive A, ora como B. E não somente para cópias. Se em um micro de um só drive, você digitar na linha de comando:

DIR B:

e ENTER, o sistema vai lhe pedir para "inserir um disco como drive B" no seu único drive e ler o diretório. E o drive será tratado como B até que você peça para executar um comando que se refira explicitamente ao drive A. Tudo se passa como se a máquina de fato tivesse dois drives.

O sistema operacional é muito flexível, e permite fazer coisas incríveis com o conceito de drive lógico. Por exemplo: vamos supor que você tenha uma daquelas antiguidades de drive único e sem disco rígido. Você já sabe que o DOS pode tratá-lo como A ou B. Mas talvez se surpreenda ao saber que é possível atribuir até vinte e seis "letras" a ele, ou seja, fazer com que o DOS o "enxergue" como drive A, B, C e assim por diante, até Z. Isto corresponde a atribuir vinte e seis drives lógicos (o limite máximo, devido mais a uma limitação alfabética que informática) a um único drive físico. Na verdade, para o sistema operacional não faz a menor diferença em que dispositivo físico esteja o disco, pois ele somente pode acessar um drive lógico de cada vez.

Claro que o exemplo acima, embora possível, é de escassa utilidade (ainda assim, veremos breve como se pode implementá-lo). Mas usando o conceito de drive lógico com algum engenho e arte, pode-se fazer um bocado de coisas interessantes. E o DOS tem comandos que exploram a idéia de diversas formas práticas. Um bom exemplo é o comando SUBST, que discutiremos mais tarde, e que permite tratar um subdiretório como se fosse um drive ou "chamar" um drive com a "letra" de outro.

Mas onde o conceito de drive lógico realmente tem uma enorme utilidade é nos casos em que se pretende trocar um drive de 360K de um XT por um de maior capacidade. Um problema bastante comum, e que leva ao desespero alguns aflitos micreiros que compraram um drive de alta capacidade e não conseguem fazer com que o sistema operacional o enxergue como tal. Assunto que também breve destrincharemos.

Mas para fazer tudo isto é preciso incluir alguns comandos e gerenciadores de dispositivos nos arquivos de configuração, Config.Sys e Autoexec.Bat. E é por esta razão que voltamos a eles. Estou certo que vocês ainda se lembram de que eles funcionam como uma espécie de "caixa postal" onde o usuário deixa recados para o sistema operacional informando como deseja que a máquina seja configurada. Ambos são arquivos texto, cada linha contendo um comando, e são lidos pelo DOS no momento em que o micro é ligado: primeiro o Config.Sys, depois o Autoexec.Bat. E seus comandos são executados um a um, na ordem em que são encontrados.

No Config.Sys somente podem ser incluídos alguns comandos de configuração, particularmente os chamados device drivers, ou gerenciadores de dispositivos: pequenos programas que são incorporados ao próprio sistema operacional contendo o código necessário para lidar com dispositivos externos ou internos. Já o Autoexec.Bat aceita quaisquer comandos que possam ser digitados na linha de comando, inclusive chamadas de programas. Ele é usado principalmente para carregar programas residentes e executar comandos ligados à configuração da máquina, como "path" e "prompt". Ambos podem ser editados (modificados) com qualquer editor de textos que não grave no arquivo os chamados "códigos de formatação", ou seja, que gravem somente arquivos tipo "texto puro" (ou ASCII). Tudo isto já foi discutido aqui mesmo na Trilha Zero, de modo que fica apenas como lembrete. Se você não se recorda, procure refrescar a memória sobre os arquivos de configuração, pois na próxima semana vamos diretamente ao assunto dos drives lógicos.

B. Piropo