.NET o no .NET, esa es la cuestión : Sistemas Operativos

Yuliop y Windows Phone 7 SDK: Una introducción

Rafael Ontivero — Thu, 01 Nov 2012 18:52:42 GMT

Como ya comenté hace algo de tiempo, he realizado un cambio laboral bastante radical, dejando de lado el desarrollo de sistemas embebidos verticales escritos en C y C++ para subir un paso en el escalón del desarrollo en cuanto a tipos de proyecto. En otras palabras, ahora mi tarea principal es desarrollar con Windows Phone para una startup llamada Yuilop.

He pasado de ser un desarrollador más o menos versátil a estar no sólo centrado en una plataforma fija, sino en una única aplicación: su cliente de mensajería. Os contaré cómo funciona la cosa.

La aplicación está disponible para la mayoría de teléfonos Android y para iOS, y próximamente habrá una versión para Windows Phone 7.5, la que estoy haciendo yo. Olvidaros de Windows Phone 7.0 porque no tiene sockets y es prácticamente imposible hacer algo ahí. Se podría implementar con BOSH, pero no vale la pena.

Con la aplicación instalada en un teléfono se pueden enviar mensajes de texto, con emoticonos y emojis, de manera similar a como se realiza con otras aplicaciones similares. También puedes enviar fotos y localizaciones. Hasta aquí nada nuevo bajo el sol.

Lo novedoso está en que también puedes hacerlo a gente que no tenga la aplicación. Es decir, puedes chatear con prácticamente cualquier persona que tenga un móvil a través de SMS. Es decir, tu envías un mensaje de chat y la otra persona recibe un SMS, y justo al revés.

También puedes hablar por teléfono mediante VOIP. Siempre que la otra parte tenga Yuilop instalado podrás hablar con ella de forma gratuita a través de la WiFi o del 3G, sin gastar una llamada de voz tradicional…

No, espera, no. Eso también lo puedes hacer con cualquiera. Incluso con teléfonos fijos. O en otras palabras: no es necesario que la otra persona tenga la aplicación instalada para poder hablar con ella a través de Yuilop.

Todo ello con coste cero. O más bien, pagas la transferencia de datos, el Wifi o el 3G. No pagas ni SMS ni establecimiento de llamada ni a razón del tiempo que estés hablando o chateando o SMSseando.

¿Cómo puede funcionar algo así? Pues bastante fácil: la aplicación tiene publicidad, y el pulsar en ella, o instalarte aplicaciones recomendadas, o seguir ciertas indicaciones te dan energía, que es lo que gastas a la hora de hablar o chatear con gente no Yuilop.

Es decir, que cada vez que hagas algo con gente de fuera de la aplicación, gastas energía. Cada vez que instalas las aplicaciones recomendadas, o haces clic en la publicidad, o chateas con gente Yuilop, obtienes energía. También por invitar a amigos y que estos acepten la invitación.

***

Como veis resulta algo bastante interesante y más potente que las aplicaciones de la competencia (que no nos dejan nombrar).

Pues bien, el que esto suscribe tiene en un estado bastante avanzado la aplicación para Windows Phone. Dadas las características de este sistema operativo, hay algunas opciones que no van a estar disponibles, no porque no queramos, sino porque no podemos.

Y eso me lleva al tema técnico. Llevo dos meses desarrollando con Visual Studio 2010 y el SDK 7.1. Ha habido momento en los que he estado a punto de renunciar dadas no ya las enormes carencias de la plataforma, sino también la falta de documentación y las inconsistencias y bugs de todo ello.

Y de eso es de lo que voy a hablar próximamente aquí. Primero haré una lista de todos los problemas con los que me he encontrado y la forma que te tenido de solucionarlos cuando he podido hacerlo, que no siempre ha sido así.

Para adelantaros un poco el tema, el modelo MVVM es una mierda limitadísima que sólo permite realizar aplicaciones típicas y sencillas, el acceso a bases de datos es, más que pésimo, limitado e incoherente, y existen ciertas limitaciones incoherentes para realizar algunas tareas. Además, la gestión de eventos es mínima, la creación de controles personalizados deja mucho que desear, así como el API expuesto en relación a los componentes con los que podemos trabajar (y ahí incluyo también el Windows Phone Toolkit y sus amigos de Coding4Fun).

Y no, el modelo asíncrono de desarrollo es toda una gozada si no existieran las limitaciones arriba descritas. Los métodos asíncronos, los operadores lambda, los métodos de extensión (pese a ser aberraciones, ya os contaré) y demás zarandajas son una gozada.

Mejor no hablar de XAML, menuda porquería de implementación aunque la idea esté genial.

Y a todo ello añadimos el hecho de que apenas existe documentación. Mientras que para la explicación de una clase en .NET 3, 3.5 ó 4.0 tienes una explicaciones más que detalladas contándote todo, en Silverlight las páginas están más que peladas. Por no incluir ni siquiera ponen lo imprescindible. Parece que se hayan creado a partir del propio código fuente sin más. Y no, no vale aplicar las explicaciones de una a la otra: simplemente funcionan diferente o el comportamiento no existe.

Bueno, lo dicho, estad atentos que le voy a dar caña a Windows Phone 7.5 (Parece ser que la versión 8 ya es adulta y han añadido cosas muy interesantes. También os contaré dentro de unos meses, cuando empiece con ella).

Viendo el código fuente de .NET con Visual Studio 2012

Rafael Ontivero — Sat, 15 Sep 2012 11:19:14 GMT

Quien tenga una versión anterior de Visual Studio seguro que sabe que se puede navegar por las tripas de .NET y ver cómo Microsoft ha implementado todo el tema. Pues bien, más o menos a mediados de agosto del corriente (2012) se anunció la disponibilidad del código fuente de .NET 4.5, lo que nos permite meternos en las tripas del Framework y, lo que es mucho más interesante, mirar cómo funciona todo lo nuevo relacionado con Windows 8.

El artículo citado da un somero repaso a las novedades no específicas de la biblioteca, entre las que se pueden destacar el añadido de métodos asíncronos en conjunción con las clases de tareas, y que ahora el jitter es capaz de optimizar el código para los procesadores multinúcleo. También se mejora el rendimiento de casi todo (como siempre dicen, lo que a veces no es cierto), y se potencia el acceso de .NET a nueva parte nativa de Windows 8 (o RT o Metro o como quieras llamarlo), que es código nativo escrito en C++ y C++/CX, permitiendo a este lenguaje acceder, también, a código escrito en otros lenguajes .NET gracias a su parte CX (que como ya he dicho varias veces, es nativa).

