IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

EDI Delphi Discussion :

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


Sujet :

EDI Delphi

  1. #21
    Membre émérite
    Avatar de Thierry Laborde
    Homme Profil pro
    N/A
    Inscrit en
    Avril 2002
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : N/A

    Informations forums :
    Inscription : Avril 2002
    Messages : 1 391
    Points : 2 529
    Points
    2 529
    Par défaut
    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.

  2. #22
    Membre habitué

    Inscrit en
    Août 2005
    Messages
    253
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 253
    Points : 197
    Points
    197
    Par défaut
    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 ?

  3. #23
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2005
    Messages
    262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2005
    Messages : 262
    Points : 665
    Points
    665
    Par défaut
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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.

  4. #24
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Points : 4 170
    Points
    4 170
    Par défaut
    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.

  5. #25
    Membre habitué Avatar de Rapha222
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    128
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 128
    Points : 168
    Points
    168
    Par défaut
    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 .
    Fedora 12 x64 (laptop) - OpenSuSe 11.2 (desktop)
    Hébergeur d'images et de fichiers (< 75Mio) gratuit et sans pub

Discussions similaires

  1. Réponses: 3
    Dernier message: 28/11/2011, 11h42
  2. Réponses: 1
    Dernier message: 21/01/2010, 15h20
  3. CBuilder dans RAD STUDIO 2009
    Par colorid dans le forum C++Builder
    Réponses: 1
    Dernier message: 22/03/2009, 21h54
  4. RAD Studio 2009 et CBuilder
    Par colorid dans le forum Débuter
    Réponses: 1
    Dernier message: 17/03/2009, 12h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo