我想在未来的某个时候建立一个操作系统,现在想一些关于它将如何的轻量级草图.我几乎已经在为Windows环境编译的C编码(和一些小Java).如果我想在Linux下运行它,我将不得不重新编译我的任何C程序.因此,对于每个操作系统,二进制文件(编译的产品)必须是不同的.如果我从头开始设计一个全新的操作系统,无论是业余爱好还是学术目的,都不使用Linux内核或操作系统的任何已知基本代码,我所理解的是,由于我的操作系统,我无法用GCC编译我的C程序不会是其目标系统之一.这里出现了关于标题的问题.提前感谢任何提示.
无论您是否选择构建新的编译器,挑战仍然是移植C库.从技术上讲,您可以在没有标准库的情况下使用C(例如Linux内核或任何自托管示例),但对于打算在操作系统下运行的程序来说,这是一个荒谬的主张,因为大多数系统都会施加内存限制等,这意味着您不能仅仅在使用内存方面拥有全权限制.因此,需要诸如malloc之类的C库调用.
由于您内核下的任何程序(很可能是您操作系统的99％)都需要一组链接功能,因此移植C库是您最大的任务. C库是一个庞大的巨石,写你自己的将是相当愚蠢的,尤其是many implementations already available,最着名的是GCC.所以,你真正应该问的问题是,你想写我自己的libc版本吗？ (答案几乎总是没有,大多数替代实现都是针对小众用例.)另外,如果你想使你的OS POSIX兼容,那么你将不得不实现更多的功能,增加了麻烦.
您是否为自己的操作系统编写自己的编译器是一个细微的细节,与其中包含的C库相比.您始终可以将自己的编译器与已编写的C库实现一起使用.
我对你基于意见的问题的建议是：不.移植现有的编译器,如GCC或clang,然后使用它.另外,这有几个优点：
>与现有工具和工具链的兼容性
>熟悉的程序(用户无需学习如何使用新的编译器)
>他们是开源的 – 尽管如此,你一点也不疯狂.哎呀,即便是Apple将两个现有的编译器–GCC和clang – 集成到他们的工具链中而不是自己动手,而且他们是一家价值数十亿美元的公司.
