Linux 和 Windows 之间的移植是如何工作的？

How does porting between Linux and Windows work?

提问by Kefka

If a particular piece of software is made to be run on one platform and the programmer/company/whatever wants to port it to the other, what exactly is done? I mean, do they just rewrite linux or windows-specific references to the equivalent in the other? Or is an entire rewrite necessary?

如果某个特定的软件要在一个平台上运行，而程序员/公司/任何想将它移植到另一个平台上的软件，究竟要做什么？我的意思是，他们是否只是将 linux 或 windows 特定的引用重写为另一个中的等价物？还是需要完全重写？

Just trying to understand what makes it so cost-prohibitive that so many major vendors don't port their software to Linux (specifically thinking about Adobe)

只是想了解是什么让它的成本如此之高以至于许多主要供应商不将他们的软件移植到 Linux（特别是考虑 Adob​​e）

Thanks

谢谢

采纳答案by chris

this is the point of a cross-platform toolkit like qt or gtk, they provide a platform-agnostic API, which delegates to whichever platform the program is compiled for.

这是像 qt 或 gtk 这样的跨平台工具包的重点，它们提供了一个与平台无关的 API，它委托给编译程序的任何平台。

some companies don't use such a toolkit, and write their own (for whatever reason - could well be optimisation-related), meaning they can't just recompile their code for another os.

一些公司不使用这样的工具包，而是自己编写（无论出于何种原因 - 很可能与优化相关），这意味着他们不能只是为另一个操作系统重新编译他们的代码。

回答by lfan

There are also libraries available that ease, at least on a specific area, the port of Windows API calls to Linux. See the Windows to Linux porting library.

还有一些可用的库，至少在特定区域，可以简化 Windows API 调用到 Linux 的端口。请参阅Windows 到 Linux 移植库。

回答by peter

There are many reasons why it may be very difficult to port an application to a different platform, most often it is because some interfaces the application uses to communicate with the system are not available, and one either has to implement them on their own, port a library your application depends on, or rewrite the application, so that it uses alternative functions. Most languages today are very portable across hardware architectures and operating systems, but the problem is with libraries, system calls and potentially other interfaces the OS (or platform) provides. To be more specific:

将应用程序移植到不同平台可能非常困难的原因有很多，最常见的原因是应用程序用于与系统通信的某些接口不可用，并且必须自己实现它们，端口应用程序依赖的库，或重写应用程序，以便它使用替代函数。今天的大多数语言在硬件架构和操作系统上都具有很强的可移植性，但问题在于库、系统调用和操作系统（或平台）提供的其他潜在接口。更具体：

• Compilers may differ in their configuration and the standard functions they provide. On Windows the most popular compiler for C/C++ is Visual Studio, while on unix it is gcc and llvm (in combination with the standard library glibc or BSD libc). They expect different flags, different forms of declaration, produce different file format of executables and shared libraries. Even though C and C++ have standard libraries, they are implemented differently across platforms. There are some systems whose aim is to make compilation portable, such as Autotools, CMake and SCons.

• On top of standard libraries there are additional functions OS provides. On Windows they are covered by win32 API, on unix systems these are part of the POSIX standard, with various GNU, BSD and Linux specific extensions, and there are also plain system calls (the lowest-level interface between applications and the operating system). POSIX functions are available on Windows via systems such as cygwin and mingw, win32 API function are available on unix via Wine. The problem is that these implementations are not complete, and often there are minor (but important) differences.

• Communication with the desktop system (in order to make a GUI interface) is done differently. On Linux this might be the X Window System (together with freedesktop libraries) or Wayland, while Windows has its own systems. There are GUI libraries which try to provide an abstract interface for these, such as Qt, GTK, wxWidgets, EFL.

• Other services the OS provides, such as network communication may be implemented differently. On Windows many applications use .NET libraries, for which there is only limited support on unix systems. Some unix applications rely on Linux-specific features such as systemd, /proc, KMS, cgroups, namespaces. This limits portability even among unix systems (Linux, BSD systems, Mac OS X, ...). Even .NET libraries are not very compatible across different versions, and they might not be available on an older version of Windows or on embedded systems. Android and iOS have different interfaces entirely.

• Web applications are usually the most portable, but HTML5 is a live standard, and many interfaces may not be available yet in some browsers/web engines. This requires the use of polyfills, but it is usually much less painful than the situation with "native" applications.

• 编译器的配置和提供的标准功能可能不同。在 Windows 上，最流行的 C/C++ 编译器是 Visual Studio，而在 unix 上是 gcc 和 llvm（与标准库 glibc 或 BSD libc 结合使用）。他们期望不同的标志、不同的声明形式、产生不同的可执行文件和共享库的文件格式。尽管 C 和 C++ 具有标准库，但它们跨平台的实现方式不同。有一些系统旨在使编译可移植，例如 Autotools、CMake 和 SCons。

