Ojito con la nueva Beta de Windows Live Essentials

Actualización, 3/7/2010

Me gustaría hacer algunas matizaciones a esta entrada justo cuando ha pasado más o menos una semana, y es que resulta que los problemas que yo he padecido son bastante comunes en esta instalación pero no universales, y parece ser que una parte importante de ellos se deben al instalador que elegí. Originalmente había dos, uno clásico que te permitía instalar los productos que quisieras y otro moderno que se lanzaba al ruedo sin preguntar nada de nada.

Este último fue rápidamente retirado por parte de Microsoft, porque ciertamente era un instalador demasiado applesiano, cosa que no pega, ni con cola, con el concepto Microsoft de la informática… En mi caso, ignoro cómo fui redireccionado a tal enlace de descarga… En plan broma, y tomando un principio antrópico personal conspiroparaonico, quizás Microsoft me redireccionó a él como prueba: “si al rano le va bien, le irá bien a todos”, conocida es mi característica personal de sacar, inmediatamente, los más obtusos, oscuros e increíblemente extraños bugs de un software (eso tiene una contrapartida buena, y es que mi software me falla a mí y a nadie más). 🙂

Bueno, volviendo al tema, personalmente creo que todos mis problemas vienen del hecho de que, durante la instalación, se aplican una serie de actualizaciones a Windows al más puro estilo Windows Update, cosa que considero inaceptable ya que no es el camino adecuado, porque entonces aquellos que tengan el Live instalado tendrán otro Windows diferente a quien no. Y esas actualizaciones se llevan mal con algo que yo tengo instalado. Ignoro qué puede ser, porque drivers y cosas raras, conocida la fama de Windows de no reaccionar bien ante drivers mal hechos (léase con tono satírico e irónico), tengo los imprescindibles. Varios Jungo y un osciloscopio que únicamente lleva un INF por driver.

Además, parece ser que MS no aprende, y ya tiene la separación forzada de Office y Windows para que venga a cometer los mismos errores en Windows Live, que encima no le llega ni a la suela de los zapatos en calidad. Y desde luego no es la forma correcta de que un programa de usuario añada funcionalidades para sí. El sistema sólo debe ser parcheado por los Service Packs y por las actualizaciones de Windows Update, y menos aún si encima esas actualizaciones las ha hecho la misma gente que el producto Live… que parece ser no son muy buenos en su tarea (a la vista están los grandísimos problemas de las Wave anteriores de Windows Live Mail, y no digamos ya los jaleos que el Movie Maker y el Photo hacen con los runtimes de C++, en lo que Windows tiene que meter baza y redirigirlos al adecuado).

Bueno, el tema está en que no es fiero el lobo como el rano lo pinta, aunque es cierto que hay mucha gente que tiene problemas con esta beta, y si no, que lea los comentarios a esta entrada y/o se de una vuelta por los foros adecuados.

Y ahora sí, ahora la entrada original:

Me corroe las entrañas la indignación e impotencia ante lo que me ha pasado por culpa de los chapuceros (no hay otra palabra de menor calificación aunque sí muchas de mayor). Lo que viene abajo fue escrito en un principio para publicarlo aquí, pero mientras consultaba cosas con otro MVP sobre el tema ha saltado la liebre bien saltada:

 

No instales esta beta de Live si piensas desinstalarla luego, porque no podrás y no volverá a funcionarte la versión anterior del Live, restauración del sistema incluida. De hecho, excepto el Messenger, nada de lo anterior me funciona, incluso Visual Studio 2010 me peta (qué tendrá que ver el tocino con la velocidad)… No puedo ni ejecutar los programas del live anteriores ni el desinstalador/instalador para recuperarlos, y un System Restore tampoco funciona. Ahora voy a probar a recuperar de una copia de seguridad que hice el lunes…

En resumen:

 

Si quieres que tu sistema siga funcionando bien, no instales la Beta del Windows Live Essentials.

 

Y ahora la entrada original tal y como estaba concebida:

Los que leáis otros blogs de Geeks, así como otros relacionados con Microsoft o que presenten las novedades de la compañía, habréis visto que ha salido una beta de los productos Live de escritorio. A saber: Windows Live Mail, Windows Live Messenger, etc.