Como en otras versiones, el código fuente está disponible para descarga directa, o para ser visto desde nuestro propio código, y también como símbolos de depuración.

La captura de abajo nos muestra una aplicación Metro por defecto, detenida en un punto de interrupción, tal y como se ve en mi Visual Studio 2012 sin cambiar la configuración por defecto:

Fijaos en que la ventana de Call Stack estgá prácticamente vacía, y si hacemos Step Into simplemente saltamos a la siguiente línea de nuestro código fuente.

Vamos a habilitar la posibilidad de meternos dentro del código de Microsoft.

Nos vamos a TOOLS -> PROPERTIES, abrimos la pestaña lateral de Debugging, y cambiamos las siguientes opciones:

· Marcar Enable Just My Code

· Marcar Enable .NET Framework source stepping

· Desmarcar Step over porperties and operators (Managed only)

· Marcar Enable source server support

· Desmarcar Require source files to exactly match the original version.

Dejadlo todo más o menos como en la imagen:

Ahora, en la pestaña de Symbols, hay que añadir una nueva dirección de descarga de los mismos: http://referencesource.microsoft.com/symbols. Como en la capura.

Finalmente, cuando le deis a OK el IDE se quedará bajando ficheros. Hay que esperar a que termine, y dependiendo de lo rápida que sea tu conexión, tendrás que esperar bastante tiempo.

Con esta configuración, cada vez que se necesite algo, el IDE irá a los servidores de Microsoft, por lo que la carga y depuración de vuestro programa podría ser muy lenta a veces… por lo que se pueden bajar todos los símbolos de una tacada e instalarlos de forma local, apuntando la URL anterior a done los hayamos instalado. Podéis bajarlos de aquí.

La siguiente captura muestra algo de las tripas de Metro:

Vale. Ahora el tío de la rebaja. ¿Habéis intentado profundizar en el código fuente, en métodos como el Activate() de la primera captura? No entra, ¿verdad? No muestra código fuente, sino que simplemente salta sobre la llamada.

Un gallinfante a quien adivine por qué es.

Vale: es código nativo. Es decir, la parte Metro del .NET Framework no es código manejado, sino nativo. Es decir, está escrita en C++/CX, en donde la parte CX actúa como Sugar Syntax de todo el perifostio COM y COM+ que finalmente es .NET

Y todavía me atrevería a añadir algo más. Metro esconde en la manga algunos trucos de desarrollo que a MS no le interesa que se sepan, y ya visteis lo fácil que es hacer ingeniería inversa de una aplicación .NET. Si toda esa parte hubiera estado hecha con .NET, sería facilísimo meterle mano.

¡Y qué cojones, donde esté C++ que se quite cualquier lenguajucho de mala muerte! ;-)

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

Rafael Ontivero — Tue, 05 Jun 2012 14:18:15 GMT

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 Files\WindowsApps” 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:

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:

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

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:

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:

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:

***

¿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

Rafael Ontivero — Fri, 01 Jun 2012 14:02:55 GMT

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 *** 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.

Menuda porquería de gestión de memoria que tiene el OS X

Rafael Ontivero — Sun, 06 May 2012 18:24:35 GMT

A veces, cuando uno es un swicher de pro como yo, se encuentra con cosas que le resultan un tanto kafkianas como la que os voy a contar.

¿Tiene alguien queja de la gestión de memoria de Windows? No me refiero a si consume más o menos, sino a si funciona como debe, sin que haga cosas raras. ¿A que no? Pues en OS X (los MAC para los despistados), dicha gestión deja mucho que desear.

Hace tiempo empecé a leer en los blogs fanboys la existencia de ciertas aplicaciones que liberaban y optimizaban la memoria de los MAC. En principio algo similar a los supuestos optimizadores de memoria en Windows, pero para OS X. Y si en Windows no hacen falta y sólo consumen recursos, en OS X debería ser lo mismo o, en opinión de los expertos, todavía más inútiles que en la plataforma de Microsoft.

Yo fui uno de esos que comenzó a defender a capa y espada la gestión de memoria del OS X sin haber hecho ninguna prueba porque suponía que era una cosa que se caía por su propio peso: si un sistema operativo es incapaz de gestionar bien su memoria, poco útil va a ser…

Y de hecho, igual que pasó en su momento cuando se promocionaban ese tipo de aplicaciones para Windows, con artículos pagados y demás, se armaron en los citados blogs unas buenas trifulcas sobre el tema, con razonamientos a favor y en contra más o menos elaborados y veraces…

Una puntualización. En OS X, cuando tu cierras una aplicación, está no se cierra realmente, sino que se suspende y queda residente en memoria. Es lo que ocurre cuando le das al aspa de cerrar, o cuando presionas Command-W. Si realmente quieres retirarla de la memoria, o cerrarla ala Windows, tienes que presionar Command-Q o hacerlo a mano desde el Dock. Aquí hablamos de cerrarla realmente, que es cuando se debería liberar su memoria. No obstante, hay programas que realmente se cierran ellos solos, como el gestor de libros Calibre.

Por lo tanto, en OS X tenemos dos formas de cerrar una aplicación. En la primera realmente no se está cerrando, sino que se está ocultando y no es aplicable lo que estamos hablando aquí. Sería el equivalente de minimizar en Windows.

En OS X, la memoria se va asignando pero no liberando. Es decir, tu abres un programa, lo usas y luego lo cierras del todo. La memoria asignada no se libera, sino que queda asignada por si se vuelve a abrir la aplicación y se aprovecha la huella de memoria ya existente.

Por lo tanto, conforme vas abriendo y cerrando aplicaciones la memoria se va llenando poco a poco hasta que apenas queda libre. Hasta aquí la cosa está bien, porque de este modo mantenemos una caché que podría resultar en un aumento de rendimiento.

Y a veces es así. La segunda vez que abres ciertos programas, estos se cargan mucho más deprisa porque recuperan su imagen de la memoria física. Por ejemplo, en el caso del Opera con varios miles de mensajes de correos y de news, la diferencia es abismal. De tardar como treinta segundos o más a ser completamente instantánea.

Según la teoría, una vez que se ha ocupado toda la memoria y se necesita más, es esa caché la que se va liberando según un algoritmo que no me he preocupado en mirar.

Eso es la teoría. La práctica es otra: se tira de swap y el rendimiento de tu MAC empieza a caer en picado y oyes cómo empiezan a rascar los discos duros. Y nadie puede negármelo porque lo he comprobado yo mismo esta mañana.