• 在标准库之上还有操作系统提供的附加功能。在 Windows 上，它们由 win32 API 覆盖，在 unix 系统上，它们是 POSIX 标准的一部分，具有各种 GNU、BSD 和 Linux 特定扩展，还有普通系统调用（应用程序和操作系统之间的最低级接口） . POSIX 函数可通过 cygwin 和 mingw 等系统在 Windows 上使用，win32 API 函数可通过 Wine 在 unix 上使用。问题是这些实现并不完整，并且通常存在细微（但重要）的差异。

• 与桌面系统的通信（为了制作 GUI 界面）的方式不同。在 Linux 上，这可能是 X Window System（与 freedesktop 库一起）或 Wayland，而 Windows 有自己的系统。有一些 GUI 库试图为这些提供抽象接口，例如 Qt、GTK、wxWidgets、EFL。

• 操作系统提供的其他服务，例如网络通信，可能会以不同的方式实现。在 Windows 上，许多应用程序使用 .NET 库，而在 unix 系统上仅对其提供有限的支持。一些 Unix 应用程序依赖于 Linux 特定的功能，例如 systemd、/proc、KMS、cgroups、命名空间。这限制了即使在 unix 系统（Linux、BSD 系统、Mac OS X 等）之间的可移植性。甚至 .NET 库在不同版本之间也不是很兼容，并且它们可能无法在旧版本的 Windows 或嵌入式系统上使用。Android 和 iOS 的界面完全不同。

• Web 应用程序通常是最可移植的，但 HTML5 是一个实时标准，许多界面可能在某些浏览器/Web 引擎中尚不可用。这需要使用 polyfill，但通常比使用“本地”应用程序的情况要少得多。

Because of all of these limitations, porting can be a pretty hard work and sometimes it is easier to create a new application from scratch, either specifically for the other platform, using cross-platform abstraction libraries/platforms (such as Qt or Java), or as a web application (potentially bundled in something like Electron). It is a good idea to use these from the beginning, but many programmers choose not to because the applications tend to look and behave differently from "native" applications on the platform, and they might also be slower and more restricted in the way they interact with the OS.

由于所有这些限制，移植可能是一项非常艰巨的工作，有时从头开始创建新应用程序会更容易，无论是专门针对其他平台，使用跨平台抽象库/平台（例如 Qt 或 Java），或作为 Web 应用程序（可能捆绑在 Electron 之类的东西中）。从一开始就使用这些是个好主意，但许多程序员选择不这样做，因为这些应用程序的外观和行为往往与平台上的“本机”应用程序不同，而且它们的交互方式也可能更慢且受到更多限制与操作系统。

回答by Larry Gritz

In my experience, there are three main reasons why it's cost-prohibitive to take a large existing program on one platform and port it to another:

根据我的经验，在一个平台上采用现有的大型程序并将其移植到另一个平台上的成本过高，主要有以下三个原因：

1. it has (not necessarily purposely) extensively used some library or API (often GUI, but there are also plenty of other things) that turns out not to exist on the other platform

2. it has unknowingly become riddled with dependency on nonstandard features or oddities of the compiler or other tools

3. it was written by somebody who didn't know that you hadto use some oddball feature to get things to work on the other platform (like a Linux library that isn't sprinkled with the right __declspecdirectives you need for a good Windows DLL).

1. 它（不一定是故意）广泛使用了一些库或 API（通常是 GUI，但也有很多其他东西），结果证明在其他平台上不存在

2. 它在不知不觉中变得依赖于非标准功能或编译器或其他工具的奇怪之处

3. 它是由某人编写的，他不知道您必须使用一些奇怪的功能才能在其他平台上运行（就像一个 Linux 库，它没有散布__declspec良好的 Windows DLL 所需的正确指令）。

It's much easier to write a cross-platform app if you consider that a design goal from the start, and I have three specific recommendations:

如果您从一开始就将其视为设计目标，那么编写跨平台应用程序会容易得多，我有以下三个具体建议：

• Use Boost—oodles of handy things you might ordinarily get from platform-specific APIs and libraries, but by using Boost you get it cross-platform.

• Do all your GUI programming using a cross-platform library. My favorite these days is Qt, but there are other worthy ones as well.

• Build and test every dayon both platforms, never provide an opportunity for the code to develop a dependency on only one platform and discover it only too late.

• 使用 Boost — 您通常可以从特定于平台的 API 和库中获得大量方便的东西，但是通过使用 Boost，您可以获得跨平台的功能。

