Anteriores:
< Trilha Zero >

< Acessos em 32 Bits >
< Parte I: As Interrupções>

Pois bem: correndo tudo como previsto, vocês me encontrarão alhures no Micro Cosmo. Se quiserem esticar esse papo, basta dar um pulo até lá. Por outro lado, se acharem que por aquelas bandas o nível é demasiadamente elementar para vossos profundos conhecimentos informatas, paciência. Mas, aqui entre nós: vocês não fazem idéia do quanto eu mesmo aprendo, ainda hoje, quando leio artigos elementares...

Mas chega de colóquio flácido (para quem não fala português castiço: conversa mole) e vamos direto ao ponto. Pois hoje começaremos a discutir uma das menos conhecidas, mais sub-utilizadas, e, não obstante, mais importantes facetas de Windows: 32 Bits Disk Access (acesso a disco em 32 bits), que daqui para a frente batizaremos de 32BDA, e 32 Bits File Access (acesso a disco em 32 bits), que chamaremos de 32BFA.

Começando pelo começo, como convém, vamos primeiro deslindar o significado real deste "32 bits". Que nada tem a ver, como muitos acreditam, com o número de bits lidos cada vez que Windows acessa o disco. E que demandará uma longa explanação.

Para entender a coisa, primeiro precisamos rever um tópico já discutido aqui mesmo na Trilha Zero. Mas há tanto tempo que provavelmente a maioria de vocês esqueceu. Trata-se da forma como os dados trafegam entre disco e memória. Por exemplo: vamos supor que você queira rever um texto qualquer. Nada mais fácil: basta carregar o editor de textos e abrir o arquivo correspondente. Pois bem: para isso você fez pelo menos dois acessos ao disco. Primeiro, copiou o conteúdo do arquivo executável do editor para a memória para que ele possa ser executado. Depois, copiou o conteúdo do arquivo texto também para a memória para que ele possa ser editado. E, mais tarde, se modificar o texto e quiser salvar as modificações, você fará ainda mais um acesso a disco, desta vez para gravar (transferir para o disco) o arquivo modificado. É tudo muito rápido e parece muito simples. Mas faz sua máquina trabalhar um bocado.

Inicialmente, vamos supor que seu editor de textos seja um programa DOS (lembra do DOS? Aquele sistema operacional muito usado antigamente e que hoje você pensa que só serve para carregar Windows...). Nesse caso, no prompt do DOS, basta digitar o nome do arquivo executável do editor e teclar ENTER. O arquivo é lido no disco, o código executável copiado para a memória e o programa se apresenta na tela lépido e fagueiro. Mas quem foi o responsável pela transferência do arquivo para a memória? Elementar, meu caro Watson: o sistema operacional, o próprio DOS.

Mas se está interessado em 32BDA e 32BFA, você deve usar Windows. Nesse caso, para carregar o editor de textos basta um clique duplo sobre seu ícone. E você, provavelmente, imagina que quem lê o arquivo é Windows. Talvez seja (adiante você vai entender o porquê desse "talvez"), mas há uma grande chance que não. Em princípio, Windows apenas informa ao DOS que você deseja carregar o editor. Quem acessa o disco e copia o conteúdo do arquivo para a memória é o DOS.

E o arquivo texto, quem transfere do disco para a memória? O editor de textos? Não mesmo. Se o editor é um programa DOS, apenas avisa ao DOS que você pretende carregar o arquivo, informando nome e localização (via de diretório). Quem acessa o disco e cuida da transferência é ainda o DOS. E se o editor é Windows, a única diferença é que entra mais um intermediário na transação: o editor avisa a Windows que avisa ao DOS que você quer carregar o arquivo. Quem lê o arquivo no disco e o transfere para a memória é, de novo, o DOS. O que não é de admirar: afinal, DOS significa exatamente Disk Operating System, sistema operacional de disco.

Mas como é que o DOS faz essa pequena mágica? Simples: usando um mecanismo interessantíssimo denominado "interrupções". Como isso já foi mais que destrinchado aqui mesmo - embora há muito tempo - vamos resumir a coisa. Se você usa Windows fora do OS/2, o sistema operacional de seu micro é o DOS. Sua missão, além de gerenciar todo o funcionamento da máquina e dos periféricos, é atender as demandas dos programas. Quando você aciona uma tecla, quem "lê" o teclado para identificar o caractere, o exibe na tela e envia a informação para o programa é DOS. E quando um programa deseja imprimir algo, ele apenas informa suas pretensões ao DOS, que é quem cuida de enviar os caracteres e códigos de formatação para a impressora.

Como era de esperar, o sistema operacional é um cara ocupadíssimo: ele fica todo o tempo investigando se o teclado foi acionado, exibindo coisas no vídeo, cuidando dos periféricos. Mesmo quando tudo o que você vê é o cursor piscando na tela em branco (ou em preto, fora de Windows), ele está assoberbado de trabalho (afinal, quem é que você pensa que faz o cursor piscar?). Então, quando um programa precisa de algum serviço, interrompe as tarefas do DOS. Assim como quem dá um tapinha no ombro do outro e diz: "Eu sei que você está muito ocupado agora, mas assim que tiver um tempinho, preciso que você leia um negócio pra mim ali no drive C".

A coisa parece demasiadamente simplificada, mas é a expressão da verdade: o DOS funciona na base de interrupções. Que são de dois tipos: as de hardware, aquelas famosas IRQ que são o pesadelo de quem precisa instalar novos periféricos (através das quais eles avisam ao DOS que necessitam de atenção, como um modem informando que chegou um bit na porta serial) e as de software, usadas pelos programas para solicitar os serviços do sistema.

Sendo o DOS um sujeito organizadíssimo, as interrupções são todas numeradas, catalogadas e muito bem documentadas (pelo menos a maioria: há livros inteiros sobre interrupções não documentadas...). E, em geral, serviços semelhantes são grupados na mesma interrupção. Por exemplo: os serviços (ou "funções") de vídeo fazem parte de uma única interrupção, a de número 16 (só para complicar, os números de interrupções costumam ser expressos em hexadecimal: a que cuida do vídeo é mais conhecida por Int 10h). Lá estão os serviços usados para ajustar o modo de vídeo (Int 10h, serviço 00), ajustar tamanho e posição do cursor (Int 10h, serviços 01 e 02), "acender" um píxel em uma dada posição da tela (Int 10h, serviço 0Ch) e assim por diante.

Para entender os mecanismos de acesso a discos e arquivos, estamos particularmente interessados em duas delas: Int 13h e Int 21h. A primeira engloba apenas os serviços de acesso direto a disco. E a última, além de um enorme número de outros serviços, todos os de acesso a arquivos.

Semana que vem vamos discuti-las (de forma muito superficial, evidentemente). Inclusive para entender a diferença entre acesso a disco e a arquivo.

B. Piropo