Wine débarque bientôt

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
27
oct.
2005
Microsoft
Wine débarque en version 0.9 première version adoptant une numérotation X.Y (plutôt que les dates). Les développeurs considèrent les utilitaires et les bibliothèques Win32 comme fonctionnellement complètes.

Pour rappel, Wine (Wine is not an emulator) est un lot de bibliothèques compatibles Win32 dont le but est de pouvoir faire tourner nativement des applications Win32 sous Linux, FreeBSD et autres Unix-like en version x86. Il est aussi maintenant possible de les faire tourner sur d'autres architectures via Qemu.

NdM : merci à inico pour avoir également proposé une dépêche à ce sujet. Parmi les changements :
- disparition du fichier .wine/config au profit d'une application winecfg
- un grand nombre de DLL disponibles nativement, supprimant ainsi la majorité des besoins de DLL natives Microsoft.

À noter aussi que Crossover Office, version commerciale de Wine, vient également de sortir en version 5, qui apporte - entre autre - le support de MS Office 2003 et les nouvelles fonctionnalités de Wine 0.9.

De mon point de vue, Wine 0.9 est la version la plus stable de Wine qu'il m'ait été donné de tester : elle permet de faire tourner la majeure partie des logiciels Windows pour mes besoins professionnels : Office XP, IE 6, etc. sans avoir besoin de Crossover pour le faire.

