.NET o no .NET, esa es la cuestión : chapuzas, lenguajes, C++ Builder

Cómo desinstalar completamente tu C++ Builder 2009/2010

Rafael Ontivero — Sat, 10 Oct 2009 09:50:00 GMT

[Actualización 12/10/2009]
Para más INRI con este tema, ayer descubro que el desinstalador ni siquiera es capaz de borrar las entradas del menú incio, así que ya sabéis, es muy posible que sigan estando enlazadas a ningún lado. Por otro lado, si habéis instalado Rave Reports, también hay que desinstalarlo a mano (es decir, desde Programs and Features) y luego borrar las correspondientes entradas del menú inicio.

Texto Original:
Siguiendo con el tema del día de ayer, y uno, que es más cabezón que mi hermano, que tropezó y se cayó escaleras abajo en casa de mis padres y partió tres escalones de granito antes de que la masa no inercial de su azotea lo hiciera quedar a media altura con las patas parriba, se volvió a instalar la versión 2009 tras haber borrado la 2010.

Haciéndole un poco de justicia a Embarcadero, hay que reconocer que la 2009 funciona algo mejor, pero sólo algo. Como botón de muestra, con dicha versión es imposible depurar en ningún sistema x64 si no se aplica un parche binario a una DLL del IDE, cosa que ha sido solucionada no gracias a CodeGear/Embarcadero, sino a un chavalín que puebla los mundos de Internet: Oalf.

Y los propietarios del producto, en lugar de incorporar el parche a alguna de las actualizaciones, simplemente te dan el enlace al blog si berreas mucho en los foros públicos. Bien para Olaf, mal para Embarcadero, muy mal.

Bueno, pues como iba diciendo, anoche instalé la versión 2009, que tuve que actualizar al último parche para que funcionara en mi Windows 7 x64... con prácticamente el mismo resultado que la 2010. Si bien algunas cosas funcionaron algo mejor, como el hecho de que ahora sí, ahora parte de la personalización realizada a través del TActionManager se grababa y se recuperaba bien, pero ojo, sólo parte.

Otras cosas que siguieron sin funcionarme fue todo el tema del Docking, y ahí dejé de probar. No descarto que esto último sea desconocimiento propio, pero visto lo visto, más vale IDE viejo y conocido que nuevo y peor por conocer. Además, ¿ha visto alguien alguna aplicación hecha con C++ Builder que use algún sistema de Docking? Yo no, aunque quizás debería extenderlo, o mejor dicho, reducirlo a la pregunta de si ha visto alguien alguna aplicación hecha en C++ Builder.

Yo pensaba que con la entrada de Embarcadero como propietario de las herramientas se iban a poner las pilas, pero no ha sido así, y la primera versión enteramente sacada bajo las alas de esta empresa quizás haya sido todavía peor que la infame versión 6. Ya sabemos que hay una crisis global galopante, y que hay que amortizar los dineros gastados en comprar CodeGear, pero sinceramente, ha sido peor el remedio que la enfermedad, eso de sacar una versión a medio terminar y que hace más agua que un colador quizás pueda ser la puntilla con la que se termine de matar al producto...

Aparte de sentirme muy, pero que muy defraudado, me da mucha lástima que algo con la potencialidad que tiene Delphi/C++Builder esté siendo miserablemente matado por su propio creador. Si creyera en eso del destino y de la fatalidad, diría que C++ Builder es un producto con gafe, pero por desgracia el gafe lo crean los mismos propietarios de la herramienta.

Con tristeza y lágrimas en los ojos te digo adiós para siempre, C++ Builder...

***

Bueno, vamos a lo que vamos. Voy a explicar cómo borrar completamente C++ Builder, o lo más completamente que se pueda hacer. Partimos de una KB de Embarcadero, esta, que reúne los pasos necesarios, pero antes una puntualización: Si sabe qué hay que borrar, ¿Por qué cojones el desinstalador no lo borra?. Sí, ya sé que lo que queda por borrar son cosas porisaca, pero quizás el desinstalador debería preguntar si quieres un borrado completo o no. Otros lo hacen.

Yo voy a explicarlo para Windows 7 x64, pero vale igual para Windows Vista x64. Y si os preguntáis por qué lo explico si ya está contado en la KB, veréis que el proceso es algo diferente y que hay cosas que no están donde dicen que están, etc.

