Por qué debería migrar de xHarbour a Harbour ?

[Antonio Linares]

Me gustaría que compartamos en esta conversación las razones que hayamos encontrado para migrar desde xHarbour a Harbour:

1. Los índices CDX se corrompen a veces. Tal como Michel Driessen comentó aqui:

viewtopic.php?p=160601#p160601

Una vez que migró a Harbour, esos errores desaparecieron

2. No existe un xHarbour 64 bits (salvo que yo esté equivocado) por lo que si un cliente te solicita una versión de 64 bits de tu aplicación no podrás construirla.

3. Por lo que sé, nadie ha sido capaz aún de construir una aplicación xHarbour + FWH desde el IDE de Visual Studio. No digo que sea imposible, pero aún no lo he visto. Con Harbour puedes construir desde el IDE de Visual Studio ó simplemente seguir construyendo tu aplicación desde un fichero batch/makefile de la forma habitual (incluso usando Visual Studio). Sin cambios practicamente, puedes construir tu aplicación en 32 bits ó en 64 bits desde VS (si dispones de FWH 64 bits).

3. Desconozco los porcentages oficiales, pero la base de usuarios de Harbour ha crecido mucho mucho, por lo que Harbour ha recibido y sigue recibiendo mucho feedback y eso ha hecho que mejore muchisimo y sea cada vez más robusto. Tanto la lista de desarrollo de Harbour como la lista de usuarios son muy activas y esto es una señal clara y muy saludable de su evolución.

4. Además de las razones mencionadas, cuantos más usuarios haya de Harbour más se beneficia Harbour y en consecuencia más se beneficia esta comunidad de usuarios. Proporcionar soporte técnico de dos productos es realmente un trabajo duro, especialmente porque muchos usuarios de xHarbour compraron la versión comercial (posiblemente porque les daba seguridad el que una empresa lo soportase) pero la realidad es que el compilador de C usado por xhb.com no es ni Borland ni Microsoft, sino una versión modificada de PellesC (por lo visto ahora estan tambien soportando MinGW). Esto ha traido una serie de problemas en el pasado que han requerido soporte técnico especial (Tim Stone os puede comentar acerca de esto, puesto que él ha vivido todo el proceso y finalmente ha migrado a Harbour). Tim, tus comentarios al respecto son bienvenidos.

Os invito a que compartais aqui vuestros resultados de la migración desde xHarbour a Harbour para que asi otros usuarios tengn una clara idea de las ventajas (y posibles desventajas) que existan.

[Patricio Avalos Aguirre]

Hola a todos

claro que me costo pasarme a harbour pero al cambiarme encontre varios errores que xharbour no reportaba por ejemplo

al declarar las datas de las clase

DATA nBar AS NUMERIC
..
blabla...

y al colocar esto por error

oVar:nBar := space(10) en xharbour no da error pero habour si ... que deberia ser lo correcto..

bueno cuesta un poco pero contento hasta ahora por el cambio

[El Loco]

Antonio, fundamentalmente yo pase definitivamente a Harbour por la posibilidad de 64bits, o sea que comparto plenamente los puntos 2 y 3 tuyos.
No así el punto 1, ya que en su momento xHarbour además de ser muchísimo más rápido que Harbour (pero muchisimo más rápido), nunca tuve ningún inconveniente de corrupción de indices, y mira que mantengo una aplicación donde tengo una de las bases con 46 millones de registro.
Hoy las cosas en cuanto a velocidad y desempeño están totalmente equiparadas.
Si bien aún mantengo algunas aplicaciones en xHarbour (solo por que no hay gana$$$ para modificar ), todas las aplicaciones y/o utilitarios están en Harbour, y la verdad que no me arrepiento de ello.
Si bien antiguamente xHarbour tenía algunas funciones que Harbour no (principalmente lo referente al zipeado de archivos), hoy para mí Harbour es la mejor opción.

