最近，一直在作libc的移植，上網查了很多資料，找到很多libc，如glic，uclibc，diet libc，newlib等，但除了newlib以外，都和linux等系統緊密聯繫，移植的工作量太大。
newlib可以在很多的平臺和操作系統中使用，移植的時候只要提供十幾個必須由操作系統才能實現的函數即可。關於newlib的資料，大多數都是和交叉編譯相關的，因此我照着資料，用了很多方法，最後終於在cygwin下，成功的編譯出了newlib，但卻是用於arm平臺的。用於386平臺的，始終沒有編譯成功（記得是gcc無法編譯）。後來決定直接移植newlib的源代碼，加上適當的編譯選項，直接編譯，遇到問題，就實現需要的函數。最後，成功編譯了大部份的函數，但使用起來好像還有點問題。比如print函數，就不能正常工作。只有換行之前的字符纔會輸出。問題一時無法解決，我又繼續移植了djgpp的libc，雖然不太喜歡這個庫，但它工作的很好。
說到這兒，又想起了gui的問題。MyOS有自己的gui，但個人能力畢竟有限，MyOS的gui雖然工作的很好，但需要
做得工作還非常多，只實現了幾個簡單的控件，無法滿足應用程序開發的需求。因此，我也經常查一些gui的資料。但和libc的情況一樣，大部分的gui都是用於linux平臺的，有的基於X，有的基於linux的FrameBuffer，關鍵是和平臺關係緊密，可移植性太差。有幾個自稱跨平臺的gui，比如wxWidget，fltk，fox等，下回來一看，都是在不同的平臺重寫很多的東西，比如wxWidgt，控件本身就是封裝的系統控件，這顯然無法移植到MyOS中（如果MyOS有它需要的控件，我也不會想着移植了，呵呵）。還有fltk，據說移植性很好，全部的代碼都是基於畫點的，所有的控件都是畫出來的，所以移植和增加控件都很容易。這正是我想要的。MyOS自己的gui就是這麼實現的，完全與平臺無關，只需提供一個blt函數即可。下載回來代碼一看，對系統的依賴還是比較厲害。折騰了一下午，決定還是放棄了。
這裏，談一談我的看法。newlib和fltk作爲跨平臺的libc和gui，基本提供了很好的可移植性。但還是有很多不足。
就拿newlib來說，只要實現十幾個函數，就可以移植到新的平臺，但需要配置很多東西，才能在一個新平臺下順利
編譯，雖然它提供了自動的配置工具幫助在已支持的平臺上編譯，但對應新的平臺，就不到不修改很多配置文件。
而且，代碼中用到了很多的define，根據平臺來包含一些代碼。我認爲這兩方面都損害了可移植性。我心中理想的
可移植性是，只要提供需要的函數，用任何一個c編譯器直接編譯鏈接即可。而配置文件和define只適合用來定義
編譯出來的庫本身的一些特性，比如庫中的函數是否可重入等，而不應該包含平臺相關的東西。
這一年多，花了很多時間在這些方面，雖然並沒有找到自己理想的庫進行移植，但也學到了很多東西。有時想一想
也對，如果真的移植了，以後的升級和維護還是個問題，而自己寫則不存在這個問題。看來以後我要打消直接移植
代碼的念頭了，而是應該參考別人的代碼來完善自己的程序。