"pehache-olino" , dans le message , a
écrit :Si. C'est une discussion récurrente ici, mais si Wine n'est pas un émulateur
alors je ne vois pas ce qu'est un émulateur.
En effet, mais le débat se renouvelle, puisque tu dis :Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non pas
"toto.exe" directement.
... qui est probablement l'argument le plus imbécile qui ait jamais été
avancé à ce sujet.
"pehache-olino" , dans le message <91iidkF5k9U1@mid.individual.net>, a
écrit :
Si. C'est une discussion récurrente ici, mais si Wine n'est pas un émulateur
alors je ne vois pas ce qu'est un émulateur.
En effet, mais le débat se renouvelle, puisque tu dis :
Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non pas
"toto.exe" directement.
... qui est probablement l'argument le plus imbécile qui ait jamais été
avancé à ce sujet.
"pehache-olino" , dans le message , a
écrit :Si. C'est une discussion récurrente ici, mais si Wine n'est pas un émulateur
alors je ne vois pas ce qu'est un émulateur.
En effet, mais le débat se renouvelle, puisque tu dis :Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non pas
"toto.exe" directement.
... qui est probablement l'argument le plus imbécile qui ait jamais été
avancé à ce sujet.
Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non pas
"toto.exe" directement.
Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non pas
"toto.exe" directement.
Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non pas
"toto.exe" directement.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 14:13, pehache-olino a écrit :Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non
pas "toto.exe" directement.
On pourrait tout à fait lancer un binaire win32 directement, puisqu'il
est bien entendu uniquement composé d'instructions assembleur
compréhensibles par ton processeur et totalement indépendant de ton
OS.
Il va « simplement » faire appel à des appels systèmes non disponibles
puisque soit fourni par le noyau NT soit par les API win32 (un peu
l'équivalent de notre glibc à nous), ce qui déclencherait de gros
core dump.
C'est d'ailleurs le seul et unique travail de Wine : combler les trous
et permettrent aux appels de se dérouler correctement.
Techniquement parlant, il n'y a aucune différence entre un binaire «
win32 » et un binaire « x86/x86_64 », juste une histoire d'API et de
librairies système.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 14:13, pehache-olino a écrit :
Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non
pas "toto.exe" directement.
On pourrait tout à fait lancer un binaire win32 directement, puisqu'il
est bien entendu uniquement composé d'instructions assembleur
compréhensibles par ton processeur et totalement indépendant de ton
OS.
Il va « simplement » faire appel à des appels systèmes non disponibles
puisque soit fourni par le noyau NT soit par les API win32 (un peu
l'équivalent de notre glibc à nous), ce qui déclencherait de gros
core dump.
C'est d'ailleurs le seul et unique travail de Wine : combler les trous
et permettrent aux appels de se dérouler correctement.
Techniquement parlant, il n'y a aucune différence entre un binaire «
win32 » et un binaire « x86/x86_64 », juste une histoire d'API et de
librairies système.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 14:13, pehache-olino a écrit :Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non
pas "toto.exe" directement.
On pourrait tout à fait lancer un binaire win32 directement, puisqu'il
est bien entendu uniquement composé d'instructions assembleur
compréhensibles par ton processeur et totalement indépendant de ton
OS.
Il va « simplement » faire appel à des appels systèmes non disponibles
puisque soit fourni par le noyau NT soit par les API win32 (un peu
l'équivalent de notre glibc à nous), ce qui déclencherait de gros
core dump.
C'est d'ailleurs le seul et unique travail de Wine : combler les trous
et permettrent aux appels de se dérouler correctement.
Techniquement parlant, il n'y a aucune différence entre un binaire «
win32 » et un binaire « x86/x86_64 », juste une histoire d'API et de
librairies système.
"Aéris" a écrit dans le message de news:
4db451f7$0$25006$-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 14:13, pehache-olino a écrit :Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non
pas "toto.exe" directement.
On pourrait tout à fait lancer un binaire win32 directement, puisqu'il
est bien entendu uniquement composé d'instructions assembleur
compréhensibles par ton processeur et totalement indépendant de ton
OS.
Il va « simplement » faire appel à des appels systèmes non disponibles
puisque soit fourni par le noyau NT soit par les API win32 (un peu
l'équivalent de notre glibc à nous), ce qui déclencherait de gros
core dump.
C'est d'ailleurs le seul et unique travail de Wine : combler les trous
et permettrent aux appels de se dérouler correctement.
Techniquement parlant, il n'y a aucune différence entre un binaire «
win32 » et un binaire « x86/x86_64 », juste une histoire d'API et de
librairies système.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie dynamique
contenant les routines correspondant à l'API Win32 pour pouvoir exécuter un
binaire Win32. Or ce n'est pas comme ça que cela fonctionne.
"Aéris" <aeris@imirhil.fr> a écrit dans le message de news:
4db451f7$0$25006$426a74cc@news.free.fr
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 14:13, pehache-olino a écrit :
Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non
pas "toto.exe" directement.
On pourrait tout à fait lancer un binaire win32 directement, puisqu'il
est bien entendu uniquement composé d'instructions assembleur
compréhensibles par ton processeur et totalement indépendant de ton
OS.
Il va « simplement » faire appel à des appels systèmes non disponibles
puisque soit fourni par le noyau NT soit par les API win32 (un peu
l'équivalent de notre glibc à nous), ce qui déclencherait de gros
core dump.
C'est d'ailleurs le seul et unique travail de Wine : combler les trous
et permettrent aux appels de se dérouler correctement.
Techniquement parlant, il n'y a aucune différence entre un binaire «
win32 » et un binaire « x86/x86_64 », juste une histoire d'API et de
librairies système.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie dynamique
contenant les routines correspondant à l'API Win32 pour pouvoir exécuter un
binaire Win32. Or ce n'est pas comme ça que cela fonctionne.
"Aéris" a écrit dans le message de news:
4db451f7$0$25006$-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 14:13, pehache-olino a écrit :Non. Si c'était le cas on pourrait lancer un exécutable natif Win32
directement. Or ce n'est pas le cas, on tape "wine toto.exe" et non
pas "toto.exe" directement.
On pourrait tout à fait lancer un binaire win32 directement, puisqu'il
est bien entendu uniquement composé d'instructions assembleur
compréhensibles par ton processeur et totalement indépendant de ton
OS.
Il va « simplement » faire appel à des appels systèmes non disponibles
puisque soit fourni par le noyau NT soit par les API win32 (un peu
l'équivalent de notre glibc à nous), ce qui déclencherait de gros
core dump.
C'est d'ailleurs le seul et unique travail de Wine : combler les trous
et permettrent aux appels de se dérouler correctement.
Techniquement parlant, il n'y a aucune différence entre un binaire «
win32 » et un binaire « x86/x86_64 », juste une histoire d'API et de
librairies système.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie dynamique
contenant les routines correspondant à l'API Win32 pour pouvoir exécuter un
binaire Win32. Or ce n'est pas comme ça que cela fonctionne.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
À peu de choses près, c'est pourtant comme ça que ça fonctionne, le
peu de chose près étant dans le format des binaires et les I/O.
Mais ergote pour noyer le poisson.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
À peu de choses près, c'est pourtant comme ça que ça fonctionne, le
peu de chose près étant dans le format des binaires et les I/O.
Mais ergote pour noyer le poisson.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
À peu de choses près, c'est pourtant comme ça que ça fonctionne, le
peu de chose près étant dans le format des binaires et les I/O.
Mais ergote pour noyer le poisson.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier valide
et non pas bêtement «1», ?
Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier valide
et non pas bêtement «1», ?
Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier valide
et non pas bêtement «1», ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 18:55, pehache-olino a écrit :Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
C'est bien là qu'est toute la complexité de la chose…
Implémenter une API bidon pour éviter les core dump, c'est très
facile à faire voire même 100% automatisable.
Il s'agit uniquement de faire un .c valide à partir d'un .h connu.
Par exemple pour l'ouverture d'un fichier, le file.h impose
uniquement un int file_open(char *path)
L'implémentation suivante est donc totalement valide
int file_open(char *path) {
return -1;
}
Mais ça ne te garantie en rien un comportement correct de ton soft,
juste qu'il s'exécutera. Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Implémenter correctement l'API de manière à ce qu'elle reproduise le
comportement souhaité quand on l'appelle en est une autre.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier valide
et non pas bêtement «1», …
C'est tout le travail de Wine, implémenter correctement le
comportement d'une API connue.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 18:55, pehache-olino a écrit :
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
C'est bien là qu'est toute la complexité de la chose…
Implémenter une API bidon pour éviter les core dump, c'est très
facile à faire voire même 100% automatisable.
Il s'agit uniquement de faire un .c valide à partir d'un .h connu.
Par exemple pour l'ouverture d'un fichier, le file.h impose
uniquement un int file_open(char *path)
L'implémentation suivante est donc totalement valide
int file_open(char *path) {
return -1;
}
Mais ça ne te garantie en rien un comportement correct de ton soft,
juste qu'il s'exécutera. Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Implémenter correctement l'API de manière à ce qu'elle reproduise le
comportement souhaité quand on l'appelle en est une autre.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier valide
et non pas bêtement «1», …
C'est tout le travail de Wine, implémenter correctement le
comportement d'une API connue.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 24/04/2011 18:55, pehache-olino a écrit :Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
C'est bien là qu'est toute la complexité de la chose…
Implémenter une API bidon pour éviter les core dump, c'est très
facile à faire voire même 100% automatisable.
Il s'agit uniquement de faire un .c valide à partir d'un .h connu.
Par exemple pour l'ouverture d'un fichier, le file.h impose
uniquement un int file_open(char *path)
L'implémentation suivante est donc totalement valide
int file_open(char *path) {
return -1;
}
Mais ça ne te garantie en rien un comportement correct de ton soft,
juste qu'il s'exécutera. Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Implémenter correctement l'API de manière à ce qu'elle reproduise le
comportement souhaité quand on l'appelle en est une autre.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier valide
et non pas bêtement «1», …
C'est tout le travail de Wine, implémenter correctement le
comportement d'une API connue.
Aéris a papoté sur Usenet le 24 avril 2011 14:59:Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Il faut implémenter tout le comportement du .c.Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier
valide et non pas bêtement «1», ?
Tu crois vraiment qu'il comprend tes explications. Le passé a prouvé
que ses connaissances dans ce domaine frisent le zéro absolu :)
Aéris a papoté sur Usenet le 24 avril 2011 14:59:
Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Il faut implémenter tout le comportement du .c.
Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier
valide et non pas bêtement «1», ?
Tu crois vraiment qu'il comprend tes explications. Le passé a prouvé
que ses connaissances dans ce domaine frisent le zéro absolu :)
Aéris a papoté sur Usenet le 24 avril 2011 14:59:Il a même de très forte chance de ne pas
dépasser l'instruction suivante, mais pas pour cause d'API invalide
mais parce que -1 n'est pas un descripteur de fichier valide.
Il faut implémenter tout le comportement du .c.Que les API de socket agissent réellement sur un socket, que quand tu
fais un file_open il te retourne un vrai descripteur de fichier
valide et non pas bêtement «1», ?
Tu crois vraiment qu'il comprend tes explications. Le passé a prouvé
que ses connaissances dans ce domaine frisent le zéro absolu :)
"JKB" a écrit dans le message de news:
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
À peu de choses près, c'est pourtant comme ça que ça fonctionne, le
peu de chose près étant dans le format des binaires et les I/O.
Des détails sans importance, en quelque sorte...
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrnir8oq1.spd.jkb@rayleigh.systella.fr
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
À peu de choses près, c'est pourtant comme ça que ça fonctionne, le
peu de chose près étant dans le format des binaires et les I/O.
Des détails sans importance, en quelque sorte...
"JKB" a écrit dans le message de news:
Si ça marchait comme tu dis, il suffirait d'avoir une librairie
dynamique contenant les routines correspondant à l'API Win32 pour
pouvoir exécuter un binaire Win32. Or ce n'est pas comme ça que cela
fonctionne.
À peu de choses près, c'est pourtant comme ça que ça fonctionne, le
peu de chose près étant dans le format des binaires et les I/O.
Des détails sans importance, en quelque sorte...