将大型 C 项目从 Unix 移植到 Windows
因此，我有一个完全基于 Unix (SPARC Solaris) 构建的大型 C 项目。我和其他几个人已经开始重新审视它，因为他们对 Windows 构建很感兴趣。
我们没有人用过如此规模的项目来做到这一点，所以对于初学者来说，有没有人将一些东西从 UNIX 移植到 Windows 上，也许可以给我一些指导或者他们是如何做到的。
我们计划的第一步是决定编译器/开发环境。
看来我们的选择是 MS Visual Studio、Cygwin、mingw/gcc 和 Windows Services for UNIX (SFU)。
我们的时间表相当短，因此我们希望重写尽可能少的代码。
所以，决定编译器。
另一个问题是代码确实使用了 POSIX 线程命令（pthread 等），
我们更愿意本地编译，而不是在可执行文件和操作系统之间使用某种层。不幸的是，对于我们代码中的 pthread 调用，这可能是不可能的。
我相信 Cygwin 和 SFU 都做到了这一点。 Cygwin 有一个 .dll，必须包含在编译代码中才能工作。我不确定 SFU，任何有关这方面的信息将不胜感激。这似乎是一个不错的选择，但开发它是为了允许 UNIX 编译的软件在带有 SFU 的 Windows 机器上运行，而不是在任何旧的 Windows 机器上运行。
mingw 确实有能力创建本机 exe，但缺乏 POSIX 支持。
那么，任何人都可以在这方面为我提供有关这些编译器的更多信息、建议和知识吗？或者他们在此类事情上有任何经验，我们非常感激。
So, I have a large C project that was built entirely on Unix (SPARC Solaris). me and several others have begun to revisit it because their was some interest in a windows build.
none of us have done this with a project of such size, so for starters, has anyone ported something from unix to windows and could maybe give me some pointers or how they did it.
our first step on our plan was to decide on a compiler/dev environment.
it seems that our options are MS Visual Studio, Cygwin, mingw/gcc, and Windows Services for UNIX (SFU).
we are on a fairly short timetable so we want to rewrite as little code as possible.
so, Deciding on a compiler.
Another issue is that the code does use POSIX thread commands (pthread, etc)
we would prefer to compile natively, not using some sort of layer between the executable and the OS. unfortunatly with the pthread calls in our code, this may not be possible.
I believe both Cygwin and SFU do just that. Cygwin has a .dll that must be included in compiled code to work. I am not sure about SFU, any information about that would be greatly appreciated. It seems like it would be a good option but was developed to allow for UNIX compiled software to run on a windows machine with SFU, not any old windows box.
mingw does have the ability to create native exes, but lacks the POSIX support.
So, can anyone give me any more information, suggestions, knowledge on any of these compilers in this context. or any experience they have with this sort of thing, it is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
时间表短？ CygWin，简单明了。
尽管您偏好不使用图层，但这将提供最快的路径，并且您似乎没有表明时间范围要求是灵活的。
我们已经使用 CygWin 将命令行和基于 X 的 UNIX 程序轻松移植到 Windows。
Short timetable? CygWin, plain and simple.
Despite your preference to not use a layer, that's going to provide the fastest path and you don't seem to indicate that the timeframe requirement is flexible.
We've ported both command-line and X-based UNIX programs to Windows using CygWin with minimal hassle.
Cygwin 可能是获得可执行文件的最快路径。然而，它会给你留下一些有趣的发行选择。最明显的是，cygwin.dll 成为了依赖项。它的授权是GPL，除非你花钱购买商业使用权。
Cygwin 对于普通 Windows 用户来说并不是特别友好。它的目标是在 Windows 上提供完整的 POSIX 体验，提供 shell、所有熟悉的 *nix 实用程序，甚至 X 端口。但是，它还将 Windows 磁盘驱动器命名重新映射到类似 POSIX 的文件系统。我从未尝试将为 Cygwin 构建的应用程序分发到尚未完整安装 Cygwin 的计算机。我要指出的是，据我所知，没有一个带有 Windows 移植的大型知名开源应用程序是基于 Cygwin 的。
如果您拥有的唯一硬 POSIX 依赖项是 pthreads，那么这是可以解决的。有一个基于本机 Windows 线程构建的 pthreads 端口，可以与 MinGW 很好地配合。 IIRC，它甚至与 MinGW 一起分发，或者至少是他们的核心支持包之一。
如果文件名的其余处理大部分是不透明字符串，您甚至可能不需要关心将
/更改为\。 Windows API 通常很乐意将任一字符视为路径分隔符，甚至混合在同一名称中。 CMD.EXE 和早期 DOS 约定使用/作为命令行选项，阻止在命令提示符下使用/作为路径名，而不是底层的 Windows API。对于可能使构建过程的移植变得更容易的工具，请查看 MinGW 的 MSYS 组件。它提供了来自 Cygwin 环境的轻量级分支，其中有足够的 *nix 实用程序可用于一般运行
./configure和类似的进程。此外，GnuWin32 项目拥有大量实用程序和库的移植，这些实用程序和库都被构建为运行没有异常依赖性的本机 Windows 应用程序。
Cygwin is likely the fastest path to a working executable. However it will leave you with some interesting distribution choices. Most obviously, cygwin.dll becomes a dependency. Its licensed GPL, unless you pay money to buy commercial use rights.
Cygwin is not particularly friendly to an ordinary Windows user. Its goal is to provide a full POSIX experience on Windows, supplying a shell, all the familiar *nix utilities, and even a port of X. However, it also remaps the Windows disk drive naming into a POSIX-like file system. I've never attempted to distribute an application built for Cygwin to machines that don't already have a full Cygwin installation. I will note that to my knowledge none of the big well-known open-source applications with Windows ports are based on Cygwin.
If the only hard POSIX dependency you have is pthreads, then that is solvable. There is a pthreads port built on native Windows threads that works well with MinGW. IIRC, it is even distributed along with MinGW, or at least is one of their core supported packages.
If the rest of your handling of file names is largely as opaque strings, you may not even need to care about changing
/to\. The Windows API is generally happy to treat either character as a path separator, even mixed in the same name. It is the CMD.EXE and early DOS convention of using/for command line options that prevents the use of/for pathnames at the command prompt, not the underlying Windows API.For tools that might make porting your build process easier, check out the MSYS component of MinGW. It provides a lightweigh fork from the Cygwin environment in which enough *nix utilities are available to generally run
./configureand similar processes.In addition, the GnuWin32 project has ports of a large number of utilities and libraries that are all built to run as native Windows applications without unusual dependencies.
如果代码（至少大部分）是可移植的，并且唯一的主要问题是 pthread 的使用，您可能需要使用 Pthreads Win32 库。虽然不完整，但它足够完整和准确，足以处理我尝试过的大多数 pthreads 代码。虽然通常构建为 DLL，但也可以构建为静态库，以避免在可执行文件中创建额外的依赖项。
当然，这让其他一切都需要移植——但你还没有说得足够多，甚至无法猜测在你的时间范围内移植其余部分是否合理。
If the code is (at least mostly) portable and the only major issue is the use of pthreads, you might want to use the Pthreads Win32 library. While incomplete, it's sufficiently complete and accurate to deal with most pthreads code I've tried it with. While normally built as a DLL, this can also be built as a static library to avoid creating an extra dependencies in your executable.
That, of course, leaves everything else to port -- but you haven't said enough to even guess whether porting the rest within your timeframe is at all reasonable.