Todo ha comenzado pasándome del iMAC al Air la biblioteca del iTunes. Para ello he iniciado el AirDrop y con ambos iTunes cerrados, lo he copiado. En el Air estaba vigilando el uso de procesador del Sparrow, que me tiene mosca, así que he abierto el monitor de actividad en el iMAC.

La primera en la frente: de los 12GB de RAM que tiene el iMAC, he visto cómo conforme si iban pasando los ficheros de uno a otro se iba quedando en cero libres. Una vez ha terminado de copiar, he abierto varios programas como el Word, el Pages y el ordenador ha comenzado a tirar de swap en lugar de liberar la memoria inactiva. Los he cerrado del todo y no ha decrecido el consumo.

Para completar el ejercicio he lanzado una máquina virtual que consume 2GB de memoria y ni aun así se ha liberado lo ocupado, sino que los discos han empezado a rascar todavía más furiosamente y el rendimiento ha caído en picado…

Tras eso me he ido a la App Store y me he bajado un liberador de RAM. Al poco de ejecutarlo y lanzar la limpieza de la misma, mano de santo, oye. Los discos han dejado de rascar y me ha dejado algo más de 8GB de RAM libres, que han subido a 10 cuando lo he vuelto a ejecutar tras cerrar la máquina virtual.

El problema, evidentemente, no está en el consumo de RAM. Por mi como si se ocupa toda, sino en el hecho de que un consumo real de 2GB del sistema operativo más otros 2 GB de la máquina virtual, han tirado abajo el rendimiento de un iMAC con 12GB de RAM y un i7 con 8 cores…

Pensaba que Apple podía hacerlo mejor, pero al final resulta que son unos chapuceros de mucho cuidado…

Por si os interesa, he probado el FreeMemory y tras comprobar que funcionaba bien, he comprado la versión Pro por tres cuartos de euro.

ExFAT 1, XBOX 0, Microsoft -infinito

Rafael Ontivero — Sun, 06 May 2012 17:07:17 GMT

Esta tarde nos hemos puesto a ver una película en la XBOX… lo que ha supuesto toda una odisea. Me explico.

Enciendo la consola y hala, actualización. No suelo encenderla muy a menudo, pero joder, que pase como con los PC… Pero el tema no es que haya sido una, sino que han sido dos, la segunda de ellas muy muy gorda. Tanto, que supongo que se ha actualizado toda entera.

La primera en la frente: no he podido usar la consola cuando he querido, sino que me he tenido que esperar más de media hora. Vale, podría haber decidido actualizarla luego, pero cualquiera se fía de un equipo que se conecta a internet con la que está cayendo…

Vale. Entro ya en el interfaz y meto un USB normal y corriente de 16GB… No lo detecta. Lo saco y meto un segundo de 4 GB, previa copia de lo que íbamos a ver. Tampoco lo coge. De 1 GB. Ni con esas.

Vale, estaban en ExFAT y la consola ¡¡no soporta los propios formatos de Microsoft!! Está bien que no lo haga cuando salió el sistema de ficheros, pero éste lleva ya varios años en el mercado.

Entiendo que no lea NTFS, ni HPFS, ni Ext2, ni ReiserFS… Es razonable a más no poder, ¡pero que un producto de Microsoft sea incapaz de leer sus propios formatos!…

Porque entendamos que si bien NTFS es un sistema “enterprise”, ExFAT es comercial y pretende ser la sustitución del veterano FAT… ¡Joder, si hasta los MAC los leen!

Y lo peor no es eso, lo peor es que una vez que ha sido tocado por la XBOX, ese USB deja de poder aceptar nuevo contenido. Es decir, que sólo deja ver y borrar ficheros, pero no añadir.

***

Al final, mientras reformateaba el disco a FAT32, y copiaba los archivos, me dio por navegar un rato con la consola…

Ahora se pueden instalar aplicaciones. Vale. Me instalo el visor de Youtube, por hacer algo. Se instala sin problemas.

Lo lanzo segundos después ¡y me dice que tiene que actualizarse! Hay que joderse, amigo Sancho… ¡¡Pero si está recién bajado de la tienda!!

En fin, se actualiza, entro y… necesito una cuenta Gold. La mía es la normal, sin pago…

¿Por qué cojones no me dice que es necesaria una cuenta Gold antes de instalar? Pues si piensan que tras la instalación voy a pasar por caja van arreglados.

Por seguir probando (ya que todavía no se habían copiado los ficheros en el disco USB), instalo la aplicación de DailyMotion. Esta al menos me avisa de que habrá cosas del interfaz no soportadas en la consola, pero cuando lo lanzo e intento ver un vídeo… me vuelve a pedir la cuenta Gold.

***

Vamos, lo dicho, un gigantesco despropósito de cosas que me resultan completamente incomprensibles… No sé quiénes tomarán las decisiones, pero seguro que serían más útiles cavando bancales de ajos que decidiendo qué va y qué no va en los productos de Microsoft.

Y no hablo de los problemas de conexión que tengo con el Media Center (de Microsoft) y el NAS (este no es de MS), aunque el último suele ir sensiblemente mejor que el primero.

***

Básicamente, que les den.

Culico que veo cubico que deseo

Rafael Ontivero — Fri, 04 May 2012 10:58:19 GMT

Creo que ya tengo un post con el mismo título por algún lado, pero no puedo resistirme a comentar algunas cosas sobre los últimos movimientos de Microsoft.

Hay cosas de las que de momento no puedo hablar, pero hay otras que sí, y la verdad es que resultan un poco risibles porque, al menos desde mi punto de vista, son la respuesta incorrecta a una competencia mal entendida.

Os comento.

Apple, de vez en cuando, dice cosas como que el Flash es malo y sus productos no lo llevan, o que la disquetera está obsoleta, o que simplemente se acabaron las instalaciones con unidad de disco…

Y eso primero genera polémica, y luego resulta que tenían razón…

Pues bien, Microsoft quiere hacer lo mismo, pero como ya sabemos dónde tienen el estilo, la cosa termina, seguro, en unas risas y en una l,vuelta atrás.

Por un lado, mientras todos los fabricantes de móviles hacen cada vez equipos más potentes y con más funcionalidades dentro de su sistema operativo, mientras que mantienen otras restricciones más o menos incomprensibles para los expertos, Microsoft ha decidido hacer lo mismo… pero a su manera.