Desinstala el producto "Rad Studio" desde "Programs and Features".
Desinstala la ayuda desde el mismo sitio (esta, por ejemplo, no viene en la KB).
Si tienes ganas, reinicia, pero no es obligatorio.
Borra las carpetas que cuelguen de "C:\Program files (x86)" que tengan el nombre de Embarcadero o CodeGear.
Borra las carpetas que cuelguen de "C:\Program Files (x86)\Common Files" con el nombre de BDE.
Vete a "C:\Program Data" y borra todas las carpetas que empiecen con un UIID o con un número y que estén ocultas y comprimidas. Ojo con este paso, es el más peligroso de todos si tienes algún otro producto instalado con la misma mierda de instalador que instala el C++ Builder. La KB da una clave del registro en donde están especificadas las claves, que en la versión de 64 bits está en HKEY_LOCAL_MACHINE \Software\Wow6432Node\MimarSinan\InstallAware\Ident.Cache\, pero en mi caso la clave está vacía. También puedes borrarla si no tienes más productos de este instalador.
Borra del registro las claves con el nombre de CodeGear, Embarcadero y Borland que estén situadas en las ramas:
1. HKEY_LOCAL_MACHINE\SOFTWARE
2. HKEY_CURRENT_USER\SOFTWARE
3. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
4. HKEY_CURRENT_USER\SOFTWARE\Wow6432Node
5. La KB da otras claves que no existen, al menos en mi ordenador.
Borra la carpeta "Rad Studio" de "C:\Users\Public\Documents", y de paso también de "Mis Documentos".
Vete a tu profile, C:\Users\<usuario>\AppData, y poda en Roaming las carpetas Embarcadero y CodeGear. Aquí es donde, entre otras cosas, se almacena la licencia del producto, que creo no vale entre instalaciones.
Vete a C:\Windows y usa el buscador para borrar una buena espuerta de ficheros. C++Builder 2009 tiene la versión 12 en los nombres de los ficheros, C++ Builder 2010, 14 (como todo buen estúpido, no quiere poner 13, pero da igual, la versión 2010 es la 13, como así lo es la del Office 2010, por mucho 14 que pongan). En las versiones de 32 bits estos ficheros suelen estar en C:\Windows\System32, y en las de 64, en C:\Windows\SysWoW64.
1. Borra cualquier cosa con extensión BPL, que son las DLL del C++ Builder, que ellos llaman "packages".
2. Borra "*120.jdbg" y "*140.jdbg", aunque podría valer sólo con la extensión.
3. "*120.xml" y "*140.xml"
4. "bdeadmin.*"
5. "cc32*.dll", que son los runtimes del C++ Builder.
6. "midas.*"
7. "xerces*.dll"

Hala, y eso es todo. El paso 6 resulta cuando menos curioso. En esas carpetas se guarda una copia de los instaladores y ficheros de instalación que vienen en el DVD del producto, y ante cada nuevo parche que instalemos, tendremos una nueva copia de los ficheros, de modo que con cuatro parches como tiene el C++ Builder 2009, será un giga y pico por instalación, es decir, sobre 5 GB de datos que no sirven para nada... Yo no sé quién será el lumbreras al que se le ha ocurrido tamaña barbaridad, pero se merece un premio; y me temo que no es el único producto que hace algo así, si no me equivoco, Office 2003 también usa una aproximación similar. En fin, que el espacio en disco duro está barato y la inteligencia cara, ya que si al menos sirviera para que los parches se pudieran desinstalar... Pero no, pese a toda esa morralla, la única forma de desinstalar un parche es reinstalar el producto...

Borland C++ 2010: No es oro todo lo que reluce

Rafael Ontivero — Fri, 09 Oct 2009 11:49:33 GMT

El que siga habitualmente este blog habrá visto varias entusiásticas entradas sobre el producto C++ Builder 2010, que fue durante varios años mi herramienta de desarrollo preferida (lo que también sabréis si me leéis), llegando hasta el punto de ser un furioso borlander al más puro estilo del fundamentalista linuxero. Luego, cansado de ella, la abandoné.

