Anteriores:
< Trilha Zero >

< Perversões e Perversidades do DOS >

Curioso idioma, o nosso. Sei de um alemão que se recusou a aprendê-lo quando descobriu que "bota" é algo que se calça, enquanto "calça" é algo que se bota. Dentre suas particularidades existe uma interessante: o verbo "perverter". Do qual derivaram os substantivos "perversão" e "perversidade". Com sentidos diferentes. Não obstante haver certos procedimentos que, além de pervertidos, podem ser considerados perversos.

Divagando, Piropo? É verdade. Mas uma divagação pertinente: impossível evitar tais pensamentos ao lembrar a forma que o DOS usa para alterar o tamanho do ambiente. Pois a maneira escolhida é, sem dúvida, uma perversão. E a forma pela qual fizeram o possível para ocultá-la, espalhando as informações necessárias nas páginas menos obvias do manual, uma perversidade.

Vimos na última Trilha Zero que eventualmente o sistema avisa que falta espaço no ambiente. A maneira lógica de aumentá-lo seria através de algum comando que pudesse ser incluído no Config.Sys, algo assim como ENVIRONMENT=256, por exemplo. O que tornaria tudo demasiadamente fácil. E eu presumo que o DOS tenha entre seus objetivos tornar a vida dos usuários mais rica em sobressaltos para evitar a pasmaceira das coisas singelas. Talvez por isto um comando como aquele não exista.

Por outro lado, você já ouviu falar do comando "command"? Não? Tudo bem: a imensa maioria dos usuários do DOS nem suspeita que ele exista. E, dentre os que suspeitam, jamais encontrei um que o tenha empregado com seu real objetivo: chamar o processador de comandos, o nosso conhecido Command.Com, para executar comandos do DOS. Ele não pode ser usado diretamente, mas somente de dentro de um programa. Quando seu processador de textos, por exemplo, permite que você acesse ao DOS e depois digite EXIT para retornar, o faz através de uma chamada a "command". Portanto, sua utilidade prática para a maioria dos mortais é quase nula.

E o comando "shell"? Também não sabe para que serve? Não se aflija: poucos o conhecem. Ele pode ser incluído no Config.Sys para especificar um novo processador de comandos. A idéia é a seguinte: se você não está satisfeito com a forma pela qual o bom e velho Command.Com executa suas ordens, pode desenvolver um processador de comandos inteiramente diferente e usá-lo no lugar do dito cujo. Juro que não estou brincando. Lá está, literalmente, no manual do DOS: "Programadores de sistemas que desenvolvam seus próprios processadores de comandos (em lugar de usar o arquivo Command.Com do MS-DOS) devem usar o comando shell para especificar o nome de seu programa". Em resumo: postas as coisas desta maneira, é lícito presumir que jamais venhamos a usar o SHELL. Afinal não é todo o mundo que se dispõe a desenvolver todo um processador de comandos numa tarde chuvosa só porquê o Command.Com é tão inamistoso.

Então podemos juntar o "shell" ao "command" na lista dos comandos que jamais usaremos, certo? Errado. Pois única forma de alterar o tamanho do ambiente é através do parâmetro "/e:nnnnn" do comando "command", onde a letra "e" simboliza "environment" (ou ambiente, em inglês) e o "nnnnn" um número de até cinco dígitos que representa o tamanho desejado. Portanto, se você quiser alterar o ambiente, vai ter que usar o "command". Agora ficou fácil?

Ah, lembrou-se que este comando só pode ser chamado de dentro de um programa, e você não é programador? Então parece que continuamos na mesma.

Felizmente o DOS foi suficientemente clemente para nos brindar com a solução deste problema, embora de forma um tanto obliqua: permite que os parâmetros do "command" sejam aceitos pelo sistema, desde que incluídos no comando "shell" do Config.Sys. Em suma: você não quer chamar o Command.Com nem avisar ao DOS através do comando "shell" que está usando outro processador de comandos, portanto não necessita deles. Mas precisa alterar o ambiente. E para isto vai ter que utilizar dois comandos crípticos, aparentemente desnecessários e sem ligação alguma com o objetivo real, um dentro do outro, em seu Config.Sys. É ou não um caso típico de perversão? E procure obter estas informações no manual do DOS que você verá um exemplo de perversidade. Se bem que na versão 5 as coisas melhoraram um pouco e as pistas são mais fáceis de serem seguidas.

Mas sejamos mais práticos e menos perversos, e vamos ao que interessa: como ajustar o ambiente às nossas necessidades. Se você nada disser em contrário, o DOS inicializa seu ambiente com 160 bytes, o tamanho default. O que não é muito: não se esqueça que PATH é uma variável ambiental. Nos discos rígidos atuais, a quantidade de diretórios é enorme, e muitos programas exigem que o seu seja incluído na PATH. O resultado disto é que freqüentemente ela atinge a seu tamanho máximo de 127 bytes, sobrando apenas 33 bytes do ambiente para as demais variáveis, o que pode ser pouco e causar aquelas mensagens de "Out of environment space" ou "Espaço de ambiente esgotado". É preciso então aumentar o ambiente, que pode ter de 160 bytes (o mínimo e default) até o absurdo máximo de 32K. Aí você vai ter que recorrer ao COMMAND. Que só pode ser usado dentro do SHELL. Que, por sua vez, tem que estar no Config.Sys. Para isto, basta incluir em seu Config.Sys a linha:

shell=command.com /p /e:256

E presto! Da próxima vez que sua máquina for ligada, terá um ambiente maior para se espalhar.

Agora, algumas observações pertinentes: se seu Command.Com estiver em outro diretório que não o raiz, não se esqueça de incluir sua via de diretório antes do nome. O parâmetro "/p" deve ser incluído e serve para informar ao sistema que aquele é o processador de comandos principal e que não deve ser descarregado com o comando EXIT (senão, ao comandar EXIT do prompt do sistema o Command.Com se descarregaria e você ficaria perdido sem a linha de comando na tela). E o tamanho do ambiente é necessariamente múltiplo de 16, ou seja, somente pode variar de 16 em 16 bytes (isto não chega a ser um problema, pois se você escolher um ambiente de, digamos 388 bytes, o DOS automaticamente o arredonda para o múltiplo de 16 imediatamente superior, no exemplo, 400). Por fim, não se entusiasme muito e aumente demais o ambiente: lembre-se que uma cópia dele é passada para cada programa, inclusive residentes, e isso pode comer um bocado de memória.

Achou que o DOS complicou demais uma coisa tão singela? Eu concordo. Mas lembre-se que sempre se pode tirar algo bom mesmo das coisas mais incômodas. Afinal, se tudo fosse simples, para que serviria esta Trilha Zero?

B. Piropo