type
status
slug
summary
tags
category
icon
password
new update day
Property
Oct 22, 2023 01:31 PM
created days
Last edited time
Oct 22, 2023 01:31 PM
“编写自己的操作系统”的想法将您带到了这里。本 Wiki 旨在为您的事业提供帮助、指导和参考。
然而,新手犯某些错误或对该主题所涉及的某些内容有着一些共同的误解是很常见的。这并不是什么坏现象——许多其他人以前犯过这些初学者的错误,而且将来很多人也会这样犯这些错误。此页面旨在确保您在深入了解所提供的信息之前知道自己在做什么。

1 这不是什么

这可能看起来像是一组复制和粘贴的教程,或者一个在您遇到困难时提出问题的论坛。事实并非如此。我们完全希望您在开始编写自己的操作系统之前,主动承担自己的责任,成为一名经验丰富的用户空间应用程序程序员。我们还希望您阅读过有关操作系统设计的信息,并且您已经研究过您选择的平台的相关文档。不要指望这个 Wiki 或论坛会成为你自己的操作系统的某种完整编写指南,更不用说一般的编程技能指南了。
您在这里找到的是前人留下的文档,他们通过阅读技术文档、可用源代码和论坛帖子以及试错编程发现了这些内容。其中一些是为了让那些人以后可以再次查找它而编写的,其中一些是为了让我们可以指向一篇 Wiki 文章,而不是重新解释一个主题。
您在这里找到的一些小提示和路标可能会帮助您走上您的道路。这不是 Oz 的完整地图,也不应该是。
如果您还不知道堆栈是什么,或者如何使用调试器,我们不会特意向您解释。访问这两个页面;你会发现它们主要是关于操作系统的细节,而不是对主题的一般性介绍。这不是瑕疵,这是设计使然。如果您正在寻找通用编程启蒙,您应该先访问诸如 StackOverflow 之类的通用编程站点并成为一名开发人员,然后再立志成为一名 OS 开发人员。
本 Wiki 不会扩展为初学者手册,因为这不是它的目的。它是为了回答当人们觉得他们已经准备好进入内核空间编程时出现的高级问题。

1.1 一个硬道理

No one who isn't already a seasoned developer with years of experience in several languages and environments should even be considering OS Dev yet. A decade of programming, including a few years of low-level coding in assembly language and/or a systems language such as C, is pretty much the minimum necessary to even understand the topic well enough to work in it.
任何人如果还不是在多种语言和环境方面拥有多年经验的经验丰富的开发人员,甚至都不应该考虑 OS Dev。十年的编程,包括几年的汇编语言和/或系统语言(如 C)的低级编码,几乎是充分理解该主题以在其中工作的最低要求。
此外,随着不同“标准”、计算机和移动设备型号、外设和设计概念的数量不断增加,这一点正变得越来越真实。
对于像 Dennis Ritchie、Richard Greenblatt、Gary Kildall 或 Steve Wozniak 这样的人来说,为硬件编写一个简单的操作系统是一回事,与他们已经非常熟悉的现有机器相比,它相对简单,并且没有标准规范可以遵循,也没有现有的cruft来保持向后兼容性。这在当前一代的库存硬件上不再适用。而且,他们每个人都已经是一位经验丰富的工程师,已经做了多年的系统编程。即便如此,它们也只是为系统提供了基础;在系统的核心(用现代行话来说就是内核)就位后,大部分工作由下属开发人员组成的小团队完成。
这个规律也有例外,但不多;不要期望自己是千里挑一的人。如果你认为你是,读读邓宁-克鲁格效应,再考虑一下这个问题。
哦,顺便说一下,Linus Torvalds并不完全是他们中的一员——他编写Linux内核时是一名研究生,已经用C语言编写代码多年了。虽然他离十年还差得很远,但作为一名将自己的爱好转化为硕士论文的研究生,他比大多数人有更多的时间从事这个项目。无论如何,他1991年在USENET上发布的著名的“Linux 0.0.1”版本只不过是一个循环调度程序,离一个完整的系统还差得很远。他花了一年时间才达到这一步。明白了吗?
虽然这个wiki的大多数贡献者确实开始得更早,但对我们大多数人来说,这是由于缺乏经验而产生的错误。这个团队中的大多数先驱甚至不知道一个小的操作系统项目的规模和复杂性,也不知道他们将会陷入什么样的境地。这是一颗难以下咽的药丸,尤其是在像维基这样的资源广泛可用之前。我们不能强迫你从我们的错误中学习,但至少我们可以传递这个警告。
现在,你不应该为此过于沮丧;关键不是你不能这样做,而是(如果你像我们大多数人开始时一样)你可能还不能这样做。开始这么大的项目时,耐心可能是一种美德。

