deaplicações para Pocket PC. Eu não conhecia nada deste tipo de equipamento.Já tinha ouvido falar de Palm mas, Pocket PC era relativamente novo. Isso foiem meados de 2001 ou início de 2002.Entrei para a empresa e fui apresentado à plataforma. Ninguém, na empresa,conhecia os equipamentos. Então fui procurar por recursos e linguagens deprogramação para o dispositivo. Acabei descobrindo que eu poderia desenvolversoftwares em C/C++ ou Visual Basic. Era bom demais para ser verdade.No meu primeiro emprego como desenvolvedor eu acabei aprendendo muito sobreVisual Basic e como eliminar as deficiências da linguagem importando eutilizando funções da API do Windows. Acabei criando uma biblioteca enorme comfunções e operações que faziam de tudo que se possa imaginar. Nós nãoutilizávamos quase nenhum componente ActiveX porque euimplementei controles (menus, barras de ferramentas, TreeViews, ListViews)usando a API do Windows diretamente. Por causa desta minha experiência com VBeu achei, em primeira instância, que poderia utilizar o mesmo VB para criaraplicativos para Windows CE. Ledo engano.O Windows CE utilizava uma linguagem que não era nem o Visual Basic que euconhecia como também não era o VBA do Access. Mas sim uma versão parecida como VBScript para páginas WEB que podia acessar alguns componentes do Windows CEpara criar uma interface com o usuário. Muito difícil de usar e limitado, masconseguimos criar nossa primeira aplicação deste modo. E lá estava elenovamente, o Ultraedit, para salvar a minha pele.Eu já estava tão acostumado às configurações que fazia no meu editor preferidoque não conseguia mais utilizar outro aplicativo. As teclas de atalho já eramautomáticas e eu não precisava mais pensar nelas. Quando precisava realizaruma operação, Zaz! Os dedos faziam o trabalho sozinhos.Logo de início percebi que VB não seria a saída definitiva para criaraplicativos para Windows CE. Eu já conhecia a linguagem C. Mas não tinhaprática. E algumas coisas me amedrontavam, como a utilização de ponteiros. Eunão conhecia C++, muito menos MFC ou ATL. Mas não tinha escolha e até gosteido desafio. Eu já havia aprendido (e superado) o VB sozinho, também já haviaaprendido HTML, VBScript e Javascript por mim mesmo. Além de SQL que éindispensável a qualquer desenvolvedor de aplicativos cliente/servidor.Aprender C++, MFC e ATL seria mais informação e bagagem para minha jornadaprofissional.Foram 2 aplicativos, várias versões e tudo estava indo bem. Até que chegou aoBrasil o Windows Smartphone. Uma versão diferente do Windows CE e uma versãodiferente da API: sem MFC. Eu fiquei realmente chateado. A Microsoft éestranha neste sentido. Embora procure manter a compatibilidade entre asversões do Windows para suportar aplicações antigas, num produto novo como oWindows Smartphone os desenvolvedores teriam que esquecer tudo o queaprenderam sobre MFC e sua estrutura Document/View e criar aplicaçõesusando diretamente o Windows SDK.Na época eu pensei: "Só eu crio as aplicações para Windows CE nesta empresa.Então, vou criar uma biblioteca de classes parecida com o MFC mas que eu possacompartilhar sua utilização tanto no Windows CE quanto no Windows Smartphone".E foi o que eu fiz. E ainda uso esta biblioteca de classes até hoje.Embora os ambientes de desenvolvimento da Microsoft evoluírem com o tempo,para o Windows CE e Smartphone eu ainda estava atrelado a uma