我正在考虑一个跨平台的C ++服务器应用程序，该应用程序可能涉及大量的Internet流量和多线程密集型计算。我已经阅读了有关Cygwin和MinGW跨平台C ++应用程序的一些比较。根据Kaz关于5th answer of this StackOverflow question的新信息，我能否说Cygwin的未来更好？
2019年7月19日，Kaz添加了以下新信息（从那里复制）：
插件：：LGPL发布后不久，我启动了Cygnal（Cygwin本机应用程序库）项目，以提供旨在解决这些问题的Cygwin DLL的分支。程序可以在Cygwin下开发，然后与Cygnwin1.dll的Cygnal版本一起部署，而无需重新编译。随着该库的改进，它将逐渐消除对MinGW的需求。
当Cygnal解决路径处理问题时，有可能开发一个可执行文件，当与Cygnal一起作为Windows应用程序提供时，该可执行文件可以与Windows路径一起使用，而当安装在/ usr /中时，可以无缝与Cygwin路径一起使用。 Cygwin下的Bin。在Cygwin下，该可执行文件将透明地使用/ cygdrive / c / Users / bob之类的路径。在与cygwin1.dll的Cygnal版本链接的本机部署中，该路径没有意义，而它将理解c：foo.txt。
他说：随着该库的改进，它将逐渐消除对MinGW的需求。这到底是什么意思？
答案 0 :(得分：3)
我完全不这么认为。
首先，我不再考虑使用MinGW，因为MinGW-w64是更好，最新的替代品。
其次，Cygwin和MinGW-w64具有不同的目标。
Cygwin希望提供足够的Unix / POSIX仿真来编译本来很难移植到本机Windows的代码。因此，Cygwin二进制文件依赖于此仿真层，这意味着它们并不是真正的本机Windows，因为始终存在仿真层，这也带来了性能开销。
但是MinGW-w64旨在允许编译为本地Windows二进制文件。缺点是并非所有Unix / Linux / POSIX源都可以使用它进行编译（例如fork()不存在），但是很多事情确实可以编译，并且它们会产生高性能的本机Windows二进制文件。
在过去的十年中，我个人根本不需要使用Cygwin。 我现在用MinGW-w64构建所有内容。实际上，我的电脑上甚至没有MSVC或任何其他编译器（例如Borland或Intel）。
我的建议始终是：仅在确实需要时才使用Cygwin。否则，MinGW-w64（尤其是与MSYS2结合使用）始终是您的最佳选择。 如果您计划构建用于商业发行的软件，则尤其如此。如果我要购买软件并发现Cygwin DLL是其中的一部分，那会让我皱眉，不知道该软件是否真的适用于Windows。
虽然MSYS2提供了不错的MinGW-w64 GCC编译器，但我决定启动http://winlibs.com/项目，以提供我自己的MinGW-w64 GCC，甚至LLVM / Clang以及将来的许多库对于本机win32和win64。
关于您的问题的结论： 如果您打算构建一些需要提高资源效率的东西，我真的建议您不要承担Cygwin的性能开销，而要使用MinGW-w64来实现最大的本机性能。