在POSIX项目中增加对Windows的支持有多痛苦？值得付出努力吗？

Question

我正在尝试/考虑使CppCMS - C++网络框架项目更加跨平台。

今天，我可以轻松地支持Linux、OpenSolaris、FreeBSD甚至Cygwin。但是当涉及到本机Windows时，它会变得非常痛苦：

概况：

1. 我是POSIX/Linux，对Visual和Win32 API等原生Windows开发工具几乎不熟悉。然而，我为这个平台做了一些工作，所以我理解Windows是完全不同的世界的局限性和事实。
2. 这是一个web项目，它使用在Unix世界中流行的API，比如:CGI、FastCGI和SCGI，它们在大多数UNIX服务器上都实现了；但是我知道我无法在IIS上使用它，因为它不支持FastCGI /IP(只有Windows )。 因此，即使它能够工作，它也可能只在Apache的Windows端口上运行。
3. 我对POSIX API作了大量介绍：

- Pref-forking allows be keep high survivability in case of crashing (not supported under windows) so this feature would be missing.
- I use some file-locking facilities (but I can probably give them up without forking)
- I have intensive use of native pthreads, even I can replace them with Boost.Thread

​

1. 我可能永远无法支持Visual (可能是2010年有C++0x支持)，因为我转发了C++0x解密类型/auto特性或typeof/_typeof_ extension，这是我工作过的大多数编译器都支持的: gcc、英特尔、sun studio。(老实说:我可以不用它们工作，但它使框架用户的生活变得更加容易。)
2. 我大量地使用自动工具，我不能用CMake、bjam或朋友来代替它们，因为当涉及到支持国际化、交叉复制、包管理时，它们只是没有给我一个解决方案。
3. 有许多恼人的地方，如缺少gmtime_r，或windows下的localtime_r，以及许多其他只需要我重写它们或用第三方库替换它们的地方。
4. 仍然有许多“类似UNIX”的库移植到Win32，如: iconv、gcrypt和其他一些几乎没有像libdbi那样移植的库，这些库在windows上有许多限制。

底线：

有许多重要的工作要做，即使它完成了，它也可能只使用MingW工具，而不是Windows程序员熟悉的“原生”工具。

所以，我的问题是：

• 这样的MingW端口值得付出努力吗？这对建设更大的社区有帮助吗？
• 有谁有过将大型项目从POSIX环境移植到Win32 API有多痛苦的经验吗？
• 这对Windows开发人员有用吗？

编辑：

对我来说也很重要的一点是，有多少windows开发人员更喜欢使用开源开发工具，MingW而不是微软的开发解决方案，比如VS。

编辑#2:关于“本机”windows解决方案和IIS的定义。

实际上，使用IIS运行框架是一个非常困难的问题。我解释：

• 该项目涉及标准 web服务器API作为FastCGI或SCGI，允许通过sinlge套接字接受许多请求。因此，在应用程序端，我接受新的请求，处理它并返回答案。有时，有几个线程处理多个请求。 因此，实现一个或两个标准协议我开放与任何现有的服务器: Apache，lighttpd，nginx，cherokee.或任何其他服务器；只有IIS的小例外
• IIS有FastCGI的实现，但是.它只允许由web服务器控制的.

所以..。绝对没有将我的应用程序连接到IIS的标准方法。

请注意，我实现了标准的 Web服务器API，我既没有实现IIS专有的ISAPI，也没有实现Apache专用的API，甚至对于面向UNIX世界来说，第二个更重要。

因此，只是Windows IIS Web world还没有真正准备好为这样的项目进行合作，所以如果有人在Windows下使用它，它将与更开放的web服务器一起使用它。

Answer 1

你应该根据用户的需求做出决定。用户是否曾在Windows上请求使用该框架？如果是这样的话，他们是否解释了为什么要使用Windows (例如，他们有哪些附加约束，他们想使用什么why服务器，等等)？

通常情况下，Windows用户确实期望事情按照Windows的方式工作。这意味着Visual支持、IIS支持、MSI安装程序等等。如果有些东西仍然觉得是Unix，我宁愿使用Unix适当，而不是与一个半工作的端口战斗。

Answer 2

作为一个windows客户端应用程序开发人员，目前开发环境部门本质上是Win32和其他一切，而且它们大多是不兼容的，这给我带来了一定的伤害。这就是为什么我准备为我的个人windows应用项目搬到MinGW，并试图让他们跨平台。

我建议逐步转向更多的跨平台库，如您所建议的那样，重构线程以增强：：fork()，或者使用IPC从fork()转到多进程，可能也使用boost的工具。日期/时间的东西，也可以处理升级换代。至于数据库支持，有

我认为微软的编译器支持并不重要，因为MinGW提供了一个很好的构建环境，支持它的所有IDE，Eclipse和Dev-C++都是最受欢迎的。但是，如果要使项目msvc兼容，请确保用户能够使用Visual 2010的Express版本(一旦发布)--这样就不会有人只为使用您的项目而为Visual 2010 (升级)支付费用，而且您也不会需要使用微软的最新技术。

您很可能不会为了项目规模的代码库而避免使用一定数量的ifdef，但这些努力肯定是值得的，如果不仅仅是因为获得了宝贵的经验并与一些新的快乐和感激的成员一起扩展了社区。

Answer 3

您说您可以很容易地支持Cygwin，这一说法提醒我，我曾经看到过一些商业Windows软件，它们只是捆绑在cygwin1.dll中来支持一些原来的Unix代码。如果将cygwin1.dll添加到安装程序中就足够了，那么就试试它吧。