conio.h

La biblioteca de C CONIO (CONsole Input Output), conocida popularmente como conio.h por su archivo de cabecera, es sin duda uno de los recuerdos más intensos de desarrolladores de C durante los años 80 y 90.

Pese a no formar parte del estándar ANSI, ni POSIX, conio se ha llegado a portar a diferentes plataformas: DOS, OS/2, Win32, Win64, etc. Está disponible también en diferentes compiladores, incluso en sus versiones más recientes, como Visual C++, Digital Mars C++, Embarcadero C++ Builder, DJGPP C++ o OpenWatcom C++.

Aunque se implementó inicialmente por Lifeboat Associates como parte de Lattice C 1.0 (1982), no fue hasta que Borland lanzara Turbo C 1.0 (1987) que conio.h cobraría gran popularidad.

Lo que hicieron en realidad, fue adoptar la filosofía de la unidad CRT de Turbo Pascal, al nuevo Turbo C. Así, mientras la conio de Lattice, básicamente usaba las rutinas de E/S de DOS, conio y CRT, las implementaban accediendo directamente al hardware, u opcionalmente usando la BIOS. ¿Os suena la variable directvideo?

Era increíble la cantidad de primitivas que ofrecía, que en otros entornos, lo habitual era tenerlas que comprar a parte a terceros: manejo de ventanas lógicas, scrolls, manipulación de buffers, … Por desgracia, a alguien que estaba acostumbrado al rendimiento de pantalla de Turbo Basic, y más aún con las mejoras en ensamblador de TBWINDOW, el rendimiento de crt y sobre todo conio, distaba mucho de ser el ideal.



De manera que los chicos de la legendaria De Trans Software se pusieron manos a la obra con DIRIO Library como acrónimo de DIRect Input Output, un remplazo de conio para Turbo/Borland C++ pensado en la prestación pura. No en vano, algunas comparativas la demostraban como 5 veces más rápida que la librería de serie.





La virtud de DIRIO, era que estaba implementada íntegramente en C. A pesar de estar bastante optimizada, los accesos a memoria seguían siendo en general de 8 bits, y los scrolls no estaban acelerados, pues usaban las funciones de la BIOS, por lo que no me cabe duda que ese aumento de rendimiento de 5x sobre conio, podría haber sido fácilmente de 10x. Una prueba más, de que el énfasis de conio no estaba en el rendimiento.

Posteriormente llegaría CONXLIB (CONIO eXtended LIBrary), que inicialmente usando conio como base, agregaba funciones de ventanas, ratón, controles de texto (campos de texto, radios, checkboxes, …). La idea era una vez fuera estable, migrarla a DIRIO, y formar parte del que iba a ser nuestro desarrollo estrella WIPE 4.0.

Por esas cosas que ocurren con bastante frecuencia, ni DIRIO 3, ni WIPE 4 llegaron a ver la luz.

11 comentarios en “conio.h”

  1. Desde luego Manuel, salvo Borland con su C++ Builder que seguía manteniendo una implementación completa, el resto de compiladores Win32, desde Visual C++, hasta Watcom C++ o GNU C++, tienen una implementación parcial, debiéndose recurrir a bibliotecas de terceros para hacerlo funcionar.

    Una lástima que las aplicaciones de consola en Win32, estén tan abandonadas, no hay más que ver OS/X o Linux para ver en realidad la increíble potencia que ofrece.

  2. pues si, practicamente tuve que tirar todos mis programas que habia hecho en c/c++ durante la universidad, aun tengo algunos que de vez en cuando ejecuto bajo dosbox para recordarlos 🙁

  3. Back to the 80’s!! Lo malo es que nos cuesta abandonar estas cosas. Es más, se siguen enseñando en las universidades.

    Por un lado es una forma rápida para hacer «cosas chulas» en la terminal, sin necesidad de aprender demasiadas cosas más. Es sencilla y hace lo justo.

    Aunque en Windows dejó de funcionar cuando dejaron de soportar los códigos ANSI en la terminal, hay muchos ports que lo consiguen con llamadas a la API de Windows, que por cierto es más complicado.

    Si por ejemplo, usas Linux, aunque tienes bibliotecas como ncurses, todo puede complicarse un poco más. Entre otros ports para Linux podemos encontrar este: http://totaki.com/poesiabinaria/2009/05/colores-y-posicionamiento-en-terminales-linux-como-conioh-en-dos/
    que sólo necesita que incluyas un .h en la cabecera, porque se usa muy muy parecido.

  4. Tienes razón Gaspar Fernández, ncurses es mucho más potente y flexible, aunque es un desarrollo bastante más reciente que conio. Mientras que conio.h data de 1982 como digo en el artículo, ncurses es de 1993, es decir, 11 años después, que en software es una eternidad.

  5. dejé de programar en c++ hace años porque es demasiado laborioso y no estaba llegando a ningún lado, lo ultimo que use fue open watcom (funciona tanto en windows xp como en windows 7) y dentro de las cosas agradables de este entorno es que se pueden crear aún programas para 16 bits, supongo que podemos hacer programas al estilo viejito y así revivirlos jejeje (claro, no hay soporte para conio.h ni graphics.h pero con sus respectivas alternativas revivir el pasado 😛 )

  6. Es cierto que programar en C o C++ es más laborioso que en otros lenguajes de más alto nivel como Java o C#. Sin embargo, sus ventajas en cuanto a rendimiento son indudables, y ahí si que resulta más sencillo que hacerlo en ensamblador.

    Watcom y OpenWatcom no soportan graphics.h, ya que son propietarias de Borland, pero si tienen en su defecto graph.h; que son equivalentes, y algo más rápidas.

    En cuanto a conio, así es la la implementación es bastante limitada, igual que en otros compiladores que no son de Borland.

    A mi Watcom me encanta, precisamente por revivir el pasado, con aplicaciones para DOS de bajo nivel, y que sigo usando de tanto en tanto, como por ejemplo en ZEROFILL.

Deja un comentario