Discussion :

[Droïde Système7]

Bonjour

Je viens vers vous, afin de vous demander, ce que vous pensez vis à vis de la compilation sous Vista.

Voilà, en fin d'année je suis passé de Windows 98se vers Vista.

Bien entendu et logiquement désormais tout se passe sous Vista.

Là, dernièrement j'ai eu la curiosité de placer une de mes applis sur Windows 98se.

Hé bien, je peux donner des collections de messages d'erreurs

Mais bon... franchement cela me fait un peu de mal au coeur de devoir prendre la décision d'abandonner la compatibilité au dessous d'XP.

Je pourrais éventuellement ajouter les bibios que j'ai actuellement sur Vista et actualiser les compos en conséquence.

Mais les époques évoluent et faut bien savoir se remettre en cause souvent.

Bref, pour vous demander votre avis, surtout comment réagissez-vous à ces divers changements de nonos à Bilou ?

Vous résignez-vous à ne plus conserver la compatibilité au dessous d'XP ?

Merci de vos avis

[Reisubar]

Vous résignez-vous à ne plus conserver la compatibilité au dessous d'XP ?

Honnêtement oui, quoique en théorie Windows 2000 doit passer aussi. Il y a énormément de limitations dans les API de Win 95/98/Me qui rendent difficile de développer des applications performantes et modernes dessus... Et qui utilise encore ces OS ?... (Oui, je sais, il y a forcément un *petit* nombre d'utilisateurs, mais c'est vraiment de plus en pls marginal).

De toute façons avec la prochaine version de Delphi tu n'auras plus le choix, puisque les programmes compilés ne seront plus compatibles avec ces vieux OS.

[Droïde Système7]

Adrien,

Là, je dois dire que tes arguments sont de poids et ça m'en ôte un (un poids ), alors d'un certain sens ouffff, mais jongler afin que tous les nonos soient satisfaits...

Merci, je vais m'y faire alors ; les époques changent et les nonos aussi.

Merci et par la même : affaire résolue.

(Même l'indispensable PowerBatch ne sera plus compatible ?)

Edit :

De toute façons avec la prochaine version de Delphi tu n'auras plus le choix, puisque les programmes compilés ne seront plus compatibles avec ces vieux OS.

Oui mais nos codes sources seront-ils encore valables sans modifs à la compil ?

[Reisubar]

Oui mais nos codes sources seront-ils encore valables sans modifs à la compil ?

Ca dépends... Si tu ne fait pas trop d'opérations low-level tout ira sans doute bien (en croisant les doigts) mais si tu joues beaucoup avec les APIs Windows, les flux, que tu utilises les chaînes pour stocker des trucs binaires, ca risque de coincer. Mais Borland publiera bientôt des docs sur comment migrer son code proprement...

Même l'indispensable PowerBatch ne sera plus compatible ?

Je n'ai pas recompilé PowerBatch depuis 5 ans et ne pense pas passer à l'acte dans les prochaines années, donc je ne me pose même pas la question

[Droïde Système7]

Encore merci Adrien de tous ces détails

Bon, alors pour les développeurs comme moi niveau math sup (maternelle supérieure ) ça devrait passer, car rien de très très haut niveau.

En plus, je ne sais même pas à quoi correspondent les opérations low-level

Dommage pour PowerBatch.

[Reisubar]

En plus, je ne sais même pas à quoi correspondent les opérations low-level

Pour être plus clair, le passage vers unicode sera problématique dans les cas suivants :
- I/O au niveau fichiers (TStream, TFileStream...)
- I/O au niveau réseau
- Communications avec des DLLs tierces

Il faut éviter d'utiliser SizeOf() pour déterminer la longueur d'une chaine de caractères car maintenant les chaînes seront allouées sur deux octets. Attention donc à SizeOf(TableauChar) (à remplacer par Length()), à MyStream.Write(String) (qui va donc prendre deux fois plus de place dans le flux), FillChar(TableauChar, Size) (utiliser Sz * SizeOf(Char) pour que tous les octets soient traités), etc etc.

Si tout cela te semble du charabia, alléluia, ton code est suffisamment "haut-niveau" pour être prêt pour le transition. Dans le cas contraire, au boulot :-)

[ShaiLeTroll]

Effectivement, les clients encore sous Win9x se rarifie, j'ai testé, il y a un an un outil de migration DBase vers MySQL sur un Win95 (P1 64Mo oui oui), le Serveur MySQL étant sur Win2000 ... eh bien, le client migrateur tournait sans soucis ... lentement, mais sans soucis

