Cygwinに代わる良い選択肢は？ -CygwinはWin32アプリのネイティブサポートをサポートしていません
2014年1月9日更新：TL; DRバージョン：Cygwinが非Cygwinを呼び出せるようにする方法については、この投稿の最後に移動してくださいプログラム。
かなりのサイズのbashスクリプトを作成するために時間を費やした後、Cygwinの新しいバージョンはそれらを破壊しました。これらのスクリプトは、CygwinとリンクしていないネイティブWin32アプリケーションを呼び出します。Cygwinは、Cygwinによって公式にサポートされていないようです。
Cygwinは、Cygwin互換性レイヤーを使用するネイティブの非Cygwin Win32アプリとPOSIXプログラムの両方を組み合わせた、より混合された環境で使用できるという印象を受けていたので、これは私にとって驚きでした。しかし、明らかにPOSIX互換性レイヤーのみが実際にサポートされており、ネイティブのWin32非Cygwinアプリが動作する場合、幸運な偶然と見なされます。
これは、Cygwin内から.NET Frameworkに対してコンパイルされたプログラムを実行するときに遭遇した非互換性から発見されました。これは以前は正常に機能していましたが、数か月前に壊れていました。具体的には、他のWin32プログラムの標準入力にパイプされる.NETプログラムからの標準出力は、Cygwinが最近数か月前にバイトパイプからメッセージパイプに切り替えたため、一般に受信Win32プログラムがファイルの途中で終了する信号を取得します-およびメッセージパイプは、Visual C++または.NET Frameworkを使用する受信アプリと互換性がないようです。これは、.NETが標準出力にnull書き込みを発行し、メッセージパイプが使用されている場合にのみ受信アプリに渡されるためです。受信アプリは0バイトを正常に読み取ったため、ファイルの終わりと見なします。プロジェクトリーダーは、Cygwin内からのCygwin以外のプログラムの実行を実際にはサポートしていないため、これを実際の問題とは見なしていないようです（驚き！）。
プロジェクトをリードするChristopher Faylorをメーリングリストの複数の電子メールから引用するには：
表示されているのは、Cygwinが2、3リビジョン前にメッセージタイプパイプを使用するように変更されたためかもしれません。これは変わりません。この変更は、Cygwinプログラムの問題を修正するために採用されたものであり、明らかに私たちの最優先事項です。
Visual C++または.NETを使用しているユーザーの数に関係なく、彼らは実際には対象読者ではありません。 UNIXツールを使いたくないが、私たちの主な焦点ではない人々のために物事が機能するのは素晴らしいことです。 Cygwin以外のものを使用したい人の問題を解決することは、私が優先度の高いものとは思いません。
Pipe.ccから：パイプの書き込み側がPIPE_TYPE_MESSAGEとして開かれていることに注意してください。このseemsは、Linuxパイプの動作をより厳密に模倣し、fhandler_pty_masterがチャンクでパイプに書き込み、Canonモードが指定されたときに改行で終了するため、ptyの処理に必ず必要です。
上記のコメントは、ここで「および」関係を示しています。メッセージタイプパイプは、Linux（UNIX）パイプの動作をより厳密に模倣し、ptyには必ず必要です。
私は、ランタイムがおそらくバグの多いジェームズに同意しますが、cygwinがこれらのシナリオを処理できるはずであることにも同意します。
お互いの完全な合意はあまり効果がありません。 Cygwinのソースコードは投票によって変更されません。
この1つの問題が最終的に何らかの形で修正されたとしても（誰が知っているのか）、3か月以内に他の何かを壊し、リグレッションを修正する気にはならないかもしれません。彼らはパッチを検討するかもしれませんが、機能するものを見つけるのにかなり時間がかかります。ネイティブのWin32アプリとの互換性を破り、Win32アプリを動作させるために時間を無駄にしたくないことは明らかだからです。だから、CygwinはWin32/Cygwinが混在する環境の安定したプラットフォームと見なすべきではないと思います-私の選択肢は何ですか？ bash以外への完全な書き換えを回避するために、どこから始めればよいですか？基本的なCygwinインストール+基本的なPerlスクリプト以外は使用しません。
UPDATE：この元の質問の投稿後、最終的にCYGWIN環境変数に新しいpipe_byteフラグを追加しました。ドキュメントをご覧ください。このフラグを設定すると、上記の問題が修正されます。非Cygwin Win32プログラムを呼び出すときは、alwayspipe_byteフラグが設定されていることを確認してください。
しかし、その後、.NET Framework 4.0およびCygwinとの非互換性を発見しました。 .NET Frameworkの以前のバージョンにはこの問題はありません。 Cygwinメーリングリストで最初にこの問題について言及しました。
Cygwinと.NET Framework 4.0間のパイプ同期と非互換性
実りのある応答が得られなかったので、私はさらに調査し、Cygwinがパイプのオーバーラップを作成していることがわかりました。これが問題の原因です。オーバーラップされたパイプでオーバーラップされていないWin32 API呼び出しを使用しようとすることは未定義であり、ほとんど（すべて？）のWin32非Cygwinプログラムは標準ファイルハンドルでオーバーラップされたI/Oを使用しません。これを防止するCYGWIN環境変数にpipe_nooverlapフラグを作成するパッチを提出しました。
残念ながら、彼らはパッチを拒否したので、メインのCygwin DLLでこれを見ることはありません。
パッチを拒否する理由：
- Cygwinのシグナル実装を壊したことが暗示されました。信号はまだオーバーラップパイプを使用しているため、これが当てはまるとは思いません。
- 問題を明らかに修正しているにもかかわらず、環境変数フラグを追加する気はありません。
- オーバーラップしないパイプを使用することさえできるコードをサポートしたくないのです。
このような推論と態度で、私は彼らの要件に合うようにパッチを変更する方法を考えることができないのです...彼らは非重複パイプがこれまで使用されることを禁止することに決心しているようです。私は今しばらくパッチを使用していますが、問題はありませんでした。また、pipe_nooverlapフラグが壊れる状況は考えられません（メーリングリストでフォローアップの電子メールを参照してください）が、トラブルが発生した場合に備えてフラグとして残しました。
したがって、Cygwinから非Cygwin Win32または.NET Frameworkプログラムを呼び出す場合は、次のことを行う必要があります。
- 使用しているCygwinバージョンのソースにパッチを適用します。このパッチが将来のCygwinバージョンに現れることを期待しないでください。
CYGWIN環境変数にpipe_byteおよびpipe_nooverlapフラグを設定します。
これは動作します...今のところ!!! Cygwinを何かに使用したい人に役立つ場合に備えて、これを投稿します。
私が見つけた最良の代替案は Gow（Gnu On Windows） です。
Cygwinの軽量な代替品であり、約10倍軽量です。私の知る限り、Gowと共にインストールされる130のツールは通常のWin32アプリケーションです。
手作業でインストールする必要があるという点で、「サポートされている」パッケージが少なくなる場合がありますが、以下はありません。
- パスの問題（
cygpathは常に解決できるわけではないため、非解決策です） - OSが「cygwin」であると報告するcygwinパッケージによって混乱するプログラム
- .dll/.so/.lib/.aの混乱
また、Windowsアプリケーションとの相互運用性が向上しています。
Cygnal は、変更されたCygwinを作成するプロジェクトです。Windowsユーザーに馴染みのある外部規約に従って、ネイティブWindowsプログラムとして実行するアプリケーションのランタイムサポートライブラリとして機能します。
アイデアは、Cygwinの実行可能ファイルを作成するのと同じコンパイラーであるデフォルトのツールチェーンを使用して、完全なCygwin環境を使用して開発できるということです。その後、Cygnalプロジェクトから変更されたcygwin1.dllをプログラムにバンドルすることにより、プログラムをCygnalプログラムとしてデプロイできます。
これは、多くのPOSIX依存関係があり、適切に機能が豊富で高品質のPOSIX実装が必要なプログラムに特に役立ちます。
プロジェクトリーダーは、Cygwin内からの非Cygwinプログラムの実行を実際にはサポートしていないため、これを実際の問題と見なしていないようです（サプライズ！）。
対照的に、Cygnalプロジェクトでは、この種の問題は、合理的な解決策がマージされる問題と見なされます。
以前は主にX11サーバー機能にcygwinを使用していました。リモートサーバーでツールを実行し、表示をローカルcygwinにエクスポートすると便利でした。私は、Xmingサーバーを使用して同じことを達成できることがわかりました。