Alfred: Cómo lanza aplicaciones dentro de vmWare

Escenario.

Quieres (o ya tienes) aplicaciones virtualizadas en el Dock. Es decir, tu tienes un programa dentro de una máquina virtual vmWare y quieres lanzarla desde el Dock sin más.

Para ello, una vez que la máquina virtual está en modo Unity, lanzas la aplicación desde el menú de vmWare y te aparecerá el icono de la misma en el Dock. Ahora sólo tienes que, con el botón derecho del mismo, elegir “Opciones -> Mantener en el Dock”. 

La próxima vez que quieras lanzarla, con hacer clic sobre dicho icono es suficiente para que se abra la máquina virtual y tu programa de forma completamente transparente. Si la máquina está en modo Unity la aplicación se abrirá como una más del MAC. Si no, lo hará dentro de la ventana.

Vale. 

 

Problema

Ahora queremos poder lanzar esa aplicación desde un atajo de teclado. Hace tiempo expliqué cómo hacer algo similar con Automator y una serie de pasos. No sé si funcionará en el caso que nos ocupa, ni me importa mucho ya que ahora tengo instalado Alfred y su Power Pack, que es lo que realmente debería traer OS X de serie…

 

Solución

Alfred con el Power Pack tiene la opción de lanzar cualquier aplicación con una combinación de teclas que, creo, se superpone a las del sistema operativo. Hacerlo para cualquier aplicación es completamente trivial, pero para las aplicaciones internas de una máquina virtual es harina de otro costal.

Mirando aquí y allí, he descubierto que el Dock guarda la configuración de los programas que tiene en su barra aquí: ~/Library/Preferences/com.apple.dock.plist 

Si abres dicho fichero con xCode te encuentras una serie de items numerados. Hay que buscar el que nos ocupa, y en la rama “file-data -> _CFURLString” tenemos lo que nos interesa: la ruta al arhivo que el sistema usa para lanzar el programa que nos interesa.

Una breve inspección nos dice que, para cada máquina virtual, y dentro de su bumdle, existe una carpeta llamada “Applications” que contiene un fichero por cada aplicación “exportada” por la máquina virtual.

Ahora ya sólo nos queda añadir el fichero deseado al lanzador de aplicaciones de Alfred.

Supongo que los que usáis Parallels tendréis algo equivalente.

Visual C++ 2012 soportará Windows XP

Dicho así, a bote pronto, puede parecer una tontería, pero no lo es. Los que hayan estado probando las diferentes versiones alfas, betas y omicrones de Visual C++ 11 se habrán dado cuenta de que no generan código para Windows XP.

El motivo no era otro más que se han hecho una serie de mejoras al runtime de C++ (ya sabéis, la biblioteca de C y de C++) que se basan en una serie de funciones de Win32 que no están presentes en Windows Xp y sí en Vista y siguientes.

La respuesta fácil sería decir que han hecho eso para empezar a ir descartando a XP como sistema operativo soportado y forzar que los nuevos programas no funcionen con él, pero a la vista de las noticias no ha sido así. De hecho, hace poco tiempo alguien publicó la forma de soportar XP con las versiones beta ya publicadas mediante un truco. No me preguntéis cómo porque no lo he mirado.

Independientemente de eso, cuando un programa debe ejecutarse en un sistema que no tiene todas las importaciones de, por ejemplo, Kernel32.DLL, lo que hace es realizar una carga parcial o suministrar funciones dummy para que el sistema funcione. Es decir, si por ejemplo el runtime de C++ llama a una supuesta función de Kernel32.DLL llamada UnaFuncion() que no está en, digamos, XP pero sí en Windows 7, lo que se hace es, o bien esas se marcan como delayed (retardadas) y sólo se cargan manualmente una vez que el runtime ha comprobado que el sistema operativo la posee, o bien se suministra una vacía o con emulación.

No me preguntéis más porque realmente no sé cómo se hace ya que nunca me ha hecho falta, y tampoco sé si está documentado de forma oficial o no, pero es un mecansimo más o menos conocido que usa al menos la propia Microsoft para soportar sistemas operativos obsoletos y no tener varios juegos de ficheros.

***

Y ya que estamos en el tema, os comento otra cosa. Hace unos días se anunció que las versiones Express (todas) de Visual Studio 2012 sólo soportarían crear aplicaciones Metro en Windows 8 y que, si queríamos escritorio, deberíamos seguir usando las 2010 para ello.

