jueves, febrero 15, 2007

¿ Porqué tengo que cambiar de Clipper a (x)Harbour ?

Como cada año por estas fechas, estoy comenzando a preparar la "Operación España 2007", que como muchos de ustedes saben, son un par de semanitas en las que voy a impartir cursillos a San Sebastián, a convivir con los colegas y posteriormente a visitar a los amigos tan entrañables que he hecho a lo largo de ya 9 años de ir por allí, puntual a la cita que da inicio el 15 de Mayo.

Comencé mis incursiones por España impartiendo cursos de FiveWin y eso me llevo a conocer a un montón de alumnos que ahora son estupendos amigos, y que tengo que decirlo con mucho orgullo, me han superado como alumnos y ahora puedo decir que además de amigos y alumnos son mis "maestros", no voy a mencionar nombres, porque seguro me voy a dejar a alguno sin mencionar y francamente paso de pecar por omisión, 9 años dan para muchas y muy duraderas amistades.

El año pasado incluimos como novedad los cursos de Xailer, y también continuamos por la via de FiveWin, ahora con el FiveWin Pocket PC, pero este año hemos detectado nuevas necesidades en el mundo de los programadores Clipper, por esa razón hemos cambiado un poco lo que hacemos año con año, sobre programación visual para Clipper / (x)Harbour y hemos pensado que sería una buena idea ofrecer a los programadores de Clipper, comenzar por el principio, con el programador que aún tiene aplicaciones de Clipper 16 bits (que aunque no lo crean son bastantes) y que quieren dar el paso a xHarbour 32 bits, para posteriormente moverse a una interfaz gráfica, llámese Xailer, FiveWin, Visual xHarbour, MiniGui, etc.

Durante el último año, y dado el contacto que tenemos día con día con muchos programadores de distintas partes del mundo, hemos detectado y aislado 4 puntos básicos que a todos los programadores de Clipper les interesan, en este comentario analizaré el primero y los demás en comentarios posteriores por separado para no aburrir al personal.

Las necesidades que detectamos se pueden clasificar en el siguiente orden.

  1. Migrar de Clipper 16 bits a (x)Harbour 32 bits. (sin Windows)
  2. Una vez en 32 bits, migrar de modo consola a Windows o si ya estas en Windows 16 bits, moverte a Windows 32 bits.
  3. Publicación de datos DBFs en internet, usando para visualizarlas un navegador web (Explorer, FireFox, Opera, etc)
  4. Una vez hecho lo anterior (32 bits en modo consola o Windows y/o internet), acceder a otros formatos de datos (SQL), usando los conocimientos que se tienen de Clipper/(x)Harbour.

Todo lo anterior es posbile y muchas otras cosas mas, sin necesidad de abandonar el lenguaje Clipper que tan bien conoces, porque el mundo de los 32 bits con (x)Harbour da para mucho mas, todo es cuestión de saber que es lo que quieres hacer y hasta donde quieres llegar, pero lo mas importante: COMO LLEGAR AHI.

Como comenté en un post anterior, muchos usuarios aun utilizan Clipper en todo el mundo, basta con darse una vuelta por los foros de UseNet comp.lang.clipper, por los mismos foros de (x)Harbour o leer la bitácora diaria de nuestro servidor web para ver el enorme número de descargas que tenemos todos los días de la versión de evaluación de FiveWin, pero volvemos a lo mismo, aunque existe un FiveWin Harbour de 32 bits, la mayoría de la gente que descarga el demo de FiveWin lo pretende utilizar con Clipper de 16 bits.

A 16 bits, Clipper pierde mucho, nunca pensé que yo iba a hablar mal de Clipper algún día, pero todo avanza, nuestro Clipper como tal se ha quedado estancado desde hace 10 años, y aunque ha evolucionado en productos como (x)Harbour, Clip ó xBase++, aun seguimos amarrados a la vieja forma de programar, así que vamos a hablar de las desventajas de las aplicaciones MS-DOS puras y duras con Clipper, no de las de Windows (hechas con FiveWin o Clip4Win, que también las tienen, pero son menos).

Para empezar, los programas de 16 bits son LENTOS, si si, aunque le queramos vender al usuario la moto de que los programas MS-DOS son mas rápidos para operar que los programas en Windows, ese ya no es un pretexto válido para no cambiarlos, a mí han venido muchos programadores de Clipper que me dicen "a mis clientes les gustan mis programas MS-DOS porque son rápidos" ó "les gustan mis programas porque no tienen que usar el mouse y todo se hace con teclas, por lo tanto acceden mas rápido y mas fácil a las distintas opciones del programa", bueno, les voy a romper el mito.