En general, un producto de Microsoft siempre ha ido creciendo tanto en vertical (más necesidad de hardware) como en horizontal (un API más rico y más completo). Esto ha llevado siempre a que la siguiente versión ha necesitado más memoria y más procesador para funcionar bien. En la parte de las APIs, han preferido enmarranar y convertir algo existente en más complejo en lugar de hacer borrón y cuenta nueva o simplemente añadir un API nuevo con más funcionalidad y dejar que el anterior muera…

Tampoco vamos a hablar del hecho de que, cuando han conseguido una tecnología madura y estable, en lugar de mantenerla y ampliarla, han decidido reinventar la rueda y vuelta a empezar: nuevo de todo, nuevos bugs, etc…

Pues bien, como decía, en un intento de paralelizarse a Apple, en lugar de cambiar para bien, lo hacen para mal. Hablo ahora de Windows Phone de 256 megas de RAM, que enmierdan todavía más ya la mierdosa API de ese sistema operativo. Quitan cosas útiles y añaden nuevas inútiles (y ya hablaré de eso en otro momento). Básicamente quieren copiar, pero copian mal.

***

Apple retiró su Media Center por los motivos que fueran. Microsoft lo retira en su Windows 8. Nada, hay que hacer lo mismo.

***

Y ahora llega el colmo de los colmos. Windows 8 no podrá reproducir DVD sin programas externos porque dicen que el uso del DVD está rápido decline en los ordenadores…

En fin, lo dicho, copia, pero copia bien, joder, y no vayas haciendo este tipo de tonterías…

Windows Phone y las petisoperías

Rafael Ontivero — Thu, 12 Apr 2012 07:45:58 GMT

Hay que joderse, que dijo aquél. Este podría ser el resumen de esta entrada. Ahora mismo veréis por qué.

***

Estoy empezando a jugar de forma más o menos seria con Windows Phone. Ya cuando salió, el no poder ejecutar código nativo básicamente me hizo pensar que Microsoft había perdido el tiempo y que WP iba a ser un gran y nuevo fracaso de la compañía que había perdido el norte, el sur, el este y el oeste…

Pasa el tiempo y pese a todos los intentos de MS, WP no levanta cabeza. Ni cuota de mercado ni aplicaciones, comparándolo con Android e iOS, que crecieron mucho más rápido.

Ahora sé algunas razones, imposibilidad de usar C++ incluída.

***

Windows Phone 7.0 no tiene sockets. Toma ya. Increíble. Para los legos: no hay posibilidad de crear ningún tipo de aplicación de chat, ni de comunicación remota a servidores ni nada parecido. Todo hay que hacerlo mediante HTTP, que no conserva el estado y necesita sobredimensionar el lado servidor frente al cliente…

Whidows Phone 7.5 tiene sockets… de aquella manera. Cuando la aplicación pasa a background el socket se cierra, con lo que pierdes la persistencia en la comunicación. Aquí lo puedes solucionar mediante técnicas Push (que todavía no he visto e ignoro las limitaciones y ventajas que puedan tener). Pero de momento, aplicaciones verticales que requieran una conexión permanente tampoco están permitidas.

***

Ahora llega la última versión, con dispostivos de 256 MB de memoria… Y la vuelven a cagar. Dadas las limitaciones de los mismos, dejan de funcionar las tareas periódicas y las intensivas… Y te dicen que cuando lances la aplicación mires en qué dispositivos estás ejecutando y uses secuencias if/else para cambiar el comportamiento.

En primer lugar eso es una soberana imbecilidad como una casa. ¿Tienes que codificar las cosas dos veces? Pues no, tendrás que hacerlo todo con la limitación predicha, porque si lo puedes hacer sin esos elementos, es una soberana gilipollez repetir el código. El problema vendrá cuando sin eso no puedas hacerlo.

En segundo lugar, mientras los demás fabricantes implementan mejoras y optimizan el código de sus sistemas operativos, Microsoft hace lo contrario. Apple pasa de dispositvos de 256 MB de RAM a 512 y luego a 1024. Microsof pasa de 512 a 256, llevándose cosas de en medio.

***

Recuerdo la presentación de Windows Phone: que si sólo .NET, que si sólo procesadores multicore, que si sólo dispositivos de gama alta… Al final tienen que pasar por el aro, pero en lugar de abrir el Windows CE interno al lenguaje C y/o C++ y quitar la mierda del .NET, que seguro consume 40 de los 60 MB de la huella de memoria de cada proceso, van y quitan prestaciones… porque lo de las tareas asíncronas es sólo una de tantas limitaciones impuestas, que podéis leer en la entrada que os enlazo más arriba.

***

Resumendo, que van de mal en peor. RFOG dixit.

C++/CX (II). C++/CX vs WRL

Rafael Ontivero — Fri, 04 Nov 2011 19:13:32 GMT

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

Rafael Ontivero — Wed, 02 Nov 2011 16:41:00 GMT

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

Rafael Ontivero — Mon, 31 Oct 2011 14:34:00 GMT

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.

Paragon HFS+ para Windows o cómo reventar un MAC

Rafael Ontivero — Tue, 18 Oct 2011 20:07:50 GMT

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.

Aventuras de un instalador de Windows 8

Rafael Ontivero — Mon, 26 Sep 2011 18:58:41 GMT

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

Rafael Ontivero — Sun, 25 Sep 2011 09:43:55 GMT

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.

OS X Lion: Activar la repetición de teclas

Rafael Ontivero — Sun, 31 Jul 2011 18:38:17 GMT

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

Rafael Ontivero — Sat, 23 Jul 2011 15:19:05 GMT

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.

El fanboy rabioso (o la obsolescencia programada de Apple)

Rafael Ontivero — Fri, 25 Mar 2011 19:38:00 GMT

Si os pensáis que porque el RFOG se haya hecho fanboy de MAC va a empezar a hablar bien de esa plataforma estás en un craso, qué digo craso, crasísimo error. No sólo voy a hablar mal, sino que voy a hablar muy mal.

Hoy le toca a la obsolescencia programada. Todos sabéis lo que es. Eso en Apple no existe. Salvo contadas ocasiones en las que el producto ha salido una pifia (me vienen a las mientes ciertas versiones del iPod), los productos de Apple son muy duraderos, tienen una gran calidad y siempre funcionan como el primer día. Y cuando no es así y tu aparato no cumple con lo esperado, en general Apple suele solucionarte el problema incluso estando fuera de garantía y de Apple Care siempre y cuando los defectos sean evidentes (vamos, que no te presentes con un MacPro oxidado por el agua del mar y pretendas que te lo cambien por uno nuevo)…

