> > Si l'implémentation complète de la norme POSIX sous Windows requiert > impérativement du code exécuté en mode noyau, et que Microsoft ne veut > pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin ne > peut pas toucher au noyau Windows.
Peut-être, mais ça ne change rien au débat "cygwin est-il une implémentation ou une émulation de la norme POSIX".
Pour ma part je suis d'accord avec ST, c'est une implémentation (peut- être incomplète) et pas une émulation.
J'ai cru comprendre que cygwin translate les appels posix en une collection d'appels Windows ayant un résultat plus ou moins équivalent (car il y a plein de choses différentes, par ex. dans les systèmes de permission sur les fichiers, etc. et donc on ne peut pas faire une translation bijective). Il me semble que ce genre d'opération s'appelle une émulation. Pour prendre un cas différent, FreeBSD permet d'exécuter des exécutables Linux. Comment ça se passe: ici il y a une implémentation directe dans le noyau des appels système Linux nécessaires, de même qu'il y a une implémentation directe des appels systèmes de la libc ordinaire. Dans ce cas c'est une implémentation, pas une émulation, enfin il me semble que c'est le sens des mots.
-- pehache
--
Michel TALON
pehache-tolai <pehache.7@gmail.com> wrote:
On 23 juil, 09:08, Toxico Nimbus <T...@free.fr> wrote:
>
> Si l'implémentation complète de la norme POSIX sous Windows requiert
> impérativement du code exécuté en mode noyau, et que Microsoft ne veut
> pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin ne
> peut pas toucher au noyau Windows.
Peut-être, mais ça ne change rien au débat "cygwin est-il une
implémentation ou une émulation de la norme POSIX".
Pour ma part je suis d'accord avec ST, c'est une implémentation (peut-
être incomplète) et pas une émulation.
J'ai cru comprendre que cygwin translate les appels posix en une
collection d'appels Windows ayant un résultat plus ou moins équivalent
(car il y a plein de choses différentes, par ex. dans les systèmes de
permission sur les fichiers, etc. et donc on ne peut pas faire une
translation bijective). Il me semble que ce genre d'opération s'appelle
une émulation. Pour prendre un cas différent, FreeBSD permet d'exécuter
des exécutables Linux. Comment ça se passe: ici il y a une
implémentation directe dans le noyau des appels système Linux
nécessaires, de même qu'il y a une implémentation directe des appels
systèmes de la libc ordinaire. Dans ce cas c'est une implémentation, pas
une émulation, enfin il me semble que c'est le sens des mots.
> > Si l'implémentation complète de la norme POSIX sous Windows requiert > impérativement du code exécuté en mode noyau, et que Microsoft ne veut > pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin ne > peut pas toucher au noyau Windows.
Peut-être, mais ça ne change rien au débat "cygwin est-il une implémentation ou une émulation de la norme POSIX".
Pour ma part je suis d'accord avec ST, c'est une implémentation (peut- être incomplète) et pas une émulation.
J'ai cru comprendre que cygwin translate les appels posix en une collection d'appels Windows ayant un résultat plus ou moins équivalent (car il y a plein de choses différentes, par ex. dans les systèmes de permission sur les fichiers, etc. et donc on ne peut pas faire une translation bijective). Il me semble que ce genre d'opération s'appelle une émulation. Pour prendre un cas différent, FreeBSD permet d'exécuter des exécutables Linux. Comment ça se passe: ici il y a une implémentation directe dans le noyau des appels système Linux nécessaires, de même qu'il y a une implémentation directe des appels systèmes de la libc ordinaire. Dans ce cas c'est une implémentation, pas une émulation, enfin il me semble que c'est le sens des mots.
-- pehache
--
Michel TALON
pehache-tolai
On 23 juil, 18:15, (Michel Talon) wrote:
J'ai cru comprendre que cygwin translate les appels posix en une collection d'appels Windows ayant un résultat plus ou moins équivalen t (car il y a plein de choses différentes, par ex. dans les systèmes de permission sur les fichiers, etc. et donc on ne peut pas faire une translation bijective). Il me semble que ce genre d'opération s'appelle une émulation.
Pourquoi ? Sans être spécialiste non plus, je suppose que la norme POSIX ne dit absolument rien sur la façon dont doivent être implémentée les fonctions. Notamment sur le fait que les appels puissent ou non faire d'autres appels, qu'ils soient système ou pas.
Il faut bien voir qu'une fois compilée, une application Cygwin est un véritable exécutable Win32.
On peut aussi voir Cygwin comme une bibliothèque de portabilité, permettant de compiler du code sur des plate-formes différentes avec une interface unique pour les appels système.
Pour prendre un cas différent, FreeBSD permet d'exécuter des exécutables Linux. Comment ça se passe: ici il y a une implémentation directe dans le noyau des appels système Linux nécessaires, de même qu'il y a une implémentation directe des appel s systèmes de la libc ordinaire. Dans ce cas c'est une implémentation, pas une émulation
Oui, c'est une implémentation. Aussi :-)
Un cas différent à mon avis est celui de Wine, qui s'apparente plus à une machine virtuelle, donc à un émulateur : l'appli Win32 ne tourne pas directement sous l'OS hôte, c'est Wine qui est lancé et qui "exécute" l'appli Win32.
-- pehache
On 23 juil, 18:15, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
J'ai cru comprendre que cygwin translate les appels posix en une
collection d'appels Windows ayant un résultat plus ou moins équivalen t
(car il y a plein de choses différentes, par ex. dans les systèmes de
permission sur les fichiers, etc. et donc on ne peut pas faire une
translation bijective). Il me semble que ce genre d'opération s'appelle
une émulation.
Pourquoi ? Sans être spécialiste non plus, je suppose que la norme
POSIX ne dit absolument rien sur la façon dont doivent être
implémentée les fonctions. Notamment sur le fait que les appels
puissent ou non faire d'autres appels, qu'ils soient système ou pas.
Il faut bien voir qu'une fois compilée, une application Cygwin est un
véritable exécutable Win32.
On peut aussi voir Cygwin comme une bibliothèque de portabilité,
permettant de compiler du code sur des plate-formes différentes avec
une interface unique pour les appels système.
Pour prendre un cas différent, FreeBSD permet d'exécuter
des exécutables Linux. Comment ça se passe: ici il y a une
implémentation directe dans le noyau des appels système Linux
nécessaires, de même qu'il y a une implémentation directe des appel s
systèmes de la libc ordinaire. Dans ce cas c'est une implémentation, pas
une émulation
Oui, c'est une implémentation. Aussi :-)
Un cas différent à mon avis est celui de Wine, qui s'apparente plus à
une machine virtuelle, donc à un émulateur : l'appli Win32 ne tourne
pas directement sous l'OS hôte, c'est Wine qui est lancé et qui
"exécute" l'appli Win32.
J'ai cru comprendre que cygwin translate les appels posix en une collection d'appels Windows ayant un résultat plus ou moins équivalen t (car il y a plein de choses différentes, par ex. dans les systèmes de permission sur les fichiers, etc. et donc on ne peut pas faire une translation bijective). Il me semble que ce genre d'opération s'appelle une émulation.
Pourquoi ? Sans être spécialiste non plus, je suppose que la norme POSIX ne dit absolument rien sur la façon dont doivent être implémentée les fonctions. Notamment sur le fait que les appels puissent ou non faire d'autres appels, qu'ils soient système ou pas.
Il faut bien voir qu'une fois compilée, une application Cygwin est un véritable exécutable Win32.
On peut aussi voir Cygwin comme une bibliothèque de portabilité, permettant de compiler du code sur des plate-formes différentes avec une interface unique pour les appels système.
Pour prendre un cas différent, FreeBSD permet d'exécuter des exécutables Linux. Comment ça se passe: ici il y a une implémentation directe dans le noyau des appels système Linux nécessaires, de même qu'il y a une implémentation directe des appel s systèmes de la libc ordinaire. Dans ce cas c'est une implémentation, pas une émulation
Oui, c'est une implémentation. Aussi :-)
Un cas différent à mon avis est celui de Wine, qui s'apparente plus à une machine virtuelle, donc à un émulateur : l'appli Win32 ne tourne pas directement sous l'OS hôte, c'est Wine qui est lancé et qui "exécute" l'appli Win32.
