关于可移植性的一点唠叨

最近，一直在作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只适合用来定义
编译出来的库本身的一些特性，比如库中的函数是否可重入等，而不应该包含平台相关的东西。

这一年多，花了很多时间在这些方面，虽然并没有找到自己理想的库进行移植，但也学到了很多东西。有时想一想
也对，如果真的移植了，以后的升级和维护还是个问题，而自己写则不存在这个问题。看来以后我要打消直接移植
代码的念头了，而是应该参考别人的代码来完善自己的程序。