Turbo C, el entorno agradecido

De mediados de los 80, y casi durante 10 años, la mayoría de juegos comerciales se desarrollaban en todo o en parte usando Borland Turbo C.

En 1986, y coincidiendo con el lanzamiento de Turbo C 1.0, C representaba un lenguaje conocido, potente, y con fácil acceso al hardware del sistema, que lo hacía ideal para el desarrollo de software que requería aprovechar al máximo el hardware, y sus capacidades multimedia, como era el caso de los juegos.

Por esa época, y aunque todavía había desarrollos escritos totalmente en ensamblador, la creciente complejidad de los mismos comenzó a agradecer el uso de herramientas de más alto nivel. Por eso, Turbo C con su compilador/optimizador ofrecía un rendimiento mucho mayor al de otros dialectos populares también como Quick BASIC de Microsoft, o Turbo Pascal también de Borland. De modo que no es de extrañar que la mayoría de títulos de esos años, estuvieran compilados con el agradecido Turbo C.

Es cierto que sobre todo en el mundo empresarial, seguía reinando Microsoft C Compiler, y que probablemente generase un código algo más eficiente al de Turbo C, pero que carecía de otras importantes características que harían de Turbo C el elegido. Basta abrir 10 ejecutables de la época, para encontrarnos con la marca de Turbo C, Turbo C++ o Borland C++ en su interior.


Turbo C, el entorno agradecido

Tenía un entorno de desarrollo integrado, con un potente editor de código, un rudimentario gestor de proyectos, una utilísima ayuda integrada, un veloz compilador y enlazador, un depurador integrado y era más barato que la competencia. Más adelante, pudiéndose combinar con Turbo Assembler y Turbo Profiler, se podía reescribir en ensamblador las partes que demandasen más recursos.

A medida que pasaba el tiempo Turbo C iba mejorando, añadiendo soporte al lenguaje C++, y editor multiventana en 1990, o coloreado de sintaxis en 1991.

Sus competidores iban mejorando, y a la vez imitándolo, así que la propia Microsoft lanzaría Quick C, que basado en Microsoft C ofrecía un IDE similar al de Turbo C, pero todavía algo distante de éste.


Turbo C, el entorno agradecido

El paso a los 32 bits bajo DOS y el modo protegido, relegó a Turbo C a una segunda linea, por uno de esos fallos de estrategia que recurrentemente ha ido teniendo, abriendo así paso al que sería su sucesor en este ámbito: Watcom C.

En el mundo empresarial y de las utilidades, Turbo C/C++ y sobre todo Borland C/C++ seguían todavía con cierta ventaja gracias a las ventajas de Turbo Vision, que facilitaban la creación de entornos de texto basados en ventanas.

Poco a poco el énfasis en el desarrollo de Turbo C parece que se va aletargando, y Turbo Pascal avanza a buen ritmo, canibalizándolo en gran medida, pues comparativamente ya no hay tanta distancia entre ellos.

Con la llegada de Windows, y sorprendentemente, los herederos de Turbo C salían en primera linea de la parrilla, y es que el soporte de C++ era mucho más completo en Borland C++ que en Visual C++, el IDE seguía siendo más completo, y la librería de clases OWL, permitía crear aplicaciones Windows evitándonos la complejidad de la API de Windows, como luego harían las MFC.


Turbo C, el entorno agradecido

En 1997 con C++ Builder y los componentes visuales VCL heredados de Delphi, Borland vuelve a obtener una posición ventajosa, pero les dura poco, otra vez por la repetición de errores del pasado.

