Memórias dos Anos 90: Coletores de Dados II

Como a "série 3000" rodava DOS (DR_DOS para ser exato) algumas pessoas pensavam que dava para escrever programas em qualquer linguagem (de preferência Clipper, estamos nos anos 90). Mas a compatibilidade limitada e a pouca memória levava à minha velha amiga, a linguagem C.

Gerando um arquivo HEX para carga no coletor

Os anos 90 foram exigentes para os desenvolvedores de software. A execução direto sobre o DOS, com tela em modo texto e um modelo simples de programação, foi sendo substituída pela execução no Windows 3.x com interface gráfica. As ferramentas demoraram um pouco para se adaptar, o surgimento do Visual Basic e do Delphi deram um certo refresco. E quando a gente começava a se sentir confortável com o Windows de 16 bits, teve a migração para os 32 bits (Windows NT e 95).

As ferramentas oficiais para os coletores sofreram com isso. Se lembro corretamente, a primeira versão do ADK (Application Developpers Kit) que eu estudei se baseava no Microsoft C v6 (não confundir com Microsoft Visual C++ v6 lançado no final da década). Acho que a recém lançada v7 também podia ser usada. Mais adiante foi suportado o Microsoft Visual C++ v.15, que foi a última versão a suportar o desenvolvimento para 16 bits. Por um certo tempo a Symbol ainda conseguiu revender o MSVC 1.5, mas mesmo isso secou. Tipicamente a compilação e linkagem eram feitas na linha de comando (ou arquivos batch), mas lembro vagamente de ter conseguido gerar também dentro da IDE do MSCV 1.5.

Uma das fortes dependências entre o ADK e a versão do compilador diz respeito aos programas "split-resident". Como mencionei na parte anterior, os programas ficavam gravados em uma memória não volátil (a NVM). O mais simples era a NVM se comportar como disco, ao executar o programa ele é copiado para a Ram e roda lá. Só que com isso ficavam duas cópias do código na memória, uma na NVM e outra na Ram. No "split-resident", o código rodava direto na NVM e apenas as variáveis ficavam na Ram. Isto envolvia alguns truques e a substituição de algumas rotinas do runtime do C.

O suporte às características especiais do coletor estavam no BIOS. Device drivers para o DOS forneciam uma API através de IOCTL (para quem não conhece isso, é uma forma complicada de programas interagirem com drivers). Os principais exemplos no ADK usavam isso, porém ele incluía uma biblioteca chamada ADL que facilitava as coisas. Aparentemente esta biblioteca tinha sido escrita por alguma outra parte da Symbol e era ignorada por grande parte da documentação.

À medida que eu ia fazendo aplicações, fui montando a minha própria "caixa de ferramentas": uma mistura de chamadas ao BIOS e usos da ADL. Os primeiros desenvolvedores que foram contratados  pela Seal foram treinados por mim, se basearam nos meus programas e acabaram adotando e aperfeiçoando as mesmas rotinas. Com o tempo elas foram transformadas em uma biblioteca, primeiro informalmente e depois formalmente com direito a documentação.

O tipo de programa mais simples (mas ainda assim útil) era o "lê e grava". Informações eram lidas de código de barra ou digitadas, gravadas num arquivo no Ram Disk e posteriormente descarregadas para um PC através da interface serial.

Complicando um pouco mais, um código lido podia ser consultado em uma tabela carregada previamente no Ram Disk (também pela serial). Com a tabela ordenada e imutável, a consulta podia ser feita via busca binária. A ADL possuía rotinas para isso.

O problema era quando era preciso fazer consultas a tabelas que iam mudando durante a execução. A ADL tinha alguma rotinas para acesso indexado, mas a implementação deixava a desejar em termos de desempenho. A minha solução foi usar uma implementação de b-tree extraída da revista Dr Dobbs. Estas rotinas, de uma forma ou de outra, iriam me acompanhar por décadas.

Alguns programas razoavelmente sofisticados chegaram a ser feitos para a linha 3000. Estes tipos de programas, com carga e descarga de dados pela serial, eram os programas "batch". Uma alternativa mais recente eram os programas "on-line", usando comunicação por rádio. No próximo post vou falar sobre o primeiro sistema de comunicação RF da série 3000, o Spectrum One.