Existe un grave problema documentado con los programas en Clipper corriendo en procesadores rápidos como AMD o Intel superiores a 3 GHZ, sucede que los programas Clipper son tan lentos y el procesador tan rápido, que el programa pierde "ciclos de reloj" del procesador, razón por la cual, pierde acceso a áreas de memoria, y por coinsiguiente tarde o temprano, causará un error "inexplicable" de Division by '0', para solucionar este problema hay que linkear al EXE el famoso _wait.obj, que es un módulo que le baja la velocidad al procesador, para que el programa Clipper pueda correr, ¿ el precio a pagar ?, una degradación general en todo el performance del equipo mientras el programa Clipper está en ejecución, una vez que el programa Clipper termina de ejecutarse, volvemos a recuperar la velocidad total del procesador.

También del lado del hardware tenemos problemas... ¿ cuantos fabricantes conoces que todavía construyan impresoras de matriz de puntos ?, muy pocos ciertamente, y ahora.... ¿ cuantos modelos de esas impresoras conoces que tengan puertos paralelos ? ¡ ninguna !, las impresoras de matriz de puntos "nuevas" van por puerto USB porque claro, ahora todas las impresoras, láser, inyección de tinta etc. son USB y por otro lado, en algunos modelos de computadoras el puerto paralelo simplemente ya no existe ¿ que hacen los programadores Clipper ?, malabarismos y "magia" capturando puertos de impresoras remotas, mapeándolos como LPT1, etc, un sin fin de "apaños" para que el programa Clipper pueda utilizar impresoras de matriz USB, las impresoras Láser y de inyección de tinta son otra historia, ya no soportan las famosas "secuencias de escape" que se utilizaban para configurar los tipos de letra, tamaños de papel y otras características de impresión, ahora hay que utilizar el "driver" de la impresora, pero los programas Clipper, no pueden hacerlo.

Por otro lado tenemos que el manejo de memoria es ineficiente, hay que hacer cambios en las "variables de entorno" como los famosos "files", "buffers" y "set clipper" para que el programa pueda correr; en Windows 2000, NT o XP no hay Config.sys, ni autoexec.bat, así que hay que recurrir a otros medios para que los programas se ejecuten sin problema como toquetear el CONFIG.NT y el AUTOEXEC.NT, o en XP, modificar las propiedades de My Computer.

Hablando de Windows 2000, NT y XP, si eres un poco curioso, cuando corras un programa en Clipper, llama al "Administrador de Tareas" de Windows (Alt+Ctrl+Del) selecciona la ventana "Procesos" y observa... veras que el programa EXE de Clipper va a compañado de 2 programitas adicionales, uno llamado WOWEXEC y otro llamado NTDVM, estos programas son necesarios para correr programas en MS-DOS, ya que el sistema operativo como tal no existe en los sistemas operativos "TRUE 32 BITS" como son los Windows NT, 2000, XP, 2003 y ahora el nuevo Vista, el MS-DOS en estos sistemas operativos es simulado, el WOWEXEC es el Windows On Windows EXECutor, es un emulador que hace correr un sistema operativo Windows 95 dentro del sistema operativo que estés usando, pero dicho programa requiere ademas del NTDVM = NT DOS Virtual Machine, que como su nombre lo indica, es una máquina virtual MS-DOS para Windows NT y que no es mas que OTRO emulador, pero ahora del sistema operativo MS-DOS, así que un programa en Clipper de 16 bits, requiere de 2 emuladores para poder ejecutarse, con la consecuente sobrecarga del procesador.

¿ Y que me dices del EXE final ?, si lo generas para "modo real", con el RTLINK, un EXE de Clipper no puede ser mayor a 64 Kbytes porque al ser de 16 bits, el EXE de Clipper se carga sobre los primeros 64 Kbytes (Nótese: he dicho 64 KBtyes, NO MEGABytes), al mas puro estilo MS-DOS 6.22, si el EXE te sale mas grande de 64 Kbytes, entonces se recurre al truco de usar OVLs para que se pueda cargar en memoria todo el programa, a menos, claro, que utilices Blinker o Exospace y compiles para "modo protegido", pero aun eso te limita, los EXEs no pueden ser mas grandes de 4 Megas, que es la mayor cantidad de memoria que un programa MS-DOS puede direccionar, así que no importa que tengas 1GByte de memoria Ram en tu computadora, los programas en Clipper MS-DOS no pueden usar mas de 4 megas, ¿ hay programas EXE que midan mas de 4 Megas ?????..... ¡ por su puesto que los hay !, mira cuanto miden el Winword.exe (12 megas) y el Excel.exe (10 megas) , por ejemplo.

