Gerenciamento de Memória - 286, o Processador "Brain-Dead"

Como vimos nas partes anteriores, os processadores 8080 e 8086 não tinham nenhum recurso de gerenciamento de memória. Isto mudou com o processador 286 (também conhecido como 80286 e iAPX286), que acrescentou ao 8086

• capacidade para endereçar até 16MBytes de memória física
• endereçamento virtual de 1 GByte
• facilidades para implementação de swap entre memória e disco
• proteção de memória
• níveis de privilégio
  

Infelizmente, embora estas características sejam bastante úteis para sistemas multi-tarefa e até tenham sido implementadas de forma elegante, elas tinham um preço muito caro no 80286: a incompatibilidade com as aplicações DOS. A principal concessão de compatibilidade no 286 consistia no real mode, modo inicial no qual ele se comportava como um 8086, sem nenhum recurso de gerenciamento de memória. Para ter acesso a estes recursos, o processador precisava ser colocado no incompatível modo protegido. Para agravar a situação, a Intel achou que o modo protegido era tão maravilhoso que ninguém iria querer sair dele; a única forma de retornar ao real mode era fazendo um reset (via hardware).

O modo protegido se baseia em mudar a interpretação dos registradores de segmento. No 8086, os registradores de segmento guardavam uma parte do endereço que era somada ao deslocamento especificado pela instrução sendo executada. No modo protegido, o registrador de segmento contém um índice para uma tabela que descreve o segmento.

Entrando um pouco mais em detalhes, no modo protegido o valor em um registrador de segmento é interpretado da seguinte forma:

• os 13 bits mais significativos são o índice para uma tabela de descritores
• o bit seguinte indica se é usada a tabela global (GDT) ou local (LDT). Existe ainda uma terceira tabela, para os segmentos usados no vetor de interrupções
• os 2 bits menos significativos indicam o nível de privilégio

O endereço inicial de cada tabela de descritores é armazenado em um registrador especial (GDTR, LDTR e IDTR). Um sistema operacional pode, por exemplo, trabalhar com uma LDT para cada processo, isolando desta forma a memória acessível por cada um.

Um descritor de segmento no 286 contém:

• o offset máximo acessível no segmento (16 bits)
• o endereço físico inicial do segmento (24 bits)
• um byte de controle de acesso. Este byte indica se o conteúdo do segmento pode ser executado, lido ou escrito (não é permitido ter um segmento que possa ser executado e escrito). Contém ainda um bit que indica se o segmento está presente na memória física e outro para indicar se o segmento foi acessado; estes bits podem ser usados pelo sistema operacional para controlar o swap entre disco e memória. Por último, este byte pode indicar alguns tipos especiais de segmentos/descritores.

Quem estiver curioso em saber mais detalhes, de uma olhada neste documento.

Embora o modo protegido do 286 seja um imenso avanço sobre o 8086, ele tem algumas restrições:

• a carga de um valor nos registradores de segmento passa a ser lenta, já que envolve um acesso à tabela de descritores que está na Ram, fora do processador
• os segmentos continuam limitados a 64KBytes
• o swap entre disco e memória é controlado no nível de segmento
• não suporta programas que fiquem fazendo contas com os registradores de segmentos, escrevam nos segmentos de código e executem instruções nos segmentos de dados - o que as aplicações DOS costumavam fazer.

O resultado foi que o 286 foi usado como um 8086 rápido pelos usuários do DOS (que eram a maioria). O modo protegido só viria a ser popular com o 386. Como veremos no próximo post desta série, existem vários motivos que levaram Bill Gates a ser referir ao 286 como "brain-dead".

O PC/AT, DOS, Xenix e OS/2

A IBM utilizou o 286 no terceiro micro da linha PC, o PC-AT (o PC original e o PC-XT utilizavam o 8088). Embora fosse muito mais rápido que os modelos anteriores (além de usar um clock mais rápido, o 286 executava as instruções em menos ciclos e o HD também era mais rápido) a IBM claramente segurou o desempenho com medo de atrapalhar as vendas de seus computadores maiores (por exemplo, o PC-AT original usava um clock de 6MHz apesar de os esquemas no manual de referência mencionaram 8MHz). Ao final da "era 286" a IBM tinha menos de metade do mercado (a liderança estava com "Outros") e tinha os modelos mais lentos (8MHz contra 12, 20 ou mesmo 25MHz).

O BIOS do PC/AT trabalhava quase que inteiramente no real mode. A principal exceção era uma função para copiar dados entre o primeiro 1M e o resto da memória. Esta função desabilitava as interrupções, colocava o processador no mode protegido, fazia a cópia e ressetava o processador (através do controlador de teclado). Este processo era suficientemente demorado para atrapalhar uma comunicação serial em andamento.

Junto com o PC/AT a IBM lançou a versão 3 do DOS. A principal alteração no DOS era interna, para permitir o compartilhamento de discos em rede. Entretanto, esta alteração não ficou pronta a tempo; o DOS 3.00 saiu com esta parte do código desabilitada. A versão 3.10 suportava rede porém tinha uma série de bugs que foram corrigidos na versão 3.20. O suporte do DOS ao 286 estava limitado a um driver de ramdisk capaz de usar a memória acima de 1MByte, como visto acima isto não era rápido e podia ter efeitos colaterais indesejados.

O modo protegido do 286 foi usado pelos sistemas *nix, como o Xenix. Entretanto, a ênfase dada era para sistemas multiusuários e a capacidade de um 286 era ainda baixa para isto.

Um legado do 286 foi a insistência da IBM em suportar exclusivamente o modo protegido do 286 na versão 1 do OS/2, ignorando o 386. Isto trouxe uma série de limitações ao OS/2, mesmo em relação ao Windows 3.0, dificultando ainda mais a sua aceitação.

HIMEM

Uma última curiosidade sobre o 286. No 8086 ao somar o segmento deslocado ao offset, o eventual vai-um era ignorado. No 286, que possuia mais bits de endereço físico, este vai-um ia para o bit 20 do endereço. Com medo que isto criasse uma incompatibilidade, a IBM colocou um hardware externo que normalmente forçava o bit 20 do endereço em zero. Entretanto, isto podia ser desligado por software, permitindo acessar 64K acima de 1M no real mode. Isto veio a ser usado no final da vida do 286 e do DOS, quando os 640KBytes de Ram estavam ficando muito apertados.

Gerenciamento de Memória - 8086, 8088, o PC-IBM e o MS-DOS

Com o sucesso dos microprocessadores de 8 bits e o constante avanço da micro-eletrônica, os fabricantes partiram para projetos mais ousados.

A Motorola, por exemplo, abandonou a arquitetura de 8 bits do 6800 e desenvolveu o 68000, com 16 registradores de 32 bits de uso geral e modos usuário e supervisor para proteção do sistema operacional. A Zilog partiu para o sofisticado Z8000.

A Intel, entretanto, se mostrou bastante conservadora com o 8086. Os registradores de uso geral do 8086 (AX, BX, CS e DX) são uma expansão direta dos registradores do 8080. Inclusive, cada registrador ?X pode ser acessado como dois registrados de 8 bit, ?H e ?L.

Isto, mais alguns cuidados na definição do conjunto de instruções, permitiu a conversão automática de código fonte assembler do 8080 para o 8086. Vários programas de sucesso no CPM/80, como WordStar e Dbase II utilizaram este processo para sair na frente no lançamento do PC IBM (por outro lado, estes programas convertidos ficaram em desvantagem quando concorrentes feitos especificamente para o PC ficaram disponíveis).

Como vimos anteriormente, embora o 8080 seja um processador de 8 bits, ele possui algumas instruções para manipular 16 bits, tipicamente endereços. O 8086, entretanto, manipula quase que exclusivamente 16 bits. Isto criou um problema, pois, mesmo no final dos anos 70, era evidente que 16 bits de endereçamento (64Kbytes) era pouco. A gamb^H^H^H^B adaptação técnica (TM Rodrigo Strauss) adotada pela Intel custou muitas noites de sono para os desenvolvedores de aplicações e compiladores. As instruções normais trabalham com endereços de 16 bits, estes endereços são convertidos para 20 bits somando com o valor de registradores especiais também de 16 bits, porém deslocados de 4 bits para a esquerda. Parece confuso? É confuso mesmo.

Estes registradores especiais são chamados registradores de segmentos. O 8086 tem 4 destes registradores, chamados CS, DS, SS e ES. Por default, estes registradores são usados, respectivamente para acesso a código, dados e pilha (o registrador ES só é usado implicitamente por algumas instruções especiais). É possível (com certas restrições) usar explicitamente um registrador de segmento diferente colocando um byte de prefixo na frente da instrução.

Vamos tentar esclarecer com um exemplo. Vamos supor que os registradores BX, DS e ES contenham, respectivamente, 0x1234, 0x9000 e 0x4321 (0x indica número hexadecimal, se você não sabia disso provavelmente está no blog errado). A instrução assembler MOV AX,[BX] carrega em AX o valor na posição de memória de endereço DS*16 + BX (ou seja, 0x91234). A instrução MOV AX,ES:[BX] usa o registrador ES no lugar do DS, carregando em AX o valor na posição de memória de endereço 0x44444.

É costume no 8086 falar em endereços na forma segmento:offset, onde segmento e offset são valores de 16 bits. No nosso exemplo anterior, o endereço 0x44444 poderia ser referenciado como 0x4321:0x1234. Ou 0x4000:0x4444. Ou outras 64K-2 formas diferentes (o 8086 ignora o "vai um" quando soma o segmento deslocado com o offset, guarde esta informação para quando formos falar do 286).

O que tudo isto significa na prática? Em primeiro lugar, que o 8086 é capaz de endereçar até 1M de memória. Em segundo lugar, que uma aplicação precisa fazer uma certa ginástica para usar mais que 64K de código ou dados. No caso do código, existem o JUMP e CALL intersegmento, mas são instruções mais longas e mais demoradas. No caso de dados, para acessar uma estrutura que ocupe mais de 64K é preciso fazer umas contas medonhas. Os compiladores C para o 8086 costumam suportar alguns modelos de endereçamento:

• Tiny: Tudo fica em um único segmento de 64K. Os quatro registradores de segmento apontam para o início do segmento no início da execução e não são mais alterados. Altamente eficiente e simples, até que o seu programa não caiba em 64K.
  

• Small: Um segmento de código (apontado por CS) e um segmento de dados (apontado por DS e SS). Novamente os registradores não precisam ser alterados durante a execução.
  

• Medium: Um segmento de código para cada rotina e um segmento único de dados. Cada chamada de rotina passa de 3 para 5 bytes; o seu código que não cabia por pouco em 64K agora ocupa 70K.
  

• Large: Múltiplos segmentos de código e dados, mas nenhuma estrutura passa de 64K. Os registradores CS e DS mudam a toda instante, o tamanho do código cresce e o desempenho cai.
  

