Quand t'as pas le choix, Wine peut servir pour quelques tests. Mais pour une très grande classe de bugs, cela rajoutera juste beaucoup de faux positifs comme de faux négatifs.
Déjà que GIMP est à peine maintenu sous Windows, si en plus les seuls tests étaient fait sous Wine...
Notamment l'un des problèmes de Wine est que ça n'émule pas les librairies Windows mais traduit des appels systèmes en appels locaux (si possible), ou réimplémente les appels qui ne peuvent être simplement traduits. Note que je dis "problème", mais c'est un des grands atoûts aussi, notamment car ça veut dire qu'il n'y a pas besoin de licence Windows pour exécuter un logiciel Windows sous Win car il n'y a aucun binaire Windows dedans; aussi sans cela, Wine ne pourrait probablement pas être fourni dans nos distribs Linux, ou du moins pas "prêt à l'emploi", demandant aux gens de manuellement copier des fichiers Windows, ou faisant d'autres galipettes logiques avant d'être utilisable. Donc de manière générale, c'est en fait un énorme avantage de Wine dans la plupart des cas. Mais pour de l'émulation système et des tests poussés de reproductions de problèmes (surtout ceux spécifiques à Windows et qu'on ne reproduit pas sur Linux, donc exactement ce qui nous intéresse justement), ça devient bien plus problématique.
Tiens, pour l'exemple du bug corrigé y a quelques jours, on ouvrait un fichier en mode "wb+" (lecture, écriture en binaire). Ce mode marche très bien avec le fopen() de Linux. Mais on a donc découvert que pas sous Windows. Par contre, le mode "w+b" (qui est un alias de "wb+" et est donc exactement la même chose) marche parfaitement sur les 2 systèmes. Ce fut donc la correction effectuée.
Ben ce serait intéressant de tester, mais si Wine remplace simplement l'appel fopen() win32 par celui de Linux (comme j'imagine qu'il ferait, après tout cet appel système existe sur tous les OS apparemment et a la même interface), je pense que le bug disparaîtrait sous Wine (sauf si les développeurs de Wine rajoutent du code spécifique pour émuler davantage les limitations de mode dispos sur chaque système, mais y aurait vraiment peu d'avantages de faire cela).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche darktable 2.4.0. Évalué à 7.
Quand t'as pas le choix, Wine peut servir pour quelques tests. Mais pour une très grande classe de bugs, cela rajoutera juste beaucoup de faux positifs comme de faux négatifs.
Déjà que GIMP est à peine maintenu sous Windows, si en plus les seuls tests étaient fait sous Wine...
Notamment l'un des problèmes de Wine est que ça n'émule pas les librairies Windows mais traduit des appels systèmes en appels locaux (si possible), ou réimplémente les appels qui ne peuvent être simplement traduits. Note que je dis "problème", mais c'est un des grands atoûts aussi, notamment car ça veut dire qu'il n'y a pas besoin de licence Windows pour exécuter un logiciel Windows sous Win car il n'y a aucun binaire Windows dedans; aussi sans cela, Wine ne pourrait probablement pas être fourni dans nos distribs Linux, ou du moins pas "prêt à l'emploi", demandant aux gens de manuellement copier des fichiers Windows, ou faisant d'autres galipettes logiques avant d'être utilisable. Donc de manière générale, c'est en fait un énorme avantage de Wine dans la plupart des cas. Mais pour de l'émulation système et des tests poussés de reproductions de problèmes (surtout ceux spécifiques à Windows et qu'on ne reproduit pas sur Linux, donc exactement ce qui nous intéresse justement), ça devient bien plus problématique.
Tiens, pour l'exemple du bug corrigé y a quelques jours, on ouvrait un fichier en mode "wb+" (lecture, écriture en binaire). Ce mode marche très bien avec le fopen() de Linux. Mais on a donc découvert que pas sous Windows. Par contre, le mode "w+b" (qui est un alias de "wb+" et est donc exactement la même chose) marche parfaitement sur les 2 systèmes. Ce fut donc la correction effectuée.
Ben ce serait intéressant de tester, mais si Wine remplace simplement l'appel fopen() win32 par celui de Linux (comme j'imagine qu'il ferait, après tout cet appel système existe sur tous les OS apparemment et a la même interface), je pense que le bug disparaîtrait sous Wine (sauf si les développeurs de Wine rajoutent du code spécifique pour émuler davantage les limitations de mode dispos sur chaque système, mais y aurait vraiment peu d'avantages de faire cela).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]