我有一個針對Windows環境並着眼於未來的現有代碼庫，希望將其作爲跨平臺。 通過使用跨平臺庫，我已經獲得了一些標準Linux發行版的成功，但是希望將其擴展到Realtime和/或嵌入式操作系統。將Windows軟件移植到嵌入式/實時操作系統
是否可以移植的大部分代碼庫這樣的系統，或者它需要針對該環境reimplentations？如果部件需要重新創建，這些系統的開發是否需要不同類型的設計方法？一些供應商提供他們自己的IDE用於開發，這些都是必需的，或者我們是否能夠在GNU工具鏈構建過程中實現標準化？
一個潛在的坑洞可能是IPC處理分歧，但沒有進一步暴露，很難得到具體的句柄。
NB儘管視窗目前設，沒有特別重使用Win32 API（主要是COM）或Windows類型。
感謝
編輯::代碼庫是C \ C++
如果您使用Windows COM接口（我假設您不是在這裏討論串口，而是通用對象模型），那麼您的代碼可能需要從中抽象出來。
至於你說到的IPC，那麼很明顯，這是一個多任務/多線程處理類型的代碼庫。在這種情況下，你將不得不想辦法來應對環境差異。
首先，你的將需要某種RTOS，因爲你的應用程序是多任務處理。當你做了一個Linux端口的時候，你可能需要考慮使用一個實時Linux版本。這樣可以儘量減少你需要做的端口數量。
如果您不想使用Linux作爲您的嵌入式平臺，請使您的代碼符合POSIX（Linux標準）並確保您選擇的RTOS支持POSIX。這樣，到Linux和嵌入式平臺的端口將大致相同。
底線，COM將是你的信天翁。
既然你不提使用GUI的，我們不會解決是可以蠕蟲:)
如果應用程序主要是C和POSIX那麼它是不是太硬。今天的嵌入式平臺可能意味着在CompactFlash卡上運行的XP或Linux的幾乎完整副本。
對於Qt和WX具有嵌入式直接繪製控件版本的GUI。
我不喜歡在Windows上使用GNU開發工具，因爲MS Dev Studio比任何GNU工具都好得多，但最近我一直在玩基於Eclipse和GCC的Wascana Desktop Developer，並且它顯示了承諾。
最重要的步驟是從項目邏輯中分離出來的所有操作系統的依賴功能。
當你這樣做後，你會立即看到你需要移植多少代碼才能遷移到新的操作系統，並且你將能夠很好地移植。
如果您處於指定您使用哪種實時/嵌入式操作系統的位置，您考慮過Windows CE嗎？