Ahora, lo que realmente critico tanto a Harbour, xHarbour e incluso a FiveWin es, o la poca información o la total falta de información. Ojo que no pido un manual, pero por lo menos alguna lista de funciones que contenga la funciones que soporta, que argumentos de entrada, que devuelve,... etc.
Si bien en este foro uno se entera a veces de que existe esta o aquella función, o esta data o este método, creo que si se contara con una información al día de lo que es capaz cada uno, se podría probar más y mejor cada uno de ellos. Y ojo que me peine toda la red en busca de ello. Lo único valido hasta el momento, es mantener un control de las novedades y/o modificaciones contenidas en "Whatsnew.txt"

Bueno volviendo al tema principal, como consejo a partir de mi experiencia, aquel que tenga alguna duda, le recomiendo ampliamente Harbour, sobretodo porque, hoy por hoy, nos abre el maravilloso y rapidísimo mundo de los 64bits.

Un gran abrazo a todos.
Miguel

[Antonio Linares]

Miguel,

gracias por compartir tu experiencia con ambos

[El Loco]

Querida gente, quiero aclarar mi comentario anterior, debido a correos y llamados telefónicos de varios colegas.
Yo NO estoy diciendo que un lenguaje sea mejor que otro, de hecho me parece que los dos son EXCELENTES.... solo que hoy el que me brinda más posibilidades de trabajo, o más alternativas si se quiere, es Harbour.
Y tampoco quiero que se entienda que solo voy a trabajar con Habour, porque si veo las mismas alternativas en xHarbour estaría gustoso de probarlas.

Disculpen, pero tenia que aclarar.... antes de que anochezca...

Abrazos a todos.
Miguel

[Antonio Linares]

Miguel,

En cuanto a la documentación de Harbour, Giovanni Di Maria ha ido recopilando y publicando toda la documentación online. Yo tomé una de sus versiones y la alojé aqui:

http://www.fivetechsoft.com/harbour-docs/harbour-reference-guide.htm

