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

Le , par Nono40, Administrateur forum
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.



Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 15/12/2008 à 13:14
Citation Envoyé par Paul TOTH  Voir le message
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.
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 15/12/2008 à 15:28
Citation Envoyé par rvzip64  Voir le message
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
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 15/12/2008 à 15:30
Citation Envoyé par Franck SORIANO  Voir le message
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...
Avatar de Aquaa Aquaa - Inactif https://www.developpez.com
le 16/12/2008 à 8:48
qu'en est-il du support XNA ?
Avatar de Thierry Laborde Thierry Laborde - Membre émérite https://www.developpez.com
le 16/12/2008 à 9:46
Citation Envoyé par Aquaa  Voir le message
qu'en est-il du support XNA ?

Cela fonctionne avec Delphi PRISM :

http://blogs.codegear.com/pawelglowa...08/12/09/38617

http://blogs.codegear.com/pawelglowa...08/12/11/38629
Avatar de Aquaa Aquaa - Inactif https://www.developpez.com
le 16/12/2008 à 16:22
tite question déplacée désolé.

y'a t-il des livres en français en cours de rédaction pour PRISM. ?

Merci
Avatar de Thierry Laborde Thierry Laborde - Membre émérite https://www.developpez.com
le 16/12/2008 à 16:35
Citation Envoyé par Aquaa  Voir le message
tite question déplacée désolé.

y'a t-il des de livre en français en cours de rédaction pour PRISM. ?

Merci

On est en train de finaliser un livre en Français sur Delphi 2009. Mais rien n'a été décidé pour le moment pour PRISM. Il y a de grande chances qu'on travaille sur quelque chose mais ça va pas être tout de suite.
Avatar de helmis helmis - Membre habitué https://www.developpez.com
le 31/12/2008 à 8:12
Citation Envoyé par Nono40  Voir le message
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.

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.

.

Et Comment il pourra être (ou est deja) natif sous Mono, puis que Mono est une replique du .net microsoft ?
Avatar de rt15 rt15 - Membre confirmé https://www.developpez.com
le 05/01/2009 à 17:59
Je pense qu'il a voulu dire :

Citation Envoyé par Nono40
l'idée de se baser sur une couche commune comme Mono/.Net devient une alternative pour le multi-plateforme. Sauf que pour Windows ça reviens à passer par .NET et on perd le coté natif que l'on a en Win32.

Multiplateforme ou natif, telle est la question...

Pour info, concernant la portabilité binaire/source en C...

Ce C standard :

Code C : Sélectionner tout
1
2
3
4
5
6
7
#include <stdio.h> 
  
int main() 
{ 
  printf("Hello world\n"); 
  return 0; 
}

Compile sous Unix ou Windows à l'aide de la commande suivante :
gcc -Wall -ansi -pedantic test.c -o test.exe

Sous Windows, le .exe est lié à msvcrt.dll et kernel32.dll (Vu avec depends). Ces dlls sont présentes sur tous les windows avec les fonctions nécessaires.

Sous Unix on peut voir les dépendances avec ldd :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
> ldd -v test.exe 
 
  find library=/usr/lib/libc.2; required by test.exe 
        /usr/lib/libc.2 =>      /usr/lib/libc.2 
 
  find library=/usr/lib/libdld.2; required by /usr/lib/libc.2 
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2 
 
  find library=/usr/lib/libc.2; required by implicit load 
        /usr/lib/libc.2 =>      /usr/lib/libc.2
La nécessité de présence de /usr/lib/libc.2 est codée en dur dans l'exécutable Unix (On la voit si on l'ouvre avec un éditeur de texte).

Sur un autre Unix, un libc.2 n'est pas forcément présente (Et pas forcément au même endroit...), et le même .c
compilé sur cet autre Unix aura besoin d'autre libs. Par exemple :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
> ldd -v test.exe 
        libc.so.6 => /lib/tls/libc.so.6 (0x00750000) 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x008a5000) 
 
        Version information: 
        ./test.exe: 
                libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6 
        /lib/tls/libc.so.6: 
                ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2 
                ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2 
                ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2 
                ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
Bilan : impossible de générer un exécutable Unix sans connaître en détail l'Unix cible. Et il faudrait probablement un binaire par version de distribution Linux... Bref, c'est un tel merdier que personne ne parviendra jamais à réaliser de la vrai cross compile, sans se connecter au machines cibles, et exécuter leurs gcc respectifs.

