De bonnes alternatives à Cygwin ? - Cygwin ne supporte pas nativement les applications Win32

Question

Mise à jour 1/9/2014 : Version TL;DR : Allez au bas de cet article pour trouver un moyen de permettre à Cygwin d'appeler des programmes non-Cygwin.

Après avoir pris le temps de réaliser quelques scripts bash qui se trouvent être de taille significative, les nouvelles versions de Cygwin les ont cassés. Ces scripts font appel à des applications Win32 natives qui ne sont pas liées à Cygwin, ce qui n'est apparemment pas officiellement supporté par Cygwin.

Cela m'a surpris, car pendant des années j'ai eu l'impression que Cygwin pouvait être utilisé dans un environnement plus mixte combinant à la fois des applications Win32 natives non-Cygwin et des programmes POSIX utilisant la couche de compatibilité Cygwin. Mais apparemment, seule la couche de compatibilité POSIX est réellement prise en charge, et si les applications natives Win32 non-Cygwin fonctionnent, cela est considéré comme une heureuse coïncidence.

J'ai découvert cela grâce à une incompatibilité que j'ai rencontrée en exécutant des programmes compilés avec le .NET Framework depuis Cygwin. Cela fonctionnait bien avant, mais a été rompu il y a quelques mois. Plus précisément, la sortie standard d'un programme .NET qui est acheminée vers l'entrée standard d'un autre programme Win32 provoquera généralement un signal de fin de fichier prématuré pour le programme Win32 récepteur, car Cygwin est passé des byte pipes aux message pipes il y a quelques mois - et les message pipes semblent être incompatibles avec toute application réceptrice utilisant Visual C++ ou le .NET Framework. Ceci est dû au fait que .NET émet une écriture nulle sur la sortie standard, qui n'est transmise à l'application réceptrice que si un message pipe est utilisé. L'application réceptrice lit avec succès zéro octet, et pense donc que le fichier est terminé. Le responsable du projet ne semble pas considérer cela comme un réel problème, puisqu'il ne supporte pas vraiment l'exécution de programmes non-Cygwin à partir de Cygwin (surprise !).

Pour citer le chef de projet Christopher Faylor à partir de plusieurs courriels sur la liste de diffusion :

Ce que vous voyez peut être dû au fait que Cygwin a été modifié pour utiliser des les pipes de type message il y a quelques révisions. Cela ne va pas changer. Le changement a été adopté pour corriger un problème avec les programmes Cygwin et ceux-ci sont évidemment notre première priorité.

Quel que soit le nombre de personnes qui utilisent Visual C++ ou .NET, elles ne sont pas vraiment pas notre public cible. C'est bien quand les choses fonctionnent pour les personnes qui qui ne veulent pas utiliser d'outils UNIX, mais ce n'est pas notre objectif principal. Corriger les problèmes des gens qui veulent utiliser des outils non-Cygwin n'est pas une priorité. quelque chose que je trouve hautement prioritaire.

Extrait de pipe.cc : Notez que le côté écriture du tuyau est ouvert comme PIPE_TYPE_MESSAGE. Ceci semble pour imiter plus fidèlement le comportement des tuyaux de Linux et est nécessaire pour la gestion du pty puisque fhandler_pty_master écrit sur le en morceaux, terminés par une nouvelle ligne lorsque le mode CANON est spécifié. spécifié.

Le commentaire ci-dessus montre une relation "et" ici. Le type de message imitent plus fidèlement le comportement des tuyaux de Linux (UNIX) ET sont définitivement nécessaires pour les ptys.

Je suis d'accord avec James que les runtimes sont probablement bogués MAIS je suis aussi également que Cygwin devrait être capable de gérer ces scénarios.

Votre accord total avec l'autre ne va pas avoir beaucoup de effet. Le code source de Cygwin n'est pas modifié par le vote.

Même si ce problème est finalement résolu d'une manière ou d'une autre - qui sait - ils pourraient casser autre chose dans 3 mois et ne pas se soucier de corriger la régression. Ils pourraient envisager un patch, mais il me faudrait un certain temps pour trouver quelque chose qui fonctionne. Je pense que mon temps est mieux utilisé ailleurs, parce qu'il est clair qu'ils sont tout à fait disposés à rompre la compatibilité avec les applications Win32 natives et ne veulent pas perdre plus de temps à faire fonctionner les applications Win32. Je suppose donc que Cygwin ne doit pas être considéré comme une plateforme stable pour les environnements mixtes Win32/Cygwin - quelles sont mes alternatives ? Par où devrais-je commencer pour éviter une réécriture complète dans quelque chose d'autre que bash ? Je n'utilise pas plus que l'installation de base de Cygwin + quelques scripts perl de base.