¿Dónde está, pues, la obsolescencia programada de la plataforma Apple?

Pues veámoslo.

***

Lo primero que nos llama la atención es el hecho de que de vez en cuando, y a veces sin un motivo demasiado justificado, hacen borrón y cuenta nueva. Sí, ya sé, ayer decía que eso era una ventaja. Vale. Pero también es un inconveniente, y este caso sólo se jode al usuario, que tiene que comprarse un nuevo equipo porque el viejo se ha quedado obsoleto y ya no funcionan los nuevos programas.

No me refiero a que el equipo se quede viejo por avances de la técnica, me refiero a la obsolescencia programada: simplemente iOS 4.3 no está disponible para un iPod de segunda generación sin haber ninguna justificación…

Otro caso es el de iMovie, que no funciona en un iPad de primera generación cuando los usuarios han demostrado que sí lo hace y que simplemente a Apple no le sale de los cojones permitir la instalación ahí con la excusa del rendimiento.

Recuerdo una de las últimas betas de Xcode 4, justo antes de su versión final. Resulta que se equivocaron y sólo se instalaba en Lion (también en beta). Es decir, Snow Leopard no podía ejecutar Xcode 4 por algún tipo de esotérica limitación… Unas horas después sacaron una versión que sí podía hacerlo. ¿Cuál era, pues, el impedimento? Para mí estuvo claro: Apple quiere que te compres su Lion y abandones el Snow… porque, de nuevo, Lion no se ejecuta en equipos antiguos y así actualizas. Pero resulta que Lion sí que se ejecuta (y encima perfectamente) en esos ordenadores (como se ha demostrado )…

O en otras palabras: he decidido obsoletar ciertos equipos porque sí, porque yo lo valgo, y si quieres el Lion, o el iOS 4.3, o el iMovie, o lo que sea, pasa por caja y actualiza tu equipo. Obsolescencia programada a más no poder.

***

En relación a este tema hay otro que quiero creer es incidental y no hecho exprofeso. Tu iCosa funciona a las mil maravillas. Suave como la seda, cumple su función perfectamente dentro de los límites marcados. Si alguna aplicación da un poco por culo, seguro que pronto sacan una nueva versión con las mejoras pertinentes. Por si no lo sabías, las iCosas (y los MAC también), envían silenciosamente y sin decírselo a nadie a Apple información sobre fallos y otras zarandajas, pero claro, cuando lo hace Microsoft se pone el grito en el cielo, pero cuando lo hace Apple no.

¿Cómo puedes comprobarlo? Instala un firewall en condiciones y verás cuántos programas de las tripas de un MAC intentan conectarse con Apple. Prácticamente casi todos y prácticamente de forma continua desde que haces login.

Decía que tu iCosa funciona perfectamente. Pero se acerca una keynote de Apple. Y de repente el aparato empieza a hacer cosas raras . No me refiero a que deje de funcionar, o se cuelgue, no. Me refiero a que de repente los programas ya no van tan fluidos y hay como ciertos “enganches”. Yo me di cuenta con el iPad. Justo unos días antes de la presentación de su segunda versión, empezó con el baile. Y con él continua.

Claro, claro, eso no aparece como por arte de magia. Aparece cuando actualizas una nueva versión de iOS, o cuando lo conectas al iTunes y lo actualizas. Recuerdo que con mi iPod de segunda generación pasó lo mismo cuando salió la tercera…

Me gustaría pensar que no es intencionado, que simplemente las nuevas mejoras del sistema hacen que este vaya algo peor… aunque sean mejoras. También podría tratarse de fragmentación en el sistema de ficheros o en la memoria, pero si lo restauras y sigue haciéndolo entonces no se debe a eso.

En fin, que sin quedar demostrado del todo, para mi es una causa más. Imaginaos que tenéis la golica de la nueva versión, que encima te la presentan como la rehostia de mejor, más rápida, más guay del Paraguay y más c00l , y de repente tu iCosa ya no funciona como antes…

***

¿Por qué son tan cortos los cables USB de las iCosas? ¿Por qué se rompen tan fácilmente? ¿Por qué cada cierto tiempo mueven una pestañita unos milímetros para que las nuevas iCosas no encajen en los cables de las viejas iCosas (caso de los iPad 1 y 2)?

Lo primero se debe a que el cobre está caro… ¿o será a que si el cable es corto sufrirá más tirones y se romperá antes? De lo segundo ni hablemos: es evidente por sí mismo.

Con más morro que nada, cada cierto tiempo, si quieres las nuevas iCosas, tendrás que comprarte los nuevos complementos que sólo se diferencian de los anteriores en la pestañita que ya no engancha bien , al económico precio de 30 euros un cable que cuesta medio…

***

¿Os habéis preguntado por qué los auriculares de las iCosas son tan incómodos, con esa forma tan grande para unos oídos de tamaño medio? Yo sí. Porque en la tienda venden otros mucho más cómodos… y bastante más caros. Menos mal que el conector es más o menos estándar y siempre puedes usar unos comprados en cualquier sitio. Aquí no aplican el concepto de obsolescencia programada , sino el de te vendo algo que no puedes usar para que todavía te gastes más dinero, que viene a ser más o menos lo mismo.

***

Esto lo conozco por terceras partes, porque en mi caso no suelo usar muchas aplicaciones diferentes en mis iCosas. El hecho es que hay programas que no funcionan en según qué versiones de iOS, y justo al revés: si quieres tener tal o cual programa, tendrás que mantener una versión obsoleta, con los problemas de seguridad que eso supone. Aunque bueno, casi da igual, ya que los productos de Apple no es que lo sean mucho .

El mayor problema viene cuando has actualizado por error, o simplemente porque ignoras que tu querido programa es incompatible, y entonces la has jodido bien jodida porque no existe manera documentada para volver hacia atrás en tu iCosa excepto que tengas una copia de seguridad… que, para ser sincero, muy pocos tenemos si no es la que iTunes nos hace por defecto, y ya se encarga él de dejarnos sólo la última…

Bueno… estoooo… ¿existe alguna forma de mantener una copia de seguridad de tus iCosas aparte de la que hace el propio iTunes? De nuevo a pasar por el aro.

En el caso del OS X es algo diferente, y aquí sí, aquí sí que puedes volver hacia atrás cuando quieras… mientras a Apple le salga de las narices mantener otros programas marcados como compatibles con versiones antiguas del sistema operativo que, como ya hemos demostrado más arriba, nada tiene que ver con que funcionen o no…