Os adelanto que si no os gustan las Ribbon mejor no los instaléis, porque casi todos traen una como interfaz de usuario. Personalmente creo que la cinta es una gran idea, un menú completamente abierto y visual, pero conozco a gente que la odia con toda su alma.

No obstante no he venido aquí a hablar de eso, sino de la suite completa y de cómo se instala y desinstala.

Dado el grado de descerebramiento habitual en muchos de nosotros a la hora de presentar novedades de Microsoft a tontas y a locas –sólo hay que leer cualquier blog que lo anuncie-, a veces comunicamos cosas sin avisar a los que nos leen del peligro que entrañan.

Y este es el caso que nos ocupa.

 

Os voy a contar algunas de las cosas que considero intolerables en el caso de Windows Live Essentials, y lo hago antes de que caduque mi MVP (el 1 de julio sabré si sigo o no) para que, en el caso de que no me renovaran, nadie lo tome como una venganza del hecho.

Microsoft cada vez está cayendo más bajo. Unas veces se trata de la poquísima calidad de sus productos (léase .NET Compact Framework), o el abandono, sin más, de ellos tras dos años de su creación (Visual J#), o ambas cosas (de nuevo el Compact). Y lo que es peor, a veces se abandonan sin decírselo al usuario y cliente (¿por qué será que de nuevo aparece el Compact?). Hay más elementos que confirman lo dicho (al menos para mí), pero no es el tema de esta entrada.

 Yo suelo instalarme las versiones en inglés por dos motivos. El menos válido ahora es que el código de los productos en inglés suele (solía) ser más moderno que el de las versiones localizadas (por aquello de parar para traducir), pero desde que utilizan paquetes MUI para casi todo eso ya no es cierto (o así quiero creerlo ya que nunca he hecho la prueba). El más válido es que suelen salir antes (y tampoco es el caso de ahora), pero como gato escaldado del agua fría huye…

 

1.       La primera en la frente: no me deja elegir qué instalar. Bajo el programa, lo lanzo, y se instala. Sin más. Sin decirme siquiera que se va a instalar. Hay quien dice que sí el ofrece, pero a mi no lo ha hecho, y lo he probado varias veces.

2.       La barra de BING ocupa media pantalla del IE. Es altísima, y como tengas una pantalla con baja resolución, te tapará la mitad de la pantalla.

3.       El Live Mail no está mal, pero adolece de una carencia completamente inaceptable desde mi punto de vista: no se le puede añadir un acceso directo para ir al siguiente mensaje sin leer ni en la ribbon ni en los iconcitos de arriba a la izquierda. Es decir, no puedes acelerar la opción más útil del programa.

4.       El atajo de teclado Ctrl-U (al menos en inglés) es el que salta entre mensajes sin leer: no funciona muy bien, quiero creer que lo arreglarán, pero visto el punto 3… me hace dudar de ello.

5.       Desinstalé y ya no puedo reinstalar. El instalador peta a medio hacerlo, dejando el sistema nadie sabe en qué estado… y llevándose entre medias otros programas que estaban en ejecución…

6.       Si instalar no te permite elegir qué instalar, desinstalar sí, pero aunque elijas todo, te deja un montón de cosas sin eliminar, entre ellas la estúpida y esteroídica barra de BING.

7.       Si tienes el “Community Forums NNTP Server”, la instalación lo romperá y te tocará volverlo a instalar (Estropea el “Live Signin Assistant”).

8.       Hace un punto de restauración DESPUÉS de instalar, pero no ANTES, por lo que la limpieza total de programa se hace imposible. En una versión final podría ser aceptable, pero en una beta es completamente inaceptable e inapropiado.

 

La verdad es que el instalador/desinstalador deja muchísimo que desear, así como algunas opciones. Para mi es completamente inaceptable todo lo que he comentado aquí. No obstante, parece que Windows Live Mail ha sido sensiblemente mejorado aunque no he comprobado si los bugs históricos en relación a las news han sido solucionados o no (quiero creer que sí, pero no me fío, y menos desde que ya no hay comunidades nntp por parte de Microsoft)…

 

Básicamente, mi recomendación es que no lo instaléis.

Compilar QT para Windows CE (y Windows Mobile) con Visual C++

Bueno, siguiendo con la tónica de las compilaciones de QT, ahora le toca el turno a la versión para Windows CE. Aquí la apuesta sube, porque no es todo tan automatizado como las compilaciones más estándar, aunque lo cierto es que no es tan complicado y tan sólo hay que llevar algo de cuidado al hacerlo.

En primer lugar necesitamos una versión de Visual C++ compatible con dispositivos embebidos. En mi caso será Visual Studio 2008SP1 Team System, pero también valen versiones inferiores o anteriores, aunque no posteriores porque, de momento, Visual Studsio 2010 no soporta desarrollos para Windows CE ni ningún otro Windows Mobile.

Una vez que tengamos dicha versión, tenemos que instalar correspondiente SDK de Windows Mobile. En el caso que nos ocupa, será un SDK de Windows CE 5.0 que yo mismo he generado y que ya he publicado en entradas anteriores.

La instalación ha de ser cuidadosa, sobre todo en Windows Vista y 7, ya que los instaladores de Windows Mobile 5 e inferiores fallan silenciosamente y, aunque parece que el SDK está instalado, falta algo y luego no funcionará bien.

Para hacerlo bien, seguimos los siguientes pasos:

  1. Desactivamos UAC.
  2. Reiniciamos el ordenador.
  3. Instalamos el SDK
  4. Volvemos a reiniciar.
  5. Ejecutamos la versión correspondiente de Visual Studio.
  6. Cerramos Visual Studio.
  7. Activamos UAC.
  8. Reiniciamos.

Seguid el proceso exactamente como está descrito y todo funcionará perfectamente bien.

***

Ahora le toca a QT. Vamos a la web de Nokia y nos bajamos la versión Open Source correspondiente a Windows CE, que no es otra cosa que el SDK normal y corriente pero sólo con el código fuente. Generalmente es un ZIP, que debemos descomprimir sobre alguna carpeta sin espacios en blanco. Yo lo tengo en C:QTce-4.6.3, y de ahí cuelgan las carpetas del SDK (bin, src, etc).

En el caso de que vayáis a usar mi SDK, u otro generado con el Platform Builder 5, hay que realizar una serie de pasos extra. Si vais a usar un SDK oficial de Microsoft, nos podemos saltar los pasos siguientes.

Nos vamos a la carpeta C:QTce-4.6.3mkspecs, y ahí veremos una serie de carpetas que se corresponden con cada compilación posible. Veremos una espuerta de Linuxes y Unixes, y también una serie de carpetas que tienen una pauta como “wince50<nombre>-<procesador>-msvc<Versión>”.

Si os fijáis, hay soporte automático para Windows CE 5, Windows CE 6, Windows Mobile 5 (Pocket y Smart), Windows Mobile 6 y 6.5 en todas sus variantes. Y encima para Visual C++ 2005 y 2008. Pues bien, de esas carpetas es de dónde sacan las herramientas de QT la información para compilar. Y como podréis comprobar, no hay ninguna con el nombre de mi SDK o de cualquier otro.

Tenemos que crear una de ellas con nuestra configuración. Mientras no hayamos creado un SDK que se aparte mucho del estándar, los cambios son sencillos.

Lo primero es copiar la carpeta que más se acerque a nuestro SDK. En mi caso ha sido “wince50standard-armv4i-msvc2008”. Yo la he renombrado a “wince50custom-armv4i-msvc2008”. Entramos en ella y abrimos el fichero “qmake.conf”. Vemos que simplemente incluye al “qmake.conf” de la misma configuración de Visual C++ 2005 y cambia la versión del compilador.

Nosotros, para evitarnos rollos, hemos creado uno desde cero juntando ambos, y grabándolo en nuestra carpeta. El contenido para mi SDK es el siguiente:

#
# qmake configuration for wince50standard-armv4i-msvc2005
#
# Written for Microsoft VC2005.NET with Standard SDK for WindowsCE 5.0 (ARMV4I)
#

include(../common/wince/qmake.conf)

CE_SDK = WindowsCE5Emulator

CE_ARCH = ARMV4I

DEFINES += STANDARDSHELL_UI_MODEL _WIN32_WCE=0x500 $$CE_ARCH _ARMV4I_ armv4i _ARM_ ARM _M_ARM ARM __arm__ Q_OS_WINCE_STD QT_NO_PRINTER QT_NO_PRINTDIALOG

QMAKE_CFLAGS += -QRarch4T -QRinterwork-return

QMAKE_LFLAGS_CONSOLE = /SUBSYSTEM:WINDOWSCE,5.00 /MACHINE:THUMB /ENTRY:mainACRTStartup

QMAKE_LFLAGS_WINDOWS = /SUBSYSTEM:WINDOWSCE,5.00 /MACHINE:THUMB

QMAKE_LFLAGS_DLL = /SUBSYSTEM:WINDOWSCE,5.00 /MACHINE:THUMB /DLL

QMAKE_LIBFLAGS = $$QMAKE_LFLAGS_WINDOWS

QMAKE_LIBFLAGS_RELEASE = /LTCG

QMAKE_LIBS = corelibc.lib

QMAKE_LIBS_CORE = corelibc.lib ole32.lib oleaut32.lib uuid.lib commctrl.lib coredll.lib winsock.lib

QMAKE_LIBS_GUI = ceshell.lib ole32.lib $$QMAKE_LIBS_CORE

QMAKE_LIBS_NETWORK = ws2.lib

QMAKE_COMPILER_DEFINES -= _MSC_VER=1400

QMAKE_COMPILER_DEFINES += _MSC_VER=1500

Tan sólo hemos cambiado el nombre del SDK original por el mío:

CE_SDK = WindowsCE5Emulator

Quizás os preguntéis por qué crear un nuevo SDK si ya existe uno: el “Standard SDK for CE 5.0”. Es muy sencillo: el emulador que viene con dicho SDK no es compatible con Visual C++ 2005/8. Además, es un emulador x86 en lugar de ARM.

***

Bueno, ya hemos definido los specs de nuestro SDK. Ahora toca ejecutar el “configure.exe” correspondiente.

Abrimos una consola de comandos de Visual Studio o del Windows SDK (de Windows normal, no de CE) que tengamos instalado. Una vez abierto nos vamos a C:QTce-4.6.2 y desde allí ejecutamos

setenv /Release /x86 /xp

De este modo activamos la configuración para Release, x86, y XP que es lo más común a todas las opciones (aunque de hecho no nos haga falta).

Añadimos el PATH a lo que será la carpeta en donde irán los ejecutables de plataforma cruzada cuando se compilen:

set path=C:QT-4.6.3bin;%path%

Que no se os olvide añadir el PATH anterior porque si no nos quedaremos con una consola poco menos que inútil.

Vale. Ahora le toca al configure:

configure -platform win32-msvc2008 -xplatform wince50custom-armv4i-msvc2008 -debug-and-release -shared -no-qt3support –opensource

Si habéis seguido mis otras entradas, aquí hemos añadido la opción xplaform para que compile con nuestros specs. Ahí es donde tenéis que colocar los adecuados a vuestro SDK, sea estándar o no. Por ejemplo, si fuéramos a compilar para Windows Mobile 6.5 profesional, deberíamos poner “wincewm65professional-msvc-2008”.

No debería haber ningún problema con la ejecución del comando, pero si la hubiera hay que revisar lo que hemos hecho o incluso probar con una plataforma existente o diferente a ver qué pasa.

***

Ahora viene un paso un tanto delicado si estamos con una plataforma personalizada, como es el caso. Si estamos usando un SDK estándar, con seguir las órdenes que nos ha dado el propio configure al terminar es suficiente, pero si no, debemos ignorarlas y hacerlo a mano.

Lo primero es averiguar los SDK disponibles, ejecutando el comando:

checksdk –list

La captura siguiente nos muestra los que el autor tiene disponibles:

image

La que nos interesa es la última de todas, que se corresponde a nuestro SDK. Ahora volvemos a ejecutar el comando pero con otros parámetros (respeta las mayúsculas y minúsculas):

checksdk -sdk "WindowsCE5Emulator (ARMV4I)" -script env.bat

De este modo creamos el fichero BAT con los comandos necesarios para habilitar las variables de entorno del SDK para que el compilador de plataforma cruzada sepa dónde y qué ficheros cabecera y bibliotecas enlazar.

Ya solo nos quedan dos pasos:

env.bat
nmake

Al final de ese proceso (varias horas en mi Q4 con 8GB de RAM), tendremos QT compilado y listo para funcionar en cualquier SDK.

Como atajo, os dejo el contenido de un fichero .BAT que automatiza los últimos pasos según la forma explicada en otras entradas:

cd %1
set path=C:QT%1bin;%path%
configure -platform win32-msvc2008 -xplatform wince50custom-armv4i-msvc2008 -debug-and-release -shared -no-qt3support –opensource
rem checksdk -sdk "WindowsCE5Emulator (ARMV4I)" -script env.bat
call env.bat
nmake
cd ..

Con este fichero, y la copia de la carpeta que hemos creado dentro de mkspecs podremos recompilar cualquier versión de QT para Windows CE/Mobile.

Y después de configurar las opciones adecuadas en las opciones del QT Addin para Visual Studio (que he explicado en otra entrada del blog), y tras varios petes de Visual Studio intentando lanzar el emulador y las DLL de QT (cosa que siempre me pasa las primeras veces que añado algo nuevo al IDE), aquí tenéis una captura de un programa de demo ejecutándose con el emulador configurado como si fuera un JE200:

image

Compilando QT con Visual Studio (esta sí que sí)

Dicen que a la tercera va la vencida, y esta vez así ha sido. Ahora que me voy a meter más en serio con QT estoy dándole algo más de caña al asunto, y lo primero de todo era aprovechar, de verdad, Visual Studio y su magnífico compilador, que es mejor en al menos un orden de magnitud al de GNU y seguro que en varios al de C++ Builder (que por cierto no creo que sea capaz de compilar QT ni a trompicones).

Como sabréis he escrito al menos tres entradas sobre cómo compilar QT con Visual C++, y en las tres (aquí, aquí y aquí) siempre he hablado de lo mismo: errores en el proceso de compilación. ¡Pues bien, las manchas se van a acabar!

O en otras palabras: ya sé qué está pasando. La verdad es que es una tontada mayúscula, pero hasta que te das cuenta de ello…

Todo está relacionado con el meta-compilador de QT, MOC. La tarea de éste es coger nuestros ficheros cabecera que tengan algún signal o slot y generar un nuevo fichero post-procesado al que se le ha añadido el código necesario para que todo funcione, y entonces compilarlo todo.

La biblioteca de QT, se ve que para acelerar un poco los procesos, incluye una serie de ficheros de caché llamados mocinclude.tmp. Gracias a estos ficheros a veces no es necesario un proceso completo de compilación.

Hasta ahora todo bien, pero dado que compilar con Visual C++ no es lo mismo que hacerlo con GCC, esos ficheros temporales no son intercambiables entre compiladores, y la distribución del código fuente se deja algunos sin borrar. Como esos ficheros dependen de GCC y nosotros estamos recompilando para VC++, el proceso de generación de código falla.

Por eso comenté en las entradas anteriores que había que borrar algunos ficheros para poder compilar el WebKit y que la parte de scripting no funcionaba. Todo ello era debido al mismo problema con esos ficheros de caché, pero no me había dado cuenta de ello.

Ahora sí, si ya has leído las entradas anteriores, compilar QT con VC++ es tan fácil si antes recorres el árbol de ficheros fuente borrando todos los mocinclude.tmp, lo que se puede hacer de forma muy fácil modificando el .BAT que en su momento expliqué en las otras entradas. El nuevo quedaría como:

cd %1qt
del mocinclude.tmp /s
configure -debug-and-release -shared -no-qt3support –opensource
nmake
cd ..
cd ..

Eso sí, tenemos que compilarlo con Visual Studio 2008SP1 o anterior porque con Visual Studio 2010 hay algún cambio en el compilador que rompe la compilación, y esta vez no es una cosa de ficheros, sino algo que se le ha añadido y que al nuevo compilador de C++ no le gusta. Supongo que Nokia no tarde mucho a actualizarlo.