Choix du couple version Delphi et OS

Version imprimable

11/05/2011, 01h54
delphman

Choix du couple version Delphi et OS

Démarrant le développement d'une nouvelle application professionnelle, destinée à être distribuée essentiellement en entreprise (BDD Oracle ou MSSQL), je cherche comment choisir le couple OS/Delphi pour développer ce projet...

Dans le but d'éviter tout problème de compatibilité de l'exécutable (32 bits a priori) dans son environnement (XP mais de plus en plus W7 bien sûr)
et d'assurer la plus longue vie possible au logiciel développé, vaut-il mieux

- Conserver une version (relativement) ancienne de Delphi (D7,D2006...) et compiler sous XP, puis tester sous XP & W7 et éventuellement travailler en mode compatibilité XP

ou bien

- Utiliser une version récente de Delphi, 100% compatible W7 (>= D2010) ET travailler sous W7, puis tester sous XP ?

Est-ce ce choix a une incidence sur les problèmes potentiellement rencontrés par l'exécutable dans son environnement ou bien cela n'a t-il que peu ou très peu d'impact ?

Autrement dit, pour simplifier, un exe produit sous XP/"Delphi ancien" risque t-il de présenter moins de problèmes sous W7 (avec évt compat. XP) qu'un exe dév. sous W7 et tournant sous XP...?

En dehors de cet aspect, il y a bien sûr le problème des composants tiers qui risquent de ne plus être mis à jour dans leurs versions anciennes (D7 par ex.)

Merci de bien vouloir m'éclairer un peu sur ce sujet important et épineux... pour moi
:aie:
11/05/2011, 07h11
Paul TOTH

Bonjour,

personnellement je partirais sur du Delphi 7 avec quelques précisions:

1) le code doit tenir compte du passage en Unicode à partir de Delphi 2009

2) le code doit tenir compte du passage en 64bits sur la prochaine version

3) le code doit tenir compte du possible support ARM sur les versions suivantes

pour cela, le code métier doit être bien isolé du reste, avec un code 100% Pascal le moins dépendant possible de l'interface graphique.

ce code doit donc pouvoir être recompilé sans modification sous Delphi XE :)

Pour ce qui est de l'interface, je développerais sous XP car Seven est supposé affiché du XP mais l'inverse n'est pas vrai.

Maintenant, si tu as le temps et les moyens, rien ne t'empêche de concevoir deux interfaces, l'une pour XP avec Delphi 7 l'autre pour Seven avec Delphi XE, le tout ne seraient de toutes façon que des coques vides s'appuyant sur le code métier ci-dessus.

Maintenant tu peux vouloir faire la même chose mais sous Delphi XE car :
- tu as besoin du support Unicode
- tu veux utiliser les améliorations de l'IDE
- tu veux utiliser les generics, la surcharge d'opérateur, etc...
- tu connais bien Delphi et XP et sais ce qui fonctionne sous XP et Seven

mais attentions aux éventuels problèmes XE/XP
11/05/2011, 20h30
delphman

Merci...

Merci pour cette réponse...
Pour résumer, il vaudrait mieux, pour des raisons de fiabilité/compatibilité, de développer du code sous D7/XP exécuté sous W7 que du Delphi XE compilé sous W7 et exécuté sous XP.
Même si les entreprises sont en train de migrer plus rapidement que prévu sous W7, il faudra pendant assez longtemps que cette application, redéveloppée complètement, tourne sous XP...

Pour le code sous D7 :

1) le code doit tenir compte du passage en Unicode à partir de Delphi 2009
OK, donc il est possible de travailler en unicode sous D7 ?
En utilisant des WideString et Widechar ? (= UCS2)
Par contre, il peut y avoir des problèmes avec les composants VCL qui ne sont pas compatibles unicode ?
Si on travaille en WideString pr les expressions à traduire, le code D7 est donc compatible XE ?
Je ne pense pas avoir besoin d'utiliser des caractères complexes comme les caractères chinois. Peut-être des caractères arabes, tout au plus.

2) le code doit tenir compte du passage en 64bits sur la prochaine version
La prochaine version de Delphi ??
Cela voudrait dire utiliser systématiquement en integer64, entre autres ?
Quelles seraient les impératifs à respecter pour ce passage en 64 bits ?

3) le code doit tenir compte du possible support ARM sur les versions suivantes
Code ARM : pour du code portable sur les mobiles ???

- besoin du support Unicode : peut-être si langues asiatiques
- utiliser les améliorations de l'IDE : pas nécessaire
- utiliser les generics, la surcharge d'opérateur, etc... : du code simple

Effectivement, pas de besoins de l'IDE ou des nouvelles fonctionnalités XE.

Merci d'avance pour les précisions que vous pourrez m'apporter...
12/05/2011, 06h56
Paul TOTH
Pour l'unicode, je pense que sous D7 il est préférable de rester en Ansi et de basculer en Unicode avec D2009+.

Pour cela il faut juste tenir compte du fait que "string" deviendra unicode et "char" deviendra wide.

il y a donc certaines choses à bannir du code, comme supposer sur la longueur d'une chaîne est sa taille en octets :
Code:

1 2 3 4 FillChar(string[1], Length(s), ' '); // ne remplit que la moitié d'un string unicode FillChar(string[1], Length(s) * SizeOf(Char), ' '); // ok
le string D2009+ est localisé (il a un charset associé) il ne faut donc pas y stocker des données binaires, pour cela il y a le RawByteString
Code:

1 2 3 4 5 {$IFNDEF UNICODE} type RawByteString = string; // pour D7 pas de différence entre les deux {$ENDIF}
dans le même genre, ne pas supposer que la longueur d'un Integer est de 32bits (encore que je ne me souvienne plus ce qu'ils ont décidé, mais lors du passage de Delphi 1 à Delphi 2 l'integer est passé de 16 à 32bits)

d'une manière général, le plus simple dans ces cas là est de déclaré des nouveaux types pour tout (je n'aime pas cette pratique couramment utilisée en C++ mais c'est la seule qui garantisse une facilité de portage)
Code:

1 2 3 4 5 6 type int8 = Byte; int16 = SmallInt; int32 = Integer; // int64 existe déjà
il suffit ensuite d'ajouter des {$IFDEF VERXXX} pour adapter les déclarations afin d'avoir toujours les mêmes types.

Note que tout ceci n'a d'importance que quand la taille de l'élément compte (accès ficher, socket ...)

pour ce qui est de la compatibilité des composants tiers, si à ce jour il n'existe pas de version unicode, c'est qu'il y a peu de chance qu'il en existe une un jour, ça date tout de même de D2009 !

Pour le support ARM, c'est encore plus simple, il ne faut pas mettre d'assembleur Intel dans le code :) ... peut-être l'endianness, mais apparemment, l'ARM est bi-endian.