1.2 有关于…的教程吗...?

因为这个地方不能也不迎合初学者开发者,所以经常有人问,其他哪个地方提供教程,较好的解释,或者通俗易懂的读物。然而,它们并不存在。困难的主题不能用轻松的散文来描述,就像有太多太复杂的事情让一只猴子无法正确学习一样。如果您阅读官方文档有困难,这将是一个练习的好时机。
事实上,目前市面上绝大多数的教程都至少在一个方面存在漏洞,所以你最好不要一开始就相信它们。

2 Scope

2.1 最后期限

无论是用于大学、业余爱好还是商业用途,操作系统的开发都需要时间。Linux 内核花费了一年多的时间投入大量精力来获得表面上的实用性,而 Linus Torvalds 所做的只是模仿现有的和有据可查的行为来让已经存在的用户空间在其上运行。此外,对于每一个像 Linux 一样成功的项目,实际上有数百个项目花费了一个人年或更多的时间,却没有达到托管功能性 shell 的程度。
因此,为您想要完成的工作计划一个合理的路线图。不要假设在 3 个月内你的操作系统会有 GUI 和语音识别,因为操作系统开发根本不包含任何 RAD 工具。事实上,它完全没有它们。

2.2 最终目标定义

当开始一个项目时,你应该估计你的最终目标,你的最终用户,项目开发的目的等等。操作系统开发与此无异。对你的目标有一个粗略的想法会给你动力和你需要前进的方向。然而,当你想到更好的东西时,不要停留在最初的最终目标上。
不幸的是,许多操作系统开发者没有估计他们最终的操作系统会是什么样子;因此,他们不知道朝哪个方向走,只能问:“下一步怎么办?”
然而,应该提到的是,为了估计您的最终目标,您应该了解现有操作系统如何工作的整个(技术)概念。

2.3 商业OSDev

不要认为开发这样一个伟大的操作系统会让你变得富有。如果有什么不同的话,历史告诉我们,最好的操作系统永远不会获得任何商业成功,而那些几乎完全缺乏设计和灵感的操作系统会获得商业成功,这是因为聪明的商业举措,以及在正确的时间和正确的地点进行了正确的掩盖。
尽管如此,尽管论坛的“工作”部分相对空白,一些单独开发的操作系统已经取得了一些商业上的成功。一个例子是01000101的“嵌入式网络安全”,这是一个操作系统,旨在作为一个专门的深度包分析器。请注意,它是专门针对特定应用的。为了以这种方式推销你的操作系统,你需要像理解操作系统开发一样理解应用程序,甚至更多,并且你需要很好地对两者都进行编码。你的顾客会期望你是专业的。
另一种可能性是向目前使用MS-DOS进行过程控制的公司推销你的操作系统。这可能看起来容易些,因为你不负责最终的申请,但是你需要专业地回应你客户的问题和询问。他们可能需要长期支持。他们可能不喜欢您真正想要实现的功能。

2.4 假设它不会去任何地方

与上述相反,有些人认为他们的操作系统将一事无成。由于这个原因,他们的项目有丑陋的代码,不考虑重要的方面,并且通常依赖丑陋的黑客。最糟糕的是,他们做出的决定不会带来可用性和可扩展性。这样,他们的假设就变成了自我实现的预言。
事实上,虽然让您的操作系统在您的测试机器之外运行的机会很低,但是有足够多的高级操作系统项目就是从这个社区开始的。

2.5 避免无知