***

NOTA: aquí tenéis otra entrada mía relacionada en cierta medida con ésta.

MAC Rationale vs Windows Rationale en el desarrollo

Rafael Ontivero — Sat, 19 Mar 2011 14:42:00 GMT

Todavía estoy leyendo temas generales sobre el desarrollo en MAC, de hecho aún no he pasado de los manuales que describen las tecnologías y los diferentes bloques en que se divide el desarrollo en MAC.

No obstante me ha surgido una curiosa reflexión que quiero compartir con vosotros. Todavía no estoy muy seguro de que sea completamente cierta, porque todavía no he profundizado en los conceptos MAC y lo que he leído tiene más que ver con la publicidad del desarrollo en esta plataforma que otra cosa, pero creo que tiene muchos visos de ser real como la vida misma.

Y lo más curioso de todo es que tiene mucho que ver con el desarrollo Windows, y más cercanamente al de las tecnologías .NET. Cuanto más leo sobre Cocoa, QuickTime (que no sólo es un programa sino una tecnología), etc., más me parece estar leyendo sobre .NET, o más bien sobre la forma en la que se publicita .NET.

Se habla de grandes grupos de tecnologías orientadas a objetos, con grandes rendimientos y grandes facilidades ofrecidas a los desarrolladores. Calcado uno de otro. Ahora habrá que ver la pura realidad.

Del lado .NET ya lo tengo claro: mucho ruido y pocas nueces, al menos para desarrollo de sistemas. Quiero creer que del lado MAC no será igual, pero cualquiera sabe. Ya os iré diciendo.

***

Pero no, no es sobre eso sobre lo que os quería hablar. Veamos por un lado la arquitectura lógica expresada por los manuales de MAC, que creo es más real que la dicha por los de Windows.

Debajo del todo un ordenador de Apple hay un Kernel BSD que no es otra cosa que una variante de UNIX igual que es Linux. Y luego hay un sistema POSIX de toda la vida que de nuevo tiene que ver con el mundo UNIX (que viene a ser como una serie de servicios que simplifican el acceso al núcleo del sistema igual que una consola de comandos en Windows permite trabajar con ficheros sin tener que tocarlo).

Aunque Apple lo ha llamado Darwin, no deja de ser lo que es, y de hecho Apple publica todo el código fuente de ello. Al ser un estándar debe estar separado. Realmente está separado.

Encima de eso hay una serie de capas, Cocoa, Carbon, QuickTime. Más o menos. Pero lo que es cierto es que esos subsistemas están completamente separados del núcleo o más bien encima de él.

En Windows creo que no es así. En su momento, en las versiones NT originales sí que lo era (o al menos así se publicitaba). Recordemos la capa HAL que podía ser para un montón de procesadores y luego el sistema NT Executive nativo, que corría sobre dicha capa. Pero ahora, después de la unificación con la plataforma 9x en lo que fue Windows XP dudo mucho que siga siéndolo.

Porque ahora no hay soporte para ARM, ni para SuperH, ni para PPC. Sólo Intel x86 y dando gracias. Me juego un gallifante a que ahora está todo mezclado y revuelto (y de ahí los problemas de Microsoft para volver a añadir soporte para ARM). Porque si no fuera así no se entendería cómo puede funcionar el sistema de vídeo sobre Win32 accediendo al driver que está en el núcleo (sí, ya sé, anillos, gateways y todo eso, pero no voy por ahí)…

Bueno, quizás en esto me equivoque, pero si alguien me explicara cómo el hecho de reproducir un vídeo dentro de un navegador pueda generar una BSOD estando los sistemas separados, que me lo diga. Porque me ha pasado. Y no una, sino varias veces. Putas ATI.

De todos modos luego veremos alguna razón más de ello y quizás uno de los puntos más fuertes de por qué Microsoft está un poco contra la espada y la pared.

***

Apple ya lo ha hecho al menos dos veces y lo va a hacer una más. En x64 no va a haber Carbon, que es como se le llama al subsistema que soporta programar en C y C++ de forma nativa. En x64 sólo vamos a tener Cocoa (Objetive-C y Objetive-C++) y POSIX (que yo sepa). En su momento, con el cambio de PPC a x86 repitió jugada, haciendo borrón y cuenta nueva y forzando a muchas empresas de software a reescribir sus programas. Como cosa curiosa os diré que Apple encargó a Adobe la creación de su iPhoto, iVideo y demás programas de esa plataforma y Adobe los mandó a freír espárragos porque estaban como locos rehaciendo sus propios programas. Creo que hubo otro cambio rompedor más en los MAC pero ahora no recuerdo qué.

Bueno, el meollo del asunto está en que a veces es conveniente hacer borrón y cuenta nueva. Hasta donde sé, el API de MAC OS X y el de iOS es un API moderno, orientado a objetos y bastante potente. Ya os diré si realmente es cierto cuando me enfangue las manos con ello.

***

Ahora volvamos a Windows. Aquellos que hayan leído sobre el tema, sabrán lo que son los subsistemas. Para los que no, una pequeña introducción.

Win32 es un subsistema. POSIX es un subsistema (o lo era hasta que lo quitaron). De hecho, en las primeras versiones de NT había hasta un subsistema OS/2.

Un subsistema es una API completa que sirve para que las aplicaciones escritas para tal subsistema se ejecuten en él, sean independientes del núcleo y no puedan afectarlo en ninguna manera. Ved la siguiente imagen de la Wikipedia y fijaros arriba a la derecha.

http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg

Básicamente esa debería ser la arquitectura de Windows. Fijaros también en lo que hemos hablado antes sobre el HAL y el Executive.

¿Realmente Windows es así? Creo que no. Teóricamente si cogéis un programa 100% compatible POSIX y lo ejecutáis en Windows 2000, debería funcionar. ¿Lo hace? Pues no. En su momento lo probé y no funcionaba. Tampoco lo hacía uno de OS/2 cuando ese subsistema estaba, todavía, presente. No es que no funcionaran bien o hicieran alguna cosa rara, es que la mayoría de veces simplemente no cargaban.

¿Ha visto alguno de vosotros un Windows NT ejecutado en un ARM o en un SuperH? Yo no y no creo que funcionen. ¿Vais viendo ya por dónde voy?

Con esto no quiero decir que nunca hayan llegado a funcionar, lo que quiero decir es que yo al menos no lo conseguí en su momento. En un MAC moderno podemos ejecutar prácticamente cualquier comando típico UNIX, desde un “ls” hasta un “ps” pasando por un “dd” o lo que queramos. Aparte de los que la propia Apple ha añadido, que hay unos cuantos.

