我有一个针对Windows环境并着眼于未来的现有代码库，希望使它尽可能地成为跨平台的。
通过使用跨平台库，我对标准Linux发行版有所了解，但希望将其扩展到实时和嵌入式操作系统。

是否可以将大多数代码库移植到此类系统，还是需要针对该环境重新实现？如果需要重新创建零件，这些系统的开发是否需要不同类型的设计方法？一些供应商提供自己的IDE进行开发，这是必须的吗？或者我们是否可以标准化GNU工具链类型的构建过程？

潜在的坑洼可能是IPC处理方面的差异，但是如果没有进一步的暴露，很难掌握具体的细节。

注意：尽管目前基于Windows，但没有特别大量使用Win32 API(主要是COM)或者Windows类型。

谢谢

编辑：：代码库是C \ C ++

解决方案

如果应用程序主要是C和posix，那么它就不太难了。
今天的嵌入式平台可能意味着可以在紧凑型闪存卡上运行的XP或者Linux几乎是完整副本。

对于gui，QT和WX均具有嵌入式版本，可直接绘制小部件。

取决于嵌入式平台的功能。如果它是8位的话，那么我们将走得很艰难，但是如果它是32位的并且具有不错的RAM等，那么可以使用许多开源的跨平台库。

我在上一个嵌入式GUI应用程序中使用了DirectFB，它轻巧且可以，但不能跨平台。下次我想我将尝试wxWidgets。

我不喜欢在Windows上使用GNU开发工具，因为MS Dev Studio比任何GNU工具都要好得多，但是最近我一直在与基于Eclipse和GCC的Wascana Desktop Developer玩，这显示出了希望。

如果我们使用的是Windows COM接口(我假设我们不是在这里谈论串行端口，而是公共对象模型)，则可能需要从中抽象出代码。

当我们谈论IPC时，显然这是一个多任务/多处理类型的代码库。在这种情况下，我们将不得不以某种方式提出一种解决环境差异的方法。

首先，由于应用程序是多任务的，因此我们将需要某种RTOS。在移植到Linux时，我们可能需要考虑使用实时Linux版本。这样可以最大程度地减少我们必须执行的端口数量。

如果我们不想使用Linux作为嵌入式平台，请使代码与POSIX兼容(Linux是)，并确保我们选择的RTOS支持POSIX。这样，Linux和嵌入式平台的端口将基本相同。

最重要的是，COM将是信天翁。

由于我们没有提到GUI的使用，因此我们不会解决蠕虫的问题:)

最重要的步骤是将所有OS依赖功能与项目逻辑分开。

完成此操作后，我们将立即看到要移植到新OS所需移植的代码量，并且可以很好地开始移植。

如果我们可以指定使用哪种实时/嵌入式OS，我们是否考虑过Windows CE？