Posting Checklist

由于各种原因，论坛上的许多问题无法立即回答。 这在一定程度上是一个主题的本质——记住，在操作系统开发中，一切都取决于一切，基础中的小错误可能意味着在以后的阶段会出现巨大的无法追踪的问题。 然而，许多查询是完全可以避免的。

修复bug的琐事

给出明显随机结果的事物通常是以下结果之一：

1. 您的构建调用“gcc”和/或“ld”。 这不是应该如何使用编译器。 不幸的是，这种做法也打破了一些教程在野外。
2. 您正在使用过时版本的Bochs或QEMU。 特别是，不要使用Linux发行版附带的版本。
3. 你忘记检查虚拟机日志了。 特别是在Bochs的情况下，准确的错误原因通常打印在其中。

当你问

1. 目前，五分之一的新员工公然违反了法律[1]在第一篇帖子上，对于大约一半的新来者来说，他们是否真的读过而不是按自动驾驶仪行事是值得怀疑的。 不要浪费我们的时间，或者更重要的是你自己的时间：它包含各种各样的指针，包括一些可能已经回答问题的指针。
2. 不要猜“任何事”。坚持事实。 如果你有悬而未决的问题阻碍你理解你在做什么，考虑把最初的问题变成背景故事，因为你缺乏理解。
3. 包括您正在使用的仿真器和虚拟机的名称和版本。 提及您的体系结构（保护模式、长模式、树莓等），以及您正在使用的任何引导加载程序。
4. 请务必提及不同虚拟机和实际硬件之间的任何明显差异。 你的操作系统在任何地方都应该是一样的，这些都是重要的提示。
5. 如果在VM中运行代码，请显示代码生成的所有日志行。
6. 将代码减少到显示错误的最小集合，然后发布。 不要浪费一天时间来询问我们“发布您的代码”，因为您本可以马上发布代码。 在适当的地方翻译。

答复后

1. 不要盲目地听从建议。了解他们应该做什么。
2. 您的代码可能存在多个问题。 “修复所有问题”，并要求对所有您不理解的评论进行详细说明。 有时，您需要修复多个问题才能使其正常工作，有时一个问题现在可能不起作用，但以后可能会出现问题。 这还有另一个影响，这是因为许多软件开发人员天生就接受训练，在遇到第一个bug后就停止阅读。 如果您的代码有几个（可能是次要的）问题，那么您只会遇到前几个问题，而不是当时最重要的问题。 直到你跟进并解释你做了什么，但它仍然不起作用。
3. 有很多人试图提供帮助，但你会发现有些人基于自己的理解力不足而发表武断的建议。 同样，如果你不明白为什么，你最好质疑细化的建议，并了解到底发生了什么。
4. 要有礼貌，写一篇你所学的简短摘要。