C++Builder XE/Delphi XE Starter edition (como los Express de Visual Studio, pero pagando poco)

Actualización 31/01/2011: Definitivamente es una realidad. Hoy acaba de ser anunciado oficialmente, con los precios indicados (al menos en USA), y para Europa, como siempre, la traducción 1 dólar 1 euro, es decir, 199 euros para la versión completa y 149 para la actualización. En un primer vistazo, la versión Starter es la Professional pero sin el soporte para UML, refactorización y competado de código, así como de alguna que otra cosilla más…

Hacía ya varios años que BorlandCodegearEmbarcadero no sacaba nada express como ya lo hicieron con sus Turbo Explorer hace bastante tiempo. De hecho esas ediciones ya no se pueden conseguir, ni funcionan las activaciones aunque tenglas la clave…

Pues bien, se comenta por los mentideros de la red que van a aparecer una versiones Starter de los productos citados. Parecer ser que a alguien se le escapó sin querer la semana pasada, y la noticia ha sido comentada hasta el punto de que Embarcadero ha reconocido que está en ello.

http://delphi-insider.blogspot.com/2011/01/delphi-starter-official-announcement.html

http://blog.marcocantu.com/blog/delphi_started_edition.html

http://www.sdtimes.com/link/35223

El mayor problema es que esas ediciones van a ser de pago. Se habla de unos 199 dólares o 149 euros, aunque permiten desarrollar hasta en cinco máquinas simultaneamente y para fines comerciales hasta que los beneficios producidos por ellas no sobrepasen los 1000$ anuales (o al menos eso es lo que creo haber entendido de las noticias en inglés).

No es mala idea ofrecer esos productos a ese precio, aunque si fueran gratis sería todavía mejor ya que tienen que competir con las versiones Express de Visual Studio, que son gratis total para cualquier uso. No quiero hablar de la estupidez que me parece eso de los 1000 dólares, como tampoco del hecho de que Delphi no puede competir con Visual C# Express por la sencilla razón del precio. En el caso de C++ Builder sí que podría existir una sana competencia con su equivalente de Microsoft, más que nada porque, aunque el compilador de C++/CLI es superior, Windows Forms orientadas a C++ son un poco mierdosas, sin hablar de que C++ no vale para WPF (y poco les habría costado implementar clases parciales en C++/CLI)… C++ Builder es mucho más rápido y con mucha más funcionalidad que Visual C++, ya sea con MFC o con C++/CLI y Windows Forms (recordemos que los sueños de Microsoft de dejar atrás C++ han fracasado completamente).

Desde un punto de vista general sí que es una buena jugada, ya que la próxima versión de Delphi/C++Builder se supone será lo suficientemente multiplataforma como para poder desarrollar para Mac y para Linux… o al menos es lo que se pretende. De hecho, toda la documentación y el código fuente que he podido ver así lo indica: en muchos lugares hay compilación condicional para las tres plataformas y en otros la documentación indica que eso no está disponible para Linux o para MAC…

Por lo tanto, una ampliación de usuarios les vendría muy bien para luego vender las nuevas versiones, porque debemos recordar que, al menos C++Builder en sus versiones 2009, 2010 y XE son casi el mismo producto con la diferencia de que cada versión soluciona los bugs de la anterior (y genera nuevos) y trae complementos de terceros. Y es que la goma no se puede estirar más. La VCL está completa, pocas cosas genéricas se les puede añadir, los IDE tampoco dan más de sí, y a lo sumo a C++Builder se le podrían añadir lo que le falta para ser compatible con C++0x…

C++ Builder XE, en su fecha de salida y pese a haber corregido varios miles de bugs de la versión 2010, era un puñadito de caca que casi no podía compilar nada. No obstante unos meses después sacaron el primer parche y el producto se convirtió en lo que debía haber sido en un principio. Esta versión mejora también el sistema de búsqueda (*), y parece ser que hay una nueva actualización de la misma que todavía arregla más cosas. Yo lo estoy usando un poco y ciertamente es bastante más estable que las versiones anteriores.

De todos modos imaginaros el siguiente escenario dentro de uno o años a partir de estas fechas. Un futuro C++ Builder XE 3 Starter gratuito o de coste mínimo, capaz de compilar sólo para Windows y Win32. Y un C++ Builder XE 3 Professional y superior capaz de compilar para Win32, Win64, MAC x64, Linux x64… Esos son los planes de Embarcadero, pero como no se espabilen les van a comer la merienda. QT viene pegando fuerte, muy fuerte.

(*) Lo que demuestra que la tecnología dentro del Document Explorer de Microsoft no es el problema. El problema es la poca preocupación de la integración del sistema de ayuda con los IDE…

El driver que se pasó de listo

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.

GetWindowText() en ropa interior

Justo he empezado a leer The old new thing de Raymond Chen, que es un libro entresacado a partir de las entradas más interesantes del blog del autor. Y me está gustando tanto que lo estoy leyendo como si fuera una novela de aventuras, sección tras sección. En él hay un curioso capítulo que trata de las interioridades de la función de Win32 GetWindowText() que no he podido reprimirme en parafrasearlo aquí.

Para aquel que no lo sepa, dicha función devuelve en uno de sus parámetros el título de la ventana o el texto contenido en un control, dependiendo sobre qué tipo de ventana se ejecute.

Lo curioso es ver cómo funciona. Si la llamamos sobre una ventana de nuestro propio proceso, la función genera el mensaje WM_GETTEXT para que seamos nosotros mismos los que devolvamos el texto que queramos. Evidentemente si no capturamos el mensaje, será Windows quien devuelva el valor por defecto, que será el mismo que si se realiza la llamada a una ventana de otro proceso. En este caso, la función devolverá la cadena que Windows ha almacenado interiormente y que contendrá lo dicho.

Curioso, ¿no? De hecho en el libro de Raymod viene un ejemplo para hacer que una ventana devuelva un texto diferente según se llame desde el mismo proceso o fuera de él.

¿Por qué funciona esto así?

Según Chen es muy sencillo, y viene de la herencia de Windows 1.0 y versiones posteriores en las que la multitarea era cooperativa.

Imaginemos que vamos a mostrar la lista de programas en ejecución. Para ello, el programa enumerará todas las ventanas principales de Windows y les pedirá su nombre a través de GetWindowText(). Ahora supongamos que uno de esos procesos está colgado por algún motivo. Si la función genera un WM_GETTEXT sobre dicho proceso tonto, Windows al completo se quedaría bloqueado porque al no procesar el mensaje, la función nunca retornaría y un supuesto programa “matador” de procesos que no responden también se colgaría…

Por lo tanto, los diseñadores de Windows decidieron que una llamada a GetWindowText() debería comportarse tal y como se ha descrito más arriba. Es decir, si un proceso usa la función sobre sí mismo, es indicativo de que el bucle de mensajes está funcionando bien y por tanto podrá responder a un WM_GETTEXT. Pero si se hace desde otro proceso, nadie garantiza que el bucle de mensajes del llamado esté funcionando bien, por lo que entonces Windows toma el valor almacenado internamente, que generalmente es el nombre de la clase de ventana o el título de la misma.

De este modo, al menos desde Windows 95, un proceso tonto no tumba al sistema cuando intentemos matarlo desde el Administrador de Tareas o desde cualquier otro programa enumerador.