Embarcadero étend les fonctionnalités de RAD Studio 2009 de Windows à .NET et mono

**Nono40** · 09/12/2008, 00h17

Embarcadero étend les fonctionnalités de CodeGear RAD Studio 2009 de Windows à .NET et Mono

RAD Studio 2009 apporte aux développeurs et aux ISV une solution complète de développement rapide d'applications

PARIS & SAN FRANCISCO – 8 décembre 2008 -- Embarcadero Technologies annonce la disponibilité de RAD Studio 2009, solution complète de développement rapide d'applications apportant aux ISV, entreprises et développeurs de logiciels tous les outils nécessaires pour bâtir des applications natives Windows, .NET, Web et de bases de données, indépendamment du type de base de données auquel elles se connectent ou qu'elles intègrent.

CodeGear RAD Studio 2009, produit phare d'Embarcadero pour les plateformes Windows et .NET, combine les fonctionnalités de développement rapide d'applications de Delphi 2009 et C++ Builder 2009 avec les fonctionnalités de développement .NET de Delphi Prism, récemment présentées. Cette combinaison de produits apporte aux développeurs un environnement complet aussi bien pour le support des développements simples Windows que pour le support des développements complexes sous .NET. De plus, la nouvelle édition de RAD Studio Architect inclut ER/Studio Developer Edition d'Embarcadero, pour le développement rapide d'applications grâce à des fonctionnalités puissantes de modélisation et de conception de bases de données.

Selon Michael Swindell, vice président Produits chez Embarcadero, « Etant donné qu'il devient de plus en plus important de faire plus, plus vite et avec moins de ressources, RAD Studio 2009 aide les développeurs et leurs équipes à répondre aux besoins des directions informatiques et des ISV en matière de développement rapide et qualitatif. RAD Studio 2009 est la seule solution de développement rapide pour les développements Windows natifs, proposant désormais la flexibilité nécessaire pour atteindre .NET sur Windows, et Linux et Mac OS X via Mono ».

RAD Studio 2009 apporte aux développeurs .NET les fonctionnalités clés suivantes :

- Le tout nouvel environnement de développement Delphi Prism, qui repose sur l'outil de compilation RemObjects Oxygene™ ;

- La possibilité de tirer parti des toutes dernières technologies .NET, telles que WinForms, WPF, ADO.NET, ASP.NET et LINQ ;

- Le support de déploiement pour la plateforme MONO sur Mac OS X et Linux ;

- La possibilité de développer des applications de bases de données en utilisant les fonctionnalités éprouvées dbExpress et de créer des clients .NET connecté aux serveurs natifs DataSnap ;

RAD Studio permet aux développeurs Windows de :

- Créer facilement des applications adaptées aux données globales grâce au nouveau support Unicode dans l'EDI et la Visual Component Library (VCL) ;

- Moderniser les interfaces utilisateur avec les nouvelles fonctionnalités de contrôle VCL ;

- Tirer avantage des fonctionnalités de langages modernes proposées par Delphi, telles que les méthodes génériques et anonymes, ou telles que le support pour les standards C++0x compris dans C++Builder ;

- Bâtir des applications de bases de données puissantes, efficaces et sécurisées en séparant les données des processus métiers avec le nouveau DataSnap ;

- Bénéficier d'un plus haut niveau de détails dans les structures de bases de données grâce aux fonctionnalités de modélisation et de visualisation de l'édition Architect.

« Avec l'ajout de Delphi Prism à RAD Studio, notre rêve de développer sur les autres plateformes est devenu réalité, » comment Mauricio Buso, directeur du développement chez OneSolution Brasil. « Nous pouvons désormais bâtir un excellent serveur DataSnap dans Delphi 2009, et déployer nos solutions client en utilisant .NET, les plateformes Mono pour Windows, Mac OS X, Linux, et bien d'autres encore. Delphi Prism nous apporte des capacités inédites de développement et nous ouvre de nouvelles frontières. »

RAD Studio est disponible sous trois éditions : RAD Studio Professional pour le développement d'applications avec une connexion locale aux bases de données ; RAD Studio Enterprise pour le développement de bases de données et d'applications web client/serveur et multi-tiers ; et RAD Studio Architect, qui inclut des fonctionnalités puissantes de modélisation et de conception de bases de données. Pour plus d'informations :

