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

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/12/2008, 16h35
Thierry Laborde

Citation:

Envoyé par Aquaa

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.
31/12/2008, 08h12
helmis

Citation:

Envoyé par Nono40

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 ?

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:

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:

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:

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.

05/01/2009, 20h38
Franck SORIANO

Citation:

Envoyé par rt15

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.
06/01/2009, 10h07
Rapha222
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 :D).
- 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 :king:.

Voir 40 message(s) de cette discussion en une page