Windows CE, "accel_c", el catálogo y LMQMP

Sí, ya sé que el título es extraño, pero me ha hecho perder tres días completos como si nada… Pero comencemos por el principio.

A veces veo muertos… digoooo… a veces me tengo que pelear con el Windows CE para modificar nuestra plataforma para algún cliente. Lo cierto es que debería hacerlo la empresa propietaria de la placa, pero éste prefiere delegar en mi, seguro que para quitarse el muerto de encima.

Teóricamente la creación o modificación de una plataforma existente debería ser algo trivial, tan trivial como abrir el Platform Builder con el proyecto adecuado, quitar y poner cosas del catálogo, recompilar y listo. Al cliente se le distribuye el eboot.nb0 y el nk.bin.

Pero de la teoría a la práctica va un gran trecho. En general un cambio en algunos componentes significa que otros dejan de funcionar por dependencias incompatibles, y también en general dichas dependencias ni están todo lo claras que deberían, ni a veces existen.

En mi caso actual me han pedido un servidor ftp y uno web con asp y javascript, así como soporte para ATL y ASP. El asunto es teóricamente sencillo: ir añadiendo los componentes desde el catálogo, recompilar y listo.

Pues no. Tras una compilación aparentemente exitosa, el proceso «gwes.exe» se caía al arrancar, con lo que dejábamos de tener bucle de mensajes y sonido… Como esta compilación es sin pantalla, no disponemos de ella desde el principio, pero si la tuviéramos también la habríamos perdido.

Tras solucionar el tema del «gwes.exe» (un pequeño cambio en el driver dummy de vídeo de la placa, cosa de Cirrus Logic), resulta que ahora el CE no ve ni la tarjeta SD ni es capaz de conectarse al Visual Studio 2005SP1 para depurar… porque la placa no es capaz de cambiarse la IP y porque sigue habiendo algo mal.

Vale, lo de la SD ya me ha pasado antes: me falta incluir a mano en el «project.bib» una DLL que si no está el sistema no es capaz de verla y no encima no protesta…

Seguimos con lo nuestro. Ahora falta que el TCP/IP vuelva a funcionar, porque finalmente, tras añadir todo lo anterior, ni el servidor ftp ni el web funcionan, y menos aún la opción de conectar al Visual Studio 2005…

Y comienza el baile. Nada de lo que hago hace que funcione. Ni siquiera volviendo a la plataforma original: por algún motivo algo dentro del CE se ha ido al carajo. La solución en este caso siempre ha sido regenerar la plataforma desde cero, es decir, un clean total y volver a compilarlo todo. Nada, sigue fallando. La solución drástica: máquina virtual nueva y todo desde cero.

Ya empiezan a salir cosas, dependencias que faltan. Compilaciones que fallan. Todo ello debido a referencias que faltan. Es decir, ATL necesita MINGWES o GWES, pero no lo dice. MINGWES necesita MINGDI pero tampoco lo dice. Y así con unas cuantas dependencias, hasta que al final me quedo con tres funciones relativas a los aceleradores de teclados (es decir, el que funcionen los atajos de teclado como CTRL-C y que una aplicación pueda procesarlos a través de su bucle de mensajes, que no tiene mucho sentido en un dispositivo que no va a llevar ni teclado ni ratón ni monitor, pero bueno).

INTERLUDIO: Por todo ello deduzco que tanto el Platform Builder como la propia máquina virtual estaban corrompidas de algún modo; la cuestión pendiente es porqué una VM se ha corrompido de esa forma… Pero dejemos el tema y volvamos a lo nuestro:

La cuestión ahora consiste en que no encuentro esas dependencias de ninguna manera, pero hay truquitos, sacados de blogs de gente de Microsoft. Primero vamos a encontrar a qué componente del catálogo pertenecen esas funciones.

Nos vamos a C:WINCE500PRIVATEWINCEOSCOREOSCOREDLLcoredll.def y buscamos una de las funciones que faltan. El valor es COREDLL_ACCEL_C, es decir, «accel_c». Esa es la dependencia que tenemos que buscar.

Nos vamos a la MSDN y efectivamente, aquí esta. ¡Tachán! El componente se llama «Shell»… Añadimos la dependencia y… y… y… nones, seguimos teniendo el problema. Probamos varias shells: ninguna va, o más bien ninguna tiene dentro lo que la documentación dice que debe tener.

Pero uno, como es perro viejo, mira un poco, pone en marcha su sexto sentido y la lógica más abstrusa y añade el componente MINWMGR, que, evidentemente, tampoco funciona.

Hala, a buscar en los foros. No hay nada de nada. Alguien comenta con otro problema similar que se añada a CESYSGEN.BAT la variable de entorno COREDLL_COMPONENTS y se añada a mano el «accel_c». Que si quieres arroz Catalina.

Finalmente, la solución drástica: una búsqueda total en todo el árbol del Windows CE, pese a haber encontrado algo en la documentación pero que tampoco funciona; la documentación decía que para encontrar dependencias «extrañas» hay que ir al CESYSGEN.BAT del Sistema Operativo y buscar dicha dependencia y ver cuál es su padre: pues resulta que en ningún CESYSGEN.BAR está «accel_c», por lo que decido la búsqueda total por contenido de archivo.

Al final me aparece otro fichero BAT que sí la tiene: C:WINCE500PUBLICCEBASEOAKMISCwinceos.bat. Y, pese a la mala documentación, a los blogs mentirosos y a mucha gente que no tiene casi ni idea de lo que habla, el menda la ha encontrado, y tras mirarse con detalle las cosas, determina

¡que la dependencia está en MINWMGR!

Ya es el colmo. ¡Está ahí pero no compila!… ¿Más corrupción de ficheros? Pues sí, tras marcar «Clean before building» en las opciones del Platform Builder, la cosa compila bien…

Pero el proceso «gwes.exe» continúa petando, justo como al principio de todo.

Para evitar que el proceso «gwes.exe» explote, la solución correcta es añadir el driver de vídeo de la BSP completo, así que lo añado y ya no peta… pero sigo sin poder conectar con el VS2005SP1 y ahora tengo otros errores relativos a un teclado y un ratón PS/2 que no existen y que no pueden existir ya que la placa no tiene puertos para ello. Tras cambiar el driver completo por el dummy, ahora tengo errores sobre que no he definido ningún lenguaje por defecto… y tengo el English(US) definido…

Y llevo cuatro días con esto.

Y los que me quedan. Seguiremos informando, pero ya os podéis hacer una idea de la gente que está haciendo PDAs y aparatos similares con Windows CE… Y ahora que no me salga ningún fundamentalista linuxero diciendo que con Linux eso no pasa, os puedo asegurar que las aventuras bajo Linux son mucho, pero mucho peores…