http://www.codegear.com/products/radstudio.

Tarifs

CodeGear RAD Studio 2009 peut être commandé dès à présent via le site web de la société (http://shop.codegear.com) ou via l'un des partenaires d'Embarcadero. Les tarifs débutent à 1 399 euros par développeur pour l'édition Professional, avec un tarif de mise à jour de 649 euros par développeur. Un tarif spécial de mise à jour pour les possesseurs de Delphi et C++Builder 2009, des tarifs liés au volume de licences et des réductions pour le secteur de l'enseignement sont disponibles. Le produit est d'ores et déjà disponible en Anglais, Français, Allemand et Japonais.

**Nono40** · 09/12/2008, 00h29

Ce message est le communiqué officiel d'Embarcadero

Delphi présente enfin une solution pour les utilisateurs de linux.

Pour Delphi 2005, mono ne faisait pas partie du projet et n'était pas garanti par Borland.

Un an plus tard Mono commence à pointer dans les couloirs.

Bien que Kylix ne soit pas annoncé comme abandonné, il n'a plus évolué depuis des années. Embarcadero suit maintentant officiellement la voie de mono pour l'utilisation de Delphi sur les platerformes Linux et Mac OSx.

**qi130** · 09/12/2008, 11h50

Envoyé par Nono40

Embarcadero suit maintentant officiellement la voie de mono pour l'utilisation de Delphi sur les platerformes Linux et Mac OSx.

A lire un article sur le Developper Netword de CodeGear

**skywaukers** · 10/12/2008, 16h50

Bonjour,

Envoyé par Nono40

Embarcadero suit maintentant officiellement la voie de mono pour l'utilisation de Delphi sur les platerformes Linux et Mac OSx.

Cela veut-il dire qu'ils éliminent définitivement la possibilité de sortir une version de compilateur natif pour les autres plates-formes de windows ?

@++
Dany

**Thierry Laborde** · 10/12/2008, 18h40

Envoyé par skywaukers

Bonjour,

Cela veut-il dire qu'ils éliminent définitivement la possibilité de sortir une version de compilateur natif pour les autres plates-formes de windows ?

@++
Dany

Non pas du tout, cette solution n'est pas éliminée.

**Nono40** · 11/12/2008, 00h49

Envoyé par skywaukers

Cela veut-il dire qu'ils éliminent définitivement la possibilité de sortir une version de compilateur natif pour les autres plates-formes de windows ?

Ca veut surtout dire qu'ils reconnaissent maintenant officellement l'exitence de mono et la réalisation d'appli multi-plateforme.

Pour Kylix, la réponse est toujours "non, non, ce n'est pas abandonné" mais je n'ai jamais entendu parlé d'un reprise de service

Après le portage entre Delphi et Kylix n'a pas été formidable. j'ai essayé une fois mais la CLX, heu, bon enfin passons ce n'était pas la VCL

. On ne pouvait pas dire que c'est le même code qui fonctionne sous deux plateforme vu qu'il fallait le recompiler avec Kylix.
Si c'est repris un jour j'espère que l'échange entre Kylix<->Delphi sera meilleur : pouvoir compiler un natif linux dans Delphi et réciproquement.

**skywaukers** · 11/12/2008, 11h31

Bonjour,

Envoyé par Nono40

Si c'est repris un jour j'espère que l'échange entre Kylix<->Delphi sera meilleur : pouvoir compiler un natif linux dans Delphi et réciproquement.

En fait le problème en natif sera toujours l'utilisation de couches propre au système, je pense notamment à l'interface graphique. Si tu utilise une api windows qui n'existe pas sous linux, je ne vois pas comment ton code windows pourrait fonctionner tel que sous Linux, et vice versa bien sûr. Il faut pour cela une couche d'abstraction, et c'est un peu ce qu'avait fait avec plus ou moins de bonheur Kylix.
Pour moi un des inconvénient de Kylix venait de l'utilisation de QT4, trop tôt qui du coup empêchait le fonctionnement direct des applications.
Il faudrait peut-être qu'ils se rapprochent des équipes free Pascal/ Lazarus qui ont une bonne expérience du multi-plateformes natifs. Pourquoi ne pas imaginer un rapprochement des 2, comme il y a eu un rapprochement avec RemObjects ? Il devrait bien y avoir moyen de trouver un terrain d'entente qui soit bénéfique aux deux.

@++
Dany

**Paul TOTH** · 11/12/2008, 13h23

Envoyé par skywaukers

Bonjour,

En fait le problème en natif sera toujours l'utilisation de couches propre au système, je pense notamment à l'interface graphique. Si tu utilise une api windows qui n'existe pas sous linux, je ne vois pas comment ton code windows pourrait fonctionner tel que sous Linux, et vice versa bien sûr. Il faut pour cela une couche d'abstraction, et c'est un peu ce qu'avait fait avec plus ou moins de bonheur Kylix.
Pour moi un des inconvénient de Kylix venait de l'utilisation de QT4, trop tôt qui du coup empêchait le fonctionnement direct des applications.
Il faudrait peut-être qu'ils se rapprochent des équipes free Pascal/ Lazarus qui ont une bonne expérience du multi-plateformes natifs. Pourquoi ne pas imaginer un rapprochement des 2, comme il y a eu un rapprochement avec RemObjects ? Il devrait bien y avoir moyen de trouver un terrain d'entente qui soit bénéfique aux deux.

@++
Dany

La VCL pourrait être cette couche d'abstraction

Ceci dit la remarque de nono était sur la possibilité depuis un même produit de compiler vers deux OS différents (comme du temps de Turbo Pascal qui proposait de compiler pour DOS, DOS/PM ou Windows

)...soit une intégration du compilateur Kylix dans Delphi for Windows.

D'autant qu'à mon sens, Delphi gagnerait à proposer des outils de développements qui permettent de développer un client léger sous Windows et un serveur sous Linux, donc pas forcément avec les mêmes composants, mais des composants qui se parlent !

**rt15** · 11/12/2008, 13h49

La LCL (Equivalent de la VCL) de Lazarus s'appuie généralement sur le Win32 sous Windows et sur GTK2 sous Linux, bien que l'on puisse aussi s'appuyer sur QT4.

Bilan faut que GTK ou QT soit installées sur les machines Linux cibles...

Il n'y a à ma connaissance que X11 qui permettent d'être à peu près portable sur les Unixs. D'où fpGUI.

Envoyé par Nono40

Si c'est repris un jour j'espère que l'échange entre Kylix<->Delphi sera meilleur : pouvoir compiler un natif linux dans Delphi et réciproquement.

Alors ça, d'après mes modestes recherches de windowsien, c'est tout à fait utopique, Delphi ou pas.

Sous Windows, on est pépère : la couche Win32 est à peu près la même sur un 2000/XP/Vista... Bilan on fait des applis qui sont liées statiquement aux librairies dynamiques kernel32.dll, user32.dll et autres et ça tourne.

Sous Linux, les .so ont des versions : il n'y a pas de continuité dans la compatibilité. Bilan le point de compatibilité justement, c'est le source. Avec un certain nombre de .h que l'on est plus ou moins sûr de trouver, et un gcc qui est fourni de base dans toutes les distribs.

Quand on récupère une appli Linux, soit on télécharge des "paquets" qui sont compilées spécifiquement pour notre Nunux, soit on télécharge un source, et on se tape la compile à base de make all install ou autre.

Bref, la cross compilation Windows -> Linux, je pense que l'on ne la verra jamais. Par contre, l'inverse (Linux -> Windows) ne représente aucune difficulté technique.

**Thierry Laborde** · 11/12/2008, 14h14

Envoyé par Paul TOTH

D'autant qu'à mon sens, Delphi gagnerait à proposer des outils de développements qui permettent de développer un client léger sous Windows et un serveur sous Linux, donc pas forcément avec les mêmes composants, mais des composants qui se parlent !

En fait c'est déjà le cas avec DataSnapp qui a été intégré dans Delphi PRISM.
Donc on peut faire un serveur Datasnapp en linux par exemple et un client windows ou web et vice versa.
D'ailleurs Andreano Lanusse de CodeGear a fait un article là dessus, avec le source d'un projet qu'on peut récupérer où le serveur est en Delphi Win32 et le client en ASP.NET :

http://blogs.codegear.com/andreanola...entral-part-1/

**Nono40** · 12/12/2008, 00h36

Envoyé par skywaukers

En fait le problème en natif sera toujours l'utilisation de couches propre au système, je pense notamment à l'interface graphique. Si tu utilise une api windows qui n'existe pas sous linux, je ne vois pas comment ton code windows pourrait fonctionner tel que sous Linux, et vice versa bien sûr. Il faut pour cela une couche d'abstraction, et c'est un peu ce qu'avait fait avec plus ou moins de bonheur Kylix.

Je suis d'accord, si on utilise des APIs trop proche d'un système ça ne peut pas aller. Mais la CLX était sensé fonctionner sur les deux systèmes, c'était le cas bien qu'elle soit pleine de bugs.
Ce que je voulais dire est qu'il fallait ouvrir les sources avec Kylix et les compiler pour générer le code Linux. L'idée que j'évoquais était de générer la version compilée pour linux dans Delphi sans avoir à utiliser Kylix. Je n'ai pas dis que ce serait le même exécutable mais une destination différente de compilation des mêmes sources dans Delphi.

Sous Linux, les .so ont des versions : il n'y a pas de continuité dans la compatibilité. Bilan le point de compatibilité justement, c'est le source. Avec un certain nombre de .h que l'on est plus ou moins sûr de trouver, et un gcc qui est fourni de base dans toutes les distribs.

Effectivement vu comme cela l'idée est utopique. (Note que perso je n'ai jamais vu un linux de près, dans mon boulot ça n'existe même pas), mais à ce moment là l'idée de se baser sur une couche commune comme Mono devient une alternative pour le multi-plateforme. Sauf que pour Windows ça reviens à passer par .NET et on perd notre coté natif.

**Just-Soft** · 15/12/2008, 10h45

Salut;

je suis de très près ce que vous vous échangez mais par la nature de ma formation j'ai du mal à comprendre assez vite tout ces termes !

1. je pensais depuis une belle lurette que .net voulait dire multi plate formes entre autre les autres OS;

2. pouvez-vous m'expliquer, avec simplicité, ce que veut dire et l'objectif de mono ?

Merci à vous tous.

**Paul TOTH** · 15/12/2008, 11h35

Envoyé par Just-Soft

Salut;

je suis de très près ce que vous vous échangez mais par la nature de ma formation j'ai du mal à comprendre assez vite tout ces termes !

1. je pensais depuis une belle lurette que .net voulait dire multi plate formes entre autre les autres OS;

2. pouvez-vous m'expliquer, avec simplicité, ce que veut dire et l'objectif de mono ?

Merci à vous tous.

voici qui pourra t'éclairer.

A mon avis, la portabilité de dotNet permet à Microsoft d'envisager un jour du quitter la plateforme Intel à laquelle il est lié depuis ses débuts...mais je doute que leur projet soit de permettre un développement en dehors de Windows

**rvzip64** · 15/12/2008, 13h01

euh .. si je ne me trompe pas windows n'est pas réservé qu'au architecture x86 ou x64 d'intel , je pense qu'il est aussi capable de trouver sur des processeurs alpha et autre ...

**Franck SORIANO** · 15/12/2008, 14h14

Envoyé par Paul TOTH

A mon avis, la portabilité de dotNet permet à Microsoft d'envisager un jour du quitter la plateforme Intel à laquelle il est lié depuis ses débuts...mais je doute que leur projet soit de permettre un développement en dehors de Windows

Ben si, c'est déjà le cas. Mais pas sur des plateformes qui concurrencent Windows :
- .Net est utilisé pour développer des jeux sur XBOX.
- Il sert également au développement pour les PDA.

**Paul TOTH** · 15/12/2008, 16h28

Envoyé par rvzip64

euh .. si je ne me trompe pas windows n'est pas réservé qu'au architecture x86 ou x64 d'intel , je pense qu'il est aussi capable de trouver sur des processeurs alpha et autre ...

oui mais les applis ne sont pas les mêmes...alors que si les applications Windows passent de win32/64 à dotNet, Microsoft n'a que la partie native du framework à changer

**Paul TOTH** · 15/12/2008, 16h30

Envoyé par Franck SORIANO

Ben si, c'est déjà le cas. Mais pas sur des plateformes qui concurrencent Windows :
- .Net est utilisé pour développer des jeux sur XBOX.
- Il sert également au développement pour les PDA.

pour les consoles c'est un autre problème...j'imagine que c'est surtout DirectX qui bosse

pour les PDA, on n'a de toute façon pas la même interface graphique que sur un PC classique...