UPDATE : Après la publication de cette question originale, ils ont fini par créer un nouveau site Web. pipe_byte dans le CYGWIN variable d'environnement : consultez la documentation. Si ce drapeau est activé, cela résoudra le problème évoqué ci-dessus. Lors de l'invocation d'un programme Win32 non-Cygwin, toujours assurez-vous que le pipe_byte est activé.

Cependant, j'ai depuis découvert une incompatibilité avec .NET Framework 4.0 et Cygwin. Les versions précédentes de .NET Framework ne présentent pas ce problème. J'ai mentionné ce problème pour la première fois sur la liste de diffusion Cygwin ici :

Synchronisation des tuyaux et incompatibilité entre Cygwin et .NET Framework 4.0

N'obtenant aucune réponse fructueuse, j'ai poursuivi mes recherches et j'ai découvert que Cygwin crée des tuyaux superposés, ce qui cause le problème. Notez qu'essayer d'utiliser des appels d'API Win32 non chevauchés avec un tuyau chevauché n'est pas défini, et la plupart (tous ?) des programmes Win32 non-Cygwin n'utilisent pas d'E/S chevauchées avec leurs poignées de fichier standard. J'ai soumis un patch qui crée un pipe_nooverlap dans le CYGWIN qui empêche ce phénomène de se produire :

Correctif pour désactiver optionnellement les tuyaux superposés

Malheureusement, ils ont rejeté le patch, donc vous ne verrez jamais cela dans la DLL principale de Cygwin :

Re : Patch pour désactiver optionnellement les tuyaux superposés

Le raisonnement pour le rejet du patch :

1. Il a été sous-entendu que j'ai cassé l'implémentation des signaux dans Cygwin ; je n'ai pas trouvé que c'était le cas, car les signaux utilisent toujours des pipes superposés.
2. Ils n'ont pas envie d'ajouter un indicateur de variable d'environnement, même si cela permet apparemment de résoudre des problèmes.
3. Ils ne veulent pas supporter un code qui a même la possibilité d'avoir des tuyaux qui ne se chevauchent pas.

Avec un tel raisonnement et une telle attitude, j'ai bien peur de ne pouvoir trouver aucun moyen de modifier le patch pour qu'il réponde à leurs exigences... ils semblent déterminés à interdire l'utilisation de tuyaux non chevauchés. J'utilise le patch depuis un certain temps maintenant, et je n'ai eu aucun problème avec lui. De plus, je ne peux pas penser à des situations dans lesquelles l'option pipe_nooverlap sera cassé (voir mon e-mail de suivi sur leur liste de diffusion), mais je l'ai laissé comme un drapeau juste au cas où il y a des problèmes.

Ainsi, si vous souhaitez appeler des programmes Win32 ou .NET Framework non Cygwin à partir de Cygwin, vous devez procéder comme suit :

1. Appliquez mon correctif aux sources de la version de Cygwin que vous utilisez. Ne vous attendez pas à ce que ce patch apparaisse dans les futures versions de Cygwin.
2. Définissez le pipe_byte y pipe_nooverlap dans le CYGWIN variable d'environnement.

Cela fonctionne... pour l'instant ! !! Je poste ceci au cas où cela aiderait quelqu'un d'autre qui veut encore utiliser Cygwin pour certaines choses.

Answer 1

La meilleure alternative que j'ai trouvée est Gow (Gnu sous Windows) .

C'est une alternative légère à Cygwin, environ 10 fois plus légère. Pour autant que je sache, les 130 outils installés avec Gow sont des applications Win32 ordinaires.

Answer 2

MSYS

Il y aura peut-être moins de paquets "supportés", dans le sens où vous devrez installer des choses à la main, mais il n'y en aura pas :

• Questions relatives aux chemins ( cygpath est une non-solution, car vous ne pouvez pas toujours l'enfoncer)
• Programmes confondus par des paquets cygwin indiquant que leur système d'exploitation est 'cygwin'.
• Confusion .dll/.so/.lib/.a

Et l'interopérabilité avec les applications Windows est bien meilleure.

Answer 3

J'avais l'habitude d'utiliser cygwin principalement pour la fonctionnalité de serveur X11. Il était utile d'exécuter n'importe quel outil sur un serveur distant et d'exporter l'affichage vers le cygwin local. Je trouve que je peux réaliser la même chose en utilisant le serveur Xming qui est beaucoup plus léger.