Archive for November, 2006

Off-topic HP 50G

28 de November de 2006

Finalmente o período de provas semestrais terminou. Já posso voltar à vida normal, me re-integrar à sociedade, e porque não, escrever posts. Para os que não sabiam, estou cursando Engenharia da Computação na Universidade São Judas Tadeu. Apesar dos meus trinta anos de idade, ainda estou no terceiro ano devido à uma vida um tanto agitada que um programador pode ter. Tenho certeza que muitos de vocês sabem exatamente do que estou falando. Tive que interromper meu curso diversas vezes, ou por falta de grana, ou por excesso de trabalho. Enfim, estas últimas semanas estive correndo atrás do prejuízo e não pude compor um post decente. Assim, vão ter que se contentar com algumas curiosidades sobre minha nova melhor amiga, a HP 50G.

Costumo dizer que programador não é nome de profissão, e sim nome de doença. “Programador: Pessoa que sofre de programação”. Um dos sintomas que considero mais determinantes no programador é a grande capacidade de associar coisas diversas com programação, mesmo sem que se queira. Um exemplo? Fácil!!! Quando eu estava cursando Informática Industrial na ETE, havia um professor que falava pausadamente, cerca de 3 segundos entre uma frase e outra. Ele parecia um andróide. Eu costumava imaginar que aquela característica se dava ao fato de que o professor tinha pouca RAM, dessa forma, levava um certo tempo para carregar uma nova frase da HD para ser processada pelo sintetizador de voz. Na época dizíamos que se prestássemos atenção, poderiamos ver um led piscando dentro da orelha dele durante aquelas pausas. Felizmente aquilo poderia ser facilmente resolvido se houvesse uma segunda thread que colocasse a próxima frase na RAM à medida que a frase atual fosse processada pela thread principal. Não sei o que vocês pensam sobre isso, mas para mim parece doença. :-S

Estudando para as provas de Cálculo Numérico Computacional e armado com uma HP 50G, foi inevitável programar a HP para automatizar alguns passos. Os exercícios desta matéria são compostos basicamente por contas simples, mas são longos e cheios de regrinhas. Portador de programação desde os 13 anos de idade, baixei os manuais e mãos à obra. Quando compramos a HP, vem um “Quick Start” de umas 120 páginas, mas é possível baixar PDF do manual completo de 918 páginas em português.

Como era de se esperar, encontrei muitos sites e tutoriais sobre o assunto, vários em português mesmo. O site hpcalc.org foi um grande colaborador. Na página de programação pode-se encontrar muita coisa. E o melhor, é tudo free.

Podemos programar a HP em UserRPL ou SystemRPL. Programar em SystemRPL nos dá um ganho de performance quase 10 vezes superior que em UserRPL. Entretanto, tudo na vida em um preço. O trecho abaixo foi retirado em um dos inúmeros PDFs que encontrei.

Estranho! Eu podia jurar que já li algo parecido em algum lugar.

Como não consegui baixar uma versão do WinDbg que depurasse a HP, resolvi programar em UserRPL mesmo. A linguagem é basicamente composta pela seqüência de teclas que seriam pressionadas durante o uso normal da calculadora, porém, podemos ainda contar com blocos de execução, laços de repetição(for, while), execução condicional (if, else), execução de sub-programas e outras tantas coisas que não tive paciência de ler. É divertido poder misturar coisas como IF e ELSE com comandos que fazem operações com matrizes como se fossem tão simples quanto somar 1 em 1.

A HP pode ser programada nela mesma, ou seja, utilizando seu próprio teclado. Mas ficar escrevendo sobre aquele tecladinho é similiar a ficar jogando Decathlon no Atari. Funciona, mas você sabe o que vai acabar acontecendo. Outra coisa super desconfortável é tentar entender o que está errado no seu programa olhando o fonte (que não esta indentado) em uma telinha de LCD. Uma das facilidades é um cabo USB que conecta a HP em seu micro.

Para ter acesso aos diretórios e variáveis armazenados na calculadora, você terá que fazer o download do software que faz esta conexão. Mas se você possuir uma máquina x64 (mesmo que seja da HP), não haverão drivers disponíveis para realizar esta conexão. Se este for o seu caso, você pode utilizar uma máquina virtual que esteja rodando um sistema operacional de 32 bits. Não é que funciona mesmo!

Quando conectado, é exibido uma espécie de “Explorer” onde você pode navegar nas pastas e editar variáveis e programas. Com um double-click sobre os programas, um excelente ambiente de desenvolvimento chamado “Notepad” é aberto com o seu programa. Nem pense em identar seu programa. Quando o este é enviado para a HP, ele assume uma identação dela, que obviamente não é a mesma que gostariamos de ter.

Pois é, foi no mínimo interessante aprender mais essa. Realmente valeu a pena gastar essa grana comprando algo que eu possa programar e poder sustentar meu vício. Mas ainda não para por aí. Se você der uma olhada na quantidade e variedade de aplicações para download da hpcalc.org, você terá uma idéia do que mais ela pode fazer além de calcular o determinante de uma matriz. Se estiver curioso, você pode baixar um emulador da calculadora em seu PC e fazer um Test Drive.

Kernel + Visual Studio 2005

16 de November de 2006

