Première présentation de Delphi XE2

**John Colibri** · 21/08/2011, 15h41

Première présentation de Delphi XE2
Compilateur 64 bits, DataBindings et framework FireMonkey pour la prochaine version de Delphi

La prochaine version de Delphi s’appelera Delphi XE2 (pour Delphi 2012). Elle devrait être officiellement annoncée le 24 Août aux "Delphi X2 World Tour" de Buenos Aires.

Cette nouvelle version incorporera :

le compilateur 64 bits pour Windows 64 bits. Une simple sélection de la plateforme cible devrait suffire, avec modifications éventuelle des instructions qui font des hypothèses 32 bits explicites
un nouveau jeu de composants visuels qui forment le framework FireMonkey. Il s'agit de composants 3D qui utilisent l'accélération des processeurs graphiques et qui seront utilisés pour une cross compilation NATIVE vers les plateformes Mac OsX et iOs (l'Os de iPhone et iPad). La même application Windows pourra donc être portée sur Mac OsX ou distribuée dans les boutiques iPhone
des DataBindings qui permettrons de lier des propriétes entre elles. Ces liaisons permettrons de se passer des composants sensibles aux données de la VCL, mais permettent aussi de lier n'importe quelle type d'informations autres que celles relatives aux bases de données. Sera utilisable par FireMonkey

Plus d'infos dans les semaines qui viennent.

Source

**Gilbert Geyer** · 21/08/2011, 15h50

Bonjour,

Pour quand la reprise de Pascalissime ? : ça manque dans le bureaux de tabac et autres boutiques.

A+.

**John Colibri** · 21/08/2011, 17h25

ah nostalgie, nostalgie ...
en attendant, depuis 2001, c'est http://www.jcolibri.com qui tient lieu de Pascalissime

**Gilbert Geyer** · 22/08/2011, 10h28

Bonjour,

John Colibri : ah nostalgie, nostalgie ...

... ce n'est pas uniquement par nostalgie que j'ai posé cette question.
Car comme tout autodidacte quand j'ai démarré avec Delphi j'ai acheté successivement une flopée de bouquins qui m'ont généralement déçu (manque de pédagogie, exemples qui ne fonctionnaient pas, etc) ... jusqu'au jour où j'ai trouvé "Delphi Applis Windows Rapides" : concis, très pédagogique et très digeste, et cela avait été pareil pour la quasi-totalité des articles de Pascalissime.

Mais à propos de Delphi 64 bits : faudra qu'on remplace nos processeurs par des 64 bits pour en profiter pleinement. Et là je me pose une question de compatibilité : Est-ce-que des routines développées en Asm sous les versions 32 bits de Delphi vont fonctionner sous Delphi 64 bits sans avoir à les modifier ou bien faudra-t-il les jeter à la corbeille et tout recommencer ???.

A+.

EDIT : ma question est bête : j'ai trouvé la réponse à la rubrique "Migration 64 bits Delphi: les points à surveiller" ... mais faudra pas seulement surveiller ... faudra certainement modifier.

**sjrd** · 22/08/2011, 14h26

Envoyé par Gilbert Geyer

Mais à propos de Delphi 64 bits : faudra qu'on remplace nos processeurs par des 64 bits pour en profiter pleinement. Et là je me pose une question de compatibilité : Est-ce-que des routines développées en Asm sous les versions 32 bits de Delphi vont fonctionner sous Delphi 64 bits sans avoir à les modifier ou bien faudra-t-il les jeter à la corbeille et tout recommencer ???.

Ah oui c'est évident. Pour faire tourner un programme sur un proc 32 bits, il faut un programme 64 bits.

En revanche, un proc 64 bits peut faire tourner des programmes 64 mais aussi 32.

Si ton programme est 32, les routines Asm doivent être en 32. Si tu compiles pour 64, tu dois traduire tes routines Asm pour 64.

En même temps si t'as fait des routines Asm, tu l'as cherché

**guillemouze** · 22/08/2011, 14h30

Merci pour cette petite intro, ça m'a l'air très prometteur

Et c'est vrai qu'on ne trouve pas vraiment d'infos sur XE2, si ce n'est la pub pour le "XE2 World Tour". Je suis allé sur le site d'embarcadero, c'est très pauvre en informations à ce propos !!!

**CapJack** · 24/08/2011, 13h27

Envoyé par Gilbert Geyer

Pour quand la reprise de Pascalissime ? : ça manque dans le bureaux de tabac et autres boutiques.

(Totalement hors sujet, comme d'hab')

C'est clair. Vu mon grand âge, j'ai connu les premiers numéros, dans la deuxième moitié des années '80. Et j'ai appris énormément de choses grâce à cette publication. Je me rappelle notamment l'extrême rigueur dans le nommage des variables et dans la conception des procédures et fonctions.

Maintenant, nous vivons une époque formidable, où nous pouvons communiquer avec John de façon interactive (je me permets une question indiscrète au passage : Colibri est un vrai patronyme, ou un alias ? ; trop beau pour être vrai !

).

C'est comme ça, le temps passe.

C'est une autre époque, alors, sachons profiter des gens dont la passion nous fait valoir leurs compétences, John Colibri, mais aussi Paul Toth, et d'autres.

**Paul TOTH** · 24/08/2011, 13h44

Dans la séquence nostalgie, vous avez connu DP Tool Club ? ça remonte à l'époque ou on consultait Internet sur CDROM

**dehorter olivier** · 24/08/2011, 14h38

Dans le cadre "Ils ne sont jamais contents"

John Colibri a écrit dans son petit topo :

6.6 - Platfoms futures (XE3 ?)
Linux et Android sont prévus, mais pour une version future de XE.

Pour Android, c'est pour quand ?

**Gilbert Geyer** · 24/08/2011, 14h58

Re-bonjour,

Ouille! On n'a pas encore XE2 qu'on parle déjà d'XE3 !!!
... "qui va piano va sano".

A+.

**John Colibri** · 24/08/2011, 21h02

notre présentation Delphi XE2 - Delphi 2012 ("plus technique" que la petite intro ci dessus que j'avais envoyé à Gordon Fowler ce matin)

http://www.jcolibri.com/articles/del...elphi_xe2.html

a été mise à jour avec les nouvelles informations sur les Proxy Connectors pour Android, BlackBerry, Windows Phone 7 et Ios. Avec les liens correspondant à ces informations.

D'autres informations devraient tomber après l'annonce officielle, et je continuerai à mettre à jour l'article. "Stay tuned"

Merci aussi à "rt5" pour avoir signalé que le lien "source" du début de page vers notre article est incorrect. Je mentionnerais aussi que les références à Pascalissime (où je n'étais d'ailleurs pas le seul à publier) me sont allées droit au coeur.

John COLIBRI
jcolibri@jcolibri.com

**Gilbert Geyer** · 25/08/2011, 11h51

Bonjour,

A Rekin85 : merci René pour ta réponse. Et comme tu dis :

Mais attention elles ne tourneront que sur du 64 bits et le nombre de machines concernées est petit en regard de tout ce qui tourne encore sur du 32.

... il n'y a pas le feu au lac : les NewGint et NewGCent ont encore du temps devant elles.

A Rt15 et à CapJack à propos de la récupération de l'output.
... Merci beaucoup pour vos pistes de résolution.
... Mais je dois vous dire que mon idée est carrément idiote pour la raison suivante : Utiliser un *.exe 64 bits qui lance un *.exe 32 bits truffé d'Asm+Pascal pour lui faire-faire les calculs et renvoyer le résultat à l'exe 64 bits ... à qui il ne reste plus qu'à afficher le résultat du calcul ... donc autant se passer de l'exe 64 bits et faire afficher le résultat directement par l'exe 32 bits. Faut savoir que le cas qui me préoccupe concerne des calculs effectués par les Unités NewGint et NewGcent précitées et qui renvoient des résultats de calcul dont le nombre de digits n'est limité que par la taille d'une string donc limité par la mem-vive disponible ... donc des résultats de calcul avec lesquels l'exe 64 bits ne pourrait évidemment faire rien d'autre que de les afficher.

A J. Colibri : Mon attention a été attirée par :

2.4 - Migration 64 bits Delphi: les points à surveiller
...
... inclusion de blocs assembleur:
- il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal // ça à été déjà cité par Sjrd mais pas la suite :
- seules les procédures ayant l'attribut Asm sont possibles

... compte tenu de ceci je pense qu'on peut en déduire que sous XE2 il est possible d'avoir dans la même unité des procédures et des fonctions qui depuis l'attribut Asm jusqu'au end final sont totalement en Asm et d'autres qui depuis le premier begin jusqu'au dernier end sont entièrement en Pascal. Oui/Non ?

Si Oui il n'y a plus raison de s'affoler vu qu'une routine en Asm peut être appelée par une autre en Pascal et inversement.

A+.

**tourlourou** · 25/08/2011, 12h35

Il est effectivement probable que seul le mix soit interdit.

Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...

**Gilbert Geyer** · 25/08/2011, 13h09

Bonjour Tourlourou,

Il est effectivement probable que seul le mix soit interdit.

... si on prend chaque mot à la lettre cela devrait être le cas.
... mais une bonne confirmation serait rassurante.

Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...

... ça c'est vite dit car le problème sera de savoir tricoter du code Asm-64bits
... demandes donc à René ce qu'il en pense.

A+.

**guillemouze** · 25/08/2011, 14h01

Envoyé par tourlourou

Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...

A priori, une procedure inline est equivalente a faire un $include ou a recopier le contenu à l'endroit de l'appel -> donc mix impossible ... mais ce n'est qu'une impression

**Rekin85** · 25/08/2011, 16h22

Bonjour les amis

... ça c'est vite dit car le problème sera de savoir tricoter du code Asm-64bits
... demandes donc à René ce qu'il en pense.

Moi je veux bien essayer de le faire car l'extension des registres-processeurs 32 => 64 bits ainsi que la mise à disposition de registres supplémentaires peut s'entrevoir aussi naturellement que lorsqu'il s'est agi du passage 16 => 32 bits... Mais comment le faire avec Delphi si l'EDI ne donne pas les outils pour ?

(Je précise que je ne dispose actuellement ni d'une machine à proc 64 bits et a forciori ni d'un environnement Delphi XE2... Donc je parle un peu à vide...)

**PushRax** · 27/08/2011, 21h04

Je suis impatient de voir le compilateur 64 bits final à l'œuvre.

Après l'avoir défendu ardemment pendant très longtemps (envers et contre tous), j'ai finalement dû abandonner Delphi en 2006 à cause de son non support de la compilation native 64 bits. FPC n'est pas une alternative sérieuse pour bien des raisons liées à sa conception. Il a donc fallu passer intégralement au C/C++ sous Visual Studio, qui permet de compiler en 32, AMD64 et IA64 depuis un sacré bout de temps. Dans l'imagerie numérique pro, la 3D et le montage vidéo, les OS 64 bits sont adoptés depuis longtemps (pour la quantité de RAM adressable). L'avantage d'un OS 64 bits est triple : c'est le "langage" natif des processeurs depuis quelques années (les pipelines sont optimisés pour le 64 bits), le plus grand nombre de registres permet enfin de coder efficacement en utilisant moins intensivement la pile et le stockage en mémoire, et bien sur le modèle mémoire permet d'utiliser des applications très gourmandes bien plus efficacement. De plus, sous Windows x64, le sous-système WOW64 pourtant très efficace qui gère les applications 32 bits introduit également des petites pénalités de performances : le basculement du processeur en mode 32 ou 64 bits, la traduction des chemins d'accès ainsi que les wrappers permettant la traduction des conventions d'appel et taille des paramètres a forcement un léger coût, que l'on ressent très nettement si beaucoup d'applications 32 bits tournent en même temps. Et sur plateforme IA64, c'est encore pire vu que le x86 est entièrement émulé...

Bien sur, recompiler un projet prévu pour du 32 bits (utilisant des int 32) en 64 bits n'apportera pas grand chose sinon rien en terme de performances, l'intérêt étant de prévoir son code pour tirer parti des spécificités de l'architecture 64 bits.

Le traitement d'images n'a aucun rapport avec la résolution du processeur ou de l'OS. Une image 8 bits reste 8 bits, une 32 bits reste 32 bits, indépendamment de l'OS ou du processeur. On traitait des images 32 bits sur des processeurs 8 bits (comme les premières palettes graphiques pro qui tournaient sous Z80), et on traite des images 8 bits sur des processeurs 64 bits, cela n'a strictement aucun rapport et ne change rien pour un programmeur en c ou pascal. Les espaces de couleur avec des composants de 16 bits (4x16 = 64) sont réservés à des traitements très spécifiques qui n'ont pas lieu d'être pour le commun des mortels. Par contre, cela fait plus de 10 ans que l'on traite les images grâce aux instructions et registres 64 bits introduits avec le mmx, puis 3D now, SSE, etc... Ainsi, en effet, on peut traiter 2 pixels 32 bits à la fois, 4 pixels 16 bits ou 8 pixels 8 bits (bien que cela ne présente que peu d'intérêt pour les formats palétisés). Cela est aussi très efficace pour le traitement audio. La librairie delphi Graphics32 utilise d'ailleurs abondamment cela pour gérer le blending et l'anti-aliasing de manière 100% software. Mais pour gérer efficacement du traitement d'images, rien n'égale DirectX sous Windows, qui est relativement simple à utiliser et permet de plus de bien comprendre comment les cartes vidéo gèrent les pixels et les espaces de couleur. Le type pf32bit sous delphi, si ma mémoire est bonne, est géré via une DibSection, qui reste le meilleur moyen software de gérer une image bitmap sous GDI, à la manière de DirectDraw. En 2005, j'ai créé une librairie de traitement graphique professionnelle multi-plateformes (d'abord écrite sous delphi puis portée très facilement sous C++), et l'utilisation des dibsection et de SetDIBitsToDevice() sous Windows permettait de limiter le code dépendant Win32 à quelques lignes seulement (tout le traitement possible sur les images en mode software ne nécessitant strictement aucune API ou fonction externe, uniquement des calculs et beaucoup de code machine optimisé pour chaque plateforme cible).