Um dos maiores problemas enfrentados no desenvolvimento é de como usar a ajuda. Normalmente, existe um guia de referência de todas as funções, mas ele não é claro o suficiente pra quem chega “agora”.

Particularmente, eu recomendo ao pegar uma plataforma/linguagem nova traçar um objetivo simples (quando estava no colégio técnico, meu objetivo era sempre fazer um programinha que calculava a fórmula de Baskara). Comece do começo, escreva um Hello World, se acostume com a ferramenta, coloque breakpoints. Tente antes de sair perguntando, para que quando você fizer a pergunta, ela já será não tão obvia e ao mesmo tempo você entenderá melhor a resposta pra ela. E leia pelo menos os tutoriais iniciais. Saiba do que a ajuda fala quando está lidando com termos que você nunca viu antes, principalmente acrônimos. E são deles que gostaria de falar aqui:

• SDK: Software Development Kit; O SDK contém as bibliotecas (*.h, *.lib) para o desenvolvimento específico para aquele hardware que você deseja trabalhar com. No caso do Visual Studio 2005, ele já vem com o SDK para o desenvolvimento em Pocket PC. O SDK pode ou não incluir um emulador (como é o caso do Pocket PC 2003, que vem com um emulador para vários tipos de tela e teclado diferente). Além disso, ao instalar um SDK e escolhe-lo ao iniciar um projeto, ele já acerta o caminho para as headers e libraries, além de várias outras configurações do compilador, tais como, por exemplo, a arquitetura alvo para qual se deseja desenvolver.

Normalmente, é possível utilizar qualquer SDK que tenha a mesma arquitetura de processador para um hardware qualquer.  Por isso que em meu projeto TFTPCE do codeplex eu uso o Windows CE Standard SDK, que me dá a possibilidade de compilar pra qualquer arquitetura. (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=fa1a3d66-3f61-4ddc-9510-ae450e2318c3)

É vantagem usar um SDK específico quando o fabricante do hardware fornece um, pois além das APIs padrão da Microsoft ele pode colocar mais algumas referências a funções especiais do hardware dele. (Por exemplo, um hardware que tenha uma garra pode ter uma API que controla essa garra)

• DTK: Developer Tool Kit: O DTK não é comumente usado, esse é o primeiro que eu vejo. Ele constitui de algumas ferramentas extras que dependem do SDK para funcionar. O Link pro DTK do Windows Móbile 6.5 é esse:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=20686a1d-97a8-4f80-bc6a-ae010e085a6e

Além desses dois acrônimos, há também os que são mais comuns de ser ouvido quando se trabalha um nível mais baixo, com o Platform Builder, isto é, adaptando o Sistema Operacional para um hardware específico.

• BSP, OEM e OAL: O BSP vem de Board Support Packager constitue em um conjunto de drivers e configurações que o fabricante de hardware, o OEM (Original Equipment Manufacturer). Além dos drivers, o BSP deve ter uma camada que conecta o processador com o Kernel do CE (pré-compilado). Essa camada é a OAL (OEM Adaptation Layer)

*A imagem ilustrativa foi retirada do flicker de Lucia Freitas, e está sobre a creative commons : http://www.flickr.com/photos/lufreitas/474912291/

Com o Windows CE e o Windows Mobile, não podia ser diferente. Criando e compilando um HelloWorld, já é possível avançar, e mais do que isso, fazer as perguntas corretas para as pessoas que podem te ajudar.

Passo a passo, vamos criar um simples (simples mesmo) Olá Mundo não gerenciado para Pocket PC, que é o antigo nome do Windows Mobile, que é baseado em Windows CE 4.2

Não se preocupem com as palavras grafadas em negrito, no próximo post irei explicar cada uma delas melhor.

Assumindo que o Visual Studio 2005 está instalado corretamente, vamos lá: Comece clicando em File->New Project

Agora, Selectione Visual C++ /Smart Device, e finalmente Win32 Smart Device application. Coloque um nome e um caminho para o projeto, e clique em OK.

Na proxima tela, você tem uma descrição basica do que você selecionou. Clique em Platforms.

Aqui você irá escolher para qual dispositivo(s) seu programa irá rodar. Para fins de demonstração, selecione o Pocket PC 2003

–O quê? Como assim, mas eu quero que rode no Windows Mobile/CE/Genérico X! Por quê devo escolher isso?

Como o Windows CE é um sistema operacional portável, que roda em vários tipos de coisas diferentes, aqui você aqui está escolhendo

1-) A arquitetura do processador (MIPS/ARM/SH/X86) . Por exemplo, na maioria dos celulares e pocket pcs de hoje em dia temos a arquitetura ARM.