Para FiveWin implementamos un wiki con la idea de que entre todos lo fuésemos organizando y completando, porque es realmente dificil mantener la documentación a la par que el desarrollo del software (fijaros en vuestras propias aplicaciones, las teneis completamente documentadas ? El wiki de FiveTech está aqui:

http://wiki.fivetechsoft.com/doku.php

Algunos usuarios han ido colaborando, nosotros hemos ido incluyendo todo lo posible, pero realmente si el código fuente esta bien organizado, suele ser la mejor documentación. A mi nunca me han gustado los "manuales de instrucciones" (siempre intento no usarlos) porque pienso que si un aparato, etc. está bien diseñado, y es realmente intuitivo, no requiere de instrucciones (como ejemplo, los ordenadores Apple). Y el código de FiveWin es muy fácil de entender

[El Loco]

Ok Antonio, ya conocía esos dos lugares.
Prestare mayor atención al contenido.

Un gran abrazo.
Miguel

[FranciscoA]

Hola, Antonio.
Acabo de migrar mi segundo programa (Contabilidad) a HARBOUR sin ningun problema.
El tiempo que que me llevó fue buscar y modificar, entre los 46 .prgs:
dbpack(),dbzap(),Curdrive() a: __dbpack(),__dbzap(),hb_Curdrive() y "muerto el pollo". Y... todo perfecto.

Siempre he utilizado los objetos necesarios, y codigo nativo de FWH. (tal vez por eso no tuve ningun problema). Ahora... a probar intensamente.
Saludos.

[Antonio Linares]

Francisco,

Muy bien

[postinelli]

Al intentar pasar de xHarbour a Harbour sin tocar nada me da los siguientes errores


Error: Unresolved external '_hb_itemPutDTD' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_hb_itemGetDTD' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_hb_itemPutDTL' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_hb_itemGetDTL' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_HB_FUN_HB_SENDMAIL' referenced from C:\PROGRAMACION\ASOLAFIRMA\PRESTAMOSADS1101_6DIG\OBJ\INDEXA.OBJ
Error: Unresolved external '_HB_FUN_TURL' referenced from C:\PROGRAMACION\ASOLAFIRMA\PRESTAMOSADS1101_6DIG\OBJ\CREDITOS.OBJ
Error: Unresolved external '_HB_FUN_TIPCLIENTFTP' referenced from C:\PROGRAMACION\ASOLAFIRMA\PRESTAMOSADS1101_6DIG\OBJ\CREDITOS.OBJ
Error: Unresolved external '_HB_FUN_HB_GT_GUI_DEFAULT' referenced from C:\FWH1312\LIB\FIVEH.LIB|ERRSYSW
Tiempo de compilación: 16.88s Tiempo de enlazado: 1.03s Tiempo total: 17.92s

[postinelli]

agregue HBTIP.LIB y GTGUI y desaparecieron algunos errores

solo me quedan

Error: Unresolved external '_hb_itemPutDTD' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_hb_itemGetDTD' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_hb_itemPutDTL' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1
Error: Unresolved external '_hb_itemGetDTL' referenced from C:\HARBOUR2014\LIB\RDDADS.LIB|ads1

[Antonio Linares]

Tienes que usar una versión de RDDADS.LIB construida para Harbour.

Seguro que algún usuario en estos foros que use ADS podrá proporcionártela.

[postinelli]

gracias por el dato

descargada la libreria rddads.lib desde aquí

https://code.google.com/p/harbour-and-x ... loads/list

ya compiló perfectamente

resumiendo, sin ningún cambio en mi código logré migrar de xHarbour a Harbour 3.2.0

la aplicación se ejecuta bien, por ahora ningún problema detectado
aún no he notado diferencias
luego reporto mayores apreciaciones cuando la aplicación esté instalada en varias maquinas y reciba comentarios de los usuarios

[Antonio Linares]

Te agradezco si compartes como ha sido tu experiencia en la migración, para que los demás usuarios se den cuenta de que ya están tardando en migrar a Harbour

Asi se fortalece la comunidad en Harbour, y eso es lo que cuenta. Que seamos una comunidad fuerte, con un gran compilador en donde todos nos ayudemos a todos Harbour empezó poco a poco, sin prisas. xHarbour quiso correr y adelantarse, pero Harbour ya ha superado con creces a xHarbour, y es el mejor compilador de xbase que haya existido nunca (desde nuestro fantástico Clipper .

El nombre "FiveWin" se acuñó de Clipper 5 ("five"). Primero apareció FivePro y luego eso llevaría a FiveWin y de FiveWin a Harbour. Y toda esa magia ha sido gracias a todos y a cada uno de vosotros

gracias!

[Antonio Linares]

Y por supuesto gracias a ese grupo de gente que se reunieron en una oficina junto al mar para crear Clipper (de ahí que a su máquina virtual se le llamase "plankton" )

Curiosamente el dueño de Nantucket no era informático, sino que se dedicaba al mercado inmobiliario, pero conoció dBase y se dió cuenta de la oportunidad de negocio de hacer una herramienta asi.

Es historia, pero hay que saber recordar para entender como hemos llegado hasta aqui

Y nuestro más sincero reconocimiento a Wayne Rattlif por crear dBase II (para hacer un software para gestionar apuestas deportivas) que posteriormente publicaría Ashton-Tate (que aunque pareciese que eran "dos" socios, en realidad era una simple estrategía de marketing, y era solo una perona). A su vez Wayne estuvo involucrado en el Jet Propulsion Laboratory que idearon el "dbase" para usarlo en misiones espaciales (wow!), justo salieron los ordenadores personales y Wayne se animó a hacerse el suyo propio...

Para que no olvidemos nuestras raices y de donde viene lo que usamos

Y a los que se fueron a otros lenguajes de programación, pues simplemente se perdieron esta magnífica aventura y este maravilloso compilador que hoy usamos gratuitamente