Dans la plupart des applications que je maintiens, on installe par défaut XP chez les clients, et certaines à causes des API externes (eh oui, lien sur library fait avec external, même si pas utiliser dans l'application, même pas l'effort d'un LoadLibrary\GetProcAddress, rrrrr...), du coup on ne support plus Win98, pour l'application elles-même c'est tellement un sac de noeud, que je n'en sais rien, ....

En plus, le Prochain Delphi est totalement UniCode, ils ont refait le type string (il serait par défaut WideString au lieu de AnsiString, je vous laisse imaginer, le travail qu'il y aura à faire pour les libs qui manipulait les string via des PChar, faudra jouer avec une directive de compilation ...), alors SizeOf, FillChar ... il faudra les revoir ... est-ce que le type Char pointera aussi sur un WideChar (pour faciliter la vie, car sinon C := S[1] compilera plus si C est un Char) en fonction de la fameure directive ...

[Reisubar]

il serait par défaut WideString au lieu de AnsiString

Non, il sera UnicodeString. WideString restera un type dont la mémoire est géré par Windows (alias du type COM "BSTR"), alors que UnicodeString utilisera un compteur de références comme AnsiString. Les deux seront évidemment compatibles.

faudra jouer avec une directive de compilation

Il n'y aura pas de directive de compilation. Si tu achètes Delphi 2009, soit tu migres tout à unicode, soit tu fais du chercher/remplacer pour passer de string à AnsiString dans toutes tes applications et tes composants tiers pour demander explicitement à rester non unicode.

est-ce que le type Char pointera aussi sur un WideChar

Il pointera sur le type UnicodeChar (par analogie avec le AnsiChar).

[Droïde Système7]

Whaoouuuu les copains !

Oui mais alors, même sans trop manipuler des codes contenant des SizeOf() etc. je suppose que tout programmeur dispose de composants qui eux...

Imaginons les programmeurs ayant passé des mois sur un compo ; paquet, ou bibio, etc., et d'un seul coup d'un seul ; tout devient obsolète

De quoi se la dévorer toute crue ! la souris

[Reisubar]

Imaginons les programmeurs ayant passé des mois sur un compo ; paquet, ou bibio, etc., et d'un seul coup d'un seul ; tout devient obsolète

Ca dépends... Les composants très bien programmés migreront sans changer grand chose... Les composants payant seront migrés par leurs auteurs... Les composants gratuits toujours supportés, aussi... Restent les composants abandonnés potentiellement mal programmés. A voir, dans quelques mois, si y'a eu des suicides ou des meurtres

[ShaiLeTroll]

Merci Reisubar pour avoir corriger mes erreurs, autant être précis, sinon, pour l'avoir vu au CodeWay Tour, il y a bien une directive (ils nous ont montré system.pas ) ... sinon, pour la précision du UnicodeChar, cela pourra simplifier la transition, ...

[Reisubar]

J'étais moi aussi au CodeWay tour. Le problème c'est qu'ils ne connaissent pas assez Delphi que Borland, d'un point de vue technique ;-)

Il n'y a pas de directive de compilation, même si Thierry Laborde a dit que c'était le cas. Allen Bauer, l'architecte en chef du compilateur l'a affirmé à de multiples reprises. En voilà encore une couche :

http://chrisbensen.blogspot.com/2008...witch-for.html

Dans system.pas, il y a juste des {$IFDEF UNICODE}, mais cette définition est faite de manière systématique par le compilateur de Delphi 2009. Ce n'est pas "au choix".

[ShaiLeTroll]

La directive de compilation permet donc dans une fonction de gérer le type de string si l'on ne fait qu'une fonction qui fait les deux, au lieu de deux fonctions surchargés avec les deux types de string ... c'est dans le sens là que je disais qu'il fallait jouer avec une directive ... si l'on fait une lib qui est commune à plusieurs delphi (perso, j'ai des codes compatible de 3 à 7 , je sais je suis old school), car si il faut tout se retapper entre Delphi 2008 et 2009, la directive évite les duplications de code entre les versions de Delphi, ça promet du taf ...

Sinon, effectivement, si l'on a mis comme moi mis des "1" dans le GetMem pour allouer des PChar, au lieu d'un SizeOf(Char), ben c'est le caca (ça m'apprendra à ne pas utiliser StrAlloc)... je pense que je suis pas le seul à mal programmer dans ce cas, mes CopyMemory sauvage entre string et pointeur ça va pas aimer non plus, ... bon, je suis pas pret de sortir de Delphi 7 ... avec la tétra-chier de lib externes qui n'existent plus, ou que les objets ont trop changé depuis et la lib interne que se trimballe mon employeur ... la migration ça promet, et comme les chefs ne jurent plus que par le PHP maintenant, ...

[ShaiLeTroll]

Salut Reisubar, ça m'a fait plaisir de te voir hier au Code Way Tour Delphi 2009, bon on a revu cette fameuse directive UNICODE, vu le code autour, ça sent juste une utilisation interne à CodeGear le temps de tout passer en UNICODE, ... donc pour les petits porcs ou trolls qui avaient alloué des PChar à coup de GetMem(p, 1); vont avoir des surprises (le type PChar pointera sur quoi ? Char ? mais comme le Char sera un WideChar ? beau bordel donc !), idem pour le CopyMemory PChar vers string (au lieu d'une affectation)

On va avoir du TAF ! Youpi !