假设我有一个我在cygwin下编译的应用程序,我希望在没有用户安装cygwin的情况下分发该应用程序.打包可执行文件和cygwin DLL是否足够？
事情变了。Cygwin 库现在属于 Lesser GPL (v3)，这使得可以将它们与属于广泛许可范围的应用程序捆绑在一起，从 FOSS 到专有。
阻碍的是 Cygwin 中的 POSIX 仿真从原生 Windows 应用程序的角度来看有点太远了。
这就是我的Cygnal项目的用武之地。 Cygnal 代表 CYGwin 本机应用程序库：它是 Cygwin 的一个插入式兼容分支，它改变或在某些情况下只是重新配置某些功能的行为以符合本机Windows 平台的约定。
一个基本的“Hello, World”Cygwin 程序需要两个库。一个 GCC 运行时调用cyggcc_s-1.dll和 Cygwin DLL cygwin1.dll。Cygnal 项目提供了后者的替代品。（32 位版本可供下载）。
Cygwin POSIX 世界观与 Windows 之间的一个明显不兼容领域是路径处理。文件系统的 Cygwin 视图是通过一个假的/根目录，以及它自己的内部“挂载表”，它提供了像/cygdrive,/proc和/dev. Cygnal 消除了这一切。路径是 Win32 路径。当前工作目录的行为类似于 Windows 当前工作目录。驱动器与当前目录相关联，驱动器相对路径与D:foo.txtCygnal 下的工作类似。在 Cygnal 下，/dev并且/proc仍然可用：它们作为特殊前缀dev:/和proc:/. 不允许chdir进入这些：那不是本地人！在 Cygnal 下，如果您chdir要D:\wherever那么您当前的驱动器是D驱动器，路径/foo或\foo引用D:\foo. Cygwin 的主 POSIX 根目录消失了。
然而，与使用 MinGW 或 Microsoft Visual C/C++ 维护端口相比，借助 Cygnal，您可以继续使用 POSIX 功能，从而可以开发基于平台切换的代码更少的跨平台程序。
例如：您可以使用 VT100 代码和termios. 相同的代码将在 Unix 上运行。无需在 Windows 上使用 Win32 控制台 API，termios在 POSIX 系统上使用VT100/ 。
另一个例子：对于线程，你可以只使用 POSIX 线程。pthread_create启动一个线程，pthread_mutex_lock锁定一个互斥锁等等。您的程序不需要可转换为 Win32 或 POSIX 的线程的可移植性抽象；您只需使用 POSIX，仅此而已。
unameCygnal 中的函数sysname使用CYGNAL前缀而不是 来报告CYGWIN。通过这种方式，您的程序可以判断它运行在 Cygnal 而不是 Cygwin（或任何其他 POSIX 平台）上。因此，您可以进行任何必要的调整：例如，如果您的程序需要/dev/null，则可以在 Cygnal 上查找dev:/null。
您的应用程序是否真的需要任何 Cygwin 提供的 Posix 仿真？如果没有，您可以使用 -mno-cygwin 标志编译它，它根本不依赖于 cygwin，而是一个本机 Windows 应用程序。通常，您只需要一个真正的 shell (bash) 来配置和构建您的应用程序，但您实际上并不需要 Cygwin 的 Posix 功能。
另一种选择是MSYS + MinGW，它是 Cygwin 的轻量级叉。这提供了一个编译环境，默认情况下会生成本机 Windows 应用程序。
第三种选择是使用 Cygwin 本身的 MinGW 编译器。它们应该可以通过普通的 Cygwin 包管理器获得。然后，您将使用 MinGW 编译器配置项目以进行交叉编译。