Javier Caceres – jacace

Javier's blog about C#, Software Architecture and Design


Windows Mobile

How to obtain the device Id in Windows Mobile

Let’s clarify what the device id is: the device id is an umbrella term form the device UUID and for the IMEI/ESN identifiers on phones. Let’s remember that UUID is a type of GUID which exists in every device (including desktop/laptop computers).

For getting the device UUID Microsoft has defined two methods: application specific hash and the real UUID. For getting the IMEI/ESM there is a method which uses TAPI. All of them are explained here:

·         Real UUID: by using the KernelIoControl method with the  IOCTL_HAL_GET_UUID parameter you can get the UUID which is an Universal identifier for the device hardware, a sample of using this method is below:

TCHAR* GetDeviceUUID()


      TCHAR *pszGuuid=NULL;

      TCHAR szFormat[]=TEXT(“%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X\r\n”);


      GUID myUUID;

      DWORD dwBytesReturned;                  

      DWORD dwError=0;                  


      if(KernelIoControl(IOCTL_HAL_GET_UUID, NULL, 0, &myUUID,sizeof(myUUID),&dwBytesReturned))


            pszGuuid=new TCHAR[MAX_HW_VALUE];

            LPCTSTR pszFormat=szFormat;







            delete[] pszFormat;








      return pszGuuid;



·         Application specific hash: as you can imagine there is a security threat if applications can read the device UUID because identity can be stolen, so for preventing it Microsoft defined the new API method GetDeviceUniqueID (starting with Windows Mobile 6) for generating a hash based application specific identifier. That’s means that method returns an application specific hash for every requester, those hash are guaranteed to be unique for every single application. Here there is a sample:


#define APPLICATION_DATA “@^!MyAppName!^@”





DWORD cbDeviceId = sizeof(appDeviceId);