新手经常会问“做X最简单的方法是什么?”而不是“做X的最好的、恰当的、正确的方法是什么?”这是很危险的,因为新手不会花时间去理解实现某些东西的优越方法,而是选择从教程中复制的概念上更简单的方法。事实上,更简单的路线往往过于简单,最终会导致更多的问题,因为初学者不知道更好的选择,也不知道什么时候转换更好,改走强硬路线有什么不好?
常见的例子包括懒得使用交叉编译器,不了解实模式虚幻模式保护模式长模式,在没有首先了解如何收集所有重要配置并充分使用其所有功能的情况下从一个模式跳到另一个模式太快(特别是在启动和初始化期间使用 BIOS 检测基本功能),依赖非标准的BIOS调用,不学习在自己的操作系统中以及在 Windows 和 Linux 下编写硬件驱动程序以获得最大的便利,全局暴露测试功能,使用平面二进制文件而不是 ELF,没有学会可执行文件、存档、图形、文档等文件格式和压缩算法等等。 有经验的开发人员使用更好的替代方案是有原因的,这一点你可能还不明白。有经验的开发人员在某些情况下会选择使用劣质方法,但那是因为他们可以仔细分析它是否合适,他们知道什么时候不应该使用它。作为一名初学者或中级开发人员,您可能不太了解这些方法和技术,无法判断劣质解决方案是否适合您。记住,如果你反对一种方法,你应该足够了解它,知道它所有的错误(和正确)部分。不管怎样,懒惰和无知只会带来麻烦。当有疑问时,应选择看起来保守的选择,而不是简单的。

3 设计

3.1 图形用户界面设计

如果从零开始,您可能需要几年时间才能真正做任何与 GUI 相关的事情。GUI的外观充其量是次要的,因为它们可以很容易地被修改;真正决定GUI可用性的是功能性,而这并不是用模型图来表达的。如果你的目标是创造一个更好的外观而不是一个更好的操作系统,考虑实现一个X窗口管理器而不是一个完整的操作系统。

3.2 流行

我的OS会比Windows,Mac OS,Linux更受欢迎!
这是极不可能的。要做到这一点需要相当多的时间、金钱和知识。不是每个人都会下载你的操作系统,因为:
  • 他们可能不知道什么是操作系统或者如何安装操作系统
  • 您的操作系统存在安全风险
  • 您的操作系统支持的应用程序较少
  • 您的操作系统功能不全(最小的命令行界面或糟糕的GUI)
你会幸运地得到一些人使用你的。今天流行的操作系统流行的唯一原因是因为它们在几十年前是可用的,并且满足了需求,当时可供选择的操作系统很少。

3.3 内存使用

我想让我的操作系统使用少于几千字节的内存!
抱歉,那可能是不可能的。使用这么少内存的操作系统几乎无法使用。除非取消文件系统驱动,磁盘驱动,usb驱动等等。如果你想开发小的东西,就做一个简单的bootloader,不要做OS。
你可以试试原生的 Forth;它就像一个小操作系统,内核、命令解释器和汇编器都在一个微小的二进制文件中!内核的某些部分甚至可以编写脚本。你甚至不需要一个文件系统,许多Forths直接编辑和加载磁盘扇区。这里有一个很大的问题:Forth不是轻技能的。编写好的 Forth 是一个完全不同的星球,你需要了解它以超越最基本的东西。令人惊讶的是,一些Forth爱好者擅长编写Forth解释器,但却是糟糕的Forth程序员。您需要成为一名优秀的(-ish)Forth 程序员才能将 OS 设计概念与 Forth 相匹配,或者弄清楚哪些概念是不需要的。如果你不能这样做,你的操作系统将比它需要的要大得多。 ;)
弄清楚如何减少代码大小可能需要花费大量的时间和精力。Forth的发明者Charles Moore写了一个CAD程序,它的结构只有5行代码。当被问及写这5行代码花了多长时间时,他回答说,“哦,大约两年了”!

3.4 操作系统仿真

我的操作系统将能够运行来自Windows、Mac OS、Linux甚至PDP-11程序的程序!!!
我很抱歉打破你的幻想,但它可能做不到。即使只是模拟一个系统也需要数年的工作,尤其是当它是专有系统时,比如Windows或Mac OS (Linux可能是四个中最容易的。)。尽管自1993年以来 Wine 一直在开发,并且是在用户空间中编写的,但在许多程序中它仍然存在问题。
因此,与其专注于模仿其他系统,不如专注于自己的系统。设计它,开发它,和它做朋友。

3.5 编程语言

有些语言非常适合编写内核,有些则不太适合。阅读关于使用c之外的语言的页面。

4 内核映像

4.1 引导问题

引导问题的原因通常是从磁盘获取的扇区太少,特别是在早期阶段和使用自建引导加载程序时。解决方法是:要么调整从磁盘获取的扇区数量,要么让引导加载程序/第二阶段加载程序解析文件系统。

5 故障排除/寻求帮助

