CDG Contre Apple.. - Page 3

Je sous-entendais que Mr parle beaucoup sans bien connaître de quoi il en retourne.

Pas nécessaire de faire des commentaires comme ça hein. J'ai rien fait d'autre que donner mon avis parce que je pense qu'il est fondé (en plus je me suis fait chier à développer sur un long post). Si j'ai tort, ok, mais si c'est pour recevoir des réponses du style "non", ça va rien faire avancer...

Mais en l'occurrence il avait pas tord... Et oui il n'y a besoin d'aucune connaissance en linux pour comprendre le fonctionnement de Wine... Et oui il fonctionne sur d'autres OS...

Les benchs ont tort? Mais t'as pas compris ce que je voulais dire alors, ou tu t'es arrêté à la phrase "je connais rien à linux"?
Je n'ai pas contredit les benchs, j'ai bien dit que c'était toujours possible que tu aies de meilleures perfs du moment que l'API implémentée par l'hôte (Wine) est meilleure que celle de l'invité (Windows)
Vu que t'as pas compris je vais prendre un exemple différent. Mettons que je veux émuler une unité de division hardware qui prend 200 cycles pour faire division, et que mon émulateur peut la remplacer en faisant une division software en 150 cycles, ben il sera plus performant que le hardware original et le soft émulé obtiendra de MEILLEURES performances à ce test... c'est exactement le cas des benchs faits sur Wine. Maintenant en imaginant que ton proço a une instruction division qui prend un cycle, le coup de la division hardware qui implique une merde du style (je le fais en 68k pour toi, et là je peux dire que je n'ai jamais fait d'ASM 68k, le principe reste valable):

  lea IO_BASE, a0
  move.l d0, REG_DIVRS(a0)
  move.l d1, REG_DIVRT(a0)
  bset #DIV_START, REG_DIVCNT(a0)
wait_until_complete:
  btst #DIV_BUSY, REG_DIVCNT(a0)
  bne wait_until_complete
  ; On va dire que RS contient le résultat, même si ça change rien
  move.l d0, REG_DIVRS(a0)

Bref même dans le cas où mon émulateur est parfait et que chaque instruction prend 1 cycle à être émulée, la division prendra au minimum 6 ou 7 cycles au lieu de 1 car son implémentation ne correspond pas à la couche inférieure.

Mais sauf que Wine ne fait pas du tout d'émulation. Il implémente simplement l'API Win32