Hablamos, claro está, de las gratuitas. La versión Professional y superiores sí que iban a poder crear ambos tipos de aplicaciones, y todo bajo un mismo IDE tal y como estamos acostumbrados. 

[Para los despistados, diré que con las versiones Express, si uno necesita crear un proyecto mixto, digamos una DLL hecha en C, C++ ó C++/CLI para que luego una aplicación en C# la use, tienes que instalar los productos por separado y manejar cada tipo de proyecto también por separado, y nada de depurar y saltar de código manejado a nativo y viceversa. Con las versiones de pago todo está en un mismo IDE y se pueden manejar de forma conjunta].

En principio la imposibilidad de crear aplicaciones de escritorio con la Express 2012 puede parecer trivial ya que tenemos las 2010, pero lo cierto es que perdemos muchas mejoras en todos los lenguajes. Podría citar como ejemplo los métodos asíncronos en C# y toda la nueva parafernalia del C++11 para C++, que no es poco.

Pero ha sido tal el clamor popular (y no tan popular, porque algunos MVP le han dado caña de la buena a MS -no, esta vez yo no he movido un dedo), que Microsoft ha reaccionado y va a sacar una versión 2012 Desktop para crear aplicaciones de escritorio.

Es decir, que vamos a tener al menos dos C# Express, dos C++ Express y demás, una para aplicaciones Metro y otra para escritorio. Y lo que es mejor, las versiones escritorio creo, y digo creo porque no lo tengo claro, va a ser un solo IDE que va a soportar todos los lenguajes como las versiones de pago…

***

Enlaces originales:

Ingeniería inversa de una aplicación Metro: más fácil que nunca

Andaba yo esta mañana mirando mis fuentes de noticias cuando me encuentro con esta entrada: Your Metro-style app needs protection and here is why.

En principio no me lo creí, o pensé que el contenido venía de versiones anteriores a la última Release Preview de Windows 8. Pero no, es completamente cierto.

Todos debéis saber que realizar ingeniería inversa a un programa escrito en .NET es cosa de minutos y es una tarea enormemente sencilla incluso si la aplicación está ofuscada. Si no lo está, podemos obtener el código fuente completo tal y como lo escribió el autor, y encima en el lenguaje que queramos.

Esto nos da un truco muy sencillo para usar código de terceros escrito en un lenguaje .NET que no conocemos. Tomamos el código a copiar, creamos una aplicación, le aplicamos un Reflector (que es como se llaman a estos programas) y obtenemos el código fuente en el lenguaje deseado, ya sea VB.NET, C# o incluso C++/CLI.

Si el programa está ofuscado la ingeniería inversa es algo más difícil, pero con un poco de práctica es posible convertir el resultado en algo legible. No obstante, si queremos copiar un bloque de código o ver cómo está hecha una cosa, no necesitamos más. Copiamos, pegamos y listo. A ver, no es tan fácil, pero un ofuscador de código lo único que hace es cambiarle el nombre a todo y allí donde es posible, separar o juntar cosas. Nada que un experto medianamente espabilado no pueda deshacer.

Pues bien, las aplicaciones Metro en Windows 8 todavía son más fáciles de desensamblar. Estoy intentando instalarme un programa de demo, pero todavía no sé cómo se hace localmente pese a tener el paquete listo para su instalación.

Mientras averiguo eso, podéis jugar un ratín como he jugado yo. Lo primero de todo es hacer que la carpeta “C:Program FilesWindowsApps” esté visible. Para ello abrimos la ventana de Windows Explorer en el escritorio y en la opción “View” del menú, seleccionamos “Options”. Allí, en la pestaña “View”, marcamos “Show hidden files, folders and drives” y ya de paso, también “Hide extensions for known file types”, que no es imprescindible pero ayuda.

Ahora ya podemos ver la carpeta WindowsApps. Desde el explorador de Windows nos dice que no podemos entrar. Podríamos tomar control de la carpeta, pero al menos yo no lo he hecho, ya que abriendo una consola de comandos con permisos elevados podemos entrar y ver el contenido:

clip_image002

Vaya. Tenemos acceso a todas las aplicaciones Metro instaladas… Aunque podemos navegar por ellas desde la ventana de comandos, también podemos copiarlas a otro destino con el comando “xcopy <origen> <destino> /r/s”. Y eso es lo que he hecho. Me he movido el “Reader” de Microsoft.

Y ahora puedo entrar sin tocar nada de nada:

clip_image004

Interesante, ¿no? Tenemos archivos XAML, ejecutables, imágenes, metadatos, todos ellos al alcance de la mano. Dos pantallazos más:

clip_image006

clip_image008

Creo que es suficiente, ¿no?

Pues no, ahora vamos a abrir y desensamblar algún ejecutable. La aplicación Reader que hemos estado viendo parece ser que es binaria (luego volveremos sobre ello), pero por ejemplo la “BingFinance” es .NET pura y encima está sin ofuscar:

clip_image010

En la imagen de arriba vemos dos ficheros de dicha aplicación abiertos de… esto… piernas.

***

Pero todavía hay más. Vamos a echar un vistazo a un par de aplicaciones escritas por uno mismo. La primera es un SplitView en C++ tal y como sale del asistente de Visual Studio 2012RC. Entre otras cosas genera dos ficheros “ejecutables”. Un EXE tradicional, que es binario o al menos así lo parece, y otro con la extensión Winnmd y el mismo nombre. Este sí que es manejado, pero parece ser que sólo contiene las exportaciones a WinRT. Tampoco tengo claro qué es, aunque parece ser que WinRT necesita las exportaciones del programa y MS lo ha solucionado de esta manera. En fin, aquí esta:

clip_image012

Ahora veamos la misma aplicación tomada del asistente de C#. En este caso sólo hay un ejecutable, el propio programa que es desensamblable por completo:

clip_image014

***

¿Os mola? A mi nada de nada. Esperemos que Microsoft se ponga las pilas con esto, porque si no mal vamos.

Un poco hasta los cojones del OS X sí que estoy, la verdad

No sé quién diría eso de en MAC eso no pasa, pero el hecho es que, a fecha de hoy, OS X Lion no llega ni a la suela de los zapatos de Windows 7. Esperemos que el Montañés mejore algo, porque lo que es la versión actual, es un mucho mierdosa.

Aparte de las infinitas carencias en usabilidad, con un Finder al que hay que meterle diez extensiones o instalarse sustitutos para se que acerquen un poco al Explorador de Windows, los programas más o menos mierdosos que necesitan sustituto (léase Mail, iCal, …), las porquerías del Spotlight que unas veces va lentísimo, otras antepone los propios programas de Apple a otros de terceros aunque los de origen no se hayan usado nunca (y por eso uso Alfred), la necesidad de gastarte una pasta en sustitutos que en la mayor parte suelen ser gratuitos en Windows, las pifias de programas serios como iPhoto que unas veces sí y otras también es incapaz de recordar que tengo activo el photo streaming, los petes del Pages porque él lo vale y que me hace rememorar las primeras versiones de Open Office, que cascaban o iban mal sí o sí, los enganches y autismos varios del iTunes, la ruedecilla multicolor de la muette, que aparece de vez en cuando, sobre todo en Safari, la lentitud en arrancar el sistema completo… 

… Todo eso, a lo que hay que sumar la pésima gestión de memoria y, ahora mismo, dos problemas con el kelmer o que creo que vienen directamente del mismo.

***

Tengo un monitor secundario enganchado a un puerto Thunderbolt pero usado como DVI con su adaptador correspondiente. Pues bien, cada dos por tres pierde lo que quiera que pierda y ambas pantallas se ponen a parpadear. La anexa porque se ha perdido, y la principal poniendo y quitando el escritorio como si eso fuera a solucionar en algo la otra pantalla.

***

El otro problema viene con el puerto de la SD, que sólo me permite insertar una tarjeta por reinicio. Sí, una vez que he insertado una tarjeta, y tras su expulsión, ya no vuelve a leer nada de ella.

***

En ambos casos no es el hardware, porque en Windows con Boot Camp en ningún momento me ha pasado nada parecido. Es el puto OS X que, tras cada actualización, va peor que la anterior.

***

Y ya para finalizar, ¿quién es lumbrera al que se le ha ocurrido poner el puerto de la SD justo debajo de la ranura del DVD? Porque manda cojones, mucho diseño, mucha tontería pero lo dicho: ergonomía poca o ninguna. Justo hace un momento casi tengo que desmontar mi iMAC (que todavía está en garantía) porque he metido por error la SD en el hueco del DVD…

En fin, que mucho ruido pero pocas nueces.

***

Perdonadme la entrada, pero creo que tengo razón al quejarme de todas estas cosas y de más que no os cuento porque tengo la duda de si es el layer 8 o el sistema.