"Vivo o muerto" y el C++
Llevo bastante tiempo sin leer novedades literarias, y menos aún las de esta clase: Vivo o muerto, Tom Clancy y Grant Blackwood. Y suena a lo que es: un bestseller que aprovecha el tirón del 11S y que forma parte de la serie Jack Ryan del autor. Para los que no saben de qué va, estos libros son novelas de entretenimiento en los que el personaje Jack Ryan, primero analista de la CIA y luego más cosas, termina en medio de los berenjenales más típicos de este tipo de obras: terrorismo, espionaje, etc.. Las novelas estarían mejor si no tuvieran ese pro-USA tan acérrimo. Pero bueno, es lo que hay.
Si os preguntáis qué hace una entrada como esta en un blog como este, os lo diré: id a la página 168 de la edición de Umbriel de 2011 (la única por ahora) y leed conmigo:
“Y aunque hubieran examinado aquél [un CD grabado], no habrían visto más que un galimatías incomprensible: datos sólidamente cifrados en lenguaje de programación C++, carentes por completo de sentido.”
Sí, yo también me he asustado, y no poco. Vale, es una pifia del traductor, ¿no? Pues no, en el original pone:
“Even if that one had been examined, it would have been shown to contain gibberish, robustly encrypted data written in C++ computer code that made no sense at all,”
Bueno, pues ya lo sabéis, chicos, el C++ también sirve para encriptar datos. Ya sé que el obfuscated code puede ser difícil de entender, pero tanto como para incluir elementos encriptados en su código…
Desde luego hay quien oye campanas y se imagina belenes.
En fin.
RAD Studio XE2: ¿Pruebas de integración? ¿Para qué?
Ya las hará el cliente y protestará. En el caso de que tengamos ganas, le ayudaremos. Si no, que se joda.
Esa parece ser la filosofía de Embarcadero para su producto RAD Studio XE2. Para hacernos una idea, lo que ahora trae el XE2 es lo que debería haber traído el XE original, pero ya sabemos, después de varios (muchos) años intentando convertir a la VCL en multiplataforma, llegan, compran un producto cualquiera, y en menos de seis meses lo integran en su RAD Studio, sustituyendo a la vetusta VCL que, por cierto, dio nacimiento a .NET cuando Microsoft se llevó a Anders de Borland.
El sistema de desarrollo es un tanto churrimangui, aunque parece ser que funciona. La idea es tener una máquina Windows con RAD Studio instalado. Puede ser una máquina virtual corriendo dentro de OS X, pero tened mucho cuidado con la compartición de perfiles y demás: en un tris tenéis que volver a activar, porque una de las cosas que mira el entorno para detectar que no lo han tocado es el nombre del equipo en la red. En fin.
Luego instalas un servidor en OS X, lo que, junto a un debugger de plataforma cruzada, puedes editar y compilar en la máquina Windows y ejecutar y depurar en el MAC. Digo churrimangui porque no es a lo que nos tiene habituados Borland, digo Embarcadero. Encima todo el tema al lado del MAC es por línea de comandos. Cualquier programador de hardware, o ya puestos de teléfonos y similares, verá el paralelismo evidente.
***
Pero bueno, no es de eso de lo que quiero hablar aquí. Hasta el 32 de diciembre del 2011, hay una oferta que si compras alguna versión del producto, te regalan otros. A veces ha sido comprar C++ Builder (o Delphi) y obtener el otro gratis. La de este año consiste en que te regalan más componentes y otros programas de la casa.
Uno de los productos es FastCube, componentes que te ayudan al análisis de datos. En mi caso no creo que me hagan falta, pero podría ser interesante para aquellos que hagan programas de gestión y tengan que presentar datos analizados.
Pues bien, las pruebas de integración de este producto con RAD Studio no se han hecho. No porque si instalas el componente, el producto deja de funcionar. No se trata de algunas configuraciones en concreto, ni que ocurra en ciertas máquinas: pasa siempre.
Si uno se pone a buscar en internet el error que da C++ Builder (que es el que falla, Delphi funciona bien), no encuentras absolutamente nada sobre el tema. Aplicando un poco de lógica, podemos llegar a varias posibles conclusiones:
- Nadie está usando C++ Builder, o si lo está, no ha instalado dichos componentes.
- Desde que han sacado la oferta, no han vendido ni una sola copia de C++ Builder o de RAD Studio.
- Nadie está usando el producto.
Os dejo con la reflexión antes de pasar a la solución.
***
El problema se genera cuando la instalación del producto (que no es de Embarcadero, pero deberían haber hecho el test de integración antes de ponerlo a disposición de la gente tan alegremente) estropea por completo las rutas por defecto del compilador. Es decir, si abrimos el IDE (ya sea la versión completa de RAD Studio o personalidad de C++Builder), y nos vamos a Tools -> Options -> C++ Options -> Paths and Directories, las rutas de Include Path y de Library Path quedan completamente inutilizadas porque FastCube, en su soberana sabiduría, ha decidido que nadie más que él debe estar ahí.
Desinstalar el producto no soluciona nada, porque dichas rutas se quedan sin restaurar.
Por lo tanto, la solución pasa por volver a colocar allí dichas rutas. En mi caso son:
- Include: $(CG_BOOST_ROOT)\boost\tr1\tr1;$(CG_BOOST_ROOT);$(BDSINCLUDE);$(BDSINCLUDE)\dinkumware;$(BDSINCLUDE)\windows\crtl;$(BDSINCLUDE)\windows\sdk;$(BDSINCLUDE)\windows\rtl;$(BDSINCLUDE)\windows\vcl;C:\Program Files (x86)\FastReports\LibD16;$(BDS)\RaveReports\Lib;C:\Program Files (x86)\Raize\CS5\Lib\RS-XE2\Win32
- Lib: $(BDSLIB)\win32\release;$(BDSLIB)\win32\release\psdk;C:\Program Files (x86)\FastReports\LibD16;$(BDS)\RaveReports\Lib;C:\Program Files (x86)\Raize\CS5\Lib\RS-XE2\Win32
No te garantizo que la instalación haya tocado otras cosas, pero en mi caso, con volver a colocar ahí dichas cadenas, se soluciona el tema.
***
Por lo tanto, otro coscorrón más para Embarcadero. Y ya os diré cómo funciona el producto, porque voy a usarlo para un proyecto personal.
Win/MAC: arranque dual y jodimiento de particiones
Os lo juro. Estoy hasta los putísimos cojones de Windows, de MAC y de la madre que los parió a todos. El primero por pensarse que todo le pertenece, incluyendo las particiones HFS+, y el segundo por pensar que todos los usuarios son tontos del culo.
No tengo muchas ganas de escribir, así que voy a ser bastante escueto.
Escenario: Windows/MAC con Boot Camp y arranque dual. Como Windows asigna las unidades como le sale de los cojones, entro en el Administrador de Discos y las cambio a los valores que quiero.
Vale, todo bien en Windows. Inicio OS X y… una de las tres particiones no se carga. Es decir, habiendo cambiado la letra de unidad a dos particiones HFS+ desde Windows, una de ellas luego no se carga desde OS X porque Windows, en su maravilloso afán de poseerlo todo, ha decidido cambiar cierta cadena de las tablas internas del disco por “Microsoft Basic Data”. Hay que joderse con tomate. ¿No saben reconocer una partición ajena y no tocar nada? Pues parece ser que no, que tienen ganas de joder la marrana.
Bueno, la Utilidad de Discos de OS X se ve incapaz de recuperar la partición. Hala, nueva pérdida de datos. Cuatro máquinas virtuales y un montón de descargas.
***
Pues no, hay solución. Está aquí. Otro geek de la más alta alcurnia se ha encontrado con el mismo problema y ha creado una aplicación en Python para solucionar el problema. Lo único que hace es cambiar dicha cadena por su valor por defecto. Y entonces OS X reconoce la partición como suya y la monta.
Olé sus cojones.
Os cuento cómo hacerlo.
***
Desmonta el disco completo en donde esté la partición afectada. Luego graba el fichero gpt_surgeon.py en disco (ojo con grabar el html y no el contenido del mismo). Aquí viene cuando Apple piensa que somos imbéciles o así. Tu grabas un archivo, que te lo pone como texto de lectura escritura. Pero tu lo quieres de ejecución, porque si no ya puedes darle de sopapos porque se negará a correr.
Hay que añadir el bit de ejecución. ¿Cómo? Ahí está el problema. Desde la interfaz gráfica no se puede, porque CMD-I sólo te dejar cambiar entre lectura y escritura, pero no ejecución.
Quizás haya algún botón por algún lado para activarlo, pero no lo he encontrado, así que tienes que abrir una ventana de terminal y cambiarlo ala UNIX: “chmod u+x gpt_surgeon.py”. Claro, puede que algún imbécil siga la secuencia desde el Finder y sea capaz de cambiarle los permisos a un troyano. En fin, viva la ergonomía y usabilidad maqueras.
Luego sigues la secuencia explicada en el enlace de arriba:
- ./gpt_surgeon.py list /dev/disk<n>, en donde <n> es el disco malo.
- Localiza la partición jodida, en la que debe aparecer el infame texto de “Microsoft Basic Data”.
- sudo ./gpt_surgeon.py repair /dev/disk<n> <y>, en donde <y> es la partición rota.
- Al poco, OS X (o el script) montará todas las unidades, habiendo reparado la estropeada.
Y ya está, esta ha sido la crónica del día de hoy. Cagontó…
C++/CX (II). C++/CX vs WRL
Bueno, una vez que hemos visto lo que hay dentro del nuevo Windows 8, y comprobado que WinRT no es un subsistema sino algo por encima de Win32 como es .NET, vamos a contaros las dos formas que hay de programar con C++ para la interfaz Metro.
Ya lo he comentado antes, pero voy a repetirlo aquí por mor de claridad. En Windows 8 hay dos escritorios diferentes. Por un lado tenemos el clásico de toda la vida que es prácticamente idéntico al de Windows 7, y por otro el de la interfaz Metro. Si no cambian las cosas, los equipos que lleven un procesador x86 tendrán acceso indistinto a los dos, mientras que aquellos que lleven procesador ARM sólo verán la interfaz Metro.
Eso quiere decir que habrá dos tipos de aplicaciones: las clásicas y las Metro. Las primeras sólo podrán compilarse para x86 (de 32 o de 64 bits) y sólo funcionarán en las máquinas Intel. Si estamos en la interfaz Metro y lanzamos una aplicación de este tipo, el sistema cambiará al escritorio clásico.
Las segundas podrán compilarse para x86 o para ARM y en ambos casos funcionarán en sus propios sistemas, pero siempre bajo la interfaz Metro. Es decir, si queremos que nuestra aplicación Metro escrita con código nativo pueda correr en los dos tipos de arquitectura, tendremos que proveer dos compilaciones.
Con .NET (C# y VB.NET) viene a pasar lo mismo, aunque en este caso creo que con especificar AnyCPU será suficiente para que la aplicación corra en ambas arquitecturas. Y de nuevo tendremos los dos tipos de aplicaciones: de escritorio y Metro, con las mismas reglas.
Por lo tanto, cualquier programa escrito en cualquier lenguaje que funcione ahora mismo en Windows 7, no debe tener ningún problema en ejecutarse en la siguiente versión, pero siempre en el escritorio clásico. Y podremos seguir escribiéndolos como hasta ahora.
***
Eso quiere decir que tenemos dos API diferentes e incompatibles entre sí. Por un lado tenemos el API de Win32 clásico y tradicional, sobre el que se construyen bibliotecas de terceros y el .NET. Aquí podemos meter VB6, Delphi, C#, C++/CLI, QT… Vamos, lo que hasta ahora.
Y para Metro hay una nueva API que se llama WinRT. Creo que hay cosas compartidas con Win32, pero no me hagáis mucho caso porque todavía no he visto nada. De todos modos si las hubiera, podemos tomarlas como si fueran nuevas, porque son excluyentes, al menos de momento.
Es decir, o bien desarrollas para Win32 o bien para WinRT, pero no puedes tener un ejecutable que use partes del otro más allá de las que MS ha querido compartir, y entre ellas no se encuentra C++/CX.
Por lo tanto también hay dos versiones de .NET. La de la interfaz Metro se construye sobre WinRT, y la clásica sobre Win32. Nos podemos hacer a la idea de que, aunque tengamos un API con nombres similares, por dentro funciona todo diferente (lo que no es cierto, pero a efectos prácticos sí que lo es, ya que las aplicaciones Metro deberán ir firmadas y el proceso de firmado garantiza que no vas a salirte de las API estándar -¿De qué me sonará eso?).
***
No obstante, WinRT no está escrito con C++/CX si no que está hecho con C++ clásico. Y en cierto modo es lógico, ya que no es más que una extensión a Win32, que es C y C++. Además, independientemente de mis diatribas personales, es algo bueno que le añada funcionalidad a un API que lleva tanto tiempo funcionando con regularidad y sin grandes problemas. Imaginaos los bugs que podría tener algo escrito desde cero.
Por lo tanto, podemos desarrollar aplicaciones para Metro sin usar .NET ni C++/CX. Podemos utilizar C++ y una biblioteca de plantillas llamada WRL (Windows Runtime Library), que viene a ser algo así como el ATL de Metro.
Microsoft no recomienda usarla, más que nada porque es compleja y porque de momento no hay documentación alguna sobre ella, pero está ahí, y es la base de Metro.
Si queremos echarle un vistazo, podemos acercarnos a “Program Files (x86)\Windows Kits\8.0\Include\winrt\wrl” y ver qué hay dentro. Tomaos un par de aspirinas antes.
Básicamente se trata de toda la infraestructura y parafernalia para acceder a los objetos COM y componentes de Metro.
***
C++/CX ocupa el nicho de lenguaje nativo para Metro, con lo que es más rápido que C# y que VB.NET, y es con el único con el que se puede acceder a DirectX (y por tanto a la creación de juegos). También es nativo. Es decir, que no es .NET y compila al código máquina que todos conocemos y de hecho es idéntico al C++ de toda la vida.
Lo que ocurre es que contiene una serie de extensiones que nos van a facilitar la vida a la hora de operar con Metro y sus componentes. Soporta clases parciales, se entiende bien con XAML e instanciar o crear un componente COM es un juego de niños comparado a como se hace con Win32.
Digamos que con esas extensiones nos ahorramos una buena faena a la hora de programar, y será el compilador el que sustituya esa azúcar sintáctica por el código necesario.
En siguientes entradas os contaré más sobre C++/CX.
¿WinRT un subsistema? No, no lo es
Bueno, al final no ha costado mucho encontrarlo. Básicamente, el resultado de esta investigación es:
O con otras palabras: WinRT y Metro se ejecutan, como todo lo demás, sobre Win32, con las ventajas y los inconvenientes que eso pueda tener. No me malinterpretéis: no hay nada malo que la arquitectura sea diferente a la indicada en el gráfico de arriba, lo que está mal es que Microsoft nos mienta tan descaradamente. Simplemente eso.
Si lo han hecho así, por algo será y sus motivos tendrán, y es entonces cuando, ya definitivamente, yo tenía razón: Windows ya no es Windows NT, y su grandiosa arquitectura por bloques se ha perdido en el camino. Y esto sí que es malo, bastante malo, porque estamos volviendo a un batiburrillo de código como es, por cierto, el OS X (quizás algún día hable de ello).
Vosotros mismos podéis comprobarlo sin problema alguno y de forma muy rápida. Tenéis que construir dos aplicaciones, una WinRT en C++/CX y otra clásica de Win32. No hay más que utilizar las plantillas por defecto sin ningún cambio.
Eso sí, hay que hacerlo a partir de la versión Developer de 64 bits de Windows 8, e instalar una versión de la MSDN, porque la Express creo que no es capaz de generar programas Win32 puros.
He llamado “TestWin32” a mi aplicación tradicional, que genera una ventana de Windows normal y corriente utilizando directamente el API de Win32. A la Metro la he llamado “TestSplitApplication”. Una vez generadas, tenemos que compilarlas. Visual Studio se os quedará más o menos así:
Si ahora nos vamos a la carpeta en donde está almacenado el proyecto (que podemos hacer desde el mismo IDE posicionándonos en el nombre de la solución en el Explorador y elegimos Open Folder in Windows Explorer), carpeta Debug, encontraremos el ejecutable del programa nativo (TestWin32.exe) y dentro de la carpeta TestSplitApplication, el de la aplicación Metro.
(Por cierto, en uno de esos lapsus teclae tan habituales en mi, le he dado el nombre de “TestSplitApplicarion” en lugar del correcto.)
Ahora debemos conseguir el Dependency Walker, aunque existen otras herramientas de línea de comandos que nos permiten hacer lo mismo dentro del SDK, lo interesante es utilizar esta porque lo veremos todo de un golpe. El mayor problema es que se trata de una utilidad que hace tiempo que no se incluye en ningún SDK, por lo que hay que conseguirla de forma externa.
Una vez obtenida la versión de 32 bits, porque nuestros proyectos son de dicho tipo, la ejecutamos sobre cada uno de los dos programas. Este es el resultado:
¿Lo veis? Ambos programas importan las mismas DLL, las de Win32 como KERNEL32.DLL y USER32.DLL.
Es decir que ambos son aplicaciones Win32 nativas.
***
Si nos diera por abrir, por ejemplo, uno de los dos KERNEL32.DLL, veríamos que ambas DLL son la misma con las mismas dependencias y exportaciones. Por lo tanto, ambas aplicaciones dependen del mismo subsistema.
Reitero que es una tontería, pero no lo es cuando intentan engañarte.
Lo que sí parece han hecho ha sido romper KERNEL32.DLL en otros ficheros más pequeños que contemplan subconjuntos de lo que en versiones anteriores había en él. Quizás de esta forma reduzcan la huella de memoria evitando cargar sub ficheros cuando estos no se vayan a utilizar.
***
Esto nos lleva a un tercer problema: parecer ser que una aplicación Metro no puede ejecutar funciones de Win32, y una de Win32 tampoco de WinRT.
¡¡Pero si es el mismo subsistema!!
Pues bien, estamos ante una limitación artificialmente impuesta por Microsoft sin ningún motivo técnico aparente… con lo guapo que sería hacer aplicaciones Win32 con C++/CX…
Se me ocurren un par de trucos para poder forzar esto, pero no creo que valga la pena hacerlo en una versión tan temprana como esta. Quizás cuando salga la definitiva, si tengo ganas y si nadie más se me adelanta, lo intente.
C++/CX (I). Windows 8 y el nuevo subsistema WinRT
Observad con detalle la imagen de arriba. Fijaos en que está dividida en dos grandes bloques. A poco que os haya preocupado la arquitectura lógica de Windows, os daréis cuenta de que hay nueva chica en la oficina: WinRT.
Ya hablé de algo así aquí, pero en relación con la arquitectura de Apple comparada con la de Windows, y de los últimos cambios que Microsoft ha ido haciendo para adecuar su plataforma NT para que sea funcional y útil para el usuario medio, dejando un poco de lado la arquitectura tradicional.
Pues bien, parece ser que me tengo que comer mis palabras con patatas (no, no esas patatas, Z). Volviendo al gráfico anterior, WinRT es un nuevo subsistema igual que lo es Win32. Para aquellos que no tengan claro qué es, os cuento un poco la arquitectura teórica de Windows NT.
El sistema operativo cuenta con un kernel (sí, como el de Linux, pero con muchas más cosas dentro de él y mucho más dinámico), que en teoría se asienta sobre una capa HAL que abstrae a dicho núcleo de la arquitectura física. En su momento hubo HAL para ARM y para otras plataformas. En la actualidad sólo la hay para x86, tanto en versión de 32 como de 64 bits.
O eso creía tras haber hecho un somero análisis de las tripas de Windows 7. Pues bien, si Microsoft añade soporte para ARM (y recordemos que van a salir procesadores de este tipo de 64 bits), dicha capa debe ser o bien reimplementada o bien ya existía y simplemente estaba inactiva. O lo que me parece más lógico: recompilar todo el sistema operativo para que se ejecute en dicha arquitectura, cambiando lo que haya que cambiar, dado que eso de traducir cualquier otro procesador a x86, sobre todo desde un ARM, suena a fantasía animada de ayer y de hoy.
Por otro lado, Windows se mueve mediante subsistemas. Uno de ellos es Win32. Otro lo fue OS/2 y también Posix (sí, en un pasado lejano, Windows NT era capaz de ejecutar comandos de unix con las primitivas de desarrollo que tiene la parte estándar Posix de Unix). Es decir, un subsistema suministra cierta abstracción sobre el núcleo, proporcionando un API mucho más rico y potente. Y de paso lo aísla para que las aplicaciones sean incapaces de tumbarlo.
En otras palabras, Win32 se ejecuta en el anillo 3 y el núcleo en el cero, y es Win32 el que, cuando una aplicación pide algún recursos del sistema (por ejemplo un puerto serie), el que se encarga de mover la petición y de realizar tareas intermedias, evitando así que un mal uso por parte de una aplicación genere una pantalla azul.
Digamos que una aplicación en el anillo 3 jamás podrá tumbar al sistema ejecutándose en el anillo 0, o al menos esa es la teoría. A veces un parámetro mal pasado puede terminar en una caída completa, pero no es lo habitual, y cada vez menos.
Pues bien, aparte de Win32, ahora tenemos un nuevo subsistema llamado WinRT. O eso dice, al menos la teoría y así nos lo presenta Microsoft en sus gráficos y en la escasísima información de la que disponemos.
Una de mis próximas tareas es la de intentar averiguar si esto es así o no lo es. No es la primera vez que Microsoft miente descaradamente, como cuando dijo de XAML no iba a necesitar de Win32 y que desaparecían los bucles de mensajes y que se ejecutaría sobre DirectX… Hasta donde sé, todavía eso no es del todo cierto.
También nos dijo que .NET iba a ser un subsistema, y realmente se ha quedado como una capa sobre Win32…
Por lo tanto, estad atentos al blog. Además, el dibujo original de Microsoft deja mucho que desear respecto a la claridad, presentando Internet Explorer y .NET como subsistemas independientes de Win32, lo que es, a todas luces, completamente falso:
***
Volviendo al gráfico de arriba, podemos ver algunos detalles que creo no son del todo ciertos, pero nos dan una idea de la arquitectura del nuevo WinRT (sobre la que se basa la interfaz METRO que llevará, junto al escritorio tradicional, Windows 8).
(Una de las cosas por las que dudo que WinRT sea un subsistema completo es el hecho de que Windows 8 consuma menos memoria que el 7 y de que se pueda producir ese intercambio tan rápido entre los dos escritorios, lo que me hace pensar que, de nuevo, se trata de algo sobre Win32).
En WinRT hay dos interfaces de desarrollo principales: XAML y HTML. Es decir, podemos hacer aplicaciones clásicas basadas en el primer modelo y modernas en el segundo.
A simple vista puede parecer que en ambas se utiliza una misma variación del XML, pero no es así. En el caso de HTML/CSS nuestra aplicación no será otra cosa más que una página web ejecutándose dentro de una sesión más o menos oculta de Internet Explorer. Tendremos acceso a esas dos tecnologías (incluyendo HTML5) y JavaScript como lenguaje de desarrollo.
En el caso de XAML, estamos ante la última evolución de las interfaces de usuario dinámicas en las que la interfaz está completamente (o lo más posible) separada del código en sí, lo que permite una soltura nunca vista hasta ahora. O al menos esa es la teoría y casi os diría que la práctica.
XAML es muy potente. Demasiado, casi diría. Se trata de una especie de colección de contenedores jerárquicos que pueden actuar como tales o como elementos finales, y pueden mutar de un tipo a otro con una facilidad pasmosa. De hecho, cambiar el aspecto visual de una aplicación XAML puede llegar a ser cosa de unas pocas –muy pocas- líneas de código, con el añadido de que quien haya desarrollado con .NET y la versión anterior, está casi listo para esta nueva (que por cierto no es mi caso, pese a ver en su momento las ventajas evidentes del nuevo modelo).
Por lo tanto, los programadores de .NET que hayan abandonado Windows Forms por la nueva forma, lo tendrán bastante fácil. Los dinosaurios como yo mismo tendremos ciertas dificultades en adaptarnos… o no.
¿Recordáis C++/CLI, el C++ del .NET? Pues bien, la única pega para que dicha extensión de C++ pudiera utilizar XAML es que no se soportan las clases parciales como en C o en VB.NET. Por desgracia, eso sigue siendo así, y la interfaz clásica continua estando vedada para los programadores de C++ en .NET, quedando limitados a Windows Forms y a un IDE que no es que se muestre muy estable manejando el lenguaje…
***
Bueno, ahora, por fin, entra C++/CX. ¿Qué es? Nada más y nada menos que una nueva extensión a C++, con una sintaxis muy similar a C++/CLI pero con un propósito muy diferente: el de soportar METRO y XAML. Y no, no es .NET. Es nativo.
Supongo que Microsoft se planteó ante una disyuntiva muy pero que muy gorda: el rendimiento de .NET es suficiente para un PC, pero no lo es para una plataforma móvil como una tableta. No estoy diciendo que sea malo, estoy diciendo que eso de tener una máquina virtual consumiendo memoria y recursos, un jitter ejecutándose detrás de todo, y un post-compilador pasando MSIL a código nativo no es de recibo para un Tablet.
Delante de todos está el fracaso de Android. Por favor, absteneros fundamentalistas y otros pájaros de similar calaña: Android es un fracaso. Puede que aguante unos cuantos años, pero terminará por caer estrepitosamente, tanto por problemas técnicos (demasiado consumo de memoria, demasiada lentitud, demasiadas capas una encima de otra, demasiadas caídas) como por comerciales (demasiada fragmentación, demasiado abandono de terminales a medio hacer), etc..
Por lo tanto, para competir en igualdad de condiciones, tenemos que darle caña a iOS. Se debe hacer algo similar, y ese algo es WinRT y C++/CX. No hay máquina virtual .NET, ni nada oculto (o eso quiero creer), tan solo un motor de ejecución, una interfaz y el propio sistema operativo. O en otras palabras: objetive-c, cocoa y lo que quiera que haya en el núcleo de iOS (parece ser que un BSD recortadito).
Otro problema es la arquitectura. Ya se ha demostrado que x86 es demasiado pesado y demasiado hambriento de energía como para ser útil en el mercado móvil, por lo que hay que subirse al carro de ARM, que son micros mucho menos complejos y por tanto consumen mucho menos y andan más sueltos.
Por lo tanto se necesita algo diferente, algo mucho más liviano. Y eso, de nuevo, es WinRT. Por lo tanto, la combinación ganadora es C++/CX, XAML y, cómo no, C# y VB.NET corriendo sobre una variación de .NET llamada .NET 4.5 WinRT (y que funcionará más lento y consumirá más batería que una aplicación realizada con C++/CX).
Pero el núcleo, el centro de todo, es C++ y WinRT. Luego está .NET, encima igual que en Win32. Como debe ser. Y de nuevo absténgase fundamentalistas. Si lo han hecho por algo será. Quien cae del árbol a tiempo todavía puede recuperarse.
***
C++/CX no es .NET. Es nativo. Y la parte CX no es más que un envoltorio cómo para los interfaces COM, ese animal mitológico con el que los programadores de C++ nos tenemos que enfrentar de tiempo en tiempo y que nos pone los pelos de punta.
Es decir, la parte CX sólo se utiliza para interactuar con XAML y los componentes que se hayan creado a tal efecto. Luego, nuestro código será C++ normal y corriente, con la STL, los streams (que personalmente pienso que no son muy útiles), Boost o lo que queramos usar y esté disponible. Desarrollo determinista por completo, sin recolector de basura (a no ser que nos hagamos uno), sin elementos ocultos excepto el envolvente COM que han llamado CX y que nos servirá para interactuar con los componentes.
Otra ventaja de C++/CX sobre .NET es que, si quieres hacer un juego sobre DirectX, tendrás que usarlo ya que ni C# ni VB.NET están soportados, de nuevo como debe ser.
Ah, y con soporte para clases parciales, lo que… bueno, mejor lo dejamos para más adelante.
Code Complete 2, Steve McConnell
Ñas. Por fin lo he leído. Más de un año para acabarlo. Entre lo que os conté con mi jefe y la empresa, y cierto bajón existencial, dejé de leer temas técnicos, pero creo que he vuelto, o eso espero.
Bueno, al rollo.
Lo primero de todo, y pese a que me vais a llamar de todo, el libro no me ha aportado nada nuevo, salvo quizás en los últimos capítulos cuando habla de integraciones y manejo de grandes grupos de programadores, entre los que no me cuento. Es decir, o bien programo solo o bien en pareja o para un tercero, haciendo rutinas de bajo nivel o bibliotecas (DLL, como las llama mi jefe).
Lo único ha sido la sorpresa de encontrar veinte años de experiencia condensados en un solo libro. Y lo que falta, que no es poco. Pero bueno, lo cierto es que este libro tienes que leerlo.
Si no lo has hecho, cómpralo y ponte a ello, porque seguro que te va a resultar constructivo. Y si te dice cosas nuevas, vuélvelo a leer cada año o cada seis meses. O si eres de los que va despacio, cuando termines por una punta, cógelo por la otra.
Es increíble lo que pueden dar ochocientas páginas, pero lo dan.
Te pego una cita, sacada de aquí:
Si sólo tienes oportunidad de leer un libro sobre desarrollo de software en toda tu vida, procura que sea éste. Code Complete es prácticamente la biblia del desarrollo de software, además de una de las mejores guías prácticas sobre la programación de todos los tiempos. Es un libro muy fácil de leer, entretenido, y tremendamente práctico, con montones de recomendaciones útiles para cada fase del ciclo de vida del software. El simple hecho de leerlo te hará mejor programador. Seguro.
Con eso creo que basta.
El compilador como servicio
Me he quedado poco menos que estupefacto con esta entrada del blog de SomaSegar. Y no, no penséis mal, que no es malo.
Básicamente viene a decirnos que está disponible la CTP de “Roslyn”, que según entiendo es una extensión -de momento- a Visual Studio 2010 SP1. De hecho nos la podemos bajar y jugar con ella.
Comienza diciendo que los compiladores se han venido haciendo en C++ nativo, pero que ya es hora de cambiar y que han rehecho los compiladores de C# y de Visual Basic desde cero en… Visual Basic.
Hay que joderse. La primera en la boca. ¿Pero no decían que el compilador y el propio .NET estaban hechos en C# (lo siento, no encuentro la referencia)? Ahora no, ahora resulta que C# está escrito en C++.
Y la segunda, también: C# está hecho en Visual Basic.
O están tontos, o yo no me entero, o mienten más que hablan. Para nada me extraña de que hubieran mentido en lo de hacer C# en C++, de hecho es lo lógico y coherente, ¡pero construirlo todo en VB?
De todos modos dejemos esto aquí, corramos un estúpido velo, y centrémonos en el meollo del artículo: compilador como servicio.
Es decir, en Visual Studio 11 los compiladores de C# y VB no serán ejecutables, sino servicios expuestos al público (espero que haya uno para invocarlo desde la línea de comandos), de modo que cualquiera podrá compilar.
No solo eso, sino que dejarán de ser una caja negra que, a partir de un código fuente, genera una salida compilada, sino que podremos acceder a los diferentes estados del proceso de compilación, e incluso podremos realizar solo unos pasos, como análisis semántico o la obtención del código IL (ensamblador del .NET).
Eso posibilita la creación de scripts en una consola interactiva. ¿Recuerdan la consola aquella que tenía el Visual FoxPro que permitía ir encadenando comandos como si programáramos? Pues lo mismo, pero en VB y en C#. Vamos, que reinventan la rueda.
En la entrada original hay un par de imágenes enseñando lo que puede hacer.
Paragon HFS+ para Windows o cómo reventar un MAC
Cuando uno está en esto del switching indeciso, que no sabe si irse para Pinto o para Valdemoro, le pueden pasar cosas como la que os voy a contar.
Todos sabéis que desde hace unos años Apple permite la ejecución de Windows sobre su hardware compatible, y que suministra no sólo los drviers (que funcionan cojonudos), sino las herramientas necesarias para tener un arranque dual sin mucho problema. Por tener, hasta tenemos soporte de lectura para el formato de ficheros HFS+, con lo que veremos sin problemas las unidades del MAC, aunque no podremos escribir en ellas.
Una suposición personal es que, así, no podremos trastear en un sistema de ficheros en el que es peligroso tocar si no está cargado el sistema operativo. (Lo que viene a ser igual que con Windows, ya que si tenemos arranque dual, la instalación que no se haya iniciado podría ser fácilmente estropeada por algún zarpas, léanseme: yo mismo.
Pues bien, hasta aquí todo perfecto.
Supongamos ahora que queremos soporte de escritura. Porque somos así de chulos y así de molones, porque nosotros lo valemos. O simplemente porque tenemos una unidad de disco externo con nuestro MAC que también queremos usar en Windows.
Vale, la formateamos con FAT32 y listo. No os lo aconsejo. Aparte de que es un sistema de ficheros no muy robusto, carece de sistema de permisos y tiene otras limitaciones en cuanto a los nombres de los ficheros. Y si encima tienes ya ocupados unos cuantos gigas, como que se hace cuesta arriba la conversión.
¿Podemos escribir en HFS+ desde Windows? La respuesta corta es que sí. La larga es que mejor no lo hagas. Me explico.
Paragon Software Group cuenta con un driver para Windows (tanto de 32 como de 64 bits) que permite eso mismo: leer y escribir sin problemas sobre particiones HFS+. O eso dicen.
En mi caso ha sido un desastre total. No sólo me ha jodido la partición donde estaba el OS X (que no tendría mayor problema) sino que también ha destrozado otra sobre la que no estaba escribiendo, alojada en un disco externo por FireWire 800.
Me tocó reinstalar el OS X desde el DVD de Lion (porque de paso borré todo el disco interno del iMAC e hice una instalación limpia para ver si se me iban los problemas al actualizar a la 10.7.2) y olvidarme de los datos que había en el disco externo, algo así como medio Tera en máquinas virtuales, ISOs descargadas y otras copias de seguridad…
Así que ya sabéis, tomaos con calma el “HFS+ for Windows” y probadlo extensamente antes de pasar a producción.
iCloud o la flagrante tontería
¿Sabéis lo que es iCloud? Aunque digáis que sí, me juego un gallifante a que no. ICloud es una mierda envuelta en papel brillante, un trozo de bisutería rodeado de oro del que cagó el moro.
Acabo de comprobarlo. Tengo dos iMAC, un iPad, un iPod y un iPhone (este del curro, que todavía no he actualizado).
Como sabéis, hace unos días salieron todas las actualizaciones de golpe, tanto para el escritorio como para los dispositivos móviles. En mi caso la actualización a Lion 10.7.2 se realizó sin problemas, salvo una notable ralentización del sistema una vez reiniciado, ralentización que parece es temporal ya que ahora funciona todo casi igual de rápido que antes… excepto algún que otro rosetón multicolor de la muette que deja mi i7 de cuatro núcleos dobles y 12 GB de RAM como autista unos segundos… Eso no lo hacía antes de aplicar el parche.
No obstante, la actualización de los dispositivos móviles ha sido más que penosa. En primer lugar falló la descarga y la actualización. Me dio el infausto “internal error” causado por la caída de los servidores de Apple. Hay que joderse, con la expectativa generada y que la empresa no fuera capaz de preverlo con antelación. Joder, hasta Microsoft, el denostado Microsoft, cuando saca un producto nuevo que es muy esperado, aumenta y confía en terceros para las descargas…
Pero no todo termina ahí, no. El iPod se actualizó más o menos bien, a la tercera o la cuarta, pero el iPad hubo de sufrir bastantes intentos. O bien se quedaba autista o bien simplemente fallaba. Como tengo casi 40 GB de datos en él, y la interrupción se producía casi al final, la cosa llevaba su tiempo. Al final, restauración de fábrica, instalación de las aplicaciones y vuelta a meter los datos. Menos mal que soy un chico previsor y los tengo en el MAC, listos en sus carpetas. Eso sí, todavía estoy configurando programas…
¡Quietos parados, fanboys! A ver. Uno mete el iPad, te dice que tiene una actualización, le dices que sí, y a medias falla. No hay otra. No es mi culpa. Es de Apple. Por el motivo que sea. Mi iPad está impoluto, sin Jailbreak, sin cosas raras. Ya que está todo cerrado, debería funcionar a la primera, porque si no me vuelvo a Windows que me deja hacer lo que quiera sin más, y si falla puedo achacarlo a mi ineptitud, no a la de Apple. [Como colofón a esto, no soy el primero que ha tenido problemas. Básicamente la actualización a iOS 5 ha sido pésima. También quiero pensar que no se trata de un intento de que estampe mi iPad 1 contra la pared y me compre un 2.]
***
Bueno, ahora sí, ahora hablemos de la magia de la cosa esa del iCloud. ¿Os pensáis que es una versión mejorada de Dropbox? Juas, ni se le acerca. Hasta el infausto SkyDrive de Microsoft es mejor.
No, no es que vaya mal, es que no cumple mis expectativas. Es una decepción total, más que total, humillante. Lo único que te va a guardar iCloud son los documentos de Pages, de Office (a mi no me lo hace), tus fotos y los calendarios… pero los que crees en la nube. Es decir, la cacareada sincronización sólo se va a producir entre los documentos políticamente correctos que, como siempre, le vengan en gana a Apple. No mis documentos. No mis fotos ya hechas, no los documentos que yo quiera, no.
Y encima, como elemento de obsolescencia programada, si quieres tus documentos en la nube, paga por nuevas versiones que lo soporten. Asco me da. Decepción. Tristeza.
***
En serio, tengo una extraña sensación que me parece que, conforme va pasando el tiempo, es más fuerte y coherente: cuanta más cuota de mercado coge Apple, más se parece a los peores tiempos de Microsoft, con fallos estúpidos, dejadez en atender los requisitos de los clientes y olvidarse de que uno debe estar al loro con las actualizaciones de seguridad y que no debe esperar dos meses a, por ejemplo, invalidar una entidad certificadora. Es una especie de deja-vu, una sensación como de inquietud y de malestar… Ahora que Jobs ya no está, quizás la cosa mejore… aunque lo más seguro es que empeore.
Básicamente, maldita la hora en que me pasé a Apple.
Más sobre C++ AMP
Ya os comentaba en otra entrada del blog algo sobre la nueva biblioteca de paralelismo masivo llamada C++ AMP que traerá la nueva versión de Visual Studio, que ahora, tras el lanzamiento BUILD de hace unos días, se llama Visual Studio 11. Eso no quiere decir que vaya a salir este año, sino que se trata del número de versión. Si Visual Studio 2010 era la 10 (una mera coincidencia), la 11 quizás salga en 2012, más o menos cuando Windows 8.
Una pequeñísima introducción sobre C++ AMP
Es una biblioteca de C++ escrita para poder ejecutar código paralelo de forma independiente del hardware y a la vez aprovechar el hardware actual de los PC (léase procesadores multi núcleo y tarjetas de vídeo 3D) sin tener que complicarnos mucho la cabeza. También está pensada para aprovechar los futuros desarrollos de forma transparente para el programador.
También forma parte de Visual C++, por lo que no es necesario nada extra, y se encuentra perfectamente integrada en el producto, por lo que las tareas habituales como compilación y depuración son transparentes para el usuario.
Tan sólo necesita una extensión del compilador de C++ (el famoso restrict del que os hablé en la otra entrada), tiene una sintaxis similar a la de la STL, y es muy fácil trabajar con vectores multidimensionales de forma independiente del hardware.
Para los que no lo sepáis, una de las limitaciones de los procesadores SIMD (Single Instruction Multiple Data), que parafraseado podría ser Una Sola Instrucción Para Muchos Datos, está en su limitación respecto al tamaño de los arrays que pueden ejecutar de una sola tacada. Es decir, imaginaos que tenéis que rotar un cuerpo 3D compuesto por X polígonos. La rotación se puede hacer con una sola instrucción ejecutada para cada uno de los polígonos. Algo así como un bucle for que recorra todos y cada uno de ellos, aplicando la misma transformación. Con un SIMD, uno carga los datos en cada pipeline (o como se llame) y luego ejecuta la instrucción sobre todos ellos a la vez. El problema viene cuando tienes más polígonos que pipelines, y tienes que hacerlo a pedazos. Añade que el tamaño de cada pedazo no solo es diferente para cada procesador SIMD, sino también para cada versión (SIMD=Tarjeta de vídeo 3D). Con esta biblioteca te olvidas de todo eso. Ya lo hace ella sola.
Está basada en DirectCompute, una ampliación añadida a DirectX 11.
¿Puedo ejecutar C++ AMP?
Una opción es instalarte todo el tema (compilador, Direct X, etc) y probar a ejecutar un programa. Otra más sencilla es bajarte el programa que se describe en esta entrada y ejecutarlo. No requiere nada especial, y no usa C++ AMP para determinar si tu hardware lo permite o no.
En mi caso, ni el PC del curro, ni la máquina virtual, ni el portátil lo soportan. Pero sí mi PC principal, y seguro que el iMAC con Windows 8 instalado, que va a ser una de mis próximas tareas.
De todos modos, si el programa te dice que NO tienes hardware, no te preocupes, ya que la instalación del SDK de DirectX 11 o de Visual Studio 11 te creará un dispositivo emulado que no va a funcionar muy rápido que digamos, pero que al menos te permitirá ejecutar los programas.
Para aquellos vagos que no quieran leerse la entrada, o que simplemente no sepan inglés, aquí está el programilla.
Usando C++ AMP
Necesitas tener Visual Studio 11 en algún Windows (incluyendo la versión 8). Usar esto es tan fácil como incluir amp.h y añadir el espacio de nombre concurrency en tu proyecto. Ya está, ya puedes escribir código funcional.
Uno de los ejemplos más sencillos (y afuncionales) podría ser:
#include "stdafx.h"
#include <amp.h>
#include <iostream>
using namespace concurrency;
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
cout<<acos(0.123456)<<endl;
return 0;
}
Lo que a todas luces sirve para poco pero nos permite ver que todo funciona bien, ya que la función acos viene dentro del espacio de nombres concurrency como podríamos comprobar si escribiéramos
concurrency::a
Y dejáramos al sistema de IntelliSense que se abra y nos muestre las funciones disponibles.
Más ejemplos
Un buen sitio para aprender más sobre esto, en pequeñas dosis, es el blog de Parallel Programming in Native Code, que es de donde yo he sacado todo esto. De todos modos, en esta entrada del citado blog tenéis algunos puntos de entrada: C++ AMP in a nutshell.
Otro ejemplo, que de momento no he podido ejecutar porque lo he compilado con Visual C++ 11 en un Windows 7 virtualizado, es el ejemplo del SDK de DirextX llamado “N-Body Simulation Sample” y que ha sido portado aquí.
Aventuras de un instalador de Windows 8
Bueno, como ya os comenté en la entrada anterior, hablamos y hablaremos sobre Windows 8 y su orientación a los Tablet en este blog.
Por lo tanto, la entrada del título la podéis leer aquí.
WinTablet.info: Windows 8 y los Tablet
Ya sabéis que me gusta meter baza en los nuevos productos de Microsoft más que a un pollo la mierda. No creo que os pille de sorpresa, pero en este caso estamos hablando de caviar Beluga ya que encima tenemos dominio y web propia.
Sí, lo que leéis, el RFOG ha sido invitado a participar en un blog de temática exclusiva sobre Windows 8 y su orientación hacia los Tablet. Sin restricción de temática, sin censura y con libertad total de publicar lo que quiera (no, que no se os abran los ojos como platos, de momento no voy a poner porno).
Bueno, después de la presentación chula, vienen los detalles. Nos hemos juntado cuatro interfectos de entre los indeseables de la internet y que encima somos granos en el culo de las grandes corporaciones y nos hemos decidido a poner los puntos sobre las íes en el tópico descrito más arriba. La idea fue originalmente de Juan Luis Chulilla, quien la propuso a Ctitanic y a mi. No hace falta decir que tardamos 100 milisegundos en decir que sí, que es el tiempo medio de reacción entre el ojo y el cerebro (para aquellos que tengan neuronas, claro). Luego se nos unió Mahjong, y así formamos el cuarteto concertante (la referencia es de Verne).
Dicho y hecho, sólo faltaba arremangarse y empezar a escribir, así que el sitio ya contiene entradas chulas, aunque todavía anda algo en obras y debéis poneos casco no sea que se os caiga algún ladrillo en la cocorota.
Para aquellos que todavía estéis en Babia, os comento. Windows 8 es la siguiente versión de Windows 7, y viene en modo dual. Es decir, que trae dosShell de usuario. La primera es la que todos ya conocemos, con su menú inicio, su explorador y su Internet Explorer, con las mejoras pertinentes. Lo pongo en cursiva porque hay mucha gente a la que la Ribbon en el Explorador no les mola nada… a mí sí.
La segunda interfaz se llama Metro y está destinada a los Tablet, sean del tipo que sean. Si habéis visto Windows Phone ya tenéis una idea de qué es. Como siempre con las tecnologías de Microsoft, debajo hay más de lo que parece, y también ahora ocurre así.
A simple vista Metro parece nada más que una interfaz de apretar botones, pero dentro existe un motor basado en DirectX muy potente e interesante, envuelto en una capa que se programa con C# y una variante de C++/CLI. Y no es .NET, es nativa. De esto os contaré más aquí, pero en otro momento.
Finalmente también hay una preview de la siguiente versión de Visual Studio que es capaz de generar ejecutables para esta nueva plataforma, y de esto también hablaré por aquí.
Bueno, lo dicho, daos una vuelta por WinTablet.info.
Novedades en el futuro Visual C++ 2011 (o vNext)
Microsoft ya está planeando y compilando la siguiente versión de Visual Studio, que ellos han llamado temporalmente vNext o, recientemente, 2011, para indicarnos que se trata de la siguiente versión. No hay nada definitivo, ni fecha de salida ni qué va a traer, pero haciendo un poco de gurú, y teniendo en cuenta el ciclo bianual de salida, posiblemente tengamos algo el año que viene por estas fechas o un poco antes. Y no, no estoy haciendo uso de ninguna información privilegiada, que últimamente a los MVP nos dicen lo mismo que a los demás.
No obstante ya se empiezan a publicar algunas novedades sobre lo que va a traer. No son definitivas y quizás al final no las incluyan, pero tienen cosas bastante interesantes. Pese a referiros a los enlaces originales, os cuento yo aquí algunas cosillas. Iremos cronológicamente conforme han ido saliendo, ya que el interés también va en ese sentido.
Según Sumit Kumar, van a potenciarlo hasta el nivel de C# y más allá. Vamos a tener color para más elementos semánticos, de hecho hablan de hasta veinte tokens a los que podremos aplicar diferentes colores. Es decir, podremos distinguir a simple vista si un nombre es una variable local o global, una macro, una plantilla, un parámetro, un espacio de nombre, una enumeración… cosa que no está nada mal.
También habilitan la selección de una misma referencia en todo el código fuente. Es decir, cuando pongamos el cursor sobre un símbolo, dicho símbolo se selecciona en todo el texto.
También traerá un analizador heurístico en los desplegables, que se abrirán automáticamente y nos mostrarán los tipos más comunes y más probables pese a que empecemos a teclearlos mal.
Y, para equipararse a otros lenguajes, se añaden los Code Snippets, que son bloques de código listos para insertar.
Ne da un poco de corte explicar lo de arriba, porque todo eso ya lo hace Visual Assist de Whole Tomato… pero bien está que lo traiga de forma nativa… si funciona. Recordemos que no es la primera vez que el IntelliSense falla por completo en un producto de Microsoft. Esperemos que esta vez acierten a la primera.
Otra cosa que nos cuenta Sumit, y que personalmente yo no le veo mucho sentido, es que el Explorador de Soluciones traerá una vista de clases. Es decir, cuando abramos un fichero en dicha ventana, tendremos acceso a todas las clases y todos los símbolos de forma automática.
Si queréis ver las capturas de pantalla de todo lo que he explicado, haced clic en el enlace de arriba y veréis todo eso en marcha.
Amit Mohindra nos explica otras novedades en torno al IDE. La más destacable es que ahora no existe asistente para actualizar la solución. Es decir, si abrimos una solución escrita con Visual Studio 2008 o superior, no nos pedirá actualizarla y podremos usarla aprovechando las mejoras del nuevo IDE, y todavía podremos seguir abriéndola con la versión anterior.
Aquí surge un problema potencial, y es el uso de los nuevos compiladores. Es decir, imaginad que no tenemos instalado Visual Studio 2008 en la máquina en la que abrimos la solución pero sí Visual Studio vNext… Pues bien, existirá la forma de utilizar el nuevo compilador. Este tema está todavía pendiente de estudio, por lo que no está claro cómo lo van a hacer.
Otra cosa interesante va a ser la creación de plantillas de proyectos. En versiones anteriores había que crear una serie de ficheros bastante complicados de entender. Ahora esto podrá hacerse mediante un asistente. Aquí y aquí se explican algunas cosas más sobre esto.
Siguiendo con la lista de novedades, y conforme se van publicando en los blogs de Microsoft, ahora nos toca hablar de una característica que yo considero muy pero que muy potente en relación a la ejecución de código en paralelo.
Recientemente Microsoft ha sacado una biblioteca que ha dado en llamar C++AMP, y de la que podemos leer por aquí. Ignoro si forma parte de algún estándar (lo siento, ando un poco desactualizadillo en estos temas), pero creo que sí, al menos en su especificación si no en la implementación. Las siglas se conocen como Accelerated Massive Parallelism, y tiene que ver con los procesadores de uso generl multinúcleo y los vectoriales SIMD (de los cuales forman parte los chips de las tarjetas de vídeo modernas).
Evidentemente esto no sirve para un programa de gestión de datos, pero sí para juegos y otras aplicaciones que necesiten un rendimiento alto y que realicen tareas que se puedan ejecutar en paralelo. Digamos que es la solución que Microsoft está implementando en el mundo nativo (C++) como solución a los problemas actuales de paralelismo, y personalmente no lo veo nada mal.
Pues bien, DanielMoth nos cuenta que en vNext tendremos una nueva palabra reservada llamada restrict y que nada tiene que ver con su equivalente de C99, que MS no implementa. Básicamente la idea es utilizar dicho término para indicar dónde se debe ejecutar un método, si en el procesador principal o en el SIMD (tarjeta de vídeo).
Es decir, si nosotros ponemos algo como
void myFunction(int a) restrict(cpu)
{
}
Le estamos diciendo al compilador que esta función deberá ser ejecutada por la CPU del sistema, mientras que si lo indicamos así:
void myFunction(int a) restrict(direct3d)
{
}
Estaremos indicando que eso se debe ejecutar en el procesador gráfico.
E incluso es posible algo como esto:
void myFunction(int a) restrict(direct3d, cpu) //o restrict(cpu, direct3d)
{
}
Que indica que se podrá o deberá ejecutar en ambos procesadores.
Lo chulo de esto es que se trata de una indicación transparente para el programador, y que debe ser la implementación la que se encargue de toda la martingala para que pueda ejecutarse en uno o en otro sitio.
También podremos sobrecargar el método, de forma que podríamos tener tres funciones idénticas pero con diferente restricción, de forma que sería el compilador y el motor de tiempo de ejecución el que decidiera qué y cómo ejecutar.
Toda una chulada.
De todos modos, esto está un poco en el aire, y todavía no tienen claro algunas partes de la implementación y cómo va a terminar funcionando, pero es una característica muy guapa. Ojalá implementen algo similar para los threads y la sincronización.
Otra cosa que sí han hecho es optimizar el PPL (otra librería de ejecución en paralelo, esta con algo más de solera), ganando en algunos casos hasta un 20% de mejoras en el rendimiento con sólo recompilar el código existente con la nueva implementación de PPL que traerá vNext. Aquí lo tenéis con más detalle.
Ya está aquí C++Builder XE2: Una porquería de producto
Ya está aquí, ya ha llegado, la que prácticamente es la versión más mierdosa que jamás han sacado de C++Builder.
Pensaba que no se podía caer más bajo en ofrecer una versión de una herramienta de desarrollo, pero lo cierto es que sí, y se llama C++Builder XE2.
Ya estamos acostumbrados al ciclo de salida anuales de los productos de Embarcadero, con versión tras versión de un producto bastante inacabado y que sólo comienza a funcionar bien tras dos o tres parches, como es el caso de la última versión hasta ahora, la XE, que sólo ha comenzado a ser más o menos estable tras el Update 3, pero sin que solucionen bugs históricos como los que impiden trabajar con las versiones no parcheadas de Boost o que hacen casi inusables las que ofrecen parcheadas, eso sin contar con el pobre rendimiento de los ejecutables…
Pues bien, la única mejora destacable, y destacable de verdad, en C++Builder XE2, es que puede generar ejecutables para OS X. Sí, lo que leéis. Pero ¿vosotros habéis visto un ejecutable corriendo sobre OS X y compilado con esta herramienta? Si la respuesta es afirmativa es que sois bastante más suertudos que yo, porque, pese a tener la versión de prueba, no lo he conseguido.
El sistema de compilación cruzada funciona más o menos así:
Hay una nueva biblioteca visual que se llama FireMonkey y que es calcada a la VCL pero con la característica de que es multiplataforma, por lo que debéis olvidaros de simplemente recompilar vuestros anteriores proyectos. Hay que construirlos desde cero con esta nueva biblioteca. La ventaja es que los componentes se llaman casi igual y puede serte válido mucho código ya escrito.
Bueno, una vez que tienes instalada esta versión de Bulider, tienes que instalar una especie de servidor en el MAC donde vayas a depurar. Sí, C++Builder no se ejecuta dentro de un MAC, sino que sigue siendo una aplicación nativa Windows. Sí que puedes hacerlo desde una máquina virtual, pero ojo con la licencia de activación, que se suele perder cada cierto tiempo por algún problema con el sistema de ficheros, y tienes que reactivar el producto, y cuando llegas a cierto límite tienes que al menos enviar un correo explicando qué te pasa y por qué quieres más activaciones.
Una vez que tienes instalado y lanzado el servidor en tu MAC (tras leerte bastante documentación y tras varias pruebas en falso), tienes que añadir la plataforma en tu proyecto FireMonkey (nombre ridículo donde lo haya). Luego tienes que crear un perfil y asociarlo al proyecto. Y finalmente ejecutarlo.
Vale. Todo el tema del perfil y demás está hecho de aquella manera, con una especie de asistente mierdoso y con poca documentación, pero una vez lo tienes todo hecho… no te funcionará. Ni siquiera compilará.
¿Por qué? Muy sencillo: aparte del tema de la pérdida de la licencia, el IDE del RAD Studio no es compatible con carpetas compartidas de una máquina virtual. Igual que ocurre con Visual Studio, que parecen productos calcados…
Vale, tienes que tener tu proyecto en una carpeta local de la máquina virtual. Ahora sí que compila. Pero al lanzar el ejecutable, el lado servidor empieza a soltar error sobre error con librerías no instaladas, recursos faltantes y demás que hacen que, al menos yo, deje de mirar esta mierda de producto.
Lo dicho: si vais a comprar la versión de C++Builder porque genera ejecutables de plataforma cruzada, no lo hagáis hasta por lo menos la versión XE1000000000 o superior, porque simplemente da asquito.
Eso sin mencionar que la compilación tanto para Windows como para MAC es de 32 bits. Sí, lo dicho, C++Builder todavía no trae compilador de 64 bits (aunque Delphi XE2 sí que lo trae, pero no para OS X).
Vamos, lo dicho, una mierda pinchada en un palo.
Qué grandes palabras, sí señor
Me vais a permitir un exabrupto off-topic total con este blog (y en general con todos mis blogs en donde lo voy a poner), pero son unas grandes palabras dichas por un grande y que por desgracia son más ciertas de lo que parece.
El artículo de Javier Armentia está bien, pero todavía están mejor las palabras de José Luis Sampedro y que reflejan toda mi indignación sobre la visita del Papa y ya de paso de otros temas más que candentes.
Me refiero a esto:
http://javarm.blogalia.com/historias/70247
Aprobado: C++0x ya es C++11
Leo en el blog de Sutter, la representación de Microsoft como compañía en el comité internacional de estandarización de C++, que, por fin, el nuevo estándar ha sido aprobado por unanimidad y que pasa a llamarse, como ya se esperaba, C++11.
Un poco más y lo tentemos que llamar C++12.
El rey ha muerto. ¡Viva el rey!
Ahora a ver qué tal lo hace Microsoft con su próximo compilador, y a ver si BorlandEmbarcadero se pone las pilas y también hace algo, aunque lo más seguro sea para C++Builder XE3 el año que viene o el otro, porque el XE2 ya está terminado y a punto de salir, por cierto con compilación cruzada para MAC OS…
La noticia original: http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/
OS X Lion: Ver la carpeta Librería desde dentro del Time Machine
De nuevo volvemos a Lion y a sus chipirtifláuticas nuevas características súper fashion de la muette.
Ahora hablamos de cómo mirar dentro de la Librería de nuestra carpeta de usuario cuando estamos dentro de Time Machine porque queremos recuperar algo de allí.
No, no se ve. Aparte de que es un poco complicado acceder a la carpeta de usuario porque Apple nos quiere ocultar cada vez más el sistema de ficheros de OS X, cuando entras en ella la carpeta Librería no está aunque le hayas cambiado el atributo de oculto…
Mola, ¿no?
Si buscas por la red verás un montón de páginas que explican cómo hacerlo, matando el Finder y con otras técnicas un tanto barrocas. La mía no es que sea muy directa, pero al menos no le tocamos las pelotas al sistema operativo y se hace todo de forma ordenada.
Lo primero que hay que hacer es montar la unidad en donde se guarda la copia de seguridad. Hay varias formas, como lanzar una copia de seguridad manual, entrar en el Time Machine y luego salir o simplemente haciendo clic en la unidad en donde estemos realizando la copia.
Una vez montada, es tan fácil como abrir un Terminal y movernos al
home de la copia que queramos. Partimos de la carpeta "/Volumes" y nos vamos adentrando en la copia. También podemos hacer doble clic en el disco montado en el escritorio o seguir navegando por el Finder… La cosa es llegar al
home de la fecha que nos interese, ya sea por terminal o con el Finder.
Una vez allí podemos pulsar CTRL-I (o Ver información) sobre la ruta, para saber dónde estamos. Si hemos usado el terminal no tenemos que hacer nada más que, una vez en nuestro
home, picar "cd Library" y estaremos dentro.
Si lo hemos hecho con el Finder, ahora es turno de abrir un Terminal y seleccionar y copiar la ruta completa que nos aparece en la ventana de información, picar "cd " en el terminal y pegar dicha ruta sobre el mismo. Al pulsar Enter estaremos en la misma situación que el párrafo de arriba.
Ahora viene el truco del almendruco. Podemos usar el terminal para copiar lo que queramos con los comandos de Unix (ya sabéis, cp), pero resulta mucho más cómo hacerlo con el Finder. Por lo tanto ahora picamos
pwd
en el terminal y presionamos enter. Justo arriba del cursor nos aparece la ruta completa en donde estamos. La seleccionamos con el ratón y la copiamos.
Hacemos clic sobre el escritorio para que en el menú del sistema nos aparezca el del Finder. Elegimos "Ir -> Ir a la carpeta" y en cajetín, pegamos la URL que acabamos de copiar. Se nos abrirá una ventana del Finder en todo su esplendor.
[Sí, ya sé que hay una forma muy fácil de mostrar la Libería, que es explica en infinidad de sitios, pero sólo sirve para la carpeta de la cuenta actual, no dentro del Time Machine.]
Por supuesto también vale hacer esto para entrar en la Libería del
home actual de nuestra cuenta de usuario.
Otra forma para, desde cualquier carpeta, ir retrocediendo carpetas padre, es pulsar Commando+Flecha Arriba o, sobre el título de la carpeta en el Finder, retroceder haciendo clic con el botón secundario del ratón.
OS X Lion: Activar la repetición de teclas
Sin muchas ganas de escribir una nueva entrada, voy a poner algo interesante que corrige una de las cagadas de OS X Lion: la repetición de las teclas que llevan caracteres especiales.
Como os comenté en la entrada anterior, Apple la había cagado a base de bien con el tema de la repetición de teclas. Supongo que para un usuario Ruso o Báltico, la cosa puede resultarle interesante, pero no para la mayoría del resto del mundo.
Si la opción fuera configurable no habría problema: se cambia y ya está, pero no lo es, o al menos no lo es de forma sencilla ya que no aparece por ningún lado en la configuración.
Sin embargo sí que existe una forma de volver la cosa a su estado original, y es mediante un comando tecleado en el terminal de OS.
Abrís la aplicación de terminal (tal y como se escribe), y pegáis el texto:
defaults write -g ApplePressAndHoldEnabled -bool false
Y pulsáis enter. Ya está cambiado. No sé si es necesario reiniciar o cerrar la sesión abierta porque simplemente lo piqué y seguí con el MAC encendido y no tuve oportunidad de comprobarlo hasta que reinicié al día siguiente.
Y es que, a veces, sólo a veces, esas webs sensacionalistas pro Apple sirven para algo, ya que de esto me enteré aquí.
OS X LION: Mucho rugido y pocas nueces
Como ya sabréis, hace un par de días que ha salido Lion, la nueva encarnación de MAC OS X de Apple. Tras estar usándolo un poco, estas son mis conclusiones.
Como ya nos tiene acostumbrados el mago Steve, mucho ruido y pocas nueces. Lion no es más que una lavada de cara de Snow Leopard, con ciertas concesiones a la usabilidad y a los usuarios que no han tocado en su *** vida un ordenador o que vienen de manejar su iPhone, iPad, etc…
Sigue careciendo de cosas evidentes por sí mismas, como una combinación de teclas global para llamar al Finder igual que Win+E llama a la Shell de Windows. De verdad, os lo aseguro, no me entra en la cabeza cómo los lumbreras de Apple no se han percatado de ello. (Disclaimer para fanboys y demás morralla: CMD-Espacio y ALT-CMD-Espacio, ya me las conozco, pero navegad con ellas por los archivos).
La chorrada más gorda de todas las novedades que trae es el famoso Launchpad que, hablando en plata, es una mierda pinchada en un palo. No por el concepto, sino por la implementación. Está bien eso de enseñar los iconcillos de las aplicaciones todos a una, como Fuenteovejuna, pero la implementación deja mucho que desear porque no se puede manejar con el teclado. Lo único que puedes hacer es cerrarlo con la tecla de escape o cambiar de página con los cursores.
Si bien el tema del Launchpad puede ser algo relativo a gustos, el de la repetición del teclado es de imbéciles. Sí, de imbéciles. No sé a qué lumbreras de Apple se le habrá ocurrido eso, pero habría que condenarlo a no acercarse jamás a un ordenador el resto de su triste y miserable vida.
En Lion, ¡no hay repetición de tecla! Es decir, si tu vas a escribir una X y muchas D seguidas, te vas a cansar de mantener la D apretada. Lo que te va a aparecer es el *** globito de mierda como en iOS para que elijas, pulsando un número la tecla especial que has decidido poner.
Vamos a ver una cosa. Hasta los teclados de los portátiles llevan los acentos y demás teclas. De hecho, todos los teclados de todos los ordenadores de Apple son prácticamente idénticos. ¿Por qué cojones ponen eso? Y lo peor de todo es que no puedes volver atrás.
Otra de las features que se han estado cantando a bombo y platillo es lo de que el ordenador se abre igual que se cerró: ¡Mentira cochina!
Me explico. Abres Word, editas un documento y lo cierras con CMD-W. Abres iTunes, sincronizas tu iPhone y lo cierras de la crucecita. Haces lo mismo con más programas. Digamos que dejas Mail viéndose en la pantalla. Entonces reinicias tu MAC. Cuando se vuelve a cargar, se supone que vas a tener Mail en pantalla y los demás programas cargados y residentes.
¡Pues no! ¡Se abren absolutamente todos como si hubieran estado abiertos antes! Por lo que tendrás que cerrarlos de nuevo, uno a uno menos Mail. Lo dicho: una mierda completamente inútil.
Mail, el programa de correo de Apple. ¿Cuántas tonterías e imbecilidades se pueden llegar a decir de esa mierda de programa? Os aseguro que muchas, muchísimas. Muy bonito, muy cuco, muy bien organizado, pero como tengas más de diez mensajes leídos en la bandeja de entrada, te las vas a ver putas para encontrar los nuevos no leídos, a no ser que los tengas ordenados por leído… Y no, no vale hacer una carpeta inteligente porque entonces sólo te pone el mensaje sin leer pero sin el contexto de los otros. Y con carpetas IMAP no se entera de que el mensaje está ya leído en una de ellas y lo deja sin leer si aparece en otra, teniendo que volver a marcarlo como leído… Y no hablo del iCal y la mierda esa de simulación de arrancar página que tarda una eternidad… La usabilidad en el *** culo.
***
Si no lo sabéis, y a falta del Air, que tendré en breve, tengo dos iMAC. El primero de todos es un Mid 2008 (para aquellos que no estén al tanto, un Core2Duo con 4 GB de RAM y monitor de 24”). El segundo es uno nuevo, el Mid 2011 pero con esteroides: i7, 27” de pantalla y 12 GB de RAM (compradas aparte). Con un segundo monitor de 24” normal y corriente y el MY BOOK STUDIO EDITION II que ya tenía como disco secundario.
La bajada del león fue rápida, y tras copiarlo a un USB, empecé la actualización de ambos equipos a la vez. Mientras el antiguo estuvo listo en cosa de media hora, el nuevo, sí, el nuevo, tardó cerca de una. Mientras que el viejo iba como una moto después de actualizar, el nuevo se colgaba y hacía cosas rarísimas. Debería haber sido justo al revés.
Lo cierto es que el sistema me quedó prácticamente inusable, con extraños cuelgues de aplicaciones e incluso del sistema entero. De hecho hubo momentos en los que ni funcionaba ni internet. Al final, siguiendo documentos no oficiales (porque los oficiales te dicen que instales Snow Leopard y luego Lion encima, aunque el error se presente al hacer eso mismo –y que conste que no soy el único que está teniendo serios problemas con la instalación), me hice un DVD e instalé en limpio. Ahora sí, ahora va todo bien.
Otras cosas como Airdrop sí que están bien, y ya podría Microsoft aprender algo de Apple, porque por ejemplo su Homegroup apesta… cuando funciona, que no siempre lo hace. Y sí, la nueva versión de OS X tiene sus cosas guapas que aumentan la productividad, pero de eso ya han hablado otros largo y tendido.
Más artículos
Página siguiente >