在论坛或IRC上寻求帮助之前,你应该采取一切可能的措施自我诊断问题的本质。对于像三重错误或“随机”异常这样的问题,对问题的原因做出假设是一个常见的错误。使用调试器或打印语句来定位发生异常的确切位置。使用仿真器和调试器(如GDB和Bochs/QEMU)将帮助您定位难以跟踪的问题。如果你提供一些关于问题的理论和你已经采取的解决问题的行动,人们将能够更容易地帮助你(即使你的理论不正确,它至少让人们知道你对问题的看法和你可能已经尝试过的策略,以及你可能错过的策略)。
总的来说,在向别人寻求帮助之前,尽可能多地自己解决问题。在你发帖之前,问问你自己,“我已经尽我所能去诊断和解决这个问题了吗?”通常你会在这个过程中学到很多东西,并且你很可能能够自己解决这个问题(以及未来类似的问题),而不需要别人的帮助,这是一件好事。当您寻求帮助时,请提供与您的问题相关的代码。然而,问题可能出在其他地方,所以也要给其他人一种查看代码其他部分的方法(如果你使用的是GitHub或Bitbucket之类的东西,这稍微容易一些,但肯定还有很多其他方法)。
关于论坛,请阅读论坛规则。它们是必读的,会提高你文章的质量,让人们更有可能帮助你。在IRC频道上,如果你问了一个问题,不要期望在 10 秒甚至 5 分钟内得到答复。其他人也有自己的生活。如果您需要离开去做某事并想检查是否遗漏了任何内容,则可以查看日志。有关这些,请参阅 IRC 主题中的链接。
有关如何在寻求帮助时成为优秀社区成员的更深入指南,请参阅如何提问。这是一本很好的读物,理想情况下,你应该在向任何人寻求帮助之前读完整本书(它没有那么长,非常值得一读)。

6 促进

6.1 命名

命名通常是最后一个需要解决的问题,我们都希望为我们那酷酷的追做系统取一个酷酷的名字。因为名字的“酷”是一个品味问题,所以我们不能帮你找到它。此外,如果您将您的项目名称与某个特性联系起来,您可能会发现没有一个概念是完美的,并且您想要改变您最初认为是关键特性的东西。没有什么比仅仅因为你“想坚持一个名字”而不进化更愚蠢的了...
在这个帖子中可以找到很多关于命名的有用信息。简而言之,将您的操作系统命名为< name>OS (JackOS、FredOS等。)似乎是个好主意,直到你有了第二个项目成员。一个好主意(由Solar提供)是选择一个代号(像Longhorn,Chicago等。)然后在更接近发布时间的时候编一个更好的名称。

6.2 项目网站

许多osdev新手在网站上有任何值得展示的东西之前就创建了项目网站。在你还不知道你的项目将走向何方,或者还没有任何代码、截屏或下载来展示你已经制作的东西之前,创建一个网站,对你的项目的未来计划做出戏剧性的声明是没有价值的。这样的网站看起来死气沉沉,造成了不好的口碑。宣布你的网站(例如在OSDev.org论坛上的公告论坛)或在你的签名中链接到它,而网站上只有“欢迎来到<在此插入精彩项目名称>”的信息,这只会让人们在你开始之前就对你的项目失去兴趣,如果/当你最终做出值得炫耀的东西时,你将面临一个难以克服的糟糕名声。

7 团队协作

在公告论坛中可以看到初学者的头号错误。它通常以两种形式出现,尽管这两种形式有很多重叠:

7.1 社区项目

不要高估你让人们对你的项目感兴趣的机会。即使是更成功的项目通常也是由一个,也许是两个实际从事代码工作的人组成的。这并不是因为缺乏需求。
布鲁克斯定律指出,一个项目中的人越多,项目需要的时间就越长。解决这个问题的唯一方法是将项目分成几个部分,让人们去做,并且只做。祝你好运。

7.2 招聘

有些事情你需要去争取机会(并避免被痛苦地告知你是个失败者):
如果你没有现成的代码库,人们不会加入,因为他们可以看到你缺乏经验,预计项目会失败。 如果你缺乏一个(完善的)设计,人们不会加入你,因为他们看不到你的操作系统比他们自己的设计更有趣。 如果你的名声不在你之前,尤其是更有经验的人会对你非常警惕,缺乏加入的信任。 如果你没有项目管理技能,少数几个加入的人会很快退出,因为他们正在讨论一些事情并且不会编写代码。 然而,加入的人通常是比这个列表的中更糟糕的程序员。
wiki.osdev.org 系列之(一) - 简介wiki.osdev.org 系列之(二)- How To Ask Questions