Otros impedimentos que se tienen son a nivel operativo, como por ejemplo en la apertura de archivos DBFs con sus índices sean NTX o CDX que está limitado por la memoria asignada por Windows para ellos y por la configuración de "files" y "buffers" que hayas establecido al arrancar el sistema operativo, aunque los manuales dicen que se pueden abrir hasta 256 "áreas de trabajo", todos sabemos que eso no es cierto y por eso hay que abrir y cerrar archivos cada vez que se entra a algún módulo del programa, lo que genera tráfico en la red, también el tamaño del DBF esta limitado, no puede ser mayor de 4GBytes (aunque vamos a ser serios.... ¿ quien tiene un DBF de 4 Gigas ?, yo tengo alguno de 1.5 Gbytes, pero nada mas).

Hablemos un poco sobre las capacidades de Clipper, los arrays están limitados a 4096 elementos y las cadenas de caracteres a 64 kbytes, lo que quiere decir que si por ejemplo queremos meter en un array todos los elementos de una tabla DBF, pues solo cabrán los primeros 4096 y si queremos leer un archivo de texto, por ejemplo con un MEMOREAD() que mida mas de 64 kbytes, pues simple y sencillamente no podemos, Clipper no da para tanto.

La pregunta hasta este punto puede ser ¿ me compensa cambiarme a (x)Harbour aunque mi aplicación sea MS-DOS?, ¡ por su puesto que si !, muchos programadores Clipper no hacen el cambio porque están esperando a construir la versión "Windows" del programa, algunos con FiveWin o con Xailer y otros definitivamente se han mudado de lenguaje a Visual Basic o Delphi, sin embargo mientras la aplicación Windows queda terminada, tienen que seguir manteniendo la vieja aplicación MS-DOS, con sus limitaciones, cuando en realidad, pueden tomar su código Clipper actual, y con pocos o ningún cambio estar funcionando a 32 bits en muy poco tiempo (usualmente una semana o menos).

(x)Harbour tiene enormes ventajas, para empezar es OpenSource, es decir, tienes acceso a todo el código fuente del compilador y no tienes que pagar nada por el uso del mismo, aun para generar aplicaciones comerciales, otra ventaja importante es que es Multiplataforma, hay (x)Harbour para Windows, para Linux, para OS/2, para MacOS X así que tu programa, con el mismo código fuente, puede correr en distintos sistemas operativos.

El principal problema del uso de (x)Harbour para el programador que viene de Clipper MS-DOS es que (x)Harbour, a diferencia de Clipper, no sigue la estructura .PRG -> .OBJ -> .EXE. Con (x)Harbour la secuencia que se sigue es: .PRG -> .C -> .OBJ -> .EXE y aquí es donde el programador de Clipper se confunde, porque (x)Harbour no genera un OBJ a partir de un PRG, genera un archivo en "C", a partir de este o estos archivos en "C", hay que generar el EXE, lo cual queda en manos de un compilador de "C", como el Microsoft Visual C, El Borland C++, el MingW32, o el Pelles C, el desconocimiento del uso del compilador de "C" es lo que hace que muchos programadores de Clipper abandonen la migración del programa a 32 bits, cuando en realidad no necesitas saber ABSOLUTAMENTE NADA DE "C", porque hay herramientas visuales como el AJ-Make, el xMate, el VeRCE, el xHarbour Builder o el HbMake de xHarbour, que te ahorran tener que saber como utilizar un compilador de "C".

El cambio de Clipper MS-DOS a xHarbour en modo consola, no tiene porqué ser traumático, por eso, para los cursos de este año, pensamos que lo primero que tendría que aprender un programador de Clipper es a compilar con (x)Harbour y por eso el curso con el que abriremos será precisamente un curso de migracion de 16 a 32 bits de aplicaciones Clipper, y una vez que hayas dado el salto a 32 bits lo cual te permitirá continuar trabajando con tus mismos programas, tus mismos archivos y tus mismas metodologías, pero con mas desahogo porque te habrás librado de las limitaciones de Clipper, lo cual te dará mas libertad y podrás elegir entre la GUI que mas te guste (FiveWin Xailer, Visual xHarbour, MiniGUI) para dar el siguiente paso hacia Windows.

Posteriormente a pasar a 32 bits, puedes optar por varios caminos, mi ruta ideal sería primero la parte de OLE (via Programación Orientada a Objetos), lo cual te abre las puertas al mundo de los componentes COM, de los controles OCX y a un montón de herramientas que puedes usar para mejorar tus programas como por ejemplo integrar tu programa en modo consola con Office, es decir, que exporte datos y pueda leer hojas de Excel, a Word, que pueda mandar un correo por OutLook, etc. estas mismas herramientas continuarán funcionando cuando hagas el paso a una interfaz gráfica Windows.

De la mano de OLE viene ADO (ActiveX Data Objects) que es la tecnología "de moda" hoy en día para acceder a bases de datos SQL desde casi todos los lenguajes de programación "modernos", tecnología que es perfectamente soportada por (x)Harbour, aun en modo de consola, con lo cual, tus programas Clipper/(x)Harbour podrán acceder a datos en bases de datos relaciones SQL, utilizando un método similar a como lo haces actualmente con Clipper, pero basado en objetos.