13 comentarios en “Turbo C, el entorno agradecido”

  1. Qué tiempos aquellos. Yo aprendí C con Turbo C 2.0, y seguí usando herramientas de Borland hasta el C++ Builder 4 que mantuve en producción hasta después de salir el C++ Builder 6, pero me cansé de tanto bug no resuelto, de tanta nueva versión que no era más que la anterior pero más pesada y con más problemas y pocas mejoras reales…

    Y ahora, Embarcadero con su C++ Builder XE2 (y el XE3 a puertas) no hace más que ir a la cola, con un compilador más que obsoleto, una mulitplataforma que no termina de cuajar (debido a la masiva cantidad de bugs que tiene FireMonkey, a que en un MAC no se ve como aplicación nativa y a las limitaciones del producto que por ejemplo no tiene soporte de impresión)…

  2. Javier Gutiérrez Chamorro (Guti)

    Me alegra que te gustase RFOG. Y no te pierdas un post que estoy preparando de cómo aprendí C, que se parece bastante a tu caso, pues empecé a dominarlo con Turbo C 1.5, a pesar de que ya había salido el 2.0, pero no pude conseguirlo en su momento.

    Estoy plenamente de acuerdo con tu opinión sobre C++ Builder, una herramienta realmente innovadora cuando salió la versión 1, pero que sigue arrastrando las obsolescencia del compilador basado en Borland C++ 5.

    Esperemos que con XE3, y el soporte x64, lo hayan actualizado de verdad, y ya sólo quedará la VCL escrita en Delphi, y los problemas con FireMonkey, que entiendo son normales (aunque no deseables) debido a lo reciente que es.

  3. jejeje, turbo c, le tengo especial cariño pues en el aprendí a programar, de hecho aún tengo por ahí (creo) la versión de la universidad, aunque desconozco si funcione en windows 7. Me encantaba que traía las librerías graphics.h y funcionaba sin problemas, de hecho sin necesidad de salir del entorno, algo que no pasaba con borland c++, tenía que pasar al explorador y ejecutar el programa, porque de lo contrario daba error, supongo que mal configurado pero nunca encontré como arreglarlo 😀
    Ahora uso open watcom y funciona perfectamente, saludos.

  4. Yo también empecé con el TC 1.0 en mi flamante Amstrad PC1640. Luego pasé al BC++ 3.1 y aún lo usamos en el curro de vez en cuando porque tenemos unas aplicaciones hechas en DOS para sistemas industriales, y un programa para Win desarrollado con BC++ 5.01 y las OWL que como un día nos de un disgusto en un Win nuevo, lo vamos a flipar. De momento, el invento funciona incluso en un Win7-x64, que no te creas que las tenía yo todas conmigo cuando fui a instalarlo.

    Cuando el BC++ 3.1 era novedad, M$ tenía el MSC 8.0 y, si la memoria no me falla, el 8.1 que veía con el primer Visual C++ 1.0. Comparados frente a frente, el compilador de M$ era una castaña que daba vergüenza ajena. De hecho, siempre me pareció que las MFC eran puro cascajo comparadas con las OWL debido al pobre compilador de C++ que tenía M$. Era un festival de macros de lo más marrano que podía encontrarse. Desde el VC++ 5.0 no he vuelto a saber nada de los compiladores de M$, así que no sé cuanto habrán mejorado, pero nunca fueron excesivamente buenos en eso.

    Y no es que el BC++ estuviera libre de bugs. En general, había que tener mucho cuidado con los programas en modo LARGE y mejor no meterse con los HUGE. La aritmética de punteros siempre patinaba en esos modelos de memoria… 😀

  5. Que tal Jose Luis, yo también usé Visual C en su momento, de hecho fué el primer entorno windows que usé para programar, pero lo que no me gustó fué que los archivos del proyecto eran enormes. En aquel entonces no tenía pc propia, de manera que usabamos las del laboratorio de cómputo de la universidad y pues no siempre nos tocaban las mismas con el riesgo adicional de que nos borraran las cosas que dejabamos, así que teniamos que recurrir al uso de disquettes y winzip para poder llevar todo ese proyecto en varios discos. El problema es que se dañaban con facilidad y perdía muchos trabajos.
    Cuando conocí visual basic pues me encantó porque todo el proyecto cabía sin problemas en un disquette, así que eso fue muy bueno para mi, de manera que ahí me quedé y hasta el día de hoy sigo programando en vb.net (pasé por vb 5 y 6 además). Ultimamente he reducido el uso de c++ a pequeñas cosas, pero es muy bueno, saludos.

  6. Javier Gutiérrez Chamorro (Guti)

    Es cierto, las cabeceras precompiladas de Visual C++ hacían que el proyecto pesase muchísimo. Recuerdo que tenía un script de 4DOS que hacía limpieza de todo eso.

  7. Juas!, ahora que lo habéis mencionado me he acordado de una cosa que sufrí y encima me reñían (por currar). En el 94 entré a trabajar para una empresa informática que tenía la red (ethernet a 10 Mpbs con hubs) dividida en dos segmentos, y para cada segmento un servidor de Novell Netware donde lo almacenaban todo.

    A los curritos, nos daban un disquete de 3 1/2 que nos servía de arranque del DOS, cargaba todo el tema de la red IPX/SPX y permitía entrar en el servidor donde estaba instalado todo. El ordenador *NO TENIA HD*, atentos al dato, así que todo iba por red.

    Ya arrancar el Win 3.11 era lo más parecido a un retiro espiritual. Lo de arrancar el VC++ 1.0 era de nota. Pero lo mejor……. lo mejor era compilar!!!!. Literalmente, mandabas a paseo al servidor y a la red local. Era fantavilloso, hasta que llegaba el jerifaltrillo de turno (un matemático con muy malas pulgas y muy poco interés por la informática) y me preguntaba con cajas destempladas que qué hacía que estaba hundiendo la empresa. Compilar, maese analista, compilar….. 😀

  8. Javier Gutiérrez Chamorro (Guti)

    Recuerdo algo parecido en la universidad, el disquette oficial con DOS y el cliente de Novell, que todos acabábamos tuneando. Lo que cabía en un disco de 3 1/2 con 2M y Stacker!

  9. Es curioso como muchos estudios de juegos usaban el Microsoft C junto con MASM, los de borlsnd en juegos mainstream no se veía tanto, ya luego con los extenders fue otra cosa. Pero c para dos es una delicia .

  10. Javier Gutiérrez Chamorro (Guti)

    Tienes mucha razón Alfa MSX. Y yo creo que hay dos motivos. El primero es que MSC apareció mucho antes en el mercado, ya sabes que inicialmente se basaba en Lattice C, así que era una solución más madura y además más conocida por los programadores profesionales. La segunda, y esa nunca se corrigió, es que el compilador de Microsoft siempre fue mucho más competitivo a la hora de generar código optimizado que el de Borland, y claro, en un juego donde el rendimiento es clave ello importaba.

    Por cierto, bienvenido a este espacio.

Deja un comentario