• 使用跨平台库完成所有 GUI 编程。这些天我最喜欢的是 Qt，但也有其他有价值的。

• 每天在两个平台上进行构建和测试，永远不要让代码有机会开发仅依赖于一个平台的依赖项并且发现它为时已晚。

回答by small_duck

Porting a piece of software that has not been made platform-independant upfront can be an enormous task. Often, the code is deeply ingrained with non-portable APIs, whether 3rd party or just OS libraries. If the 3rd party vendor does not provide the API for the platform you are porting on, you are pretty much forced into a full rewrite of that functionality, or finding another 3rd party that is portable. This only can be awfully costly.

移植一个没有预先独立于平台的软件可能是一项艰巨的任务。通常，代码与不可移植的 API 根深蒂固，无论是 3rd 方还是 OS 库。如果第 3 方供应商没有为您要移植的平台提供 API，则您几乎被迫完全重写该功能，或者寻找另一个可移植的第 3 方。这只可能是非常昂贵的。

Finally, porting software also means supporting it on another platform, which means hiring some specialists, and training support to answer more complex queries.

最后，移植软件还意味着在另一个平台上支持它，这意味着聘请一些专家，并培训支持以回答更复杂的查询。

In the end, such a process can be very costly, for very little additional sales. Sadly, the decision is easy: concentrate on new functionality on your current platform that you know your customers are going to pay for.

最后，这样的过程可能会非常昂贵，额外的销售额很少。遗憾的是，决定很简单：专注于您当前平台上的新功能，您知道您的客户会为此付费。

回答by Robert Harvey

Under Mono, you can write a C# Winforms program that works on both platforms. But to make that possible, the Mono team had to write their own Winforms library that essentially duplicates all of the functions of Winforms. So there is still no free lunch.

在 Mono 下，您可以编写可在两个平台上运行的 C# Winforms 程序。但要实现这一点，Mono 团队必须编写自己的 Winforms 库，该库基本上复制了 Winforms 的所有功能。所以仍然没有免费的午餐。

回答by Bozhidar Batsov

Most software is portable to some extent. In the case of a C app - there will be a lot of #ifdefs in the area, apart from path changes, etc.

大多数软件在某种程度上是可移植的。在 C 应用程序的情况下 - 除了路径更改等之外，该区域还会有很多 #ifdefs。

Rarely windows/linux version of the same software don't share a common codebase - this would actually mean that they only share a common name. It's always harder to maintain more codebases, but I think that the actual problem with porting applications has little to do with the technical side and a lot with business side. Linux has much fewer users that Windows/OSX, most of them expect everything to be free as in beer or simply hate commercial software on some religious grounds.

很少有相同软件的 windows/linux 版本不共享通用代码库 - 这实际上意味着它们只共享一个通用名称。维护更多的代码库总是很困难，但我认为移植应用程序的实际问题与技术方面关系不大，而与业务方面关系很大。Linux 的用户比 Windows/OSX 少得多，他们中的大多数人希望一切都像啤酒一样免费，或者只是出于某些宗教原因讨厌商业软件。

When you come to think about it - most open source software is multiplatform, no matter what language was used to implement it. This speaks for itself...

仔细想想 - 大多数开源软件都是多平台的，无论使用什么语言来实现它。这不言自明...

P.S. Disclaimer - I'm an avid supporter of Free and Open source software, I don't want to insult anybody - I just share my perspective on the topic.

PS 免责声明 - 我是自由和开源软件的狂热支持者，我不想侮辱任何人 - 我只是分享我对这个话题的看法。

回答by Marcelo Cantos

If the software was written for a single OS, a major rework is likely. The first step is to move absolutely all platform-specific code into a single area of the code base; this area should have little or no app-specific stuff. Then rewrite this isolated portion of the code for the new target OS.

如果软件是为单个操作系统编写的，则可能需要进行重大返工。第一步是将所有特定于平台的代码绝对移动到代码库的一个区域中；这个区域应该很少或没有特定于应用程序的东西。然后为新的目标操作系统重写代码的这个孤立部分。

Of course, this glosses over some extremely major implications. For instance, if your first version targeted the Win32 API, then any GUI code will be heavily tied to Windows, and to maintain any hope of preserving your sanity, you will need to move all that code to a cross-platform GUI framework like Qt or GTK.

当然，这掩盖了一些极其重大的影响。例如，如果您的第一个版本针对 Win32 API，那么任何 GUI 代码都将与 Windows 紧密相关，并且为了保持您的理智，您需要将所有这些代码移动到跨平台 GUI 框架，如 Qt或 GTK。