A noter une solution parfois utilisée pour faire du multiplateforme : produire du code C plus ou moins standard (Tout le monde à sa définition de la norme...). Genre un compilo Delphi vers du C s'appuyant sur :

Sous Unix : des headers standards (stdio, stdlib...), ou des headers systèmes courants (unistd...) et les headers X11.
Sous Windows : windows.h et quelques autres.

Ou compiler directement pour du Win32 sous Windows comme c'est fait actuellement.

Cela permettrait d'avoir des appli natives Win32 et des applis prêtes à être compilées pour le reste des plateformes. Pas besoin de machine virtuelle, pas besoin de pré-requis exorbitants sur les machines cibles... Et la rapidité du code natif consciencieusement compilé par le gcc spécifique à la plateforme.
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 05/01/2009 à 20:38
Citation Envoyé par rt15  Voir le message
A noter une solution parfois utilisée pour faire du multiplateforme : produire du code C plus ou moins standard (Tout le monde à sa définition de la norme...)
....
Cela permettrait d'avoir des appli natives Win32 et des applis prêtes à être compilées pour le reste des plateformes. Pas besoin de machine virtuelle, pas besoin de pré-requis exorbitants sur les machines cibles... Et la rapidité du code natif consciencieusement compilé par le gcc spécifique à la plateforme.

C'est le principe des machines virtuelles .NET ou Java. Ton code source est compilé vers une cible parfaitement standardisée, avec des librairies et un framework également standardisé.
Ensuite la machine virtuelle est spécifique à la plateforme sur laquelle tu l'exécutes et son compilateur est là pour produire le code natif, parfaitement optimisé en fonction de l'architecture de ta machine (32 bits, 64 bits, mono CPU, multi CPU...).
C'est comme ça que tu peux te retrouver avec du code .NET beaucoup plus rapide que son équivalent Win32. Je suis toujours ébahi devant les performances de ADO.NET, même comparée à OLEDB.

Par contre, c'est vrai qu'il existe un compilateur C sur toute plateforme sur laquelle il est possible de compiler un programme. Et pour les autres, il y a une solution en cross-compile. Ce qui est loin d'être le cas des machines virtuelles à l'heure actuelle.
Avatar de Rapha222 Rapha222 - Membre habitué https://www.developpez.com
le 06/01/2009 à 10:07
C'est sympa de voir que l'on commence à s'intéresser serieurement à Mono.
Ils sont arrivés à un bon niveau avec la version 2.0 de leur projet.
Je pense que maintenant ils veulent plus innover et ne plus se contenter de suivre ce que Microsoft fait, enfin c'est ce que j'ai rétenu de la video du speech de Miguel de Icaza au PDC2008 : http://channel9.msdn.com/pdc2008/PC54/

Il y présente quelques nouveautés assez sympatiques prévues pour Mono dont :
  • Un interpretteur en ligne de commande pour Csharp: fort semblable à ce que l'ont peut trouver sur Python. L'interpretteur permet d'executer du code just in time, et une nouveauté par rapport à l'interpretteur de Python, c'est qu'il devient possible "d'injecter" du code dans une application tournant sur la machine virtuelle, c'est vraiment très bon. Ca devrait être sur la feuille de route de C# 5.0 également (apparement les responsables de chez MS ont été impressionnés ).
  • Une classe représentant le compilateur (Mono.CSharp): ça existe déjà avec Mono 2.0. C'était nécéssaire à la construction de l'interpretteur en ligne de commande et ça permet de démarrer une instance du compilateur de Mono, dans Mono, pour compiler et évalier du code en temps réel (équivalent à eval dans les languages interprettés). Ca peut être utile pour réaliser des applications utilisant mono en intégré comme language de script (SecondLife par exemple utilise Mono pour la gestion des scripts des IA).
  • MonoLinker: C'est un outil qui vous permet de génerer votre propre compact framework (de 2Mo à 100Mo pour le framework complet) adapté au materiel embarqué.
  • Mono sur iPhone: J'ai pas tout compris mais apparement il seraient arrivés à utiliser Mono sur iPhone tout en respectant la charte pour la publication d'applications d'Apple (qui interdit tout interpretteur de language) en supprimant quelques composants du framework.

Tout ce que j'ai listé ici devrait être présent sur Mono 2.2 qui devrait sortit d'ici quelques jours .
Offres d'emploi IT
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Microsoft DotNET : Hinault Romaric -