Cambiar de Version en Delphi es Problematico

[Casimiro Noteví]

Empezado por ASAPLTDA

[..]He trabajado durante muchos anos en sistemas as400 y antes de los sistemas 32/34/36 y aun ahora existen programas con 30 o mas anos de existencia y siguen funcionando sin importar el cambio de version de sistema operativo. en delphi se llamria delphi V delphi XE .... etc[..]

Bueno, amigo, es muy distinto cambiar de delphi que cambiar de sistema operativo.
Los programas que hablas seguramente están hechos en cobol y los cambios que se hacen en esos sistemas AS400 y demás que has mencionado son mínimos en años y años, prácticamente son iguales, sin embargo no tiene nada que ver con los cambios/mejoras de un IDE y componentes que se actualizan de versión a versión.
Debes tener en cuenta lo comentado por gatosoft, hay que pensar en el futuro y hacer las cosas "estandares", lo más simple posible sin meterse en lios con componentes bonitos y llamativos que lo mismo desaparecen en un año y luego ya no puedes actualizar el sistema.

[ASAPLTDA]

Es cierto que algunos componentes de terceros desaparecen, pero el problema es que no solo los componentes de terceros lo son son los mismos elelementos de trabajo que da delphi , recuerdan quickreports? desapaprecion de borlan , recuerdan report smith desaparecion de borland .
Pr no hablar de las funciones/procedimientos que cambian de clases
Ahora si comparas un as400 de hoy con hace 10 anos te puedo decir que si ha cambiado y mucho

Ahora toca usar algunos componentes de terceros por ejemplo no tengo la version para usar bases de datos me toca usar SQL-DIRECT , algunos recomiendan ZEUS Pero esta absoleta .
Estoy usando SdfData Application de Author : Orlando Arrocha email: [email protected] para cargar arhivos de texto, es excelente pero en delphi xe no funciona, los fuentes estan en Torry pero no tengo el conocimiento para actualizarlas valdria la pena recuperarlas

[Casimiro Noteví]

Empezado por ASAPLTDA

[..] Ahora si comparas un as400 de hoy con hace 10 anos te puedo decir que si ha cambiado y mucho [..]

Pero el as400 es el "aparato", que puede llevar el SO os400 e incluso en los últimos modelos creo que incluso linux, windows o el unix de ibm, el aix.
Seguro que un programa que funciona en os400 no funcionará en windows, por decir algo.

Lo que comentas es así, por eso es lo que decíamos antes, hay que pensar en el futuro, a veces es dificil acertar en las herramientas, por ejemplo, supongo que aunque delphi ya no venga con quickreport, me imagino que se podrá comprar por separado o quizás de primera hora se tendría que haber elegido otro "reporteador" externo a delphi, en fin, nadie es adivino, creo que casi todos hemos sufrido esos problemas que comentas.

[mcs]

Empezado por Casimiro Notevi

Pero el as400 es el "aparato", que puede llevar el SO os400 e incluso en los últimos modelos creo que incluso linux, windows o el unix de ibm, el aix.
Seguro que un programa que funciona en os400 no funcionará en windows, por decir algo.

No te creas... Hace 10 años trabajaba en una empresa de software donde se programaba principalmente en RM-Cobol. La versión inicial del programa lo habían hecho para Xenix/286, se había portado a MS-DOS, a Novell Netware, y a Windows sin cambiar ni una coma del programa, y dicha aplicación se había pasado a AS/400 (o quizá era un System/36?? No sé, un cacharro grande de IBM) sin modificar el código fuente.

Esto en Delphi es difícil de hacer, por el simple motivo que no hay un estándar... Hoy (Delphi XE) un String es un conjunto de hasta 65535 WideChar (16 bit). Hace 5 años (Delphi 2006), un String era un conjunto de hasta 255 Char (8 bit).

Es mala esta evolución? Para nada. Pero tenemos el inconveniente que a veces se rompe completamente la compatibilidad hacía atrás.

[Casimiro Noteví]

Cierto, lo sé por experiencia, con RM-Cobol es posible ejecutar el mismo programa en msdos, xenix, unix, windows (como programa msdos), etc. y todo eso con tan sólo compilarlo. Pero no puedes comparar, no tiene nada que ver eso con delphi.
Aunque hoy en día también hay entornos gráficos y IDEs para cobol, pero seguramente ya no serán compatibles entre distintos sistemas.

[ASAPLTDA]

Empezado por mcs

No te creas... Hace 10 años
Es mala esta evolución? Para nada. Pero tenemos el inconveniente que a veces se rompe completamente la compatibilidad hacía atrás .

La evolucion es importante pero tambien la comptabilidad hacia adelante, si estoy migrando de delphi 5 a XE dberia ser compatible, porque cada ano si uno actualiza el IDE le tocara cambiar de nuevo los programas y sobre esto creo que es importante hablar compatabilidad porque cada ano al actualzizar el IDE por mejorar me toca revisar un poco de cosas que dolor de cabeza

[Casimiro Noteví]

El programa de gestión que tenemos en mi trabajo se empezó a programar en 1999 con delphi 5 y seguimos todavía con delphi 5 porque cambiarlo sería costosísimo en tiempo, dinero y trabajo.
Lo de la compatibilidad hacia adelante... no sé, depende, el problema es el de siempre, que hay cosas que son muy difíciles de mantener, se engordan los programas con parches para mantener la compatibilidad de las versiones anteriores y al final salen cosas como... windows

[JXJ]

Empezado por ASAPLTDA

La evolucion es importante pero tambien la comptabilidad hacia adelante, si estoy migrando de delphi 5 a XE dberia ser compatible, porque cada ano si uno actualiza el IDE le tocara cambiar de nuevo los programas y sobre esto creo que es importante hablar compatabilidad porque cada ano al actualzizar el IDE por mejorar me toca revisar un poco de cosas que dolor de cabeza

no has programado con visual C de microsoft.

de los programas que he compilado den visual c 6, no
compilan en visual c 2003, 2005 y asi.
si tu programa compila bien en una version
en la siguiente casi siempre da errores
y eso que no usa componentes de terceros.
cimplemente, puro C++ y los componentes standar de visual studio.

erorr tras error de compilacion

yo al contrario.
he programdo con delphi 1 hasta 2007
y el codigo. bien facil de portar excepto por
las versiones intermedias de delphi 6 con la porqueria de CLX incrustada
y delphi 7, de ahi sin CLX se porta facililismo.

menos en delphi 2009 en adelante.
aun no hay componentes nativos para soportar unicode.
en el procesamiento de archivos de textos
que se generan en sistema Ansi. y que tienen que manejar texto
en chino. mi caso mucho problema por que hay que hacerlo bien.

pero pronto.

[[Lepe]]

ASAPLTDA, ¿te has parado a pensar que TUS clientes estarán diciendo lo mismo de tu programa?

Malos días los tenemos todos... y lo sé muy bien porque llevo 1 semana portando un programa de D7 a D2010 , me ha asombrado que todo el código compile perfectamente y sólo falle un 0.005 % que encima son componente de terceros (por el unicode).

Un cafelito (o té) y pa'lante compañero de fatigas...