hr = GetDeviceUniqueID(reinterpret_cast(APPLICATION_DATA),






//do whatever with appDeviceId

As shown above, the unique id is hashed with the input you provide in the APPLICATION_DATA parameter. Every time you change that parameter, the generated id will be different.


·         IMEI/ESN: on Windows phones there is an additional unique identifier given by the mobile operator. On GSM devices the serial number returned is the equipment identity International Mobile Equipment Identity (IMEI) code and on CDMA devices, the serial number returned is the Electronic Serial Number (ESN). The method for getting this data is named lineGetGeneralInfo. There is an example of using it next:

TCHAR* GetImeiEsn()


      DWORD       dwLineID;

      HLINEAPP    hLineApp = NULL;

      HINSTANCE   hInst=NULL;

      DWORD       dwReturn;

      DWORD       dwNumDevs = 0;

      LINEINFO    *g_lpLineInfo = NULL; // Array that contains all the lines’


      dwReturn = lineInitialize (&hLineApp, hInst,

                                           (LINECALLBACK) lineCallbackFunc,

                                            NULL, &dwNumDevs);


      if (! (g_lpLineInfo = (LPLINEINFO) LocalAlloc(

            LPTR, sizeof (LINEINFO) * dwNumDevs)))

            return NULL;


      if(dwReturn || (dwNumDevs==0)) return NULL;


      DWORD           rc;    

      TCHAR*          pszValue=new TCHAR[MIN_HW_VALUE];                     


      // Fill lpLineInfo[] for every line.

      for (dwLineID = 0; dwLineID < dwNumDevs; ++dwLineID)


            GetLineInfo (dwLineID, &g_lpLineInfo [dwLineID],hLineApp);


         if (rc = lineOpen (

                  hLineApp,              // Usage handle for TAPI

                  dwLineID,                  // Cannot use the LINEMAPPER value

                  &g_lpLineInfo->hLine,  // Line handle

                  g_lpLineInfo->dwAPIVersion, // API version number

                  0,                          // Must set to zero for Windows CE

                  0,                          // No data passed back

                  LINECALLPRIVILEGE_NONE,     // Can only make an outgoing call

                  0,                          // Media mode

                  NULL))                      // Must set to NULL for Windows CE





            LINEGENERALINFO LineGeneralInfo;

            memset( &LineGeneralInfo, 0, sizeof(LineGeneralInfo));

            LineGeneralInfo.dwTotalSize  = sizeof(LineGeneralInfo);                    


            rc = lineGetGeneralInfo(g_lpLineInfo->hLine, &LineGeneralInfo);




                  case LINEERR_RESOURCEUNAVAIL:

                  case LINEERR_INVALLINEHANDLE:

                  case LINEERR_STRUCTURETOOSMALL:

                  case LINEERR_INVALPOINTER:

                  case LINEERR_UNINITIALIZED:

                  case LINEERR_OPERATIONUNAVAIL:

                  case LINEERR_OPERATIONFAILED:

                  case LINEERR_NOMEM:

                        return NULL;



            memcpy(pszValue, (TCHAR*)((&LineGeneralInfo)+LineGeneralInfo.dwSerialNumberOffset),



            return pszValue;



      return NULL;


Previous sample is a little more difficult than other methods because lineGetGeneralInfo uses the Telephony Application Programming Interface (TAPI) and then phone line must be initialized, opened and then read. By the way, TAPI can be used to query much information about phone line (usage, statics and so on).


Methods mentioned here are the most common used by getting the device id, so evaluate your current need and use the one which suits you best.


Tips para migrar una App WinCE.Net 4.2 a Win Mobile 6.1 Classic

Este es un post bien corto; resulta que ando migrando una aplicaciòn a WM 6.1 Classic y me he encontrado algunos errores que he resuelto con los siguientes tips:
1-En Windows CE .Net 4.2 el mètodo Dispose era asì:
    <System.Diagnostics.DebuggerNonUserCode()> _
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing AndAlso components IsNot Nothing Then
End If
End Sub
Y en Windows Mobile es asì:
    Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
End Sub
Por favor reemplacen ese mètodo.
2- En Windows CE .Net 4.2 no existìa el concepto de “code behind”, por lo cual la declaraciòn e inicializaciòn de los controles gràficos ocurrìa en el mismo archivo. Por favor muevan todo lo relativo a UI en Form.Designer.vb
3-En Windows Mobile 6.1 Classic se ha agregado el siguiente atrobuto al siguiente mètodo:
    <System.Diagnostics.DebuggerStepThrough()> _
Private Sub InitializeComponent()
4-En Windows Mobile CE .Net 4.2 las formas tenìan la propiedad AutoScaleMode en Inherit; deben cambiarlo a Dpi porque sino toda tu UI quedarà “agrupada” (superpuesta y desordenada).
5-Si desean depurar aplicaciones pero los breakpoint se deshabilitan y muestran el mensaje “The breakpoint will not currently be hit. No symbols have been loaded.” deben instalar una versiòn de desarrollo y redistribuìble en el dispositivo para que librerìas como “mscorlib.dll” retornen las cadenas de error correctamete.
Las siguientes dos imàgenes muestran el dispositivo WM 6.1 Classic:
La siguiente imagen muestra el dispositivo que ejecutaba Windows CE .Net 4.2 (pantalla blanco y negro, solo el logo inicial era a color):
6-El ultimo tip general es actualizar la versiòn del SDK con la que estàn trabajando; recuerden que su aplciaciòn puede llevar mucho tiempo y ya existen nuevas versiones. En el caso de los dispositivos Psion Teklogix, la ùltima versiòn del SDK es 3.4.
7-Tambièn revisen en la documentaciòn o pregunten en los foros si las nuevas versiones implementan patrones diferentes; miren en este foro un ejemplo de lo anterior: http://tinyurl.com/PortingWM6-1

Microsoft Most Valuable Professional – MVP Windows Mobile

Hola a todos quienes leen este blog!,
Acabo de recibir la noticia que fui premiado como Most Valuable Professional – MVP en Windows Mobile.
Wow, que puedo decir? Es el reconocimiento al expertise en desarrollo en la plataforma y al trabajo en comunidad, largas noches enseñando a principiantes sobre la tecnología después de una dura jornada laboral, días completos metidos en salones aportando un granito de arena a la industria local, interminables reuniones  y mucho tiempo de autoestudio para estar en la punta de la tecnología en cuanto a desarrollo con C++ y C# para Windows Mobile. Pero todo hecho con pasión y pulso.
La lista de personas a las que he influenciado con este quehacer filantrópico es larga y tal vez no conozco ni a la mitad de ellos aunque ellos si me conocen. Desde Bucaramanga pasando por Cartagena y llegando a Bogota he tenido la fortuna de estar frente a diferentes audiencias desde el 2004.
Pero esto no hubiera sido posible si el guiño de Dios, mi familia y una interminable lista de personas/instituciones que son “Javier Andrés Most Valuable Partners”, aquí un breve resumen de ellos:
-La comunidad de desarrollo (no me alcanzaría la lista para nombrar los diferentes grupos!).
-Toda la gente valiosa de Aranda Software.
-Gente anterior y actual en Microsoft Colombia: Ricardo Marulanda, Andrés Felipe Otero, Sergio Victorio, Ivanov Cepeda, Roberto Erazo, @Warnov, Sandra, Maite, etc, etc. A todos ellos, cada uno de forma diferente, porque me han ayudado desde diferentes iniciativas (desde las Dot Net Cells, la CAM -Comunidad Académica Microsoft-, el programa Microsoft Influencers y ahora el programa Microsoft Activa) a convertir la tecnología en algo tangible (satisfacción propia y de los demás). Ellos ratifican la frase “Todo comienza con una oportunidad”.
-Gente de Microsoft e Intel en diferentes países: Andy G., Inga Bemman, Alan Page, Ken Johnston, Kathy Farrel, Gunjan Rawal, Lance Atencio, Andrew Schiestl, etc, etc. Todos ellos tienen dos grandes cualidades que adoro en una persona: humildad e inteligencia.
-Gente anterior y actual de Ineta: José Berrios, Nilda Díaz, Miguel Almeyda, etc..
-Universidades: San Buenaventura, Los Andes, Autonoma, Los Libertadores, Cooperativa, Fundación San José, Tecnológico Comfenalco, etc, etc…
-Diversas entidades: SENA, Ministerios, etc, etc…
Esta es solo una pequeña lista. Espero que pueda aumentar mi impacto con mi nueva medalla de boy scout.
Como siempre saludos y gracias,

Programando el acelerómetro en Windows Mobile


Como les comenté en un post anterior, Windows Mobile 6.5 a través del API de gestos soporta el touch, el acelerómetro y el sensor de reconocimiento de sonrisas, sin embargo solo el acceso al touch es genérico (universal) y desarrollado completamente por Microsoft, para los demás sensores se debe consultar información específica de cada fabricante. Este post describe el acceso al acelerómetro.

Antes de empezar, me gustaría comentar mi inconformidad porque los grandes fabricantes de hardware como HTC (entre otros) no proveen un SDK ni documentación para acceder a los sensores específicos del dispositivo. Esta es una actitud contraria a la filosofía Microsoft de documentar sus SDK’s e impulsar que los desarrolladores aprendan y recorran la curva de aprendizaje en el menor tiempo posible.

Un acelerómetro es un sensor que mide la rata de cambio de velocidad a través del tiempo; existen diferentes tipos de acelerómetros pero trabajaremos con el Micro-Electro Mechanical System de la HTC Diamond para medir el vector de aceleración en tres valores (ejes) como se muestra en la Figura 1.

Figura 1. Micro-Electro Mechanical System

Este sensor (así como el GPS) es un dispositivo más de entrada que puede ser abierto, leído y cerrado. El cálculo de si el dispositivo se desplazó o no debe ser realizado por la aplicación que lee el dispositivo a través de una comparación con una lectura anterior.

SDK para la HTC Diamond

Como HTC no provee un SDK oficial para acceder al acelerómetro (al igual que LG), entonces nos vemos en la necesidad de utilizar SDK’s no oficiales; existe un buen hacker llamado Scott que hizo ingeniería inversa del código ensamblador ARM de las DLL’s propietarias que proveen la funcionalidad de lectura del sensor de la HTC DIamond y lo compartió aquí.

Scott encontró que la DLL HTCSensorSDK.dll es la encargado del acelerómetro y contiene:

·         Métodos: HTCSensorOpen, HTCSensorClose y HTCSensorGetDataOutput


·         Estructuras: SENSORDATA

Y la DLL HTCAPI.dll es la encargada del soporte del API de gestos y contiene:

Métodos: HTCNavOpen, HTCNavSetMode y HTCNavClose



El procedimiento de lectura es similar al de un GPS porque debemos abrir el sensor con HTCSensorOpen, leerlo con HTCSensorGetDataOutput y cerrarlo con HTCSensorClose. La estructura SENSORDATA llenada por el método HTCSensorGetDataOutput contiene todos los valores X, Y, Z actuales de velocidad, por lo cual para calcular una aceleración debemos comparar una lectura actual con una anterior.

Pero el código anterior es no manejado, una versión C# P/Invoke del mismo está disponible aquí gracias a Koushik Dutta; el SDK construido por Koushit tiene una clase llamada HTCGSensor con un método llamado GetRawSensorData el cual utiliza el método nativo HTCSensorGetDataOutput y retorna un objeto vector de tipo GVector con las coordenadas de velocidad (X, Y,  Z) actuales. Gracias a estos dos héroes el acceso al acelerómetro de la HTC Diamond está ahora disponible para todos.

Aplicaciones que utilizan el SDK de la HTC Diamond

Si quieres ver el SDK no oficial en acción descarga esta aplicación de ejemplo de Chris Mitchell (Figura 2) la cual utiliza el sensor para subir o bajar el volumen del reproductor de Media Player cuando se agita (sacude) el teléfono.

Figura 2. Acelerómetro para el control del volumen.

El código que lee los datos del acelerómetro y que detecta si el teléfono está siendo agitado (sacudido) es simple como se muestra a continuación:

            //Get Sensor Date

            myGSensor1.GetSensorData(ref mySensorData);


            //Update screen with latest Sensor Data

            TiltX_txt.Text = mySensorData.TiltX.ToString();

            TiltY_txt.Text = mySensorData.TiltY.ToString();

            TiltZ_txt.Text = mySensorData.TiltZ.ToString();

            thetaX_txt.Text = mySensorData.AngleX.ToString();

            thetaY_txt.Text = mySensorData.AngleY.ToString();


            //Detect if the phone is being shook

            if (myGSensor1.DetectShake(mySensorDataOld, mySensorData, threshold_trackBar.Value * scalevalue, shakecounter, noshakecounter))




Otro ejemplo de acceso al acelerómetro a través del SDK es este juego desarrollado por nuestros amigos de PocketMax (Figura 3); el juego se llama LunarTilt y consiste en una nave espacial que se conduce con el acelerómetro.

Figura 3. LunarTilt: juego que utiliza el SDK no oficial para acceder al acelerómetro.


El acceso al acelerómetro depende del fabricante del hardware. En este artículo se explicó las características y métodos de acceso al HTC Diamond a través de un SDK no oficial hackeado por la comunidad de desarrolladores de dispositivos móviles.


Javier Andrés Cáceres Alvis




Entendiendo el API de gestos de Windows Mobile

Este artículo tiene como objetivo explicar que es, que no es y para qué sirve el API de gestos introducido en Windows Mobile 6.5. Antes de empezar, algunos de ustedes se preguntarán: ¿por qué es importante un API de Windows Mobile 6.5 si ya hay información disponible sobre Windows Phone?, la respuesta es simple, el llamativo touch (y los controles) del Windows Phone fue construido sobre el API de gestos.

El término sombrilla API de gestos cubre el reconocimiento de sonrisas, el touch y el manejo del acelerómetro (Figura 1). La arquitectura de esta API separa el reconocimiento del procesamiento de cada input y deja en manos del OEM el soporte de todos los sensores excepto el touch. Por esta razón la documentación genérica que Microsoft ofrece relativa al API de gestos solo cubre el touch (input recognizer); si necesitas buscar información relativa a acelerómetros o reconocimiento facial debes buscar en la documentación específica del fabricante del dispositivo. Este artículo hace énfasis en el input recognizer.

Figura 1. Reconocimiento y tratamiento separado de mensajes.


El input recognizer marca la diferencia entre un simple click de mouse y el API de gestos porque soporta no solo el click derecho sino el scroll, pan, select, hold y doublé select (Figura 2). El concepto más importante detrás de este nuevo componente es el nuevo mensaje WM_GESTURE y el Physics Engine.



Para todos los programadores C++ el manejo de los mensajes que recibe la ventana principal de una aplicación es algo cotidiano; para los desarrolladores en código manejado no. El soporte para la nueva interacción (no solo click derecho) es gracias a un nuevo mensaje llamado WM_GESTURE el cual conecta el manejador del evento con el generador del evento para soportar la interacción mostrada en la Figura 2.

Figura 2. Casos soportados por el Input Recognizer.


El código para manejar este nuevo mensaje es:

            case WM_GESTURE:


                  GESTUREINFO gi = {sizeof(GESTUREINFO)};

                  if (TKGetGestureInfo((HGESTUREINFO)lParam, &gi))


                        switch (wParam)


                        case GID_SELECT:


                        case GID_HOLD:


                        case GID_DOUBLESELECT:


                        case GID_PAN:


                        case GID_SCROLL:






Si observaron detenidamente el método TKGetGestureInfo y la estructura GESTUREINFO son los encargados de encapsular toda la funcionalidad, por lo cual si tu aplicación móvil C++ quiere soportar el touch recognizer debes agregar el manejador para ese nuevo mensaje. La buena (y única) noticia para los desarrolladores en código manejado es que el Compact Framework reconocerá ese nuevo input automáticamente.


Physics Engine

Cuando interactuamos directamente con nuestros dedos (y fuerza) con la pantalla del dispositivo para por ejemplo desplazar hacia abajo una barra de scroll, nos surge la pregunta: ¿cuál debería ser la respuesta natural correcta en términos de velocidad?. Pues bien, esa misma pregunta se la hicieron los investigadores en Microsoft para saber que tan sensible es el ojo humano frente al movimiento y la respuesta fue el Physics Engine.


El Physics Engine es usado para crear animaciones en donde la velocidad y el scroll juegan un papel importante dentro y fuera de los límites de la pantalla. La diferencia con el scroll normal de nuestros equipos desktop es que el usuario cuando desplaza un scroll usando los dedos espera ver desplazamiento natural (“suavizado”) pixel por pixel.

Los siguientes controles utilizan (de fábrica, sin hacerles nada) el Physics Engine:

·         Listview

·         Listbox (incluye el combo)

·         Webview

·         Treeview

·         Tab (scroll left / right to change page)

La mala noticia para los desarrolladores en código manejado (C#/VB.NET) es que las actualizaciones del CF 2.0 ó 3.5 no incluyen nada para el API de gestos, solo el soporte por default antes mencionado, es decir si quieres crear un control para que una ventana permita una interacción natural semejante a la del iPhone o Android debes desarrollarla en C++, que es donde está disponible la estructura PHYSICSENGINEINIT, la cual permite inicializar y manipular el Physics Engine para crear animaciones como la que el usuario espera cuando por ejemplo selecciona un área y la maximiza (Figura 3).

Figura 3. Animación creada con el Physics Engine.


Como comente en la introducción, Windows Phone hace uso extensivo de interfaces que responden a la física de los movimientos que nosotros creemos, por ejemplo cuando se  navega de forma horizontal/vertical a través de los Windows Phone hubs.  Finalmente quisiera comentar que siempre tenemos a nuestra disposición el P/Invoke para utilizar la funcionalidad que aún no está disponible en código manejado. Les recomiendo esta fuente para más información y autoestudio: http://msdn.microsoft.com/en-us/magazine/ee309880.aspx



Javier Andrés Cáceres Alvis

Consejos de seguridad anti-robo para Windows Mobile

Hola a todos,
Quisiera iniciar por aclarar que este artículo no es sobre las implicaciones (o modelos) de seguridad en el desarrollo con Windows Mobile, pero si necesitan información al respecto les comparto este enlace: http://technet.microsoft.com/en-us/library/cc512651.aspx.
Bueno aclarado ese punto, también quiero decirles que definitivamente no se puede prevenir el robo (o hurto) de tu movil, lo único que si puedes hacer es tomar acciones preventivas para mitigar la pérdida de información y el robo de identidad.
La historia empieza en Junio del 2009 cuando encontré una funcionalidad de bloqueo (lock) del teléfono adicional a la ofrecida ofrecida por la SIM, esta funcionalidad está en Settings>Lock como muestra la siguiente imagen:
Este nivel de seguridad a nivel del sistema operativo te obliga a ingresar una contraseña cada vez que quieras interactuar con el teléfono excepto cuano contestas una llamada y cuando realizas una llamada de emergencia. Durante el tiempo que utilicé ese nivel de seguridad  estuve tentado varias veces a abandonarla por el paso adicional que esto implica (inclusive debes suministrar la contraseña cuando te conectas al desktop por activesync).
Pues el final de la historia fue el pasado sabado 27 de Marzo cuando me robaron el celular mientras iba camino a mi clase de postgrado en un transporte público; ¿que puedo decir? no acostumbro a tomar ese medio para esa ruta, pero fue uno de esos dias en que la oportunidad y la delincuencia se encuentran. Puedo decir que vivimos en una ciudad insegura, que los políticos hacen que perdamos el foco de lo que significa calidad de vida y miles de críticas, pero limitaré mi opinion a lo técnico.
Como mi celular iba bloqueado, ¿que riesgo estoy corriendo? Bueno, imagino que existirá alguna forma de desbloquearlo y acceder a la información que allí tenía a través de algun medio de alta ingenierá (que no dañe ninguna de las partes del dispositivo) pero estoy seguro que los ladrones no podrán hacerlo dada la alta complejidad y baja ganancia que esto implica.
De lo que si estoy seguro es que si son algo listos, llegarán a la conclusión que la forma de hacerlo es mediante un hard reset, la cual borra todo (inclusive mis datos Risa) porque si hacen un soft reset la protección se mantendrá. Vale la pena aclarar que no tenia nada importante en mi celular porque no acostumbro a “cargar” información y cuando lo hago es mediante internet o en última instancia en una memoria USB.
Bueno,les recomiendo mantener su celular bloqueado (lockED), porque esta seguridad es mayor que la ofrecida por el PIN/PUK. También les recomiendo no mantener información importante en sus teléfonos porque no sabemos cuando nos encontremos un ladrón.
Métodos de bloqueo:

Charla UniAndes – Windows Mobile

Hola a todos,
El pasado Martes 23 de Febrero asistí a una charla sobre desarrollo en Windows Mobile para estudiantes de pregrado y postgrado de la Universidad de Los Andes. Mi objetivo principal fue mostrar todo el portafolio de opciones diponibles para el desarrollo, empezando con C++ (nativo), C#/VB (manejado) y Widgets (Web: HTML+CSS).
En general los estudiantes son siempre un publico bastante critico que aprecia la calidad, por lo cual estos escenarios siempre me han sido favorables y excelentes para conocer de primera mano lo que los futuros jugadores de industria piensan acerca de la tecnología. Quiero agradecer a los profesores Hernán Castro y Claudia Jimenez por la amable invitación y logística del evento.
Durante la charla, un asistente sin dispositivo Windows Mobile quiso conocer más sobre el desarrollo de Widgets pero desafortunadamente no pude compartirle mi demo por el requerimiento de plataforma, sin embargo pude mostrarle el concepto a través de los Mobots (http://mobots.org/) que aunque son menos robustos y soportados, comparten algo de la filosofía de lo Widgets.
Para quienes tengan la misma restricción de ese estudiante, también los invito a conocer los MoBots desde su plataforma para que aprecien e incrementen su expectativa en Windows Mobile:

Stacks de Bluetooth en Windows Mobile

Cuando necesitas acceder al hardware Bluetooth en Windows Mobile debes tener en cuenta la implementación que tu dispositivo utiliza para poder acceder a la información correctamente. Existen al menos dos tipos de stacks (implementaciones) de Bluetooth en Windows Mobile: una de Microsoft y una de BroadComm.

Las dos implementaciones son iguales y transparentes para el usuario final, pero a bajo nivel las dos utilizan interfaces de programación diferentes. Para el caso de Microsoft existe un API de Win32 para el acceso al dispositivo Bluetooth cuya función principal es BthGetHardwareStatus. Como siempre comento en las presentaciones la información para Windows Mobile depende de la versión subyacente de Windows CE, por lo cual la documentación de esta API viene con Windows CE .NET 4.2.

Para utilizar el API para Bluetooh de Microsoft estáticamente debes incluir el archivo de cabecera Bt_api.h y a las dependencias Btdrt.lib y btdrtstubs.lib como se muestra en la Figura 1.

Figura 1. Dependencias adicionales.

En el caso del stack Bluetooth de Broadcomm debes descargar el SDK disponible aquí. De dicho SDK debes incluir el archivo de cabecera BtSdkCE.h y hacer referencia a la librería BtSdkCE30.lib. El método para iniciar con la implementación de Broadcomm para acceder al dispositivo es IsDeviceReady().

Ahora pasemos al código. En cualquier dispositivo (Smartphone o Pocket PC) que quieras acceder al stack de Microsoft o Broadcomm debes primero activar el hardware, en mi caso la activación se muestra en la Figura 2. Sino activas el hardware, el código determinará que Bluetooth no existe.

Figura 2. Activación de Bluetooh.

Después de activar el Bluetooth, inicia un nuevo proyecto Smart Device en C++ y copia y pega el siguiente código:


      Autor: Javier Andrés Cáceres Alvis


      El siguiente código es para própósitos académicos, por lo cual

      no tiene garantía alguna.



#include “stdafx.h”





#define MIN_HW_VALUE 32


void ParseManufacturer(unsigned short usManufacturer, TCHAR *pszValue)






            … Muchos otros


            case 13:








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



      int errorCode=0;

      int btStatus=0;






            if(btStatus!=HCI_HARDWARE_NOT_PRESENT && btStatus!=HCI_HARDWARE_UNKNOWN)


                  HRESULT     retValue=E_FAIL;            

                  unsigned char phci_version;

                  unsigned short phci_revision;

                  unsigned char plmp_version;

                  unsigned short plmp_subversion;

                  unsigned short pmanufacturer;

                  unsigned char plmp_features;





                             TCHAR pszManufacturer[MIN_HW_VALUE];


                             wsprintf(TEXT(“El fabricante es %s”),pszManufacturer);






      return 0;



El código anterior es simple, utiliza el stack de Micrtosoft y por facilidad solo accede a hardware de Texas Instruments. La primera pregunta que se le podría a cualquiera ocurrir, es ¿qué pasa cuando se ejecuta el código anterior en un dispositivo con stack Broadcoom?; la respuesta es sencilla, el stack de Microsoft determina que existe hardware de Bluetooth, pero el método BthReadLocalVersion no puede acceder a la información correspondiente. En mi caso ejecuté el código en una HP iPAQ h4150 y en una HP iPAQ Voice Messenger (Figura 3), las cuales tienen implementaciones de Broadcomm y Microsoft correspondientemente.

Figura 3. Stack de Broadcomm y Microsoft en dispositivos HP.


Finalmente, el código equivalente para acceder a implementaciones de stack de Broadcomm es algo como lo que sigue:




                             CBtIf broadInfo;




                                   DEV_VER_INFO dvInfo=(DEV_VER_INFO) sizeof(DEV_VER_INFO);












Bueno llegué al final de mi post, espero que les ahorre mucho tiempo.




Javier Andrés Cáceres Alvis


Un vistazo a Windows Mobile 7

Hola a todo@s,

Así como lo leyeron, ya existe información disponible sobre la próxima version de Windows Mobile 7 code-named “Photon”.
Esta versión se liberará a mediados del 2010 y será el sucesor del actual Windows Mobile 6.5.
Con la venida del iPhone Microsoft se concentró en mejorar la experiencia del usuario que interactúa por medio del touch y en esta versión se contará con touch motion y flicking a finger up/down (para reemplazar la barra de desplazamiento), entre otros.

En la siguiente imagen se puede apreciar algo de lo anterior.

Según la fuente citada, se podrá interactuar con el sistema a través de gestos (por supuesto, en dispositivos con cámaras) y del nuevo hardware incluido en los teléfonos recientes (acelerómetros, etc). Además en look and feel será mejorado respecto a su antecesor para ser coherente con Windows 7 (el de escritorio) e integrado con Silverligth.

NVidia ha comenzado a fabricar teléfonos para esta versión de Windows y se anuncian varios servicios basados en la nube. Con todo lo nuevo, no resta más que esperar para tener este juguete. De acuerdo a algunos rumores, en esta versión Microsoft unificará sus versiones Professional (antes Pocket PC) y Standard (antes Smart Phone) en un sistema operativo más preparado para los nuevos escenarios (por ejemplo, hoy en día hay mejor cobertura WiFi). Fuente citada.

Saludos a todos,

Javier Andrés Cáceres Alvis
Blog Personal: http://speechflow.spaces.live.com/
Blog Intel: http://software.intel.com/en-us/blogs/author/javierandrescaceres/

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