Ca ne change rien (je prenais la division comme un exemple simple, on s'en fout finalement quel est le hard derrière, ce qui importe c'est le résultat que l'appli haut niveau attend). Les fonctions "windows" doivent être "traduites" pour "linux". M'enfin je pense que c'est inutile de se marcher dessus, j'ai été analyser un peu le code d'un ou deux modules (notamment gdi) et c'est exactement ce que je pensais. Après peut être qu'on se comprend mal et que j'appelle ça "émulation haut niveau" à tort, mais je vois pas ce que vous avez fait pour me prouver que j'ai tort à part faire ressortir les phrases où j'étais pas sûr de moi... (je dois vraiment m'améliorer à ce niveau d'ailleurs, merci )

C'est une implémentation de l'API Win32. Pas d'émulation.

Si c'est une "implémentation", les fenêtres win32 sont affichées avec l'interface native linux... (Déjà y'en a pas c'est bien parti)
Ce n'est pas le cas donc ce n'est pas (juste) une "implémentation"...

Bein si... vous savez ce que veux dire implementer?

Wine utilise X pour les dessins. Mais sous windows aussi l'affichage de fenêtre nécessite du code hein... C'est pas comme si tout ça devenait magiquement câblé dans le processeur quand on démarre windows. Il n'y a donc pas "d'instruction" windows à "traduire" (émuler) en "instruction" linux.
Au passage, Wine n'est utilisable que sur les processeurs de la famille x86 puisqu'il n'effectue aucun "traitement" sur les instructions exécutées. En fait, il existe une sorte de version pour PowerPC Mac, mais elle utilise QEMU pour émuler l'architecture x86 (et là tu peux parler d'émulation, pas de pb).

Ben sous Windows l'affichage des fenêtres utilise justement... l'API windows, pas besoin ensuite de passer par X.
Sous Windows: Appli > API Windows > Driver.
Sous Linux: Appli > API Windows > X > Driver.
Du coup forcément vu que t'as une étape de plus c'est pas optimal vu que l'API windows ne se mappe pas 1:1 sur celle de X.
Ca revient à ce que j'ai dit sur OpenGL: imagine que OpenGL soit obligée de passer par DirectX pour communiquer avec le GPU (parce que le GPU a été implémentée avec ce seul protocole en tête ou parce que l'OS y interdit l'accès direct), les performances seraient forcément moindres. Après c'est vrai qu'on peut toujours parler d'implémentation d'OpenGL à ce moment puisque c'est transparent pour l'utilisateur, mais bon ça ne change rien au fait que c'est pas optimal.
J'ai fait un truc similaire ("traduction" API PSP => OpenGL + Win32 pour pouvoir dév sur PC) et j'appellerais pas ça "implémentation". Ca peut se discuter, mais je trouve que c'est pas adapté vu que c'est lent à mourrir car sur pas mal de points je dois vraiment "émuler" les particularités de la PSP (d'ailleurs j'ai souvent entenu que Wine doit émuler des bugs et failles de Windows).

Sous Linux: Appli > API Windows > X > Driver.

Pour les fenêtres, c'est assez vrai. Mais je suis quasi-certain que malgré cette surcouche, on peut trouver certaines opérations du GUI (hors DirectX/OpenGL, donc) pour lesquelles Wine sous Linux, avec drivers propriétaires (évidemment, sinon on compare des pommes et des oranges), est plus rapide que Windows.
Peut-être à cause d'une lenteur quelque part dans Windows (on sait qu'il y en a, cf. les benches de Wine...), mais aussi parce que contrairement à Windows, Wine et le serveur X peuvent être compilés spécialement pour la micro-architecture du processeur sur lequel ils tournent. Et ça, ça fait une différence jusqu'à plusieurs dizaines de %. Ca m'étonnerait que Windows XP contienne du code spécialement compilé pour Core et Core 2, micro-architectures bien postérieures à la sortie de XP SP2. Et XP SP3 ne peut pas contenir le code complet pleinement optimisé pour toutes les micro-architectures sur lesquelles il va tourner: ça coûterait beaucoup trop cher en place.

magine que OpenGL soit obligée de passer par DirectX pour communiquer avec le GPU (parce que le GPU a été implémentée avec ce seul protocole en tête ou parce que l'OS y interdit l'accès direct)

(Le bruit avait couru à un moment que c'est exactement ce que Microsoft ferait pour Vista - http://slashdot.org/article.pl?sid=05/08/06/177251&tid=109&tid=152 - mais il semblerait que ça n'ait pas été fait, ou du moins, qu'un contournement ait été pris en compte avant la sortie de Vista: http://www.opengl.org/pipeline/article/vol003_7/ , http://www.opengl.org/pipeline/article/vol003_9/ )


Wine émule effectivement certains bugs de Windows, ce qui est parfois particulièrement ch*** à programmer (comportements non documentés mais sur lesquels certaines applications buggées comptent). Il est connu que Wine avait la vulnérabilité des WMF contenant du code exécutable, possibilité apparemment utile dans le début des années 1990 mais devenue une hérésie de sécurité dans les années 2000.
Mais quand le bug consiste à crasher parce qu'on passe des paramètres invalides à certaines API (et ça, les différentes versions de Windows, Vista compris, en sont bourrées: plonge-toi un peu dans la suite de tests de divers DLL de Wine), Wine ne l'émule pas