En el próximo comentario hablaré un poco de la parte de porqué es necesaria la migración de modo consola a Windows y de Windows 16 bits a Windows 32 bits.

9 comentarios:

Walter Negro dijo...

Rene: Se nota que hace tiempo que no tienes que lidiar con los 16bits y disfrutas como yo de los 32bits, seguramente por eso hay algunos errores que paso a comentar.

El EXE en 16bits no debe ser necesariamente menor a 64kb, pero en modo real debe entrar tanto el EXE como los datos dentro de los primeros 640kb, a los cuales hay que restarle parte del SO y drivers.
De todas formas aún en modo real se podía hacer uso de hasta 4Mb de memoria expandida, aunque sólo era usada para datos.
El EXE debía ser particionado en OVL para que entre dentro de los 640kb y cargue el programa en memoria por módulos más pequeños cuando el ejecutable era muy grande.
Usando blinker o exospace se podía hacer uso de hasta 16Mb de memoria extendida que podían ser compartidas por datos y programa, aunque igualmente los programas grandes tenían como mayor problemática el tamaño de la tabla de símbolos y ciertas partes del programa que debían residir en memoria baja y los malabares para tener cada uno de los parámetros ajustados al límite necesario de funcionamiento.

Ahh que delícia no tener que preocuparse de esas cosas, 5 años disfrutando de usar xHarbour.

Anónimo dijo...

Hola, me parece super interesante tu articulo, me he despejado algunas dudas pues uso una aplicacion clipper con interfase delphi, algo asi es el rollo. La acplicacion en windows xp presenta un problema de memoria virtual demasiado baja, agradeceria me indiques como hacer que no aparezca dicho mensaje y que la pc no se vuelva tan lenta despues de eso. Gracias.

Fernando B dijo...

Rene : me intersó mucho to comentario respecto de porque pasar de clipper a X(harbour).
Cómo puedo acceder al algun curso o ayuda para realizar ésta transformación que cada dia me preocupa mas.
Desde ya , muchas gracias
Fernando
Bs As
Argentina

NEOPARIS7 dijo...

yo saun soy un novato con esta programacion y en mi empresa tenemos un programa diseñado en clipper y me gustaria migrar a 32 bits como harbour... he estado estudiando e investigando como hacerlo pues como bien dices hay muchas limitaciones y en procesadores como amd superior a 3 principalmente como bien dices disminuye mucho la velocidad y al salir del la aplicacion se recupera... otro incoveniente k tengo que necesito hacer impresiones desde los otros equipos a la impresora matricial y solo puedo imprimir con versiones de win98 pero con XP no... y muchos mas inconvenientes... ojala puedira aprender mejor a usar harbour y al leer tu post creo que es la mejor opcion para migrar.... espero me puedas ayudar u orientarme... gracias...

Anónimo dijo...

Interesante artículo. Bien enfocado en las etapas de migración.

Me queda la duda de saber si con Harbour podré hacer que la pantalla en modo texto dentro de una dox-box sea de 120col x 50lin (por ejemplo) pues con clipper-16 solo consigo 80x50.

Alguien lo sabe?

Adrian dijo...

Realmente estoy mas que interesado en aprender a utilizar xharbour, pero estoy en Argentina y no encuentro mucha informacion aca. Me podrian decir por donde empiezo?
Gracias! Adrian.

Anónimo dijo...

hola si me puedieran enviar informacion a cerca de cursos del (x)Harbour .. de verdad que me gustaria probar el compratamiento de este programa con respecto a clipper ....y como bajar o descargar este programa..

Mario Alberto dijo...

Rene, esta entrada de blog aunque ya tiene algo de tiempo es justo lo que necesito, yo yome el curso de fivewin hace un tiempo contigo y me ha sido muy util, ahora quisiera saber como puedo compilar mis priogramas hechos en clipper 5.2 y que corran a 32 bits, aparentemente no necesito hacer modificaciones a mi codigo, pero que crees? No he logrado hacer que funcione ninguno, me sigue mandano errores al ejecutarlos, estoy usando el AJMake com xharbour y borland bcc55, pero no logro hacerlos funcionar, otra cosa es que los programas deben ser compatibles con DOS ya que se estarán ejecutando en un sitema operativo compatible con DOS (TSX-32). Por favor orientame o dime donde debo acudir para obtener la ayuda que necesito. Muchas gracias.

Anónimo dijo...

Yo he probado el Xharbour (.com) que es pagado en su versión free y funciona excelente, trae las tools3.
Pero la versión Xhabour (.org) que es codigo abierto, no la he probado pues NO TRAE LAS TOOLS3, que son rutinas que ocupo mucho en los sistemas.