Y como es habitual cuando transcurre el tiempo, las cosas se van difuminando y perdiendo nitidez. Recuerdo que el abandono se produjo por la enorme cantidad de bugs que el producto tenía (sobre todo con ActiveX y COM), así como porque, año tras año, el producto era prácticamente el mismo pero con más problemas.

Pero el tiempo pasa, uno crece y llega a pensar que no sería para tanto, que quizás la culpa de muchos de los problemas se debieran al Layer 8 y no al producto en sí, máxime cuando no tengo acceso al código fuente de entonces y no sabría discriminar...

Así que uno le echa un tiento al C++Builder 2009, pero no tiene tiempo ni ganas de entrar en profundidad, pese a haber encontrado varios problemas que fueron resueltos por la gente de Embarcadero incluyendo un parche binario a una DLL... Y entonces llega la siguiente versión, la 2010 con unas maravillosas mejoras, como la vuelta a la compilación en segundo plano (algo que creo que se perdió en el paso de la versión 6 a la siguiente), la colocación de los componentes en la barra de tareas (que también se perdió en versiones posteriores a la 6) y el acceso a las entretelas del IDE. Otros detalles sí que son novedades, como el soporte multitáctil o la mejora en los visualizadores del depurador...

***

Ahora debemos cambiar de tercio. Todos sabemos que a fecha de hoy no existe ningún producto decente para el uso de las news, ya sea de pago o gratuito. El Opera tiene sus cosas raras, cuando se le va la pinza la arma bien gorda, el Windows Live Mail es una mierda pinchada en un palo. El Thunderbird quizás sea el que mejor vaya de todos, pero adolece también de varios problemas que no han sido solucionados desde la época en que venía integrado en el navegador Mozilla. Forté Agent no está mal, pero es toda una odisea configurarlo y la interfaz se ha quedado bastante obsoleta y, aparte de ser de pago, al menos los problemas que tiene son siempre los mismos y no presenta comportamientos aleatorios. El MesNews tampoco está mal, pero en mi caso me da infinitos problemas de conexión...

(Por favor, absteneros de comentarios sobre "a mí me va bien" y similares. Te lo puedo garantizar: efectivamente, "a ti te va bien", pero eso no quiere decir que mañana te la líe parda, y si no, tiempo al tiempo.)

Añadamos que en MAC no existe ningún cliente que se precie, todos son prácticamente basura. Por lo tanto llevo bastante tiempo con la idea de hacer un producto conforme a mi gusto, y sé que hay gente que lo está esperando con beneplácito. Así que hace como cosa de un mes me lié la manta a la cabeza y me puse en serio con lo que será el zxNewton... y entonces comenzó una etapa de mucho trabajo que hizo que apenas pudiera dedicar tiempo al programa ya que prácticamente todo mi tiempo libre se iba en trabajar.

No obstante algo hice, como bien sabe la gente de las News de Lechado...

***

... Y entonces volví a descubrir por qué había abandonado C++ Builder, porque fue con este producto con el que me decidí a hacerlo, ya que es muy posible que futuras versiones (no my lejanas) funcionen también en MAC y Linux. Podía haber elegido QT, pero parece ser que en MAC da muchos problemas, así que me decidí a hacer dos códigos fuentes: C++Builder para Windows y aprender a programar en MAC nativo en Objetive C y luego duplicar el código.

¿Por qué C++Builder y no MFC? Pues porque el primero es como .NET pero en C++ [casi] de verdad. Y porque la VCL ha evolucionado hacia algo bastante potente...

Por ejemplo, la VCL tiene un componente que se llama TActionManager que en conjunción con otros permite una personalización completa del programa. Puedes mover barras de herramientas, cambiar de sitio botones, añadir/quitar elementos, todo ello ya hecho con soltar tres o cuatro componentes en la ficha y ser un poco cuidadoso a la hora de codificar.

Otro aspecto que me mola es que soporta herencia visual, puedes heredar una ventana de otra sin muchos aspavientos ni complicaciones, y encima es prácticamente imposible romper la sincronía entre el editor visual y el de código.

Más: no usa el registro si no quieres, puedes guardarlo todo en ficheros en el lugar que quieras. La jerarquía de objetos es muy limpia y coherente, y todos los componentes son guardables a disco sin muchos aspavientos.