Programador de driver ou software de baixo nível está acostumado a compilar seus projetos na linha de comando, utilizar editores de texto como o Notepad ou mesmo o Norton Editor para codificar seus drivers. É como meu amigo Thiago diz: “Faca nos dentes e sangue nos olhos”. Utilizar o comando TYPE | MORE para ver os arquivos de erros de compilação, mostra o quanto somos seres superiores, dominates da tecnologia, que não sub-utilizamos nosso cérebro, que não precisamos de ferramentas supérfluas como interface gráfica, sintaxe colorida, intellisence ou mesmo o auto-complete e que estamos no topo da cadeia alimentar.

Se você realmente acredita nisso, então é melhor abandonar este post por aqui mesmo. Hoje vou defender o uso das ferramentas que ajudam, e muito, na hora de codificar um driver e ter que lidar com funções com grande número de parâmetros e intermináveis estruturas.

Utilizar ou não o compilador do Visual Studio para gerar drivers é mais uma das discussões que tendem ao infinito, tal como o uso de C++ no desenvolvimento para Kernel Mode. De um lado estão aqueles que defendem que o ambiente quase nunca está perfeitamente configurado para compilar drivers. Já li posts de verdadeiras autoridades no assunto falando sobre quantos dias foram necessários para encontrar um bug que foi gerado por uma otimização do compilador ou mesmo um define incorreto que foi gerado pelo Wizard. Estes que dizem que utilizar o Visual Studio como ambiente de desenvolvimento requer um conhecimento mínimo de cada parâmetro utilizado na chamada para o cl.exe, que o ideal mesmo é utilizar o bom e velho Build que trata os arquivos sources, dirs e makefile e ter a absoluta certeza de que o ambiente configurado pelos atalhos do DDK está correto. Do outo lado estão os que não abrem mão da comodidade de ter um ambiente integrado, de poder pressionar apenas uma tecla para cair na linha do arquivo em que o erro foi detectado, de utilizar sintaxe colorida, intellisence, auto-complete e outras tantas vantagens que o Visual Studio oferece.

Já faço isso a algum tempo e lembro-me de quando o DDK resolveu trazer um compilador embitudo no Kit a partir do Windows XP. O principal objetivo desta mudança no DDK foi tentar separar o ambiente de desenvolvimento de drivers do ambiente de aplicações. Esse vínculo já criou muitos problemas. O DDK do Windows NT 4.0 era baseado no VC 4.2, mas com o surgimento do VC 5.0 e posteriormente do VC 6.0, o formato da tabela de símbolos foi alterado e o Windbg parou de funcionar. Nesta época eu utilizava muito mais o SoftIce que o WinDbg para depurar drivers e continuei utilizando o compilador do Visual Studio sem nem perceber este problema. Só tive problemas com símbolos quando o Visual Studio passou para a versão 7.0. O VToolsD até hoje não oferece suporte ao novo formato de símbolos. Conclusão, até hoje eu utilizo VC 6.0 para compilar VXDs. Não que seja impossível utilizar o VC 7.0 para isso, só não conseguiremos depura-lo.

Mas foi quando fizemos o upgrade do VS2003 para o VS2005 que mudanças mais drásticas fizeram com que minha vida se tornasse um pouco mais azul. Foi a partir dessa época que comecei a utilizar o melhor dos dois mundos, ou seja, a confiança de ter um ambiente corretamente configurado e toda a comodidade das ferramentas que o editor do VS2005 nos oferece.

Como fazer isso? Ok, vamos utilizar o projeto criado no post Getting Started como ponto de partida. Inicialmente precisaremos baixar o arquivo DDKBUILD.CMD da OSR Online e grave-o em um diretório que esteja no PATH da sua máquina. Este CMD irá precisar da variavel de ambiente WNETBASE configurada com o diretório base da sua instalação do DDK. Este arquivo é um meio de fazer um build externo com o Visual Studio. Para fazer isso, crie um projeto de Makefile no Visual Studio como mostra a seguir.







Depois de entrar com o nome do seu novo projeto e a pasta onde ele será criado, é só clicar em “OK”. Mesmo sem configurar nada, clique em “Finish” da janela seguinte. Criado o projeto, adicione os arquivos no Solution Explorer. Em seguida, vamos editar as propriedades do projeto de forma que fique como ilustrado abaixo. Note que no campo “Include Search Path” estou assumindo que a instalação do DDK foi realizada no diretório C:\WINDDK\3790. Este campo não tem nenhuma influência sobre o processo de compilação, ele apenas informa ao intellisence quais os diretórios devem ser utilizados para servirem de fontes para sua base de dados.

A partir deste ponto, já podemos compilar o projeto como se fosse um projeto qualquer de User Mode. As imagens abaixo dispensam comentários. Imagino que não é necessário dizer que não é possível depurar drivers utilizando o ambiente do Visual Studio. Lembre-se que depuração de Kernel exige depuradores especiais para isso como comentei em meu último post.

Uma janela especialmente interessante que foi adicionada ao Visual Studio 2005, foi a “Code Definition Window”, que exibe o lugar onde os símbolos foram definidos conforme você os escreve na janela de código. Veja o exemplo disso quando escrevo uma chamada para IoSetCompletionRoutine.

Enfim, dêem uma olhada nas opções oferecidas pelo DDKBUILD. Você pode listar suas opções simplesmente abrindo uma janela de prompt e executando-o sem qualquer parâmetro. Observe que podemos compilar drivers utilizando inclusive o PREfast.

É isso aê… Have fun ! 😉