De ce que j'ai appris, SUA est déprécié sous Windows 8. Pourquoi pas après tout? Je ne connais le nombre de clients mais la demande ne devait pas être très forte ; sans compter que le support Unix n'était pas très adapté…
Maintenant, je me pose la question d'un support futur viable d'un environnement POSIX sous Windows NT.
Il y a bien sûr Cygwin… mais comme d'habitude, il y a toujours un problème: l'appel à fork().
Il n'existe pas de correspondance un à un entre un appel fork() et une fonction quelqueconque dans l'API win32. Il y a bien l'appel CreateProcess que Cygwin utilise pour son implémentation de fork, mais ça "sucks" grave au niveau performance sans compter d'autres problèmes.
Pour générer son sous-système SUA Posix, windows n'utilise pas l'API win32. Si je n'en dit pas une grosse ( c'est carrément possible), il utilise d'autres api notamment la Native Api. Le problème quand on commence à toucher à ce genre d'api, c'est le manque de documentation… à tort ou à raison, une partie de cette api n'est pas documentée. Je suppose que cette api n'est pas stable avec le changement de version, et c'est cette argument qui est utilisé pour ne pas la documenter entièrement?
Si je parle de ça, c'est que Corinna Vinschen essaie d'améliorer les choses avec le fork() de Cygwin… mais qu’apparemment la barrière de dialogue est assez difficile.
Est-ce que Microsoft a une alternative à proposer pour SUA?
Pourquoi il manque une documentation pour la Native API? Interix utilise cette Api, il a une implémentation de fork() très correct et c'est très probablement par l'utilisation d'appel se rapprochant des fonctionnalités d'un fork() qui n'est documenté nulle part.
Microsoft conseille, pour le portage d'une appli Unix vers NT, d'adapter fork/exec par autres choses comme CreateProcess de l'Api Win32; s'il existe un appel plus efficace, pourquoi ne pas le déclarer, documenter?
# SUA/Interix documentation API NT
Posté par wolowizard . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 6. Dernière modification le 05 octobre 2012 à 10:06.
Bonjour,
De ce que j'ai appris, SUA est déprécié sous Windows 8. Pourquoi pas après tout? Je ne connais le nombre de clients mais la demande ne devait pas être très forte ; sans compter que le support Unix n'était pas très adapté…
Maintenant, je me pose la question d'un support futur viable d'un environnement POSIX sous Windows NT.
Il y a bien sûr Cygwin… mais comme d'habitude, il y a toujours un problème: l'appel à fork().
Il n'existe pas de correspondance un à un entre un appel fork() et une fonction quelqueconque dans l'API win32. Il y a bien l'appel CreateProcess que Cygwin utilise pour son implémentation de fork, mais ça "sucks" grave au niveau performance sans compter d'autres problèmes.
Pour générer son sous-système SUA Posix, windows n'utilise pas l'API win32. Si je n'en dit pas une grosse ( c'est carrément possible), il utilise d'autres api notamment la Native Api. Le problème quand on commence à toucher à ce genre d'api, c'est le manque de documentation… à tort ou à raison, une partie de cette api n'est pas documentée. Je suppose que cette api n'est pas stable avec le changement de version, et c'est cette argument qui est utilisé pour ne pas la documenter entièrement?
Si je parle de ça, c'est que Corinna Vinschen essaie d'améliorer les choses avec le fork() de Cygwin… mais qu’apparemment la barrière de dialogue est assez difficile.
Est-ce que Microsoft a une alternative à proposer pour SUA?
Pourquoi il manque une documentation pour la Native API? Interix utilise cette Api, il a une implémentation de fork() très correct et c'est très probablement par l'utilisation d'appel se rapprochant des fonctionnalités d'un fork() qui n'est documenté nulle part.
Microsoft conseille, pour le portage d'une appli Unix vers NT, d'adapter fork/exec par autres choses comme CreateProcess de l'Api Win32; s'il existe un appel plus efficace, pourquoi ne pas le déclarer, documenter?