windows - 是否可以为 Windows (Win32) 编写 libPOSIX，而不需要始终加载的后台服务或 DLL？

Question

我知道 Cygwin，也知道它的缺点。我也知道 fork 的速度很慢，但不知道为什么在地球上不可能解决这个问题。我也知道 Cygwin 需要一个 DLL。我也明白 POSIX 定义了一个完整的环境(shell 等)，这并不是我真正关心的。

我的问题是问是否有另一种方法来解决这个问题。我看到越来越多的 POSIX 功能正在由 MinGW 项目实现，但是没有提供完整的(与 Linux/Mac/BSD 实现状态相当)POSIX 功能的完整解决方案。

问题归结为:能否有效地使用 Win32 API(从 MSVC20 开始？？)在 Windows API 上提供完整的 POSIX 层？

也许这会变成一个完整的 libc，它只利用操作系统库来处理低级的事情，比如文件系统访问、线程和进程控制。但我不确切知道 POSIX 还包含什么。我怀疑一个库能否将 Win32 变成一个 POSIX 兼容的实体。

Answer 1

POSIX <> Win32。

如果您尝试编写以 POSIX 为目标的应用程序，为什么不使用 *N*X 的某些变体？如果您更喜欢运行 Windows，则可以在 PC/笔记本电脑/等设备上运行 Linux/BSD/Hyper-V/VMWare/Parallels/VirtualBox 中的任何内容。

Windows 曾经有一个与 Win32 子系统一起运行的 POSIX 兼容环境，但由于缺乏需求而在 NT4 之后停产。微软收购 Interix 并发布 Services For Unix (SFU) .虽然它仍然是 available for download , SFU 3.5 现已弃用，不再开发或支持。

至于为什么 fork 这么慢，你需要明白 fork 不仅仅是“创建一个新进程”，它是“创建一个新进程(本身是一个昂贵的操作)，它是调用进程的副本以及所有内存”。

在 *N*X 中， fork 进程被映射到与父进程相同的内存页面(即非常快)，并且仅在 fork 进程尝试修改任何共享页面时才获得新页面。这称为写时复制。这在很大程度上是可以实现的，因为在 UNIX 中，父进程和分支进程之间没有硬性障碍。

另一方面，在 NT 中，所有进程都被 CPU 硬件强制执行的屏障分隔开。在 NT 中，生成可访问进程内存和资源的并行事件的最简单方法是创建线程。线程在创建进程的内存空间内运行，并且可以访问进程的所有内存和资源。

您可以还可以通过各种形式的 IPC、RPC、命名管道、邮槽、memory-mapped files 在进程之间共享数据。但每种技术都有其自身的复杂性、性能特征等。阅读 this了解更多详情。

因为它试图模仿 UNIX，CygWin 的“fork”操作会创建一个新的子进程(在其自己的独立内存空间中)，并且必须在新 fork 的子进程中复制父进程中的每一页内存。这可能是一项成本非常高的操作。

同样，如果您想编写 POSIX 代码，请在 *N*X 中进行，而不是在 NT 中进行。