Pero eso es la teoría. Os cuento mis problemas. En Windows Vista x64 el editor de código no funciona muy bien, no formatea el código de forma automática, a veces se hace la picha un lío con los cierres de los paréntesis. En Windows 7 x64 el comportamiento del editor es algo más estable, pero tiene sus cosas.

El equivalente del IntelliSense muchas veces no funciona igual que en Visual C++, y cuando lo hace es lento de cojones, y no existe la posibilidad de usar el Visual Assist X o similar.

La ayuda es una mierda. Ni la online ni la local tienen apenas contenidos, con muchos problemas de enlaces que te llevan a la parte de Delphi o que contienen elementos mezclados de los dos lenguajes. Se nota que está compuesta desde el código fuente apenas comentado...

Si eso fuera poco, el IDE es incapaz de enlazar con el elemento adecuado. Si bien a esto ya nos tiene acostumbrados la MSDN y el Visual Studio, en C++ Builder es todavía peor, mucho peor (y yo que pensaba que no podía serlo).

Hay opciones del IDE que no funcionan, es decir, elijas la opción que elijas, el IDE va a la suya, y cuando vuelves a mirar está la que no has elegido.

En depuración el IDE peta sistemáticamente. Bueno, no peta, se queda autista y tienes que matarlo. No es que pase mucho, pero pasa una vez cada hora o así. Cuando pones un punto de interrupción y vas a continuar, siempre te pregunta si quieres seguir porque detecta que el código fuente ha sido modificado sin haberlo sido.

***

Eso en cuanto a elementos genéricos del entorno. En elementos específicos que he usado en el programa, tenemos más problemas, en este caso dentro de la VCL. Para que os hagáis una idea: tengo un form padre que es la que guarda el estado de la ventana, tamaño y demás. De ahí heredan las demás ventanas. En la principal hay un TActionManager que controla toda la UI, los dockings y la personalización. La parte principal es un TPageControl anclado a la ventana marco que permite pestañas. Cada pestaña es un control heredado de TFrame y que es el que realmente tiene todo el comportamiento de la aplicación.

Los marcos son como ventanas pero sin ventana, de forma que puedo anclarlos donde quiera ya que deben ser hijos de una. Es decir, si el usuario quiere que un marco (por ejemplo el del correo) esté flotando como una ventana independiente, yo creo la ventana y saco el marco de donde esté anclado y lo pongo como hijo de la misma. De esta forma no hay destrucción ni creación de nada, sólo movimiento de componentes.

Pues bien, todo esto, que está documentado y no es nada fuera de lo ordinario, presenta los siguientes problemas (quizás alguno se debe a desconocimiento personal, y si es así y la gente de Embarcadero me responde, así lo corregiré):

Las ventanas no responden a las órdenes de Docking, ya sea automático o manual. Es decir, sacas un elemento de un lugar para acoplarlo a otro y lo más que ocurre es que se quede flotando si te deja desacoplarlo. Esto es así para al menos el Frame, los elementos en el interior del mismo y la Toolbar del programa. En el caso del Frame ni siquiera deja sacarlos, y lo único que puedes hacer con la Toolbar es dejarla flotante y ya no la puedes volver a anclar a ningún lado.

El TActionManager, pese a volcarse y cargarse de disco (veo el fichero y su interior), no recupera la UI modificada, ni siquiera los botones cambiados con el asistente. Lo guardas modificado y lo cargas con los valores por defecto.

Hay componentes que al ponerlos dentro de un Frame en tiempo de ejecución generan una excepción y petan la aplicación.

***

¿Os parece poco? Pues sólo llevo con el C++Builder unas 10 horas. Imaginaros cuando lleve varios meses. Y eso que ya le ha salido un parche, que he aplicado pero que apenas ha arreglado nada.

Me da pena, mucha pena, pero la cruda realidad es que el producto continua siendo tan malo como cuando lo abandoné en su versión 4... Bueno, tan malo no, peor, ya que por lo menos en aquellos años el IDE no fallaba ni petaba ni hacía cosas raras... En fin, que como no se pongan las pilas... Yo creo que voy a abandonar... y empezar de nuevo con QT, MFC u otra solución que se me ocurra...