De nuevo no me malinterpretéis, en ningún momento estoy diciendo que un MAC sea mejor que un Windows por eso. Simplemente estoy diciendo que en un MAC sí que están separadas y presentes las distintas piezas, o al menos así lo creo. De nuevo el tiempo me lo dirá, y yo a vosotros.

***

Y ahora entramos de lleno en .NET. ¿Por qué .NET no es un subsistema y sin embargo está construido sobre Win32, que no es precisamente un API limpia y ordenadita sino más bien todo lo contrario? ¿Por qué no aprovecha Microsoft la arquitectura de los subsistemas para hacer a .NET miembro de derecho propio dentro de Windows y no un mero envoltorio que cada vez se va pareciendo más a lo que envuelve, sobre todo en el tema de la guarrería?

Si ya .NET es algo grande en el aspecto del rendimiento y funcionalidad (comparado con su contrapartida Java y a veces con el propio Win32), ¿qué rendimiento no tendría si fuera un subsistema independiente?

¿O es que toda la estructura arquitectónica de Windows es una mentira como un castillo y no puede haber otros subsistemas cooperando sobre el ejecutivo?

Me gustaría que alguien me aclarara todo esto, porque sinceramente no lo entiendo. Yo tengo mi teoría, que no voy a exponer aquí no sea que se me acuse de lo que creo no soy, y menos ahora que tengo mi calentón de fanboy…

El driver que se pasó de listo

Rafael Ontivero — Sun, 23 Jan 2011 16:59:33 GMT

Siguiendo con el libro de Raymond Chen de la entrada anterior, no puedo contenerme de contaros esto, que me ha hecho soltar sonoras carcajadas cuando lo he leído.

Estamos en los tiempos de Windows 95 y las primeras versiones de DirectX, y una de las funciones internas entre DirectX y los drivers de bajo nivel de los fabricantes de tarjetas con este soporte, es una función que pasa un GUIID que indica una característica. Si la función devuelve TRUE, el driver la soporta. Chen no nos da el nombre real de la misma, pero una de las primeras acciones que se negocian entre ambas partes es determinar qué cosas soporta el driver del fabricante y cuáles no, por lo que la función se usa repetidas veces sobre el driver.

Pues bien, había un fabricante (no dice quién) que devolvía a todo que sí, pero que luego, al ejecutar las pruebas, petaba miserablemente.

Un análisis de bajo nivel del driver determinó que la función debía haber sido implementada por el departamento comercial, porque la función era nada más y nada menos que esto (escrito en pseudocódigo):

BOOL SoportasEstaCaracteristica(GUIID característica)
{
return TRUE;
}

Vamos, que dicho driver lo soportaba absolutamente todo.

Entonces un programador de DirectX cogió una tarjeta de red y miró su UIID, anotándolo. Luego la destrozó a martillazos y la tiró a la basura. De todos es conocido que dichos UIID han de ser únicos de forma global, así que dicho número no iba a ser utilizado nunca jamás.

A partir de entonces, una de las pruebas entre DirectX y los drivers de los fabricantes, es hacer la siguiente llamada:

if(SoportasEstaCaracteristica(UIID_que_no_existe)==TRUE)
{
//¡Te pillé!
}

Si alguien quiere leer la versión original, que difiere por completo en la forma de contar el tema pero no en el contenido en sí, está entre las páginas 322 y 323 del libro.

El RFOG se renueva por dentro y por fuera (y II)

Rafael Ontivero — Sat, 18 Dec 2010 10:10:29 GMT

Vamos a por una segunda parte no planeada, pero se me quedaron en el tintero algunas cosas y me han surgido otras nuevas, cosa que quiero hacer público por si le pasa a alguien más.

Si no te molan mis rollos patateros, el mensaje de la entrada es bien sencillo: Cuando uséis discos SSD, ponedlos en AHCI y usad Windows 7 o Server 2008R2.

Y ahora sí, ahora a contaros mi vida.

Bueno, pues una de las cosas en las que ha usado este largo puente, ha sido terminar de remodelarse el despacho en su casa que en su momento fue lugar de trabajo habitual y que está completamente seguro no va a volver a utilizar como tal en una larga temporada. Así que se lo ha montado a su gusto. Os pongo una foto:

Antes el lugar estaba lleno de estanterías metálicas con material del trabajo. Ahora están en el altillo, que es como el RFOG llama a una habitación que tiene justo al lado de su terraza. Allí tiene todos sus trastos y en su momento sirvió de almacén local para material de la empresa. Ahora hay más estanterías (las de abajo) y más cosas (también subidas de abajo).

La idea ha sido meter todo lo que tenía desparramado por la casa en una sola habitación. Es un decir, porque de cuatro habitaciones que tiene la casa (sin contar cuarto de baño ni cocina), el RFOG ocupa dos de ellas con sus cacharros. Su sala de estar (que ahora sí que parece tal), su dormitorio, su biblioteca liberada de cajas y de trastos que han sido subidos al altillo, y su despacho, que es la habitación que sale en la foto.

Al fondo a la derecha podéis ver un ordenador viejales (un AMD x2) que funciona de aquella manera y al cual accede por escritorio remoto, y encima su cablemodem y su Time Capsule que hace las veces de Router y de NAS para el MAC. Luego está la mesa del atril, enfrente de la ventana, que es el lugar para leer libracos que pesan mucho.

Más cerca está su nuevo ordenador (sí, se ve, la caja no es precisamente un primor), y sus dos monitores de 24”. Luego el iMAC, con su mesa y todo.

Entre medias se puede ver un Kindle 3, un iPad, su HP Touchsmart TM2 en su funda y la caja de uno de sus nuevos discos SSD (que ha usado para ver el modelo exacto y si soporta comandos TRIM, que lo hace). Al fondo a la izquierda se puede ver la estantería que ha dejado y una bicicleta estática… que apenas usa y debería hacerlo con mayor frecuencia.