2-) As bibliotecas adicionais que você terá acesso. Como o sistema é modular, o seu dispositivo pode ter só algumas partes. (Posso fazer uma torradeira rodar Windows CE,  logo, provavelmente ela não terá tela; será um dispositivo “headless”, então as bibliotecas (APIs) de desenho na tela não estão disponíveis)

Todo esse conjunto de configurações chama-se SDK, ou software development kit. Ele é sempre fornecido pelo fabricante do produto. Junto com ele pode vir, além das APIS, um emulador também, como é o caso do Pocket PC 2003.

Tendo isso claro em mente, vamos prosseguir pro próximo passo. Clique em Application Settings.

Selecione Console Application aqui, e clique em Finish. Nosso Wizard deverá gerar o seguinte código, que é quase igual ao de qualquer hello world em c:

#include “stdafx.h”
#include <windows.h>
#include <commctrl.h>

int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
– Mas o quê?? Como assim, STDAFX.H??

Não se preocupe com ela agora. Só irei dizer por enquanto que ela é apenas um método para compilação de código pertencente as headers basicas mais rápidamente. Precisaria de um post inteiro para explicar melhor.

–Tá, mas e a <CommCrtl.h>

Ela é referente ao conjunto de controles comuns (para interface). Não imagino por quê a Microsoft colocou ela no wizard para gerar uma aplicação de linha de comando. Você pode retirá-la tranquilamente.

–Humm e o <Windows.h>

Essa é importante, contem todas as definições que o windows usa. E mais, dentro dela ela ainda inclue vários e vários arquivos.

Agora, vamos preencher o nosso Hello World!!

#include “stdafx.h”
#include <windows.h>
//#include <commctrl.h>

int _tmain(int argc, _TCHAR* argv[])
{

_tprintf(_T(”Olá Mundo!\n”));
return 0;
}

-O QUÊ ?? _tprintf, _T e TCHAR* argv[] ? Isso não parece nada com o C que eu aprendi na escola/faculdade! Blasfêmia!

Calma, ainda é cedo pra entrar em pânico, isso piora mais tarde

Como o Windows CE é UNICODE, todas as strings são baseadas em caracteres de DOIS BYTES de tamanho. o _tprintf é na verdade um define que verifica se o UNICODE foi definido pelo preprocessador e então escolhe entre wprintf ou printf normal. Isso deixa o código portável entre as várias versões diferentes do Windows. Até o Windows ME, apenas o sistema ANSI era suportado. (Caracteres que ocupam apenas UM BYTE). Isso pode parecer estranho para nós do mundo Ocidental, mas imagine um país que não usa os caracteres de A a Z para representar as palavras (Dica: Japão): A quantidade de letras deles é muito maior do que a capacidade de um byte (2^8 = 256 diferentes caracteres).

Da mesma forma, o _T explica que a string (”“Olá Mundo!\n”) irá ocupar 2 bytes na memória, e não um só.

–Ah, entendi! Então o TCHAR* argv[] é um ponteiro para Strings baseadas em Dois bytes por caracter!

Exato. Vamos ver como isso é na prática. Coloque um breakpoint no código, bem na linha do olá mundo:

E vamos apertar F5 para ver o que acontece.

–Você me enganou! Ele abre o Emulador do Pocket PC 2003, para no breakpoint mas não aparece nada!

É. Pois é. O Emulador do Pocket PC, e do Smartphone não contém um console. Isso não significa que ele não exista, significa apenas que quem criou os SDKs não quis incluir um console.

Vamos modificar o código pra ficar um pouco melhor.

Agora sim, vamos apertar F5 e ver o que acontece!

Bem melhor né.

Faltando apenas um detalhe para terminar o post, vamos abrir a Janela Memory, da aba Debug->Windows->Memory->Memory 1, ou apertando ALT+6

No endereço, vamos escrever msg (é, queremos analisar o conteúdo da variável msg)

Interessante né? Aqui podemos ver como que um char unicode é guardado. Olá mundo fica da seguinte forma:

Viram só. Ocupando Dois BYTES cada char. Coloquem isso na cabeça, pra evitar várias dores na mesma ao desenvolver. Quase todas as funções nativas do CE aceitam APENAS o tipo TCHAR, que é definido como wchar, que é o wide char, de dois bytes. Todas as funçoes com manipulação de strings DEVEM usar a sua respectiva função, que sempre começa com _t (_tprintf, _tsprintf, _tcslen, _tcscmp …)

Ufa. Até que é simples não?

-Não.

Tá, eu sei. Mas você se acostuma, e é muito bacana ver um aplicativo nosso funcionando em algo que você pode levar pra qualquer lugar. Tenho certeza que se você mostrar pra sua mãe ela ficará orgulhosa. A minha ficou. Eu acho.