À noter aussi que Wine travaille en collaboration avec ReactOS (système d'exploitation se voulant un clone de Windows NT, compatible aussi bien au niveau kernel que applicatif) ; la version 0.9 devrait leur permettre une compatibilité accrue avec les logiciels prévus pour l'OS de la firme de Redmond.

Aller plus loin

  • # Super !

    Posté par  . Évalué à 7.

    Bonne nouvelle !!!
    Mais je n arrive pas a trouver la version wine pour windows sur le site ?!
    ..
    ==> [ ]

    • [^] # Re: Super !

      Posté par  (site web personnel) . Évalué à 2.

      C'est vrai que c'est pratique pour faire tourner les programmes Windows sous Windows ;)

      • [^] # Re: Super !

        Posté par  . Évalué à 7.

        Oui, c'est pratique, par exemple lorsque tu as de vieux programmes non compatibles avec Windows XP, ou parfois l'inverse, faire tourner un programme prévu pour Windows XP sous Windows 9x :-)

    • [^] # Re: Super !

      Posté par  . Évalué à 10.

      Oui, c'est normal il faut utiliser cygwin :p

      • [^] # Re: Super !

        Posté par  (site web personnel) . Évalué à 6.

        Et c'est ici: http://www.winehq.com/site/fun_projects
        Titre : Virtualization Projects
        Wine under Cygwin in Windows (In Progress)

        • [^] # Re: Super !

          Posté par  . Évalué à 6.

          Eh en y réflechissant c'est pas si con : des développeurs windows pourraient vérifier que leurs applis tournent sous wine sans a voir a rebooter sous Linux.

      • [^] # moule inside

        Posté par  (site web personnel) . Évalué à 9.

        C'est pas un peu beaucoup ? Une seule ne suffit pas ? /o\

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Re: quel travail de titans !

    Posté par  . Évalué à 7.

    J'allais justement proposer une dépêche à ce sujet. Wine est vraiment un projet d'envergure, actif, dynamique. En plus, il en est vraiment à un stade avancé. Rendez-vous compte, faire fonctionner des applications comme MS Office en ayant réécrit la plus grande partie de l'API win32 !

    Enfin bon. Toujours est-il que pour ma part, je ne me sers de wine que pour faire tourner une seule application win32 : emu48 (c'est un émulateur de calculatrice hp48/49 sous license GPL). Il est dommage que ce programme ne fonctionne pas correctement avec wine en ce qui concerne la ROM de la hp49 :-/ Je suis obligé d'utiliser un autre émulateur, mais moins riche en fonctionnalités.

    • [^] # Re: quel travail de titans !

      Posté par  (site web personnel) . Évalué à 4.

      ah t'avais une dépêche, donc peut-être encore plus de matière à proposer / des retours d'expérience plus détaillés sur le sujet alors ? non ?

  • # Ben

    Posté par  (site web personnel) . Évalué à 8.

    Je veux pas faire ma mauvaise langue, mais on aura un Wine 1.0 pour la sortie de Windows Vista. En clair, quand Wine aura fini par implémenter les bibliothèques de Windows, ce dernier passera à des choses totalement nouvelles.

    Après, on peut espérer que Windows Vista soit un flop(trop de changements font fuire les utilisateurs) et que ReactOs domine le monde :)

    • [^] # Re: Ben

      Posté par  . Évalué à 10.

      c'est le probleme commun a tous les projets libres tentant d'emuler (oui, oui, je sais, Wine Is Not an Emulator) des projets de mastodontes du proprio : moins de ressources humaines car infiniment moins de pognon, donc toujours en retard et donc grosse baffe dans la gueule a chaque changement de version majeur.

      Cela dit, ca devrait deja depanner pas mal de monde d'avoir un win32 complet, donc l'effort n'es pas vain non plus.

    • [^] # Re: Ben

      Posté par  . Évalué à 6.

      Si les programmes faits pour tourner sous windows XP (par exemple) marcheront sous Windows Vista, pourquoi Wine ne suivrait pas ?

      • [^] # Re: Ben

        Posté par  . Évalué à 4.

        le probleme c'est pas tant de faire marcher les programmes XP qui devraient a priori tourner dans une certaine mesure, c'est plutot de faire tourner les porgrammes Vista, qui eux profiteront d'une nouvelle api et donc totalement pas compatible du tout avec celle de wine.

        • [^] # Sauf que ...

          Posté par  . Évalué à 4.

          ... pour ça existe Mono.

          Donc je vois pas où est le problème. Wine pour la compatibilité API Win32 et Mono pour la compatibilité API .Net.

          C'est donc un faux problème.

          • [^] # Re: Sauf que ...

            Posté par  (site web personnel) . Évalué à 4.

            Euh, faudrait un peu te renseigner sur Vista avant de parler ;)

            Quand y'aura Winfs(apres la sortie de vista) + Aero(interface) + Indigo(ipc), ben t'auras beau avoir Wine win32, ca marchera pas !

            Et je te rappelle que Mono permet de compiler(avec adaptation) un programme .Net, pas de faire tourner les executable créer avec les outils microsoft. Donc, pour ce qui interesse la majorité des utilisateurs de Wine, c'est à dire les logiciels proprio, ca t'avancera pas à grand chose Mono.

            • [^] # Re: Sauf que ...

              Posté par  . Évalué à 4.

              Et je te rappelle que Mono permet de compiler(avec adaptation) un programme .Net, pas de faire tourner les executable créer avec les outils microsoft. Donc, pour ce qui interesse la majorité des utilisateurs de Wine, c'est à dire les logiciels proprio, ca t'avancera pas à grand chose Mono.

              Ah bon ? Il m'avait pourtant semble que Mono avait une CLR, qui permettrait des lors de faire tourner les softs sans recompilation tant que les assemblies sont presentes.

              • [^] # Re: Sauf que ...

                Posté par  . Évalué à 2.

                [...]
                >>Ah bon ? Il m'avait pourtant semble que Mono avait une CLR, [..]

                Pour les incultes comme moi et peut être d'autre cest quoi CLR ?

                • [^] # Re: Sauf que ...

                  Posté par  . Évalué à 4.

                  C'est en gros la machine virtuelle qui traduit le MSIL (equivalent du byte code Java) en code executable.
                  Bref, c'est similaire a une machine virtuelle Java

                  • [^] # Re: Sauf que ...

                    Posté par  . Évalué à -3.

                    Bref, c'est similaire a une machine virtuelle Java

                    Y comprit sur les points de lourdeur et de lenteur ?

                    • [^] # Re: Sauf que ...

                      Posté par  . Évalué à 4.

                      pour la millieme fois une jvm n'est pas lente!!!
                      gourmande en ram, oui, ca c'est avere.

                      Mais ca n'est pas lent!!!
                      Java se traine cette legende urbaine qui remonte a ya plusieurs annees, mais ca n'est plus le cas!!!

                      un peu comme si on disait que le c/c++ est lent parce qu'en 89 les compilos ne suivaient pas...

                      • [^] # Re: Sauf que ...

                        Posté par  (site web personnel) . Évalué à 3.

                        Sauf que lorsque onb a déja une grande partie de la ram occupée, je suppose que ca ralentit car ca swappe et tout ... non ?

                        • [^] # Re: Sauf que ...

                          Posté par  . Évalué à 3.

                          Si ta question est :
                          Quand le systeme swap, est ce que le systeme swap?
                          La reponse est :
                          Oui, quand le systeme swap, le systeme swap.

                          Ce a quoi j'ai envie d'ajouter :
                          Pas de pierres... pas de palais!
                          Pas de palais... pas de palais!

                          Apres on va me dire :
                          Oui mais c'est de la merde, c'est pas utilisable sur une vieille machine.
                          Ce a quoi je reponds :
                          Il ne me parait pas anormal qu'une techno recente tourne mal sur une machine ancienne.

                        • [^] # Re: Sauf que ...

                          Posté par  . Évalué à 3.

                          Eclipse sur un ordi avec 256Mo de ram est inutilisable sous linux à cause de ca ...
                          Sous windows je sais pas pourquoi, mais ca passe très bien par contre
                          probablement la JVM de sun qui est à la traine sous linux ...

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 0.

                            Euh, non. J'ai développé des applis J2EE sur un duron 650 avec 512Mo de RAM, et je t'assure que ça ne se passe pas très bien. En gros, voilà comment se déroulaient les choses :

                            Eclipse + JBoss + plugins Eclipse : tourne bien au début. Après plusieurs heures de dév, de démarrage/arrêt du serveur, de chargement de diverses webapps de test, etc... La machine est inutilisable, et met parfois une bonne minute (voire plus) avant de prendre en compte un quelconque élément en entrée (clavier, souris).

                            Deux solutions pour ça : trifouiller la JVM (allocation de +/- de RAM, etc.), et ... rajouter 512Mo de RAM. Grâce à ça, on peut avoir plus de temps avant que la machine ne se mette à rammer. Et donc, je pouvais faire mes heures de bureau sans accroc. Evidemment, ce genre de "solution" n'est pas viable pour un serveur en production. Mais dans ce cas, il vaudrait mieux avoir un vrai admin, qui sache comment on configure correctement une JVM.

                            Bref. Java n'est pas lent, mais bouffe effectivement de la mémoire, et Windows semble mal gérer celle-ci, ce qui ralentit le système au final.

                            Sous linux, Eclipse est moins bien, mais au moins je n'ai jamais eu les problèmes constatés ci-dessus.

                            • [^] # Re: Sauf que ...

                              Posté par  (site web personnel) . Évalué à 1.

                              Je ne sais pas si certains ont essayés mais il existe sous win des programmes qui permettent de "nettoyer" la ram et de la libérer (rambooster par exemple). Peut-être simplement que ça permettrait de faire tourner plus simplement.

                              Sinon, quand tu dis que ecplise est moins bien sous linux ça veut dire quoi ?
                              Je fais pas trop de java mais je n'ai jamais trop ressenti de problème avec ecplise...

                              • [^] # Re: Sauf que ...

                                Posté par  . Évalué à 3.

                                Je ne sais pas si certains ont essayés mais il existe sous win des programmes qui permettent de "nettoyer" la ram et de la libérer (rambooster par exemple). Peut-être simplement que ça permettrait de faire tourner plus simplement.

                                Ces softs sont une escroquerie, aucun de ces softs n'est capable de liberer de la RAM sur W2k/XP/WS03

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 1.

                            eclipse utilisable avec 256 sur windows?
                            Je suis sceptique quand meme..

                            512 ca roule, je me tape generalement un freeze de 10-15 secondes juste apres le demarrage, apres ca tourne toute la journee sans aucun probleme.

                            • [^] # Re: Sauf que ...

                              Posté par  . Évalué à 0.

                              Sous FreeBSD en tout cas je l'ai fait cet été. Et en laissant Eclipse d'un jour sur l'autre!

                              Certes, c'était pas comme mon desktop à la maison avec 1Go de ram ...

                      • [^] # Re: Sauf que ...

                        Posté par  . Évalué à 5.

                        lol, la bonne blague :)

                        En fait si je te lis au pied de la lettre ce que tu dis est vrai : la JVM n'a rien de lent (ce qui tourne dedans si par contre ;)

                        C'est pas parce qu'une machine de base actuelle (du genre PIV à 2GHz avec 1 Go de RAM) peut faire tourner une petit IHM en Java sans que le tout rame que ça veut dire que Java est rapide. La lenteur (toute relative donc selon le contexte), n'en est pas une tare pour autant, l'interet de Java est ailleurs. Le jour ou Java servira à écrire des codes de calculs je voudrais bien croire qu'"il est rapide" (si tant est que "il est rapide" à un sens, vu que tout dépend bien evidemment du contexte etc...)

                        Bon ceci étant si on compare aujourd'hui un soft en Java bien codé et un bloatware à la Gnome, KDE, OOo, ou FF, effectivement Java peu sembler carrement très rapide (voir même économe en mémoire :))

                        De toute façon le débat n'a pas de sens tant qu'on compare des tomates et des carottes. Il faudrait écrire de gros soft de calcul en Java et en Whatever (avec la même architecture, les mêmes algorithmes, etc) pour pouvoir comparer "la vitesse", ça risque fort de ne jamais se faire, donc on en restera à des trolls (comme le mien, j'avoue) et des approximations, ainsi que des incompréhension mutuelle dues à un contexte différent dans la tête des interlocuteurs.

                        • [^] # Re: Sauf que ...

                          Posté par  (site web personnel) . Évalué à 1.

                          je crois que ce qu'il voulait dire (et qu'il a dit dans un autre commentaire, ou en tout cas je l'ai lu il y a pas longtemps...) c'est que java en tant que langage n'est pas beaucoup plus lent qu'un langage compilé, essentiellement grace au JIT.
                          Par contre ce qui est très lent et très mal fait sont les interfaces, SWING est horrible, SWT un poil mieux mais associé à une jvm moins bonne sous linux que sous windows on arrive à une horreur.

                          Donc en gros si on avait un toolkit graphique digne de ce nom sous java, l'impression de lenteur serait beaucoup moins présente.

                          Enfin, c'est ce que j'ai pu comprendre, allez voire dans la news OOo ça doit êter là le débat je crois... ;-)

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 3.

                            Mwai enfin dès que tu lis les manuels d'intel tu as de très gros doutes sûr la capacité d'un JIT quel qu'il soit à produire le summum de l'efficacité. Des perfs pas trop nulles, voilà ce à quoi on peut s'attendre, et c'est déjà pas mal finalement. Mais de là à concurrencer du code produit par ICC avec les sections critiques parrallélisé et vectorialisées, du prefechting et conseil de branchement conditionel produit par profiling et autre, j'ai un léger doute.... Sans même compter de l'hyperthreading dont l'interet peut énormement varier selon l'archi générale (pouvant même aller jusqu'à la diminution des perfs dans des cas patologiques)

                            Pendant que les VM ont fait des progrès non négligeable, les compilo classiques aussi. Et les processeurs sont devenus d'une grande complexitée. Et ce n'est pas parce que "c = a+b" Java va être traduit en "add %eax, %ebx" par du JIT à un moment donné que l'ensemble va atteindre ce qu'on sait faire de mieux en terme de performance.

                            • [^] # Re: Sauf que ...

                              Posté par  . Évalué à 1.

                              « Pendant que les VM ont fait des progrès non négligeable, les compilo classiques aussi »

                              Bouais. Beaucoup moins. Et le JIT de Java permet clairement bien plus d'optimisations que ce que tu sembles dire. Attention, je ne dis pas qu'on obtiendra au final quelque chose d'optimal, mais certainement pas aussi "mauvais" que ce que tu sembles croire (même si tu rappelles bien que les perfs obtenues sont déjà pas mal ;-) ).

                              Je ne suis pas un fan absolu de Java, mais les JVM avec JIT sont très bien pensées, et le langage permet vraiment beaucoup de choses au niveau optimisations... Ah, si seulement il était libre ...

                              • [^] # Re: Sauf que ...

                                Posté par  . Évalué à 1.

                                le JIT de Java permet clairement bien plus d'optimisations que ce que tu sembles dire.

                                C'est juste qu'il manque encore un "-Os"

                                et le langage permet vraiment beaucoup de choses au niveau optimisations

                                c'est la première fois que je l'entend celle-là !

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 2.

                            voila, c'est exactement ca.
                            SWT tourne tres bien sous windows, en etant reactif. Mais la lib n'est pas encore mure, ils y sont presque, je pense qu'on aura un SWT parfaitement mur pour la version 5 (estimation pyfometre total).
                            SWING peut tourner a peu pres decemment, mais ca reste un gros bouzin immonde.

                            Et pour ce qui est du calcul pur, j'ai fait un bench (rapide) fortran/java 1.4 de code de calcul scientifique (simulation numerique pour l'armee), java etait 1.3 fois plus lent que le code fortran.
                            Je suis pas sur que le C++ aurait ete tellement plus rapide.

                            Le code a ete porte a l'arrache de chez arrache, en utilisant systematiquement des objets au lieu des types de bases.
                            Et en utilisant java5, on devrait pouvoir encore diminuer cet ecart, et plus encore en adaptant le code au langage.

                            Ce qui fait perdre du temps, c'est le lancement de la jvm, ca s'est grandement ameliore avec java5, faut que la transition se fasse quoi.

                            Regarde une appli comme eclipse, c'est un truc monstrueux qui fait enormement de choses en meme temps et reste pourtant tres reactif et pas si gourmand que ca au vu de tout ce qu'il fait (je tourne generalement dans les 100-150Mo d'occupation, avec 4 projets ouvert, lomboz/tomcat en plugin, 20 a 30 jars de dependances par projet et quelques dizaines de milliers de lignes de code en tout)

                            Regarde tomcat qui supporte de grosse charges sans broncher, et pourtant c'est pas les I/O qui manquent sur un serveur d'appli (entre les logs, les IO reseau, les connections DB etc..)

                            • [^] # Re: Sauf que ...

                              Posté par  . Évalué à 3.

                              jette un oeil ici pour voir ce que le bousin immonde peut donner quand on sait y faire : http://jroller.com/page/gfx

                        • [^] # Re: Sauf que ...

                          Posté par  (site web personnel) . Évalué à 3.

                          l faudrait écrire de gros soft de calcul en Java et en Whatever (avec la même architecture, les mêmes algorithmes, etc) pour pouvoir comparer "la vitesse"
                          Comme ça ? http://shootout.alioth.debian.org/

                          J'ai l'impression que la lenteur de Java est surtout due au temps que met la JVM à se lancer. Ce qui semble provenir du fait qu'elle doit allouer plein de mémoire. Pour une application serveur c'est pas forcément grave mais pour des "petites" applications qu'on lance/arrète souvent et quand on doit développer sur une "petite" machine c'est l'enfer.

                          Tiens tant qu'on est dans les trolls sur Java, quelqu'un peut m'expliquer l'intérêt de générer des .class ? Ca serait pas plus pratique que la JVM utilise directement les .java ? Les .class sont quand même parsés et vérifiés de toute façon. Ou bien j'ai rien compris.

                          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 5.

                            Ça te fera de la peine si je te réponds que t'as rien compris ?

                            C'est tout l'intérêt d'une machine virtuelle : le .class est un code machine, il suffit de l'exécuter (= le traduire en code machine réelle), le .java est à interpréter (= à « comprendre », analyser...).

                            • [^] # Re: Sauf que ...

                              Posté par  . Évalué à 2.

                              sans compter que le .class est compilé, donc syntaxiquement et semantiquement correct, optimise et legerement preprocesse (genre l'autoboxing de java5)

                        • [^] # Re: Sauf que ...

                          Posté par  . Évalué à 2.

                          Euh, tu sais qu'il existe des softs de calcul en Java hein ? :-) Je veux dire, de vrais softs. Avec des multiplications de matrices, tout ça. Et ils s'en sortent plutôt bien. Attends, je vais te retrouver ça...

                          Voilà :

                          « Java Signal Processing : FFTs with bytecodes » (John Glossner, Jesse Thilo, Stamatis Vassiliadis). Le papier date de 98, et depuis Java a fait pas mal de progrès dans le domaine de l'optimisation en temps (en espace - donc en mémoire - c'est autre chose). Pour te résumer l'article, faire des transformées de Fourier rapides avec Java, c'est faisable. L'expérience avait été faite sur des Ultra-Sparc II avec 128Mo de RAM, avec Java 1.1.4 (sur diverses JVM) et comparé avec gcc 2.7. Au final, Java est en moyenne 2 à 3 fois plus lent qu'un code C optimisé. Mais c'était en 98. Depuis, on a encore largement amélioré les optimisations concernant Java (et aussi celles concernant C avec GCC, mais moins -- les efforts à partir de GCC 3 sont bien plus concentrés sur C++).

                          « Developing numerical libraries in Java » (Ronald F. Boisvert, Jack J. Dongarra, Roldan Pozo, Karin A. Remington, G.W. Stewart). Résultats (là encore, il ne faut pas oublier qu'on est en 98) : oui ben, y'a plein de trucs bien en Java, mais bon, quand même, c'est pas la panacée, y'a plein d'autres trucs qui manquent, du coup il faut faire plus d'effort quand on est programmeur pour avoir de bons résultats. Mais les travaux sur le JIT ont l'air intéressants, ça devrait booster les résultats.

                          Et miracle, c'est le cas.

                          Dernière chose, je te conseille de mater à cette adresse : http://shootout.alioth.debian.org/benchmark.php?test=all&(...)

                          Tu y verras entre autres les différents résultats obtenus par des benches dans le domaine du calcul [1]. Et que Java se situe devant g++ et le compilo c++ d'intel.

                          Mais à part ça, Java, c'est lent.


                          [1] évidemment, il en faut pas oublier ce que dit l'auteur sur le site, à propos des biais qu'on trouve dans ce genre de tests.

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 6.

                            Hélas, 1000x hélas, pas beaucoup de calcul numérique sur ce site (site qui a déjà été cité plus haut) (du moins tel que je l'entend, les FFT cadrant très bien avec ce que cela veut dire dans cet esprit). De l'algorithmie, certes, mais du calcul, quand il y en a, Java se fait ramasser. Jave reste derrière C (ce qui n'est guère étonnant). Étant donné la structure des tous petits tests proposé, un bon gros calcul numérique bien barbarre ferait fondre la différence C, C++ (d'ailleurs quand on entre dans ce domaine dans les tests précités, le C++ repasse largement devans Java et reste ultra proche de C). De toute manière le classement final dépand des coefficiant, on pourrait augmenter les perf du C++ en ajoutant des options de compilation (mais qui ne serait pas forcement utilisable en prod selon le contexte, donc faut-il le faire ou non?). Bref le lien me montre que Java est lent (même s'il y a pire).

                            Mais on peut faire dire n'importe quoi aux bench, non ? Donc autant les oublier completement, why not...

                            Je me rappele un soft de FTP distribué en Java qu'on avait écrit en projet de 2è année d'école d'info. Il utilisait un calcul MD5, et au début on avait pas trouvé la routine de la biblio standard qui permet de faire ça, donc on avait pris un code source Java qui avait été écrit au temps ou le calcul de MD5 n'était pas encore en standard dans la biblio. Les performances étaient, JIT ou pas JIT, horrible. N'importe quelle routine en C même écrite n'importe comment explosait litteralement le pauvre code source Java d'un rapport au moins x4 (j'ai plus les chiffres exactes en tête, mais à mon avis c'étais plutôt x10). Et à chaque fois que j'essaie la bête opération de prendre un gros bout de code C absolument bête, linéaire, etc, et que je le porte en Java tel quel (impossible de faire autrement qu'une bête recopie + adaptations ultra minimal de toute façon vu comment le code est bête), et que je fais un bench, ben j'ai la confirmation que Java c'est lent. Et je ne parle même pas des perfs qu'on peut atteindre en asm avec un code vectoriel. Dès qu'on a utilisé la routine fournis avec la JVM, les choses sont devenues correctes. Bref, quand Java est "rapide" en calcul numérique (et ça reste relatif, le "rapide"), c'est que les implémentations des routines de calcul critiques en question sont écrites en C.

                            Java n'est pas mauvais quand il s'agit de faire de l'algorithmie. Par contre je n'appele pas être 3x plus lent s'en sortir bien en matière de calcul numérique, domaine par excellence ou l'on veut tout tirer du processeur, jusqu'à qu'il en puisse plus (en utilisant les optim que j'ai citée plus haut et d'autres, dont certaines sont inaccessibles par nature à Java). Java ne permet pas de faire ça. En matière de calcul numérique, je persiste Java est lent.

                            En matière d'IHM aussi, Java est très lent. Pas besoin de faire des bench, suffit d'utiliser une appli pour ce rendre compte à quel point ça rame (ou alors c'est juste une coincidence et toutes les appli que j'utilise en Java rament ? De toute manière c'est vrai que je dois être mauvaise langue, si ça se trouve ce n'est pas Java mais mon ordi qui est lent, et ouai les gens qui ont des P12 à 20THz ne doivent pas trouver les appli dotées d'IHM et écrites en Java particulièrement lente ;)

                            Je ne vois pas pourquoi malgré l'évidence les défenseurs de Java omnubilés par ce langage n'arrivent pas à reconnaitre qu'il est par nature plus lent que le C dans enormement de domaines. Ça n'a rien de honteux, ça n'en fait pas un langage pestiféré, et il a d'autres qualités. Python aussi est lent, Perl est lent, bash est lent (si tant est que dire que bash est lent ait un sens) et alors ?

                            Bref à l'heure actuelle implanter les routines de calculs critique en Java n'a pas trop d'interet et cela va pas changer du jour au lendemain (ni même en 1 an).

                            Pour un langage à VM, Java s'en sort vraiment pas mal, j'en conviens (grâce au JIT justement). Ça n'en fait pas un foudre de guerre. Java reste plus lent que d'autres.

                            • [^] # Re: Sauf que ...

                              Posté par  . Évalué à 2.

                              A propos du md5, je te conseille le site suivant :

                              http://www.twmacinta.com/myjava/fast_md5.php

                              "The very surprising (for me) thing to note is that the Fast MD5 implementation outperforms the native "md5sum" (textutils-2.0.14-2.i386.rpm ) binary even when the native methods aren't used"

                          • [^] # Re: Sauf que ...

                            Posté par  . Évalué à 2.

                            En haut du benchmark que tu indique on lis:

                            « And remember, languages that implement more benchmarks will move to the top of the list, and those with many missing benchmarks (No Program, Error, Timeout) will stay at the bottom! »

                            Or il manque 4 benchs seulement pour Java, mais il en manque 9 pour g++ et 11 pour i++.

                            Parce que bon, c#/mono qui pulvérise intel c++ bofff...

                            Donc tout ce qu'on peut déduire de ce benchmark, c'est que pour les tests effecutés, java est le plus lent parmi les language pour lesquels il ne manque que 4 progs de bench. Derrière Pascal (!), Ocaml, forth, Haskell et Ada95.

                      • [^] # Re: Sauf que ...

                        Posté par  . Évalué à 2.

                        pour la millieme fois une jvm n'est pas lente!!!
                        gourmande en ram, oui, ca c'est avere.

                        Il consomme tellement de ram (qu'il faut allouer au départ, c'est pas rapide) que les ordinateurs personnels sont considérablement ralentis: surexitation de la vm, eventuelle swappage de furieux etc. Et le temps d'initialisation de toute cette mémoire (et de la jvm) est très long.

                        Bref, au fur et a mesure que le temps passe, les devs java trouvent de nouvelles belles techniques objet, et ajoutent des couches d'abstractions qui font que les applis sont toujours plus gourmandes. L'évolution de la puissance du matériel domestique ne suffit pas à endiguer l'évolution des libs java.

                        Java sur un poste de travail domestique (je veut dire: tout sauf un serveur):
                        - relancer les applis très souvent (vs prgm résident, sur les serveurs): lourd
                        - pas beaucoup de mémoire (vs plusieurs gigas sur les serveurs): lourd

                        Lance OOo à froid, mesure le temps de chargement. Puis décoche toutes les options java, redémare la machine et relance OOo à froid. J'ai fait cette expérience, et il faudrait vraiment etre de mauvaise fois pour ne pas reconnaitre l'influence nefaste de Java sur une appli déjà pas favorisée.

              • [^] # Re: Sauf que ...

                Posté par  (site web personnel) . Évalué à 1.

                Ah bon ? Il m'avait pourtant semble que Mono avait une CLR, qui permettrait des lors de faire tourner les softs sans recompilation tant que les assemblies sont presentes.
                Le problème c'est que les API sont pas toutes implémentables, pour des raisons de brevets.

                • [^] # Re: Sauf que ...

                  Posté par  . Évalué à 2.

                  De ce que je vois, ca ne semble pas gener Mono, et MS ne semble pas s'en plaindre non plus.

            • [^] # Re: Sauf que ...

              Posté par  . Évalué à 4.

              99% des exportations de NTDLL.DLL et de KERNEL32.DLLl de Windows 2000/XP sont présentes dans leur version "Vista", et il y en a très peu de rajoutée. Au pire, les programmes "Vista only" utiliseront des DLL specifiques, mais au final l'interface avec le noyau restant quasiment inchangée, ca ne fera que des DLL de plus à rajouter dans la liste des DLL à developper pour la team WINE. Au pire pire, pour les sans scrupule, les DLL de microsoft pourront etre utilisées tel quel.
              Enfin bon, je doute que Microsoft casse la compatibilité avec XP avant un bout de temps.

              Sinon pour .NET, tous les binaires compatibles .NET 1.1 SP1 que l'on m'a passé ont fonctionnés normalement avec mono (maintenant p-e qu'ils n'utilisaient pas d'API .NET très exotiques)

          • [^] # Re: Sauf que ...

            Posté par  (site web personnel) . Évalué à 5.

            Je crois pas que Mono se soit donné comme objectif de supporter les API spécifiques Windows.

      • [^] # Re: Ben

        Posté par  . Évalué à 2.

        Je fonctionne sous Win 2000, que j'ai acheté, et je n'ai pour l'instant trouvé aucun programe qui ne fonctionnait pas sous Win 2000, donc le temps que Vista s'impose vraiment, WINE aura eu le temps de suivre.

        • [^] # Re: Ben

          Posté par  (site web personnel) . Évalué à 3.

          Euh, tu sais, Windows Vista, il est pas encore sorti ;)

          Mais t'inquietes, Microsoft a tout prévu, les technologies de Vista seront dispo pour les versions précédentes de Windows, comme ca, les programmes récent tourneront sous Xp & co.

          Après, je sais pas comment Microsoft pense gérer la phase de transition, parce que Vista impose de grand changement niveau IHM, et ca risque d'être un beau bordel au début, pire que la transition gtk1 vers gtk2.

          http://www.bentuser.com/FileRepository/c655ca0d-740f-4a1f-98(...)

          • [^] # Re: Ben

            Posté par  (site web personnel) . Évalué à 2.

            Euh... Windows vista a part directX 10 sera toujours du w32sdk ... Donc compatible W2k,wxp, se sera l'ajout de fonction via .NET.

            de plus d'une version de windows a une autre il ajoute des fonctions dans le w32sdk donc il ya fort a parier qu'il yaura une extension du w32sdk.

            A part si il passe tout les anciens programme en emulations il sont obliger de garder le w32sdk meme si il change certaine routine dans leur travail de fond la plupart voir toutes auront les meme structures... A part les nouvelles fonctions mais qui seront pas utilisé dans les anciens programme.

    • [^] # Re: Ben

      Posté par  . Évalué à 3.

      C'est pas trop grave, la majorité des gens ne va pas passer à Vista. Et Wine sera la pour faire tourner les vieux programmes antiques.

      • [^] # Re: Ben

        Posté par  . Évalué à 2.

        C'est clair. Tout ce que je lui demandes c'est de continuer a faire tourner la série des Baldur's Gate et de rajouter (bientôt ? :) la série Total War (Shogun, médieval). Ça, ce serait le pied.

        Un grand merci aux développeurs pour ce boulot souvent décrié.

  • # ReactOS ?

    Posté par  . Évalué à -5.

    À mon avis, voilà un truc débile. Car à ma connaissance la documentation technique de Windows est secrète (NFS par exemple). Déjà que la tâche de Wine et de Mono est titanesque et périlleuse. Alors comment peuvent ils cloner Windows NT? L'approche de Qemu me semble de loin la meilleur et la plus simple. Enfin si ça les occupe.

    • [^] # Re: ReactOS ?

      Posté par  . Évalué à 6.

      >(NFS par exemple)

      Il fallait comprendre NTFS non ?

    • [^] # Re: ReactOS ?

      Posté par  . Évalué à 2.

      Car à ma connaissance la documentation technique de Windows est secrète (NFS par exemple).
      Et alors pourquoi veux tu utiliser du NTFS ?
      Tu crois que les appli windows comme Office regarde sur quel fs il tourne ?

      Non ils font comme pour ndiswrapper, java, mono, ... il reimplemente toute l'API windows dont une grande partie est detaillé sur msdn...

      • [^] # Re: ReactOS ?

        Posté par  . Évalué à -9.

        NTFS est le système de fichier de NT. Donc NT sans NTFS c'est pas NT. Et il y a surement des applications lié à NTFS.

        • [^] # Re: ReactOS ?

          Posté par  . Évalué à 5.

          Des applis liées à ntfs ?
          Si ils utilisent les APIs win, les API réécrites peuvent utiliser autre chose que ntfs.
          Si pas, j'leur ferais pas trop confiance sous un vrai NT !
          De toutes facons, tout ce boulot, c'est pas vraiment pour faire tourner les programmes de defrag pour NT !!

      • [^] # Re: ReactOS ?

        Posté par  . Évalué à 1.

        il reimplemente toute l'API windows dont une grande partie est detaillé sur msdn..
        Là j'ai des doutes. Si il y a des tractations avec Bruxelles à propos de la documentation de Windows. C'est que tout n'est pas divulgué!

        • [^] # Re: ReactOS ?

          Posté par  . Évalué à 5.

          et s'il a ecrit "dont une grande partie", c'est qu'il est au courant du probleme, non?

    • [^] # Re: ReactOS ?

      Posté par  (site web personnel) . Évalué à 4.

      C'est en bonne voie.
      Et puis c'est un moyen d'avoir un OS win32 stable :D

  • # Complet ?

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Si c'est complet, pourquoi est-ce que tous les programmes windows ne fonctionnent pas ?

    Question innocente, honnêtement, je n'essaie pas de dénigrer ce travail.

    Le seul programme que j'aimerais pouvoir faire tourner sous Wine, c'est Operation Flashpoint. Le seul truc qui me manque vraiment de mes années windows. Qqn l'a fait fonctionné ?

    Mes livres CC By-SA : https://ploum.net/livres.html

  • # question pour s'amuser

    Posté par  (site web personnel) . Évalué à 5.

    Mon fils qui n'en est pas à sa première compilation de wesnoth demande :
    <<s'il est envisageable de lancer wine dans cygwin, peut on aussi lancer cygwin dans wine?
    Et combien de fois peut on jouer à en mettre des couches comme ça?>>

    Je ne dis pas que c'est utile, mais ça peut être marant à faire.

  • # performances

    Posté par  . Évalué à 2.

    Une question toute conne :

    Si wine n'est pas de l'émulation, ça veux donc dire que si les bibliothèques win32 sont aussi bien faite que celles de windows, il est aussi rapide de faire tourner un programme sous wine que sous windows. C'est ça ?

    et es-ce qu'elle sont aussi "bien" faites ?
    je veux dire, aussi rapide

    il sagit pas de troller, mais ça m'interroge.
    et même si c'est pas aussi rapide, c'est déja super que ça marche...

    • [^] # Re: performances

      Posté par  . Évalué à 1.

      Aussi rapide, ben non forcément...
      Si c'est win, c'est l'api native (=> difficile d'être + proche du système)

      Si c'est du wine pour linux, faut exécuter les api linux qui vont faire l'équivallent, et ca n'est pas forcément fait en une seule fonction équivallente.
      Exemple : si Direct3D demande un rectangle, pour wine, ca entrainera un démarrage d'OpenGL pour faire l'équivallent, ce qui ne se fait pas forcément de la même manière et donc implique une exécution plus lourde de par la "traduction".
      En fait, c'est considéré a peu près comme des lib classiques.

    • [^] # Re: performances

      Posté par  (site web personnel) . Évalué à 3.

      De temps en temps, tu as des applications qui sont plus rapide sous wine que sous windows.
      Sinon generalement c'est legerement plus lent ...

      • [^] # Re: performances

        Posté par  . Évalué à 2.

        Je me souviens avoir écrit un programme (un peu intensif pour ma machine de l'époque) sous scilab.
        C'était du temps où j'avais encore les deux systèmes sur ma machine, et du coup, je n'avais plus de place sur la partition linux pour installer scilab. J'avais donc installé la vesion windows, et je faisais macer sous windows.
        Un jour, j'en ai eu marre, et j'ai lancé le programme sous scilab sous wine. Je m'attendais réellemnt à mettre lamachine à genoux, mais j'étais désespéré.

        Ca tournait très bien. En fait, en mesurant le temps passé dans l'algo, on trouvait que scilab sous wine était de l'ordre 5 fois plus rapide que scilab sous windows.
        Même mi je n'en revenait pas.

  • # ah ! ... d'accord !

    Posté par  . Évalué à 0.

    mais ça sert à quoi d'utiliser des logiciels win sous linux. Autant retourner sous windows. Enfin, l'intérêt m'a l'air tellement petit que je vois pas l'utilité d'essayer.

    • [^] # Re: ah ! ... d'accord !

      Posté par  . Évalué à 4.

      Après avoir scalpé le semblant de troll que j'ai cru apercevoir au fond de ta question, je peux y répondre en toute sécurité:

      mais ça sert à quoi d'utiliser des logiciels win sous linux

      Basiquement ca sert à utiliser des logiciels win sous linux. Comme par exemple quand on veut utiliser un programme qui n'existe que sous windows (tu trouveras des exemples de programmes tout au long de ce journal).

      Mais ca peut aussi servir dans une multitude de cas, qui varient selon tes besoins et ta curiosité. Si je prend mon cas personnel:
      - faire tourner msn messenger pour avoir un support son/webcam
      - lancer itunes parceque meme si c'est pas libre et trop gourmand l'interface rox
      - s'amuser a comparer la vitesse d'execution du meme programme sous les deux os et perdre lamentablement son temps
      - lancer le solitaire

      Je n'oublie pas tous les utilisateurs pour qui au contraire de moi wine est un spectaculaire moyen de gagner du temps et de la productivité (car pas de reboot forcé), tous ceux qui vont pouvoir se séparer de leur multiboot, et aussi toux ceux pour qui wine est un excellent argument pour faire une transition win/linux en douceur.

      • [^] # Re: ah ! ... d'accord !

        Posté par  . Évalué à 1.

        Effectivement, l'argument de la transition me semble être celui qui tient le mieux la route.

        A part ça, ça reste un forum dont le but est l'expression et le partage d'avis personnels. Et un avis qui amène à une réaction est toujours plus intéressant qu'un autre.

        Merci pour ta réaction.

        • [^] # Re: ah ! ... d'accord !

          Posté par  . Évalué à 4.

          Et d'ailleurs, même pour les extrémistes du libre, je tiens à dire que dans mon cas, j'essaye d'utiliser un programme libre (sous license GPL) qui a été écrit pour Windows et sans soucis de portabilité. Ce n'est pas parce qu'un programme est écrit pour un système propriétaire qu'il est nécessairement non libre.
          D'ailleurs, il semble qu'il existe pas mal de logiciels libres de très bonne qualité écrits pour Windows uniquement. Je dis « il semble » parce que j'en ai croisé quelques uns que je n'ai pas eu l'occasion de tester, ne possédant pas le système d'exploitation de Microsoft.

          • [^] # Re: ah ! ... d'accord !

            Posté par  . Évalué à 0.

            En fait, ce que je voulais dire, c'est qu'il me semble que la quantité et la diversité de programmes existant pour linux est relativement étendue pour rendre l'utilisation de Wine quasiment inutile. Sans vouloir dénigrer l'utilisation de windows et du libre sous windows.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.