Justo al principio de la parte derecha, donde está la bolsa de plástico, hay una mesa más que contiene algo de chatarra (discos duros, un EEPC del año la pera, y sus otros e-readers. En el rincón que no se ve, justo al lado del sillón que asoma a la izquierda, está la chimenea.

Y bueno, esa es la organización de la habitación del RFOG.

***

Al final no va a hackintoshear su PC, no. Porque se ha informado y ha visto que la cosa no es tan fácil como parece a simple vista. El primer problema es que necesita una BIOS parcheada para su placa base, y las versiones disponibles son bastante antiguas.

Pero luego no es todo tan fácil como se lo habían propuesto, no. Una vez instalado el Snow Leopard hay que liarse a meterle parches y drivers parcheados para que todo funcione bien, y aun así te garantizan unos cuantos kernels panic periódicos, así que al final lo ha dejado estar, y como tiene su iMAC…

***

Cuando el RFOG tenía las máquinas virtuales del trabajo en discos SATA II, las tenía en NTFS comprimidas. Sin que fuera una gran diferencia de rendimiento respecto a no tenerlas, sí que hacían su función. La idea es que, comprimidas, se minimiza el acceso a disco porque se tiene que escribir menos frente al tiempo de proceso de la compresión.

Cuando separó trabajo de vida personal, y tuvo su ordenador nuevo, instaló sus cuatro discos SSD formando dos RAID 0, uno para la partición de Windows y otro para las máquinas virtuales.

El rendimiento de lectura era de unos 300 MB/s, y el de escritura de unos 160 MB/s o así, ni de lejos los 500 y 300 respectivamente que deberían haber sido si se combinan las velocidades de los dos discos. Ya sabemos que el rendimiento no es el doble, pero en este caso tan sólo es algo superior al de uno solo.

No obstante el RFOG estaba bastante contento con su montaje. Y pasaron un par de días en el que continuó personalizando su ordenador, poniendo esto aquí y quitando esto de allá…

Y de repente el rendimiento se degradó de forma alarmante, sobre todo en la parte de las máquinas virtuales…

Para evitaros rollos varios sobre cómo encontré la solución y de los pasos que me llevaron a ello, comentaros que el tema tenía que ver con el comando TRIM de los discos SSD…

***

Debéis saber que los discos SSD no son más que un conjunto de memorias de tipo FLASH NAND (como las de las PDA, lectores de libros electrónicos, iPad y demás) con una controladora que simula ser un disco duro normal y corriente.

Lo que no se dice (y que conste que el RFOG lo sabía porque las ha tenido que usar en alguno de sus proyectos, pero fue incapaz de relacionar una cosa con la otra) es que esas memorias, una vez escritas, hay que borrarlas. Es decir, no se puede escribir sobre ellas como en un disco duro, sino que hay que realizar una operación de borrado antes, operación que suele ser bastante lenta comparada con la de escritura y sobre todo la de lectura.

En otras palabras, la controladora está diseñada para que vaya suministrando al ordenador, cada vez que se quiera escribir algo, sectores frescos y borrados. Hasta aquí bien, lo previsible. El problema viene cuando esos sectores libres se llenan y ya no quedan más.

No es que el disco se haya llenado, sino que se han usado todas las partes “vírgenes” por decirlo así. Cuando borras un fichero, la controladora de disco no borra la flash pertinente, sino que la marca como borrada y deja de usarla hasta que ya no quedan áreas libres y, cuando el sistema operativo necesita más espacio, procede a borrar las celdas ya usadas antes de darlas, y es cuando se produce la caída de rendimiento [1].

Hablando en propiedad, esto es una mierda oculta debajo de la alfombra de las SSD, que nadie airea y lo que es peor, nadie estandariza. De todos modos, existe un comando (supongo que será SCSI) que se llama TRIM. Si el sistema operativo, a la vez que borra el archivo, emite dicho comando para los sectores borrados, la controladora SSD añadirá dichos sectores a la lista de pendientes de borrar, y los borrará cuando tenga tiempo. De este modo el rendimiento no cae si tenemos tiempos muertos en el disco, ya que, en principio, todos los sectores libres estarán borrados a la hora de ser usados.

Windows 7 y su contraparte servidora son los únicos sistemas operativos que, a fecha de hoy, emiten dicho comando si tienen la configuración adecuada activa (que se pone sola si el sistema detecta este tipo de discos). Ni Linux ni Snow Leopard lo soportan, así que ojito con poner discos SSD con estos sistemas operativos, aunque existen soluciones alternativas y bastante chapuceras.

Pero hay otro problema, y es que el comando TRIM sólo funciona cuando los discos están en modo AHCI, y tampoco todas las controladoras los permiten. Generalmente las últimas versiones de todos los fabricantes lo hacen, incluyendo los ICH10R de Intel, pero es algo a comprobar.

En RAID no funcionan o más bien son ignorados por el hardware (citando a Tella, parece ser que el código RAID es antiguo, funciona al pelo y nadie se atreve a modificarlo no sea que la caguen), y también en xATA (léase ATA, SATA IDE, eSATA, etc).

Por lo tanto existe toda una serie de restricciones a la hora de tener discos SSD:

· Sólo en modo AHCI y con controladoras que soporten el comando TRIM

· Sólo discos SSD que soporten el comando TRIM (casi todos los de última generación a fecha de hoy).

· Sólo Windows 7 y Windows Server 2008R2.

· Si ponéis máquinas virtuales, que los discos estén sin comprimir.

Esta última recomendación creo que tiene que ver con el hecho de que la tasa de escritura es tan alta, que el tiempo que dura la compresión/descompresión sí que afecta al tiempo total de escritura/lectura.

No obstante, existen chapuzas para solventar este problema en aquellos discos o montajes que no lo soporten. Por ejemplo, Intel tiene una solución para sus discos y sus controladoras que consiste en tener un programa monitor en background que periódicamente revisa los discos y libera el espacio no trimmeado, y también existe algún que otro programa que se supone hace lo mismo. El mayor problema es que es un remiendo más que una solución.

En mi caso, la imagen de abajo os da una idea del rendimiento de mis discos bajo Windows 7 x64 en un disco recién formateado y 5 repeticiones de un archivo de 1GB:

Quizás estos enlaces te ayuden a comprobar tu sistema (lo siento, la mayoría están en inglés):

· http://www.ghacks.net/2010/09/14/verify-that-trim-is-enabled-in-windows-7/

· http://en.wikipedia.org/wiki/TRIM

· http://es.wikipedia.org/wiki/TRIM

· http://www.anandtech.com/show/2865

[1] Bueno, realmente ignoro si primero se emite un comando de borrar para luego ceder el espacio libre, porque dependerá del tipo de flash usado, o si se reescribe sin más, y tampoco es una cosa que me importe lo suficiente como para investigarla. Lo que es cierto es que las reescrituras de celdas ya usadas es más lenta que las de las vírgenes.