• Huge: Múltiplos segmentos de código e dados, permite estruturas com mais de 64K. Avançar um ponteiro de dados passa a ser uma operação lenta.

Neste altura vocês devem estar achando que a Intel fez uma grande besteira. Entretanto, simplificando o processador ela simplificou o processo de fabricação, saindo na frente dos concorrentes e obtendo mais chips bons por waffer de silício e portanto chips mais baratos. Além disso, a compatibilidade parcial com o 8080 permitiu ter rapidamente uma boa oferta de software. Enquanto os outros processadores de 16 bits eram usados apenas em projetos mais sofisticados, o 8086 foi ganhando terreno. Quando a IBM foi ouvir os conselhos da Microsoft (que aliás tinha muito software para 8080 e CPM/80, a ponto de ter desenvolvido uma placa de expansão com Z80 para ter penetração no mercado Apple) a estratégia deu frutos.

Um ponto interessante no interior do 8086 é a divisão do processador em uma unidade de execução e uma unidade de acesso de memória. Esta segunda unidade é a responsável por acionar os pinos de endereçamento do chip e faz algumas coisas especiais:

• no caso de um acesso a uma valor de 16 bits que está em um endereço impar, gera dois acessos à memória. Desta forma existe uma penalidade de tempo, mas o software é executado quase que normalmente.
  

• aproveita quando a unidade de execução está processando a instrução para pegar as instruções seguintes e colocá-las numa pequena fila. Não chega a ser um cache, mas dá um pequeno ganho de performance e permite usar memórias mais lentas.
  

A existência da unidade de acesso à memória simplificou criar o 8088, que é identico ao 8086 porém usa uma memória de 8 bits. Do ponto de vista de software, nada muda. Do ponto de vista de hardware, o custo de um sistema simples cai, pois os chips de memória típicos eram de 16K ou 64K posições de 1 bit. Com o 8088, dava para fazer um sistema usando 8 chips de memória, com o 8086 era preciso no mínimo 16 chips.

Ao contrário do 8080, o 8086 inicia a execução no final da memória, no endereço 0xFFFF0. Novamente, isto simplifica o projeto, pois pode-se colocar uma memória não volátil no fim da memória e Ram no começo. No início da memória existe uma tabela importante o vetor de interrupções. Esta tabela contém os endereços das rotinas que tratam as interrupções de hardware e software.

O PC-IBM

Por sugestão da Microsoft, a IBM utilizou o 8088 no PC IBM. Na placa principal havia lugar para até 64K de Ram, na forma de 32 chips de 16Kx1. No PC XT eram usados chips de 64Kx1, permitindo 256K na placa mãe.

O 1M de endereçamento foi dividido em três grandes partes: os primeiros 640K (0x00000 a 0x9FFFF) para a Ram, os últimos 64K (0xF0000 a 0xFFFFF) para a memória não volátil com o BASIC e o BIOS e o resto (0xA0000 a 0xEFFFF) para uso pelas placas de expansão (notadamente a Ram das placas de vídeo em 0xB0000 e 0xB8000 e o BIOS da controladora de HD em 0xC0000).

Uma curiosidade é que o chip de DMA da Intel (responsável entre outras coisas por transferir para a memória os dados das controladoras de disco) também era limitado a 16 bits. Para endereçar toda a memória, a IBM precisou acrescentar um registrador externo de 4 bits. Isto criou uma nova barreira de 64K: não era possível ler diretamente do disco para um trecho de memória que contivesse uma mudança nos 4 bits mais significativos do endereço. O BIOS se limitava a recusar este tipo de transferências, deixando por conta do sistema operacional ou aplicação contornar esta limitação.

O BIOS possui as rotinas de iniciação do hardware e rotinas básicas de entrada e saída. A memória de 0x00000 a 0x003FF contem os vetores de interrupção, de 0x00400 a 0x004FF estão as variáveis do BIOS.

O MS-DOS

A Seattle Computer foi uma das primeiras empresas a fazer um micro usando o 8086. Entretanto o único software disponível era o BASIC da Microsoft. Cansados de esperar pelo CP/M-86, eles desenvolveram o QDOS (Quick and Dirty Operationg System). Quando a IBM também se cansou de esperar pelo CP/M-86, a Microsoft licenciou o QDOS e o ofereceu para a IBM. O resto, como dizem, é história. (Recomendo para quem quiser os detalhes o livro Gates de Stephen Manes e Paul Andrews).

Apesar das inúmeras diferenças em relação ao CP/M-80, o MS-DOS suporta uma interface de programação muito semelhante. Como vimos na parte anterior, no CP/M-80 a interface entre a aplicação e o sistema operacional é feita através de uma estrutura no início da memória. No MS-DOS esta estrutura é simulada no Prefixo de Segmento de Programa (PSP). Lá estão a linha de comando, as estruturas de acesso a arquivos (FCBs) e até mesmo a chamada ao SO. Nas versões futuras do MS-DOS algumas destas características foram perdendo importâncio, mas continuam lá e sobrevivem até no Windows.

Ao contrário do CP/M-80, o MS-DOS reside nos endereços baixos. A memória disponível para os programas começa após o final do SO (mais rigorosamente, após a parte residente do COMMAND.COM) e vai até o fim da Ram (o final da Ram é também usado pelo parte transiente do COMMAND.COM). Na versão 1 o DOS não oferecia nenhuma função de gerenciamento de memória, exceto o Terminate and Stay Resident, através da qual um programa podia encerrar deixando uma parte de si na memória (ou seja, controle de memória do DOS se limitava ao endereço ondem os programas eram carregados). A partir da versão 2, o DOS passou a oferecer funções simples de alocação de memória, colocando um pequeno prefixo no final de cada bloco alocado.

O MS-DOS suporta dois formatos de arquivos executáveis: COM e EXE.

Um arquivo COM é uma imagem binária de um programa. Esta imagem é carregada no offset 0x100 de um segmento, os registradores CS, DS, ES e SS apontam para o início do segmento e a execução é iniciada em CS:0x100. No começo do segmento é colocado o PSP. Este esquema, muito semelhante ao CP/M-80, é apropriado para programas no modelo tiny.

O arquivo EXE suporta programas com múltiplos segmentos. Para isto ele possui um cabeçalho para para acertar as referências inter-segmentos conforme o segmento em que o programa foi carregado. O PSP é criado na memória antes do primeiro segmento do programa. No início da execução, os registradores DS e ES apontam para o PSP, os registradores CS, IP, SS e SP são carregados com informações obtidas do cabeçalho do EXE.

Do ponto de vista de gerenciamento de memória, o 8086 e o MS-DOS não trazem grandes vantagens em relação ao 8080 e CP/M-80 (exceto por suportarem uma memória maior). Isto ficou para a geração seguinte. Infelizmente, o 286 seguiu na direção errada, como veremos no próximo post desta série.

Programando em C#

Como estou acostumado a programar principalmente em C, programar em C# traz algumas novidade e desafios para mim:

• Excetos pelas variáveis numéricas, enumerações e estruturas (value types), tudo é alocado no heap gerenciado (reference types) e será liberado da memória pelo Garbage Collector. Ou seja, é um monte de X x = new X(). Para quem está acostumado a gerenciar os seus bytes um a um com muito carinho é um grande desafio de confiança.
  

• No C# não existem variáveis globais e tudo tem que estar dentro de uma classe. Por exemplo, imagine que você queira criar uma rotina chamada Arredonda e uma constante chamada ValorMinimo, que você queira usar em vários lugares. Você precisa declará-los como membros estaticos de alguma classe. No C# 2005, é possível criar classes estáticas úteis justamente para este tipo de coisa.
  

• Os controles geram eventos quando são alterados pelo operador ou pelo programa. Por exemplo, se você selecionar um item de um combox por programa, a rotina que trata o evento de mudança de seleção será chamada. Em alguns casos isto é muito útil mas em outros causa algumas complicações.

Como disse anteriormente um grande problema é que o framework é imenso e o help é muito sucinto. Estou toda hora procurando coisas no Google. Duas dicas das que acumulei até agora:

Pegar a versão do programa no assembly

No properties do projeto é definida a versão que será colocada no assembly. Para pegar este valor, por exemplo para o diálogo de Sobre, basta usar

Assembly.GetExecutingAssembly().GetName().Version.Major.ToString()
Assembly.GetExecutingAssembly().GetName().Version.Minor.ToString()

Usar um LinkLabel

Ainda no diálogo Sobre, imagine que você quer colocar um link para abrir a sua home page. O controle LinkLabel faz isto, se você souber usar. Coloque o LinkLabel no diálogo e altere a propriedade Text para o URL desejado (por exemplo, http://www.microsoft.com). No construtor do formulário, copie o texto para a lista de links:

linkHomepage.Links.Add(0, linkHomepage.Text.Length, linkHomepage.Text);

No evento LinkClicked, siga a receita abaixo (encontrada em http://www.peterritchie.com/Hamlet/Articles/63.aspx)

string strLink = e.Link.LinkData.ToString();
Process process = new Process();
process.StartInfo.FileName = "rundll32.exe";
process.StartInfo.Arguments = "url.dll,FileProtocolHandler " + strLink;
process.StartInfo.UseShellExecute = true;
process.Start();

A solução apresentada no help é mais simples

System.Diagnostics.Process.Start (e.Link.LinkData as string);

só que não funciona...

Gerenciamento de Memória - 8080 e CPM/80

Assistindo a palestra do Rodrigo Strauss sobre Gerenciamento de Memória no Windows, surgiu a idéia de fazer alguns posts sobre o gerenciamento no nível do microprocessador, começando lá no tempo dos 8 bits.

Como vocês provavelmente sabem, o primeiro microprocessador disponível comercialmente foi o 4004 da Intel, de 4 bits. Posteriormente a Intel criou o 8008 de 8 bits, que rapidamente evoluiu para o 8080, cujas influências estão presentes até hoje nos processadores Intel.

Quando dizemos que o 8080 é um processador de 8 bits, isto se deve principalmente a duas características:

• a unidade lógica aritmética (ALU) faz diretamente operações com valores de 8 bits
• a ligação com a memória utiliza 8 bits de dados

O endereçamento da memória utiliza 16 bits, permitindo endereçar diretamente até 64 Kbytes. Ao ser re-iniciado, o 8080 começa a execução sempre pelo endereço zero de memória.

A figura acima mostra os registradores do 8080. O programa counter (PC) e o stack pointer (SP) são registradores de 16 bits. Em quase todos os casos, o acumulador contém um dos operandos e recebe o resultado das operações aritméticas e lógicas.Os registradores B, C, D, E, H e L podem ser usados como registradores de uso geral de 8 bits. Entretanto, algumas instruções permitem tratar estes registradores aos pares (BC, DE e HL) para manipular valores de 16 bits. Como a ALU só consegue manipular 8 bits de cada vez, estas instruções precisam dar duas passadas pela ALU, sendo mais lentas.

Como dito, nas operações aritméticas e lógicas um dos operandos é normalmente o acumulador. O outro é um dos registradores gerais ou a posição de memória apontada pelo par HL. Em outras palavras, o registrador HL é usado principalmente como um ponteiro para a memória (endereçamento indireto).

As instruções que permitem manipular par de registradores como valores de 16 bits são:

• LXI carrega um valor imediado num par de registradores
• XCHG, XTHL trocam o conteúdo de HL respectivamente por DE e pelos dois bytes no topo da pilha
• SPHL carrega SP com o valor em HL
• LHLD carrega HL com o valor em duas posições consecutivas da memória
• SHLD guarda em duas posições consecutivas da memória p valor em HL
• INX e DCX respectivamente incrementam e decrementam um valor em um par de registradores
• DAD soma BC, DE, HL ou SP a HL

O objetivo principal destas instruções é permitir manipular endereços, para implementar ponteiros, arrays e tabelas de desvios.

A rigor podemos dizer que o 8080 não possui nenhum recurso de gerenciamento de memória. O endereço determinado pelas instruções é colocado diretamente nos pinos que endereçam a memória. Não existe nenhum recurso de mapeamento, proteção ou memória virtual.

O CPM/80

O CPM/80 foi o principal sistema operacional para os computadores "sérios" de 8 bits e influenciou diretamente o MSDOS e indiretamente o Windows. (Talvez mereça um post específico no futuro).

Do ponto de vista de gerenciamente de memória, o CP/M80 era muito simples. Os primeiros 256 bytes de memória possuíam uma estrutura fixa, contendo o endereço de chamada ao sistema operacional e a linha de comando usada para executar os aplicativos (no MSDOS, esta estrutura virou o PSP - prefixo de segmento de programa). Os aplicativos em si eram sempre carregados logo em seguida (endereço 0x100); o sistema operacional em si residia no final da memória. Obviamente, o CP/M 80 suporta a execução de apenas um aplicativo de cada vez.

A chamada ao sistema era feito através de uma instrução CALL para o endereço 5. Nesta posição existia um desvio (JMP) para a primeira posição ocupada pelo CP/M, fazendo com que os endereços 6 e 7 indicassem o fim da memória disponível para o programa. Isto permitia criar um primeiro tipo de TSR (terminate and stay resident - programa que fica na memória após ter terminado do ponto de vista do sistema operacional). O programa se copiava para o fim da memória, antes do sistema operacional, colocava um JMP para o SO no seu inicio e alterava o JMP no endereço 5.

Quando armazenados em disco (em arquivos com extensão COM), os programas já estavam com os endereços reais de execução, nenhum tipo de relocação era necessária.

Ultrapassando a barreira dos 64K

De uma forma geral os aplicativos e o CP/M 80 não tinham suporte para nenhum esquema que aumentasse a capacidade de endereçamento do 8080. Este aumento exigia um hardware adicional externo ao processador para selecionar entre diversas regiões de memória que compartilham o mesmo endereço do processador. Esta técnica é chamada de chaveamento de memória.

O chaveamento de memória no CP/M 80 era usado na parte específica do equipamento, já então chamada de BIOS. No mínimo precisa ser usada para a carga do sistema operacional, mapeando uma memória não volátil no endereço zero (onde inicia a execução do 8080 e onde posteriormente é preciso ter RAM). Outra opção comum era "esconder" as rotinas de manipulação do hardware, reduzindo o BIOS e liberando mais memória para o aplicativo.

Outros processadores de 8 bits

Alguns funcionários da Intel saíram para fundar uma nova empresa, a Zilog, que lançou uma versão muito aprimorada do 8080, o Z80. Além de ser mais rápido, o Z80 possuiu várias instruções adicionais, principalmente fornecendo formas mais flexíveis de endereçamento da memória. Entretanto, os recursos de gerenciamento de memória continuaram inexistentes. O CP/M 80 e os aplicativos que rodavam sob ele não usavam as instruções adicionais, tratando o Z80 da mesma forma que um 8080.

Posteriormente a Intel lançou o 8085 que tinha apenas pequenos avanços em relação ao 8080.

Outro processador de 8 bits popular na época era o 6502 (usado no Apple I e Apple II). O conjunto de registradores e instruções do 6502 era completamente diferente, valorizando o acesso indireto à memória. O Apple II usava extensamente a técnica de chaveamento de memória, inicialmente para as rotinas de tratamento das placas nos slots e posteriormente para aumento da capacidade gráfica e da memória disponível.

Pacotes

Uma das tarefas dos protocolos do nível de transporte, como o TCP, é garantir a entrega dos pacotes na ordem em que forem enviados. À primeira vista, isto parece desnecessário. Afinal, como os pacotes podem chegar no destino em ordem diferente da em que foram enviados? A resposta é que numa rede complexa existem vários caminhos entre a origem e o destino e nada obriga pacotes consecutivos a seguir o mesmo caminho.

Embora não tenha chegado ao extremo de chegar fora de ordem, meu último pedido na Amazom mostrou como pacotes consecutivos podem experimentar condições bem diferentes. Como mencionei antes, um dos livros foi enviando em um dia e o resto do pedido no dia seguinte. O livro que veio isolado estabeleceu um novo record, chegando em sete dias corridos. Já o resto do pedido chegou somente ontem (26 dias corridos, o que ainda é um prazo bom para o standard shipping).

Mudança do feed

Aviso aos assinantes (se é que tem algum): o Blogger mudou o endereço do feed para

http://dqsoft.blogspot.com/feeds/posts/full

Programando em C#

Embora eu já tenho obtido a certificação Microsoft em C#, não faz parte do meu dia-a-dia programar em C#. Normalmente programo em C, usando diretamente a API do Windows.

Surgiu agora uma "oportunidade" de mexer numa aplicação Windows em C# (na verdade, a necessidade de fazer os acertos finais em um projeto que eu estava coordenando e outro pessoa estava executando). Seguem algumas observações desta experiência.

Desempenho da IDE e da Aplicação

Um dos receios quanto ao Visual Studio e aplicações gerenciadas é quanto ao desempenho. A minha experiência até o momento foi boa, consigo desenvolver bem em um Pentium 4 2.8 HT, com 512M de Ram, mesmo com o Sql Server rodando na mesma máquina.

A Qualidade do Help

Minha impressão é que ao mesmo tempo que o Help do Visual Studio (MSDN Library) vem aumentado em tamanho (veio em DVD) a qualidade vem caindo. Eu fico lembrando toda hora da velha piada do piloto do helicoptero perdido que recebe a informação de que está... num helicóptero (informação tecnicamente correta e praticamente inútil).

A documentação está muitas vezes restrita ao tipo dos parâmetros (informação já apresentada pelo Intelisense). Alguns "exemplos" não fornecem muita coisa mais. Além disso, tem a mesma informação repetida na mesma página para VB.Net, C#, C++, J# e JScript.

Em comparação, a documentação da API do Windows contém muita informação sobre o quando usar, porque usar, etc.

Acessando Embedded Resources

Embedded Resources são informações, como textos e imagens, que são armazenadas dentro do próprio executável (mais precisamente, no Assembly .Net). No C + Windows API, o uso disto é quase sempre explícito. No .Net, a maior parte do tempo você não se preocupa com isto. Entretanto, se você precisar se preocupar, pode ter surpresas.

Basicamente o que eu precisei era acessar um ícone. Vou começar apresentando a solução:

1. Acrescente o arquivo com o ícone na solução (clique com o botão direito no nome do projeto, selecione Add Existing Item, navegue até o arquivo)
2. Selecione o arquivo e em Properties mude Build Action para Embedded Resource
   
3. No ponto em que você precisar do ícone coloque (supondo que o arquivo foi "Icone.ico")
   

Icon meuIcone = new Icon (GetType(), "Icone.ico")

Parece óbvio, afinal como eu posso ter errado isto? Bem, o help não tinha muita informação além de

public Icon (Type type, string resource);

e os exemplos que eu vi no livro Programming Microsoft Windows Forms e em alguns sites foram

Icon meuIcone = new Icon (GetType(), "Projeto.Icone.ico")

para confundir um pouco mais, embora a linha acima dê erro durante a execução (não acha o resource), se você examinar o Assembly com o MSIL Disassembler, vai ver que o ícone está lá e com o nome "Projeto.Icone.ico".

O que ocorre (e eu só achei no adendo do post de um blog) é que na hora de procurar o resource o namespace da classe do primeiro parâmetro é colocado automaticamente na frente do nome informado no segundo parâmetro. E o nome do resource no assembly é feito colocando o namespace default na frente do nome do arquivo. No meu caso, os namespaces eram os mesmos, e acabava sendo procurado Projeto.Projeto.Icone.ico ao invés de Projeto.Icone.ico.

Se você criar uma pasta no projeto para os seus ícones, por exemplo Icones, o nome do resource vai ficar Projeto.Icones.Icone.ico e portanto de ser usado

Icon meuIcone = new Icon (GetType(), "Icones.Icone.ico")

Depois que a gente entende, fica fácil...

Novo record da Amazon

No dia 30/8 (uma semana atrás) coloquei um pedido na Amazon. Entre os livros, um deles tinha data prevista de publicação 4/9; a minha grande preocupação era a Amazon não quebrar obrigatoriamente o pedido em dois, aumentando o custo do correio. Felizmente ela aceitou automaticamente o pedido de enviar tudo em uma única remessa, inclusive avisando que o despacho seria atrasado pelo livro que ainda não tinha saído.

Para minha surpresa, no dia seguinte (31/8) veio um email avisando que parte do pedido estava sendo mandado na frente (sem custo adicional): o livro ainda não lançado! O resto saiu no dia seguinte.

Hoje, 6/9, sete dias corridos após o pedido, o livro chegou! Não deu nem tempo de ficar com inveja dos fãs americanos que correram para comprar o livro na segunda feira. E olha que eu usei a opção mais barata de correio.

O único porém fica para o carteiro, que simplesmente largou a caixa na entrada; mesmo supondo que não tenhamos ouvido a campainha seria de esperar que ele fizesse questão de entregar em mãos a alguém.

Migração para Blogger Beta

Migrei o blog para o Bloger Beta para poder colocar labels nos post. Vamos torcer para não ter nenhum bug catastrófico!

Turbo Explorer

A Borland lançou ontem a linha Turbo, composta por versões Professional e Explorer do Turbo C++, Turbo Delphi, Turbo Delphi p/ .Net e Turbo C#.

As versões Explorer são gratuitas, download em:
http://www.borland.com/downloads/download_turbo.html

A PC Magazine já publicou um artigo sobre o Turbo Delphi Explorer. Apesar do preço (grátis) e de ser um produto bastante completo e atualizado, já existem algumas pessoas examinando os dentes do cavalo dado:

• Mesmo os produtos não .Net precisam ter o .Net Framework 1.1 instalado (para a IDE não para o executável gerado)
• É preciso ter o IE atualizado e o MSXML mais recente
• Só é possível instalar um produto Turbo Explorer na máquina; também não convive com o produto completo (Borland Developer Studio)
• Não vai ter versão Linux
• Os downloads são grandes

Lista: Nove Séries de Detetives

Para quem não viu ou não lembra, minhas regras para listas estão aqui. Neste caso, preferi listar os personagens e não livros específicos.

• Perry Mason: pouco conhecido aqui no Brasil, é um ícone nos EUA (pela proximidade geográfica, foi até mencionado no Chaves!). Perry Mason é o advogado detetive, que sempre tira um coelho da cartola nos capítulos finais, para desespero dos promotores e policiais que pensavam ter pegado o culpado. O autor (Erle Stanley Gardner) produziu dezenas de livros, o que complicou bastante o trabalho do meu pai de juntar todos eles (o que só conlcuiu com auxílio da Amazon).

• Hercule Poirot: o belga de cabeça de ovo criado por Agatha Christie. Embora eu tenha praticamente todos os livros, considero que eles se baseiam demais em truques da autora e não tem a mesma profundidade de outros desta lista. Um leitura divertida, de qualquer forma.
  

• Sherlock Holmes: criação de Conan Doyle é provavelmente o detetive mais conhecido do mundo, embora em desconfie que poucos leram os livros. Para quem ainda não leu, recomendo os que tem estórias curtas; os mais longos às vezes tem vários capítulos de romance não detetivesco (e talvez monótono)- vide a segunda parte de "Um Estudo em Vermelho". Nas histórias mais curtas brilham a inteligência do detetive e as situações fantásticas. Como os livros já estão no domínio público é fácil encontrar edições a preços baixos (quem preferir pode baixar do Projeto Gutemberg).

• Maigret: já escrevi sobre ele antes. Criação de Georges Simenon, as estórias normalmente culminam com a revelação de uma trama sórdida.

• Nero Wolfe: nas estórias escritas por Rex Stout, o caminho se sobrepõe ao destino. Embora exista um mistério, o que fascina é a interação entre os personagens. Nero Wolfe, nas suas próprias palavras, é apenas um gênio. Sua paixões são as orquídeas e a boa comida (aliás, ele pesa um sexto de tonelada). Para sustentá-las, resolve mistérios por preços altíssimos. Possui várias excentricidades, tornadas ainda mais fortes pelas excessões que ocasionalmente permite. É auxiliado por Archie Goodman, um detetive de porte mais tradicional, que tem entre as suas funções atormentar Wolfe para que ele trabalhe. Completam ainda o "cast" fixo o cozinheiro Fritz Brenner, os detetives free-lance Saul Panzer, Fred Durkin e Orrie Cather, a namorada de Archie (Lily Rowan e o inspetor de polícia Cramer.

• Philip Marlowe: imortalizado nas telas por Humphrey Bogart, o detetive criado por Raymond Chandler define (juntamente com Sam Spade do Falcão Maltês) e estilo noir. O detetive durão (mas de coração mole) faz piadas o tempo todo enquanto está perdido em meio a tramas complicadas e repletas de reviravoltas. Chandler possui um estilo todo especial de escrever, particularmente nas descrições e adjetivos. Pena que deixou tão poucos livros.

• Ellery Queen: já houve época em que este nome era sinônimo de mistério. Ellery Queen é ao mesmo tempo personagem (em alguns do dos livros) e autor (na verdade, era pseudônimo de dois primos, segredo este mantido por muito tempo). Suas histórias são bastante intensas e cheias de reviravoltas. Meus prediletos são os que tem Ellery também como personagem.

• Streeter: alguns anos atrás, procurando algo novo para ler, fui atraído pelas capas destes livros de Michel Stone, imitando os antigos pulps. São estórias no estilo noir porém ambientadas em tempos mais recentes e com techos muito criativos. Infelizmente os livros estão atualmente esgotados e parece que o autor parou após o quarto (eu só tenho dois deles).

• Inspector West: um detetive criado por John Creasey, com uma visão bem britânica. Destaco o livro A Gun for Inspector West, no qual o inspetor West se indigna com a sugestão de seus superiores de que ele passe a andar armado devido aos ataques de uma gangue violenta.
  

Livro do Mês Passado - Software Estimation

Steve McConnell é autor dos conhecidos livros Code Complete (que ainda não li) e Rapid Develpment (que li e recomendo).

Neste seu mais novo livro Software Estimation: Demystifying the Black Art (lançado agora em 2006) ele aborda a arte de estimar tamanho, esforço e prazo de projetos de software.

É um livro relativamente pequeno, cerca de 300 páginas, dividido em capítulos curtos, ideal para ler aos poucos. O livro é impresso em duas cores (preto e azul), o que é muito bem aproveitado nas tabelas, gráficos e figuras. Espero que a Microsoft Press utilize com mais frequência este tipo de recurso.

Além da experiência própria do autor (que fornece consultoria no assunto e desenvolveu um software para fazer estimativas), o livro utiliza uma quantidade imensa de dados reais coletados por diversos pesquisadores. Embora a maior parte das técnicas seja voltada para projetos de porte médio a grande, muito pode ser também aproveitado para projetos pequenos.

A utilidade deste livro não está limitada às pessoas cuja função é estimar software. O entendimento dos conceitos de estimativa pode reduzir o stress normalmente associado às estimativas e ao próprio desenvolvimento de software.

O livro está dividido em três partes:

• Conceitos Críticos
• Técnicas Fundamentais
• Desafios Específicos

Ao longo do livro são apresentadas 118 "dicas" (eu não contei, elas são reproduzidas em destaque no final do livro). Reproduzo algumas abaixo:

• Diferencie estimativas, alvos e compromissos. [Uma estimativa é um resultado obtido por uma avaliação, um alvo é um resultado desejado e um compromisso é um resultado acordado entre os envolvidos.]
• Quando uma estimativa é fornecida como um valor único (ao invés de uma faixa) existe implicitamente uma probabilidade associada.
• A penalidade para estimar para baixo é normalmente maior que estimar para cima. [Intuitivamente achamos que é o contrário]
• Existe um "Cone de Incerteza": á medida que um projeto avança, as estimativas podem ser mais precisas (desde que o projeto esteja sendo gerenciado adequadamente). [É tolice querer ser mais preciso que o estágio do projeto permite. Se o projeto não convergir, as estimativas não vão convergir - isto é um problema de gerenciamento e não de estimativa]
• Não dê estimativas de "bate-pronto". [Pensar um pouco, mesmo que alguns minutos, vai gerar uma estimativa mais precisa]
• O número de dígitos significativos e a unidade usada da estimativa deve ser compatível com a sua precisão. [Por exemplo, considere a diferença entre dizer 2 dias e dizer 16 horas]
• O tamanho do software é o fator mais significativo (mas não o único) na determinação do esforço e prazo.
• O esforço não cresce linearmente com o tamanho.
• As técnicas de estimativa devem ser escolhidas em função do que você quer estimar, o tamanho do projeto, o estágio do desenvolvimento, o estilo do desenvolvimento (interativo ou sequencial) e a precisão desejada.
• Contar quando possível. Se não for possível contar, calcular. Somente em último caso opinar. Não usar a opinião de especialistas para ajustar estimativas obtidas por cálculos.
• Guarde dados históricos dos projetos. A performance passada é o melhor indicador da performance futura. [Como otimistas, achamos sempre que os problemas anteriores não vão se repetir]
• Não discuta o resultado de uma estimativa [feita com método]. Mude o resultado somente alterando as entradas e recalculando.

Resumindo, altamente recomendado.

DVD: O Retângulo Negro

Esta semana comprei um filme em DVD e tive o maior susto quando fui assistir: de tempos em tempos (aleatoreamente) aparecia um retângulo preto no meio da tela, escondendo a maior parte da imagem.

Após experimentar todas as opções do aparelho de DVD, tentei com outro filme - e o problema continuou. Tentei o velho truque do "desce todo mundo/ sobe todo mundo" (reset geral - desligar da tomada, aguardar um tempo e ligar de novo) - e nada. Resolvi tentar ver o filme no micro: funcionou direitinho.

A cada tentativa o pânico aumentava. Cheguei a abrir o aparelho para ver se tinha algo de estranho (só o que o peso já indicava: tem quase nada dentro). Será que o filme (original!) tinha conseguido de alguma forma bagunçar o aparelho?

Como última opção (sem muita esperança) resolvi apelar para "São Google". Uma busca pelo meu modelo só trouxe anuncios e algumas procuras por senha para destravar a região. Por último, uma busca por "dvd black rectangle" e o santo fez o milagre:

http://club.cdfreaks.com/showthread.php?t=152593

Por incrível que pareça, o problema estava na TV: estava ligado um close caption estranho. Dois toques no controle da TV e tudo resolvido.

A volta do Turboman

Algum tempo atrás, comentando a decisão da Borland de sair do mercado de ambientes de desenvolvimento, eu ilustrei o post com um anúncio da Borland dos anos 80, usando o personagem Turboman. Para meu espanto, a Borland deu uma nova guinada e está ressucitando a linha Turbo e o Turboman.

Mas Que Diabos?

Nos últimos meses passei a acessar diariamente o site The Daily WTF (que traduzo candidamente como "O Mas Que Diabos Diário"). Este site traz relatos (supostamente todos reais) de coisas absurdas feitas por desenvolvedores.

Já vi uma razoável quantidade destas coisas (em situações absolutamente reais); não é incomum eu ficar resmungando quando estou dando manutenção ou tentando reaproveitar um pedaço de código. Por outro lado, não penso em enviar uma contribuição para o site. Acontece que quase todas as vezes eu conheci e convivi com o desenvolvedor responsável pelo WFT. Pessoas muito legais, esforçadas e que certamente não são idiotas.

Da mesma forma como relatado no site, os trechos ofensivos já tinham chegado nas mãos de clientes e muitas vezes já estavam em produção. O que traz a questão: porque estas coisas são feitas e porque demoram a ser detectadas?

Percebe-se sempre nos WTFs a falta do domínio de um conceito básico pelo desenvolvedor. Isto vem de diversas situações:

• O desenvolvedor está usando uma tecnologia que ele nunca estudou. O principal motivo é um otimismo tanto do desenvolvedor quanto do seu chefe de que a tecnologia será aprendida rapidamente, sem esforço e pelo simples uso. Muitas vezes o próprio desconhecimento da tecnologia impede de perceber que algo está sendo feito de errado (vide voodoo cargo cult).

• O desenvolvedor estudou a tecnologia mas não aprendeu. Fazendo um pegunta politicamente incorreta: será que qualquer um pode aprender a programar? É claro que é mais bonito pensar que todos podem fazer tudo, bastando estudo, prática e afinco. Entretanto, todos nós admitimos excessões em coisas como artes e esportes (ou alguém acha que qualquer um pode aprender a jogar como o Ronaldinho ou tocar guitarra como o Jimmy Page?). Será que aprender a programar exige alguma pré-disposição genética, com os neurônios interligados de uma certa forma? Eu certamente não sei a resposta. O fato é que existem muitas pessoas que estudaram programação, inclusive formalmente, atuam na área há anos e ainda tem falhas básicas de formação.

• O desenvolvedor abusou da abstração. Com freqüência se menciona a idéia de que rotinas, módulos e componentes devem ser usados como "caixas pretas", sem conhecimento do seu interior. Isto não significa que as suas características e limites não precisem ser bem conhecidos.

• Abuso do cut-and-paste (a rigor é a mesma coisa do item anterior). Cada vez mais, o desenvolvedor que não sabe algo faz uma busca na internet, à procura de código pronto (e não de uma explicação que permite ele mesmo escrever o código). É claro que a internet está cheia de besteiras. Mesmo que se ache algo correto, basta tirá-lo do contexto para causar desastres.

O passo seguinte é uma combinação perversa de garra, iniciativa e imaginação, que resulta nas mais absurdas soluções para o problema. Os WTFs são normalmente trechos longos e trabalhosos de código. Não se trata de pregiça mental ou braçal.

A questão seguinte é como esta pessoa foi alocada para um projeto para o qual não está preparada? A resposta é um excesso de otimismo generalizado, somado à dificuldade das pessoas em admitir suas limitações.

E como os WTFs não são detectados durante os desenvolvimentos?

Examinando apenas externamente, os softwares WTF funcionam pelo menos nas situações mais simples. Grande parte do esforço na geração dos WTFs vem justamente de martelar uma idéia errada até que o software consiga passar pelos testes. Frequentemente os testes são fracos e não existe muito rigor no processo de verificação. Muitas vezes o testador se concentra em um único aspecto e não tem nenhuma postura crítica com relação aos demais. Se os testes forem feitos pelo próprio desenvolvedor, estão contaminados desde o começo. Se os testes são feitos por outra pessoa, frequentemente ela se sente constrangida em relatar defeitos.

Uma forma mais efetiva seria a revisão de código. A maioria dos desenvolvedores se sente meio ultrajada em passar o código para outro verificar ("não confiam em mim"). Quem verifica pode não dar importância para tarefa ou se sentir constrangido em apontar defeitos.

A tudo isto soma-se uma falta de paciência (ou capacidade) do supervisor técnico para acompanhar os detalhes do desenvolvimento.

Uma vez chegando ao usuário, é comum uma certa complacência, baseada em padrões muito baixos ou mesmo a ausência deles. É comum ouvir coisas de usuários expressões como "é, isto nunca funcionou" ou "é lento mesmo" ou ainda "de vez enquando trava, mas fazendo de novo normalmente vai".

Em posts futuros vou tentar dar alguns conselhos para desenvolvedores sobre como evitar cirar WTFs.

Lista: Quatro Livros de Engenharia de Software

Para quem não viu ou não lembra, minhas regras para listas estão aqui.

Os livros listados abaixo discutem a atividade de desenvolvimento de software, apresentando filosofias, dicas e técnicas para ser um desenvolvedor melhor e mais feliz. Para ler e praticar!

• The Mythical Man Month, Fred Brooks - Escrito há três décadas, por uma pessoa que gerenciou o desenvolvimento de sistema operacional para mainframe (OS/360), muito deste livro continua se aplicando ao dia-a-dia do gerenciamento de desenvolvimento de software. Continua sendo verdade que ao se colocar mais pessoas em um projeto atrasado a tendência é o projeto atrasar mais e nenhuma metodologia ou ferramento é a bala mágica (silver bullet) capaz de reduzir esforçoes de uma ordem de grandeza (de anos para meses, por exemplo). Um livro mais conceitual, não atrelado a nenhuma linguagem ou ambiente.

• The Pragmatic Programmer, Andrew Hunt & David Thomas: Um livro repleto de filosofias e dicas práticas.

• The Practice of Programming, Brian Kernighan e Rob Pike: Mais voltado aos detalhes do desenvolvimento em si, contém dicas práticas para o desenvolvimento de software, com exemplos em C, C++ e Java.
  

• Rapid Development, Steve McConnel: Um tratado bastante completo sobre como evitar que um projeto vire um martírio. Muito bem organizado e recheado de estatísticas sobre projetos reais.

"CAPTCHA" nos comentário

Após a terceira visita de bots pelo blog, estou ligando esta chata opção. Vamos ver qual o resultado.

Lista: Sete Livros Juvenis

Existe uma estranha atração das pessoas por listas, tanto para ler como para escrever.

Este post traz a primeira do que pretendo ser várias listas. Adotei algumas regras para esta lista, que pretendo seguir nas próximas:

• Não parti de um número pré-definido de itens
• A lista não é dos melhores, maiores ou coisa parecida, é uma lista dos itens relevantes que me lembrei
• Não numerei nem ordenei os itens dentro da lista
• Coloquei apenas uma obra de cada autor. Alguns dos itens fazem parte de coleções (ou pelo menos são apenas uma dentre várias obras do autor que pertencem ao mesmo gênero).
• Não coloquei os tradicionais links para Amazon ou outras livrarias

Sete Livros Juvenis

Para os fins desta lista estou considerando "livro juvenil" um livro clássico (ou perto disso) que li quando estava no ginásio ou colégio.

• O Filho de Tarzan, Edgar Rice Burroughs: Os livros de Tarzan fizeram parte da minha infância, eu adorava lê-los no alto de uma árvore. Além dos exemplares que a minha mãe comprava, tinha também alguns volumes antigos de um primo do meu pai (ambos da mesma coleção, Terramarear). Minha mãe se desesperava com a possibilidade de eu aprender português errado por causa da ortografia nos livros antigos (perda de tempo, já que a ortografia mudou de novo pouco depois que eu me alfabetizei). Apesar dos recentes desenhos animados da Disney, as obras não estão disponíveis em português. Por outro lado, os primeiros livros em inglês já estão no dominio público e podem ser encontrados no Projeto Gutemberg.

• O Mistério da Ilha da Cabana, Franklin W Dixon: A coleção Hardy Boys é uma tradição americana. Conheci quando a Abril publicou no começo dos anos 70, no começo não gostei muito, mas no terceiro livro já estava viciado. Após o fim da publicação pela editora Abril (no volume 18), descobri que a coleção americana tinha mais de 50 livros, que fui comprando aos poucos (livro importado era difícl de achar e caro nos anos 70 e 80). Somente com a Internet fiquei sabendo como o Franklin W Dixon escreve livros de 1927 até os dias de hoje e o porque de alguns livros antigos (comprados em vendas de garagem) tinham o texto tão diferente. Aliás, quem se aventurar a comprar na Amazon tem a opção de comprar os livros com o texto original (publicados pela Applewood books).

• A Ilha Misteriosa, Jules Verne: Meu pai sempre foi um grande fã de Jules Verne. Por coincidência, o que considero o meu primeiro livro foi uma versão da Disney de 20000 Léguas Submarinas (convenci a minha mãe a comprar no supermercado, foi complicado pois não tinha preço e naquele tempo ainda não tinha computador nas lojas). Posteriormente meu pai comprava de tempos em tempos um volume de uma coleção portuguesa (para mais desespero da minha mãe). Embora os livros mais famosos do Jules Verne sejam Da Terra a Lua (que eu achei muito chato) e Viagem ao Centro da Terra (divertido), o meu predileto é A Ilha Misteriosa, com o relato de um bando de náufragos sobrevivendo em uma ilha com a ajuda da ciência e um benfeitor misterioso. Também disponível no Projeto Gutemberg.

• O Médico e o Monstro, R. L. Stevenson: Um dos primeiros livros que eu peguei na biblioteca do ginásio. Também disponível no Projeto Gutemberg.

• Um Estudo em Vermelho, Conan Doyle: O primeiro livro do Sherlock Homes. Outro que eu peguei na biblioteca do ginásio e também disponível no Projeto Gutemberg.

• Reinações de Narizinho, Monteiro Lobato: outra coleção que meu pai foi comprando aos poucos.

• As Minas do Rei Salomão, Rider Haggard: Este eu peguei emprestado na casa de um visinho, também estava com ortográfia muito antiga; minha mãe comprou correndo uma versão mais nova. Este exemplar sumiu, mas comprei alguns anos atrás um novo da coleção L&PM Pocket (que você acha até em bancas de jornal). Era a mesma tradução de Eça de Queiroz "que muito consideram superior ao original" (destaque na capa). Disponível no Projeto Gutemberg (o original, não a tradução).

Certificação Microsoft

Na minha opinião, os envolvidos com informática se dividem em dois grupos quando o assunto é certificação Microsoft. Existe uma minoria que tem experiência própria com isto e fala siglas estranhas como MCSE, MCAD, MCP e menciona o tempo todos números cabalísticos como 70-290 e 70-316. E existe a grande maioria que vive feliz ignorando tudo isto. O objetivo deste post é estragar a felicidade desde segundo grupo :)

As descrições abaixo podem conter erros ou ficarem desatualizadas, a página da Microsoft sobre certificação é www.microsoft.com/learning (pelo menos atualmente).

Como se obtem uma Certificação Microsoft

Com um exceção recente, as certificações Microsoft são obtidas passando em exames. Os exames são realizados em micros e, em grande parte, são compostos de questões de múltipla escolha. Não existe nenhum pré-requisito (curso, anos de experiência comprovada, etc); qualquer um pode fazer um exame e, se atingir a nota mínima, está aprovado.

Os exames são desenvolvidos pela Microsoft, porém a aplicação dos exames é feita por duas empresas americanas, a Pearson Vue e a Prometric. Estas empresas, por sua vez, credenciam centenas (milhares?) de centros de teste espalhados pelo globo. Atualmente os exames custam US$80, existem com frequência promoções envolvendo vales (vouchers) que cobrem parte ou todo o custo.

Ao passar no primeiro exame você se torna um MCP (Microsoft Certified Professional). Outros títulos são obtidos passando em combinações de provas.

O que você ganha sendo certificado

Fama, fortuna, mulheres lindas (ou homens lindos, se for o caso) - se você quer tudo isto é melhor tratar de aprender a jogar bola (ou a desfilar na passarela no cado das mulheres).

Para você mesmo, você poderá ganhar um pouco de auto-confiança. Para aquela minoria que conhece o assunto, você ganhará algum respeito pois eles sabem das dificuldades para obter uma certificação. O resto do mundo não vai saber exatamente do que se trata e, na sua maioria, vai ser indiferente.

A Microsoft envia um certificado, um broche e um cartão de identificação a cada certificação obtida (não a cada prova), mas você tem que solicitar. Você pode emoldurar o certificado e colocar sobre a mesa (no mínimo a assinatura impressa do Bill Gates vai chamar a atenção). Já experimentei usar o broche em eventos da Microsoft, ninguém prestou atenção. O cartão eu usei como fundo em uma das fotos deste blog (o primeiro uso prático que encontrei).

Nos eventos anuais da Microsoft é comum darem um brinde para os certificados.

Como se preparar para um exame

Ao contrário do que alguns imaginam, experiência profissional com a matéria de um exame não é condição necessária nem suficiente para passar. É perfeitamente possível estudar um assunto que não faça parte do seu dia-a-dia e passar no exame. No meu caso, uso os exames exatamente para me obrigar a estudar aquilo que não uso nem conheço. Por outro lado, uma característica dos exames é ser bastante abrangente enquanto que no trabalho a gente tende a se concentrar em uma faixa estreita.

Isto não significa que a experiência não seja útil, muito menos que o estudo não deva incluir uma parte prática.

Existem diversas formas de estudar para um exame, cada pessoa obtem melhores resultados com uma determinada combinação. As maneiras principais são cursos, livros, simulados e a prática.

Existem cursos voltados diretamente para a preparação aos exames e cursos mais gerais. Em algum ponto entre eles estão os cursos com material oficial da Microsoft (MOC - Microsoft Official Curriculum).

Da mesma forma, existem livros específicos para preparação, inclusive da Microsoft Press. Com uma exceção, usei sempre este tipo de livro como roteiro de estudo, complementando com informações obtidas na internet e livros sobre temas específicos (os bons livros de preparação costumam conter uma bibliografia no final de cada capítulo). Os livros de preparação se concentram na matéria que cai no exame e são bem resumidos, porém (pelo menos os bons) costumam conter também informações úteis para o dia-a-dia.

Várias empresas (como Transcender, ...) comercializam exames simulados, O custo destes simulados é relativamente alto; a única ocasião em que adquiri um foi para o meu primeiro exame de Análise de Requisitos e Definição de Arquiteturas, para me acostumar com o formato das questões. Felizmente as empresas costumam disponibilizar versões demo dos simulados (com poucas questões); vários livros de estudo vem com estas versões. Algumas empresas oferecem simulados com "questões reais de prova", existem questões legais e morais envolvidas (ver braindumps adiante).

Uma forma bastante eficiente de fixar o estudo é através da prática. Muitos livros de estudo contem exercícios práticos descritos passo a passo. Para fazer estes exercícios você vai precisar do produto, se não der para comprá-lo veja se não está disponível uma versão trial.

As Certificações de Desenvolvimento

Quando comecei a me interessar por certificação, a certificação para desenvolvedores era a MCSD (Microsoft Certified Software Developer), retroativamente chamada de MCSD Visual Studio 6. Para obter esta certificação eram necessários 4 exames: um de Análise de Requisitos e Definição de Arquiteturas, um de Desenvolvimento de Aplicação Desktop (com opções de Visual C++, Visual Basic e Visual FoxPro), um de Desenvolvimento de Aplicação Distribuida (também com opções de Visual C++, Visual Basic e Visual FoxPro) e um exame "eletivo" (escolhido livremente em uma lista de cerca de meia dúzia de exames). No meu caso fiz o exame de aplicação desktop para Visual C++, o de aplicação distribuida para Visual Basic e como eletivo o Projeto e Implementação de Base de dados com o SQL Server 2000.

Com o lançamento do .Net, a Microsoft criou duas novas certificações: MCAD (Microsoft Certified Application Developer) e MCSD .Net. Para ser um MCAD são precisos 3 exames: um exame de desenvolvimento de Web Services e Server Components (em C# ou VB.Net), um exame de Desenvolvimento de Aplicações (Windows ou Web, em C# ou VB.Net, num total de quatro opções) e um exame eletivo (com várias opções). Para ser um MCSD .Net são precisos 5 exames: um de Análise de Requisitos e Definição de Arquiteturas, um exame de Desenvolvimento de Web Services e Server Components (em C# ou VB.Net), um exame de Desenvolvimento de Aplicações Windows (em C# ou VB.Net), um exame de desenvolvimento de aplicações Web (em C# ou VB.Net) e um exame eletivo. No meu caso aproveitei o eletivo do MCSD VS6 e fiz os demais exames em C#. O lançamento do Visual Studio 2003 não afetou as certificações nem, até onde sei, os exames.

No final de 2005, junto com o lançamento do Visual Studio 2005, a Microsoft anunciou uma mudança profunda nas certificações. Foi criado o MCTS (Microsoft Certified Technology Specialist), com três credenciais para desenvolvedor, relativas a aplicações Web, Windows e Distribuídas. Cada uma destas credenciais requer apenas 2 exames, um igual para todas (Application Development Foundation) e outro específico. No início dos exames específicos deve-se escolher a linguagem de programação: C#, VB.Net ou C++ (somente para o exame de aplicações Windows). Além do MCTS, foi criado o Microsoft Certified Professional Developer: Enterprise Applications Developer. Para ser um MCPD:EAD é preciso passar nos 4 exames de MCTS e mais o exame Designing and Developing Enterprise Applications. Quem já é MCSD .Net pode obter o MCPD:EAD passando em dois exames de atualização.

Braindumps e Outras Robalheiras

Uma discussão sobre certificação não seria completa sem tocar neste assunto espinhoso (que muita gente prefere ignorar). No início de cada exame o candidato assina um termo de sigilo; a Microsoft protege as questões de prova também por copyright e como segredo industrial. Eventual material de rascunho usado durante a prova deve ser deixado no centro de teste.

Tudo isto não impede que algumas pessoas registrem em sites as suas recordações das questões de prova, gerando os chamados braindumps. Um outro candidato pode então decorar as perguntas e respostas e com isto passar no exame sem saber nada (supondo que o número de variações de perguntas seja baixo frente ao número de braindumpers).

Algumas pessoas são ainda mais preguiçosas e se limitam a falsificar o certificado (ou simplesmente colocar no currículo certificações que não possui).

Isto serve também de materia prima para espertalhões, que revendem os braindumps como material de estudo ou simulados ou até mesmo oferecem certificados falsos.

Como já disse em outra ocasião, tudo isto é imoral e ilegal.

19/out/07: pequenos acertos no texto.

Bugs Estranhos: INTERNAL COMPILER ERROR

O que você faz quando, ao corrigir o último erro de sintaxe em um programa C++, o Visual C++ v6 apresenta a mensagem

G:\Projetos\TOL\CColRF\CColRf.cpp(41) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'E:\8966\vc98\p2\src\P2\p2symtab.c', line 932)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information

E uma busca no google devolve um post em um forum de VB?

Felizmente o google achou uma resposta em lugar também improvável: uma lista de discussão do Samba.

Por incrível que parece, o problema todo é que estava compilando diretamente sobre a rede. Para resolver, bastou copiar tudo para uma unidade local.

E para quem está curioso, o VB utiliza (discretamente) o compilador do Visual C++ para gerar código executável.

Figurinhas e o Paradoxo dos Aniversários

Outro dia eu comprei alguns pacotes de figurinhas para a minha sobrinha e estávamos reclamando da quantidade de repetidas quando percebi que estava vendo uma manifestação do "paradoxo dos aniversários".

Para quem não conhece, este é um problema clássico de estatística: o professor pergunta para uma turma de 30 alunos se eles acham provável que pelo menos dois deles façam aniversário no mesmo dia. Os alunos acham que é improvável, o professor pergunta as datas de aniversário de cada um e, para surpresa dos alunos, encontra dois que fazem anversário no mesmo dia.

O "paradoxo" surge pelo fato de cada aluno pensar na probabilidade de algum dos outros fazer aniversário no mesmo dia que ele (29/365 = 8% *).

Este é daqueles problemas de estatística que se resolve mais facilmente calculando a probabilidade da negação. No caso, a probabilidade de 30 pessoas terem datas de aniversário distintas.

Para a primeira pessoa, a probabilidade é um. Para a segunda pessoa, a probabilidade é 364/365. Para a terceira pessoa é 363/365, múltiplicado pela probabilidade das duas anteriores não fazerem aniversário no mesmo dia (pois queremos que as duas coisas aconteçam simultaneamente), ou seja 364/365 * 363/365. Analogamente, para a quarta pessoa teremos (364*363*362)/(365*365*365). Para trinta pessoas o resultado é aproximadamente 0,29 (29%). Daí se conclui que a probabilidade de pelo menos duas pessoas em um grupo de 30 fazerem aniversário no mesmo dia é de 70%.

E as figurinhas? O album em questão tem 240 figurinhas e cada pacote vem com quatro. Isto resulta nas seguintes probabilidades de termos pelo menos uma figurinha repetida:

1 pacote = 2%
2 pacotes = 11%
3 pacotes = 24%
4 pacotes = 40%
5 pacotes = 55%
6 pacotes = 69%
7 pacotes = 80%
8 pacotes = 88%
9 pacotes = 93%
10 pacotes = 96%

Não é muito animador, certo?

* Estou desconsiderando o 29/fev. Fica como exercício para o leitor corrigir as probabilidades considerando os anos bissextos.

Dica Doméstica: Descongelamento

Quando a minha esposa vai no açogue costuma pedir para embalar a carne em separada em porções mais ou menos diárias. Ao chegar em casa vai tudo para o congelador.

Muito prático mas cria o problema de descongelar. Normalmente o que ela fazia era colocar em um prato fora da geladeira. Após várias hora ainda estava congelado e ela acabava apelando para o micro-ondas, o que acabava deixando as pontas cozidas.

Felizmente achei uma dica em um livro de culinária americano: coloque o produto a descongelar (fechado hermeticamente em um saco plástico, com o mínimo de ar possível) em uma vasilha grande com água a temperatura ambiente. Após algum tempo troque a água. Os resultados são excelentes.

Um comentário de engenheiro filho de físico: o segredo é que o ar é mau condutor de calor e a água é bom.

Yes, nós temos livrarias II: A Traça

Procurando na Internet informações sobre um livro obscuro que li quando criança, o Google retornou um link para A Traça.

É um simpátivo "sebo virtual" e a experiência de compra foi ótima: imediatamente após colocar o pedido (às 9:07) veio um e-mail confirmando o recebimento do pedido. Pouco depois (12:28) veio a informação de que o livro estava localizado e o débito no cartão tinha sido feito. No final da tarde (18:32), e-mail avisando que o livro tinha sido encaminhado ao correio. Na manhã seguinte (11:00) o Sedex estava sendo entregue. Detalhe: a Traça fica em Porto Alegre e aqui é São Paulo. O Correio foi tão rápido que o livro chegou antes do e-mail informando o identificador do objeto.

World eBook Fair - OnLine

Já está no ar o site do World eBook Fair, porém o acesso está bastante lento.

Em uma olhada rápida, já achei um livro curioso (que eu li anos atrás): Fallen Angels de Larry Niven, Jerry Pournelle e Michael Flynn. É uma sátira à onda anti-ciência que assola o mundo. Num futuro não muito distante, a raça humana se dividiu em dois grupos. A superfície da Terra é controlada por um governo "verde" totalitarista obrigando os que crêem na ciência a morar em estações espaciais. Dois destes astronautas caem na Terra e são salvos pela última resistência pró-tecnologia: os fãs de ficção científica. O livro é repleto de piadas e referências a episódios reais do mundo dos fãs. Uma leitura divertida, mas não para ser levada a sério.

World eBook Fair

Para quem não conhece, o Projeto Gutenberg reune textos que estão no domínio público (na sua maioria) e foram digitados por voluntários.

Comemorando o seu 35o (!) aniversário, está sendo organizado o World eBook Fair. De 4 de julho a 4 de agosto mais de 300.000 eBooks estarão disponíveis para download gratuito. Além dos eBooks do projeto Gutenberg (que já são e continuarão sendo gratuitos), outras editoras estarão disponibilizando obras, como a Baen Books. A previsão é repetir o evento nos próximos anos, aumentando a quantidade de obras a cada ano.

NCSD.Net - Oficialmente

Novamente demorou somente 2 dias para o resultado do exame chegar à Microsoft. Já solicitei o "Welcome Kit" (certificado, cartão e broche) .

MCSD.Net

Passei hoje na prova que faltava para ser um Microsoft Certified Software Developper for Microsoft .Net. A prova foi "Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET". Acabei não estudando muito devido ao curto tempo desde a prova anterior, um acúmulo de serviço e, principalmente, uma gripe irritante. Felizmente grande parte da matéria também fazia parte das provas anteriores. O resultado não foi brilhante, mas bem satisfatório (e mais que suficiente para a aprovação).

Próximos exames de certificação (upgrade para MCPD) só daqui a alguns meses. A família agradece...

MCAD - Oficialmente

Desta vez as coisas funcionaram rápido e o resultado do exame que eu fiz dois dias atrás já chegou na Microsoft (teoricamente poderia demorar até duas semanas e no exame anterior demorou três).

Agora só falta receber o diploma pelo correio.

C# x VB.Net

Estou estudando para a prova de desenvolvimento de aplicações Windows pelo Self-Paced Training Kit da Microsoft, primeira edição. Não é um bom livro (mais sobre isto adiante), mas tem a curiosidade de abordar simultaneamente C# e VB.Net.

É claro que a maior parte de programação .Net consiste em usar as classes do .Net Framework, que são as mesmas para as duas linguagens. Entretanto, mesmo as construções normais das linguagens são quase idênticas, recursos que existem somente em uma delas são raras excessões. A diferença fica na somente sintaxe. Dada a minha vivência com C, não é surpresa que eu ache a sintaxe do VB.Net esquisita, particularmente o uso do fim de linha como terminador de comando.

O mais curioso foi que recentemente perguntei a um desenvolvedor que usa o VB.Net no dia a dia porque ele preferiu VB .Net a C# e a resposta foi que o C# oferece mais controle, sendo mais adequado para o desenvolvemento de componentes, porém o VB.Net tem maior produtividade, permitindo fazer mais coisas com menos linhas de código. Acredito que seja a manifestação de um efeito relatado no clássico The Hidden Persuaders, um livro da década de 50 sobre o marketing científico. Um fabricante de sabão em pó colocou o mesmo produto em duas embalagens, uma em suaves tons de azul e outra em um violento vermelho, e entregou para várias donas de casa testarem. Ao final do teste, quem recebeu a caixa azul disse que o produto era excelente, porém não tinha força suficiente para tirar as manchas mais pesadas. Já quem recebeu a caixa vermelha disse que o produto excelente, mas que não devia ser usado com roupas frágeis pois era muito forte!

Voltando ao livro, ele possui uma grande quantidade de erros de revisão, principalmente nos exemplos. Mais preocupante, encontrei um erro grave: na descrição de propriedades, o livro afirma que uma propriedade read-only precisa obrigatoriamente estar associada a um campo readonly da classe (no C# e VB .Net um campo readonly pode ser iniciado apenas na declaração ou no construtor da classe). Em primeiro lugar, é possível ter uma propriedade read-only que dá acesso de apenas leitura a um campo não readonly. Mais importante, uma propriedade não precisa estar associada a um campo. Uma propriedade é uma abstração que cria um membro que se comporta como um campo independente da forma como é implementado internamente.

Para quem tiver a curiosidade de saber porque comprei este livro, foi logo após o lançamento do Visual Studio .Net, em junho de 2002. Neste época existia pouca oferta de livros sobre C# e a descrição do livro é bastante interessante. O problema todo é na implementação...

21/jun/06: acertados alguns erros de digitação.

Desenvolvedor de Aplicativos Certificado Microsoft (MCAD)

Bem, ainda falta a minha nota chegar até a Microsoft (da última vez demorou algumas semanas e precisou de um cutucão), mas com a prova de hoje (exame 70-320 - Developing XML Web Services and Server Components with Microsoft Visual C#) completei os requisitos.

Eu estudei principalmente pelo Training Guide da Que, de autoria do Amit Kalani. O livro é muito bom, mas não deixa de ser um resumo. Cada um dos onze captítulos merece um livro a parte (e tenho quase certeza que existem todos estes livros). O livro contém uma quantidade generosa de exercícios práticos e vem com um CD com uma versão eletrônica do livro e um simulado demo (com 60 questões).

Eu estava muito confiante na vespera, tendo ido muito bem no simulado impresso do livro e razoavelmente bem no simulado do CD. No início da prova, como de costume, deu aquele susto de ver algumas coisas que eu nem sabia o que era... No final eu estava confiante de ter passado, mas por pouco. Nova surpresa ao ver o resultado: aparentemente a cultura geral e o bom senso (e provavelmente um pouco de sorte) funcionaram e um tirei um notão (devo ter errado somente três ou quatro questões das 43).

A principal dificuldade do exame é que ele cobre muita coisa e várias questões são sobre detalhes. Além disso, a redação das perguntas é muitas vezes confusa. Teve uma única questão que eu achei bastante fora do assunto (dizia respeito a uma propriedade de uma classe não relacionada diretamente a Web Services ou Server Components).

Bem, daqui a 3 semanas faço o último exame para obter a certificação MCSD .Net. Só para não esquecer, estas duas certificações já ficaram obsoletas com o lançamento do .Net Framework 2.0. No segundo semestre tento a sorte com os exames de upgrade.

Sério ou Brincadeira?

Vi no Newsgroups do Technet o link abaixo

http://www.certifai.xpg.com.br/index.php

dei uma olhada no site e não consegui decidir se é ou não uma brincadeira. Será que alguém pagaria R$50 por um transcript MCP falso? (Para quem não conhece, o transcript MCP é uma folha com a relação das provas de certificação Microsoft que você fez, você imprime no seu próprio micro acessando um site da Microsoft).

Ah sim, é claro que ser for sério é ilegal, imoral, etc.

Agora vou voltar aos meus estudos para obter o meu certificado à moda antiga.

Certificação

Como mencionei em 10 de janeiro, estou a um exame da certificação MCAD e a dois exames da MCSD .Net (ambas já obsoletas). Graças às promoções do TechNet Brasil, tenho vouchers para exames gratuitos válidos até 1/julho. Portanto criei coragem e marquei o exame 70-320 para o começo de junho. Se sobrar fôlego, vou tentar também o 70-316.

Portanto, agora é "crunch time" e os posts aqui e no Wiki C/C++ Brasil vão ficar ainda mais escassos.

Amazon

Novo recorde de entrega da Amazon: fiz o pedido no dia 25/4, os três livros foram despachados no dia 27/4 e chegaram à agência hoje (5/5). E é bom lembrar que teve um feriado no Brasil no dia 1o. Ah, e foi pelo Standard International Shipping.

Bugs Terríveis de Achar - Execução Paranormal de Código

Os dois últimos dias foram de uma busca frenética atrás de um bug.

O bug se apresentou em um firmware que estamos desenvolvendo para um dispositivo e que roda em um microcontrolador. A programação deste tipo (sistema embarcado) é bem diferente da programação normal para PC. Como é comum nestes casos, o firmware é gravado em uma memória não volátil (memória Flash) dentro do próprio microcontrolador. Esta gravação é feita por um software de PC, através de um gravador ligado à porta paralela do PC e a determinados pinos do microcontrolador.

Uma segunda memória não volátil (EEProm), externa ao microcontrolador, é usada para manter dados não voláteis, alguns deles extremamente críticos para a operação (como o número de série do dispositivo). A gravação na EEProm requer uma série de passos: é preciso habilitar a gravação, enviar o comando de gravação, o endereço e o dado. Não é algo que possa acontecer por conta própria.

No processo de produção dos dispositivos, é gravado primeiro um software de teste no microcontrolador. Através de uma serial de debug, são feitos testes e gravadas as informações críticas. Após isto é gravado o firmware normal.

Bem, após a produção de 140 dispositivos, verificou-se que cerca de uma dúzia estava com número de série incorreto. Pânico! Uma primeira hipótese, erro de operação na produção, parece improvável dado a taxa de erros. Restam o software de teste estar gravando algo errado ou, pânico maior, o firmware normal estar destruindo as informações na EEProm. Por outro lado, este efeito nunca tinha sido observado com as duas dezenas de protótipos.

Uma primeira revisão do firmware mostra que a EEProm é gravada em poucos pontos. Segue-se uma discussão filosófica sobre a necessidade e conveniência destes pontos. Faz sentido colocar um número de série default em caso erro de checksum na EEProm? A conclusão é que o firmware normal deve evitar ao máximo gravar na região onde estão os parâmetros mais críticos. Entretanto, mudar isto antes de descobrir o que está acontecendo pode apenas mascarar um problema sério.

A decisão é acrescentar um teste para tentar pegar se o número de série está danificado. Se sim, acender um LED de erro e preservar o conteúdo da EEProm para ver se dá uma pista do que ocorre. Em seguida, tentar reproduzir o problema, refazendo o procedimento de produção com esta nova versão.

Feito o procedimento com 20 dispositivos, em 2 ocorre o erro. É uma boa notícia: o problema pode ser reproduzido.

Alguns testes mostram que o software de teste está gravando os valores corretos na EEProm. Hora de ativar os traces do firmware e observar as informações enviadas pela serial. Após alguma tentativas, verifica-se que a corrupção da EEProm ocorre logo após a carga do firmware.

O teste começa a ficar mais complicado. É preciso prestar atenção no trace enviado pelo dispositivo quando ele é re-iniciado após a carga. É um problema esporádico, às vezes ocorre apenas após muitas tentativas. Para dificultar, às vezes ocorre um erro na verificação feita após a gravação. Outras vezes, a execução do firmware não acontece ao final da gravação e verificação, sendo preciso esticar o braço e desligar e re-ligar o dispositivo.

Prestando mais atenção, percebe-se que o firmware executa mesmo quando ocorre um erro na verificação. Em uma destas ocasiões, o conteúdo da EEProm é danificado. Primeira teoria: o firmware executado estava danificado de uma forma que causou a gravação incorreta da EEProm. Segue-se uma discussão de como o firmware pode descobrir que está gravado errado e não executar neste caso (a técnica tradicional é colocar um checkum no código, obviamente não resolve se a rotina de verificação estiver danificada).

Segue-se mais bateria de testes, tentando ver se sempre que a EEProm é danificada ocorreu erro na verificação. Alguns minutos depois, teoria abalada: a EEprom foi corrompida sem que tivesse ocorrido erro de verificação.

Para tentar cercar mais o problema, coloquei na rotina de gravação da EEProm (no mais baixo nível) um teste do endereço de gravação. Se for o endereço do número de série, ao invés de gravar envia um ! para a serial. Mais algumas tentativas e aparece !!! isolado, sem os demais traces...

Olhando com mais atenção ainda, percebemos que existe alguma atividade no dispositivo durante a verificação da gravação, quando o processador devia estar parado. Nova teoria: existe algo errado no processo de gravação e verificação, que faz o processador iniciar a execução antes da hora e de forma "meio torta".

Para comprovar, coloquei uma variável que é iniciada com zero e incrementada a cada passo da iniciação do software. Na rotina de escrita na EEProm, acrescentei um teste: se não tiverem sido executados todos os passos da iniciação, envia pela serial @ seguido do valor do contador. Alguns poucos testes são suficientes para ver alguns @0 e @1 surgirem durante a verificação. Execução paranormal: a rotina de gravação está sendo executada desrespeitando o fluxo normal da execução.

Hora de reclamar do gravador para o projetista do hardware. Aparentemente o processador está recebendo um sinal de reset fora de hora. Após algumas tentativas de achar uma explicação no software para o comportamento anormal, decide-se colocar um capacitorzinho no sinal de reset que vem do gravador (algo como dar um tempinho em software). Antes de soldar o capacitor, o técnico decidiu verificar o cabo. Tinha um mau contato no pino de reset. Testes com um outro cabo e com o cabo com o mau contato eliminado confirmam que o problema sumiu.

Resumindo, um mau contato no cabo usado para gravar o firmware fazia com que ocasionalmente o sinal de reset "balança-se" durante a verificação da gravação. Isto deixava o processador meio "bêbado" e ele saia executando errado o firmware.

Agora é só eliminar todos os problemas potenciais que identificamos enquanto procurávamos o bug que não existia.

Sinais de Um Programa Ruim

Esbarrei com um artigo interessante sobre sinais no código fonte que indicam um programa problemático. Para quem não tiver paciência de ler o artigo todo, eis a lista de sinais:

1. Comentários ausentes ou ruins
2. Nomes inapropriados
3. Formatação inconsistente do fonte
4. Falta de teste de códigos de retorno e de erros em geral
5. Repetições de código
6. Falta de clareza
7. Complicações desnecessárias
8. Condições assumidas não documentadas
9. Substituição das funções das bibliotecas padrões por funções próprias
   
10. Falta de suporte à depuração

Esta lista pode inclusive ser usada como um checklist às avessas durante o desenvolvimento. Se você perceber que o seu código contém algum dos sinais acima, pare e conserte.

Se você precisar dar manutenção em um software, verifique antes os sinais. Se forem muitos, considere seriamente fazer um refactoring (mas pense muito antes de reescrever tudo).

GPF - Grilo Pulsante Fantasma

A foto acima é do brinqedinho que levei no Segundo Encontro de Programadores C/C++ em São Paulo. Como a regua e o cartão mostram, é um circuito bastante pequeno, onde os maiores componentes são a bateria, o buzzer (uma espécie de alto falante sem imã) e o resistor sensível a luz (LDR).

O componente mais importante, entretanto, é o PIC 12F675. Trata-se de um microcontrolador, um computardor quase completo dentro de um chip. Este modelo possui 1024 palavras para armazenamento de programa (Flash), 64 bytes de Ram para variáveis e 128 bytes de memória não volátil para dados (EEProm). O processador utiliza um conjunto de apenas 35 instruções. Neste projeto usei o clock interno de 4 MHz, o componente permite usar um cristal externo de até 20MHz. Possui um modo sleep, útil a circuitos a bateria, que reduz o consumo de energia a quase zero.

O microcontrolador possui uma quantidade grande de recursos. Possui internamente dois timers, que podem ser usados para gerar interrupções periódicas, fornecendo uma base tempo para o software. Seis dos oito pinos podem ser tratados como entrada ou saída digital (isto é, serem colocados em nível lógico "0" ou "1" por controle do software). Quatro dos pinos podem ser usados como entradas analógicas (o software pode ler o nível do sinal do pino como um valor digital de 8 ou 10 bits).

O objetivo do circuito era mostar os potenciais do microcontrolador e o fato dele poder até ser programado em C. Inspirado em um exemplo do fabricante do PIC, é um circuito para ser escondido em um lugar e perturbar as pessoas presentes. O circuito fica a maior parte do tempo dormindo. Em tempos aleatórios ele acorda e faz um pequeno bip (daí o grilo pulsante). Para tornar a detecção mais difícil, o bip é feito somente se o circuito estiver no escuro (daí o fantasma). O LED (que também só é acionado no escuro), permite confirmar que o circuito está ligado. Por último, um botão permite testar o circuito, soando o bip e piscando o LED. Desta forma, o cicuito usa:

• uma entrada digital (o botão)
• duas saídas digitais (o LED e o buzzer)
• uma entrada analógica (o sensor de luz)
• um timer para acordar o circuito periodicamente
• um timer para fornecer a temporização para a geração da frequência enviada ao buzzer.

O software foi desenvolvido em C no PC e gravado no PIC através de um gravador externo. Acrescentando um conector e um resistor seria possível gravar o PIC sem retirá-lo da placa (usando o mesmo gravador).

O custo total do circuito fica abaixo de R$50. O PIC custa menos de R$15, comprado unitariamente em uma loja. O preço USA, para 100 peças é USD 1,19.

Quando se fala em microprocessadores, a maioria das pessoas pensa imediatamente em computadores de mesa. Entretanto a grande revolução está nos microcontroladores, que permitem acrescentar inteligência a equipamentos por um baixo custo. A nossa casa está repleta deles, escondidos em geladeiras, máquinas de lavar, micro-ondas, TVs, DVDs, etc.

Livros do mês

Um dos meus motivadores para aprender inglês foi a coleção de livros do meu pai, principalmente os de fição científica. A minha primeira leitura de verdade em inglês foi a trilogia original da Fundação de Isac Asimov (Foundation, Foundation and Empire e Second Foundation).

Embora isto tenho sido há muito tempo atrás, ainda existem alguns livros da coleção do meu pai que não tinha lido. Um deles era o clássico (infelizmente esgotado) The Weapon Shops of Isher de A. E. Van Vogt. Algumas idéias podem hoje parecer chavão, mas provavelmente eram novidade quando o livro foi escrito. É um daqueles livros que prende o leitor, você fica sempre querendo saber o que vai acontecer. De quebra tem um tradicional paradoxo de viagem no tempo, com o personagem que só existe no curto intervalo de tempo entre ele chegar do futuro e voltar ao passado.

Ao devolver este livro acabei pegando para reler The Double Helix de James D. Watson. São as recordações da descoberta da estrutura do DNA (que de forma não esperada esclareceu o processo de duplicação dos genes). O livro não se limita aos aspectos técnicos, tratando muito da questão do relacionamento entre os envolvidos e da concorrência versus cooperação. Mostra um pouco como funciona internamente o meio científico e as suas motivações.

Resumindo uma longa história em um único parágrafo, a estrutura do DNA foi descoberta por James Watson e Francis Crick após um período relativamente curto de estudos, a partir de dados experimentais (fotografias por raio-X de cristais de DNA) obtidos por Maurice Wilkins e Rosalind Franklin num trabalho bem mais demorado. Watson e Crick utilizaram principalmente a montagem de modelos, técnica usada anteriormente por Linus Pauling para descobrir a estrutura dos amino-ácidos e desprezada por Wilkins e Rosalind. Para complicar mais a situação, as principais fotografias usadas foram tiradas por Rosalind, e usadas sem o seu conhecimento, devido a problemas de relacionamento com os demais. Watson, Crick e Wilkins vieram ganhar o prêmio Nobel por esta descoberta (e outras relacionadas), porém Rosalind morreu alguns anos antes. Embora alguns considerem Rosalind uma injustiçada, prefiro a versão presente na Wikipedia.

C e C++

No Wiki do "C/C++ Brasil" está em discussão o nome do grupo. Um ponto sempre lembrado é o desejo de manter o C no nome, e nesta hora me sinto meio culpado, já que às vezes sinto que sou o único do grupo que programa no dia a dia em C.

Isto não significa que eu não tenha estudado e continue estudando C++. Ainda outro dia eu tomei um susto ao abrir um livro de C++ (de 94) e descobrir que eu não só tinha lido como tinha feito correções nos exemplos. E afinal, eu passei no exame de Visual C++ da Microsoft.

Na verdade, comecei a ter algum interesse em C++ no final dos anos 80. Nesta época chegamos a comprar na Humana uma cópia de um dos primeiros compiladores C++ para o DOS, o Zortech (que alguns anos depois foi comprada pela Symantec). A Borland foi uma grande divulgadora do C++, com o Turbo C++ e o Borland C++; lembro de um vídeo da Borland chamado "The World of Objects" (ou algo parecido). Em 92 a Humana fez um primeiro projeto em C++, usando o Microsoft C/C++ 7.0 (o primeiro compilador C++ da Microsoft).

Na Seal, fizemos alguns projetos com o Visual C++ 2.0 para serem rodados no NT 3.1 (ambos novidade na época). Alguns dos meu programas usavam até a MFC (então na versão 3.0). A maioria dos desenvolvimentos na Seal era feito em Visual C++ 1.5, para coletores de dados com sistema DOS. Eventualmente alguem teve a idéia de fazer uma biblioteca de classes para facilitar o desenvolvimento para os coletores. Embora eu não estivesse na época trabalhando na área de software, alguem me passou a especificação para dar os meus palpites. A especificação começava com uma classe CString (como se o VC 1.5 já não tivesse duas classes de string) e terminava com uma classe CUtil cujos membros eram funções diversas (para deixar tudo orientado a objeto?). No final a classe CUtil foi abandonada, mas a CString ficou lá.

Foi lendo esta especificação e a coluna de dúvidas de C++ do Microsoft System Journal que eu concluí que conceitualmente o C++ é bem mais pesado que o C. Recentemente escrevi um artigo sobre construtores no Wiki, e foi um trabalho bastante árduo para descrever algo que é simplesmente básico (quem usa C++ no dia a dia tem que ter tudo isto e muito mais na ponta da lingua). Talvez por isso eu continue usando C mesmo quando o C++ é uma opção disponível. O fato de eu estar cercado de outros programadores C também contribui, principalmente porque eu sempre tenho a esperança de deixar a manutenção para eles.