# Ошибки начинающих
# Основная информация
Идея "написать свою собственную ОС" привела вас сюда. Эта вики-страница предназначена для предоставления вам помощи в вашем начинании.
Тем не менее, довольно часто новички совершают определенные ошибки или имеют неправильные представления о том, что связано с темой. Это неплохо - многие другие совершали эти ошибки раньше, и многие будут делать это в будущем. Эта страница предназначена для того, чтобы убедиться, что вы знаете, о чем идет речь, прежде чем углубляться в предоставленную информацию.
# Основные ошибки
Это может выглядеть как туториалы в виде CTRL + C CTRL + V, а также форум, на котором вы можете задавать свои вопросы, на которых вы застряли. Это не так. Мы полностью ожидаем, что вы будете ответственным и станете опытным разработчиком, прежде чем приступите к написанию собственной ОС. Мы также ожидаем, что вы прочитали о конструкции ОС и изучили соответствующую документацию по выбранной вами платформе. Не ожидайте, что эта Вики или форум станут своего рода полным руководством по созданию собственной ОС, не говоря уже о руководстве по навыкам программирования в целом.
То, что вы найдете здесь, - это документация, оставленная теми, кто пришел до вас, кто узнал об этих вещах, прочитав техническую документацию, доступный исходный код и сообщения на форуме, а также путем программирования методом проб и ошибок. Некоторые из них были написаны для того, чтобы эти люди могли посмотреть их позже, некоторые из них были написаны для того, чтобы мы могли указать на статью вики, а не объяснять тему снова и снова.
То, что вы найдете здесь, - это небольшие подсказки и дорожные знаки, которые могут помочь вам на вашем пути. Это не полная карта страны Оз.
Если у вас еще нет хорошего представления о том, что такое стек (opens new window) или как использовать отладчик (opens new window), мы не будем стараться изо всех сил, чтобы объяснить вам это. Посетите эти две страницы; вы увидите, что они в основном касаются специфики ОС, а не общего введения в тему. Это не недостаток, это сделано специально. Если вы ищете общее просвещение в области программирования, вам лучше посетить сайты, такие как StackOverflow (opens new window), и сначала стать разработчиком, прежде чем стремиться стать разработчиком ОС.
# Суровая правда
Никто из тех, кто еще не является опытным разработчиком с многолетним опытом работы в нескольких языках и средах, не должен даже рассматривать возможность разработки ОС. Десятилетие программирования, включая несколько лет низкоуровневой разработки на ассемблере и/или другом низкоуровневом языке, таком как C, - это в значительной степени минимум, необходимый для того, чтобы даже понять тему достаточно хорошо, чтобы работать в ней.
# Есть ли туториал по...?
Поскольку это место не может помочь начинающим разработчикам, часто задается вопрос о том, какое другое место предоставляет пособие, хорошие объяснения или простой для понимания текст. Однако их не существует. Трудные вещи не могут быть описаны простым текстом. Если у вас возникли проблемы с чтением официальной документации, то лучше будет подучить языки программирования и вернуться сюда позже.
# Сфера применения
# Дедлайны
Будь то для университета, хобби или коммерческого использования, разработка операционной системы требует много времени. Ядру Linux потребовалось более года очень самоотверженной работы, чтобы создать видимость полезности, и все, что сделал Линус Торвальдс, - это имитировал существующую и хорошо документированную работу проекта, чтобы заставить уже существующее пользовательское пространство работать на нем. Более того, для каждого такого успешного проекта, как Linux, существуют буквально сотни проектов, которые потребляли человеко-год или более работы, никогда не доходя до размещения функциональной оболочки.
Поэтому спланируйте разумную дорожную карту того, что вы хотите сделать. Не думайте, что через 3 месяца ваша ОС будет иметь графический интерфейс и распознавание голоса.
# Определение конечной цели
При запуске любого проекта вы должны оценить свои конечные цели, конечных пользователей и т.д. Разработка операционной системы ничем не отличается от этого. Имея приблизительное(а лучше точное) представление о ваших целях, вы получите мотивацию и направление, в котором вам нужно двигаться. Однако не зацикливайтесь на своих первоначальных целях, когда вам в голову приходит что-то лучшее(если это конечно не отказ от разработки проекта в пользу другого).
К сожалению, многие разработчики ОС не оценивают, как будет выглядеть их конечная ОС; поэтому они не знают, в каком направлении двигаться, и прибегают к вопросу: "Что дальше?"
Однако следует отметить, что для оценки ваших целей вы должны знать всю (техническую) концепцию работы существующих операционных систем.
# Коммерческая разработка операционных систем
Не думайте, что создание ещё одного BolgenOS сделает вас богатым. Во всяком случае, история показала нам, что лучшие операционные системы никогда не получают никакого коммерческого успеха, в то время как те, у которых почти полностью отсутствует мотивация и вдохновение, получаются крайне успешными.
Другая возможность - продать вашу ОС компаниям, которые в настоящее время используют семейтсво Windows для управления процессами. Это может показаться проще, поскольку вы не несете ответственности за окончательное приложение, но вам нужно быть профессиональным и реагировать на проблемы и запросы ваших клиентов. Стоит учитывать, что им может потребоваться долгосрочная поддержка.
# Предположение, что это никуда не приведёт
В отличие от вышесказанного, некоторые люди предполагают, что их ОС никуда не денется. По этой причине их проекты имеют уродливый код, не учитываются важные аспекты и в целом полагаются на уродливые концепции. Хуже всего то, что они принимают решения, которые не приводят к удобству использования и расширяемости. Таким образом, их предположение становится самореализующимся пророчеством.
На самом деле, хотя шансы на то, что ваша ОС будет работать за пределами тестовых машин, невелики, существует достаточно продвинутых проектов ОС, которые начались именно с сообщества OSDev.
# Избегайте невежства и глупых вопросов
Новички часто спрашивают: "Какой самый простой способ сделать <...>?", а не "Какой лучший и правильный способ сделать <...>?". Это опасно, поскольку новичок не тратит время на понимание реализации чего-либо. Вместо этого он выбирает концептуально более простой метод, скопированный из туториала индуса с RuTube. Действительно, такой маршрут часто слишком прост и в конечном итоге вызывает больше проблемы в долгосрочной перспективе, потому что новичок не знает о лучшей альтернативе.
Распространенные примеры включают в себя неумелое использование GCC, непонимание Real Mode, Unreal Mode, Protected Mode, Long Mode и слишком быстрые переходы от одного к другому без предварительного понимания того, как собрать конфигурацию и полностью использовать все возможности (особенно использование базовых возможностей BIOS во время загрузки и инициализации), полагаясь на нестандартные вызовы BIOS, не учась писать драйверы оборудования в вашей собственной ОС, а под Windows и Linux для наибольшего удобства. Использование двоичных файлов вместо ELF, не изучение исполняемых файлов, архивов, графики, документов и других форматов файлов, алгоритмов сжатия и т.д. Опытные разработчики используют другие альтернативы по причине, которую вы, возможно, еще не понимаете. Опытные разработчики в некоторых случаях предпочитают использовать неполноценный метод, но это потому, что они могут тщательно проанализировать, подходит ли он, и они знают, когда его не следует использовать. Как начинающий или Middle-разработчик, вы, скорее всего, не будете знать эти методы и технологии достаточно хорошо, чтобы решить плохое это решение или хорошее. Помните, что если вы выступаете против какого-либо метода, Вы должны знать его достаточно хорошо, чтобы указать на всё в нем неверное или, наоборот, правильное. В любом случае, не стоит руководствоваться ленью; всегда выбирайте что кажется более надёжным, а не более простым.
# Дизайн
# Дизайн графического интерфейса
Скорее всего, вам потребуется несколько лет, начиная с нуля, чтобы добраться до точки, где вы действительно делаете что-либо, связанное с графическим интерфейсом. Внешний вид графического интерфейса в лучшем случае вторичен, поскольку его можно легко изменить когда угодно; что действительно определяет удобство использования графического интерфейса, так это функциональность. Если ваша цель-создать лучший внешний вид, а не лучшую ОС, подумайте о внедрении X Window Manager вместо всей ОС (НЕТ).
# Популярность
Моя ОС будет популярнее чем macOS, Linux и Windows!
Это крайне маловероятно. Для достижения этого требуется довольно много времени, денег и знаний. Не все будут загружать вашу операционную систему, потому что:
- они могут не знать, что такое операционная система или как ее установить
- ваша операционная система не слишком то безопасна
- ваша операционная система поддерживает меньше приложений (по этой причине, часто отказываются от использования Linux на домашнем компьютере)
- ваша операционная система не полностью функциональна (минимальный интерфейс в виде командной строки или плохой графический интерфейс)
Вам повезет, если несколько человек воспользуются вашей ОС. Единственная причина, по которой популярные операционные системы сегодня популярны, заключается в том, что они были доступны в должной мере и удовлетворяли потребности десятилетия назад, когда было меньше альтернатив.
# Использование оперативной памяти
Я могу использовать меньше пары килобайт оперативки для запуска моей ОС
Извините, но это невозможно. ОС, использующая такой небольшой объем памяти, будет практически непригодна для использования. Забудьте о драйверах файловой системы, драйверах дисков, драйверах USB и т.д. Если вы хотите разработать что-то небольшое, просто сделайте простой загрузчик, а не ОС.
# Эмуляция другой ОС
Моя ОС может запускать программы от Windows, macOS, Linux и даже БК-0010 (opens new window)
Мне жаль, что я разрушил твои мечты, но вероятнее всего это не случится. Эмуляция даже одной системы требует многих лет работы, особенно когда она является проприетарной, как Windows или Mac OS (Linux самый простой из четырех). Wine (opens new window), несмотря на то, что находится в разработке с 1993 года и написан в сообществе свободного ПО, все еще имеет проблемы с большинством программ. Поэтому вместо того, чтобы сосредотачиваться на эмуляции других систем, сосредоточьтесь на своей собственной.
# Языки программирования
Некоторые языки хорошо подходят для написания ядра, другие - в меньшей степени. Прочитайте страницу об использовании какого-либо языка, отличного от C.
# Образ ядра
# Проблемы с загрузкой
Возникает на ранних стадиях, зачастую с самодельным загрузчиком. Причина проблем с загрузкой часто заключается в том, что слишком мало секторов извлекается с диска. Либо измените количество секторов, которые вы извлекаете с диска, либо заставьте загрузчик/загрузчик второго этапа проанализировать файловую систему.
# Решение проблем
Прежде чем обращаться за помощью на форумах или в IRC, вы должны предпринять все возможные шаги, чтобы самостоятельно диагностировать проблему. В случае таких проблем, как тройные ошибки или "случайные" исключения, делать предположения о причине проблемы - распространенная ошибка. Используйте отладчик и точки останова, чтобы найти точное место возникновения ошибки. Использование эмулятора и отладчика (таких как GDB и Bochs/QEMU) поможет вам найти проблемы, которые трудно отследить. Если вы предоставите некоторую теорию о проблеме и действиях, которые вы уже предприняли для ее решения, людям будет гораздо легче помочь вам (даже если ваша теория неверна, она, по крайней мере, дает людям представление о ваших взглядах на проблему и стратегиях, которые вы, возможно, уже пробовали, а также о том, что вы, возможно, пропустили).
В общем, приложите как можно больше усилий для решения проблемы самостоятельно, прежде чем обращаться за помощью к другим. Прежде чем опубликовать сообщение, спросите себя: "Сделал ли я все возможное, чтобы диагностировать и решить эту проблему?" Часто вы многому научитесь в процессе, и, скорее всего, сможете решить проблему (и подобные проблемы в будущем) самостоятельно, без помощи других, что хорошо. Когда вы просите о помощи, предоставьте код, относящийся к вашей проблеме. Однако проблема может быть в другом месте, поэтому дайте другим возможность взглянуть и на другие части вашего кода (если вы используете что-то вроде GitHub (opens new window) или BitBucket (opens new window), это немного проще, но, безусловно, есть много других способов).
Что касается форума (прим. ред. имеется ввиду форум на сайте оригинала (opens new window)), ознакомьтесь с его правилами. Они необходимы для чтения и улучшат качество Ваших сообщений и повысят вероятность того, что люди помогут вам. На IRC-канале, если вы задаете вопрос, не ожидайте ответа в течение 10 секунд или даже 5 минут. У других людей тоже есть жизнь. Если вам нужно уйти, чтобы что-то сделать, и вы хотите проверить, не пропустили ли вы что-нибудь, есть журналы, которые вы можете просмотреть. Для этого см. ссылки в разделе IRC.
# Распространение
# Именование
Именование обычно является последней проблемой, которую нужно решить, даже если мы все хотим классное имя для нашей классной концепции. Поскольку "крутость" имени - это дело вкуса, мы не можем помочь вам в его поиске. Более того, если вы свяжете название своего проекта с определенной функцией, вы можете обнаружить где-то в будущем, что ни одна концепция не идеальна и что вы хотите изменить то, что изначально считали ключевой функцией. Нет ничего более глупого, чем не развиваться только потому, что вы "хотите придерживаться имени"...
В этой теме можно найти много полезной информации об именовании. Проще говоря, название вашей операционной системы <name>OS (JackOS, FredOS и т.д.) может показаться хорошей идеей, пока вы не получите второго участника проекта. Хорошая идея (любезно предоставленная Solar) - выбрать кодовое имя (например, Longhorn, Chicago и т.д.), а затем придумать лучшее имя ближе к релизу.
# Веб-сайт проекта
Многие новички в osdev создают веб-сайты проектов, прежде чем у них появится что-либо стоящее на веб-сайте. Нет смысла создавать веб-сайт, делающий драматические заявления о будущих планах вашего проекта, прежде чем у вас появится какое-либо представление о том, куда движется ваш проект, или какой-либо код, скриншоты или загрузки, чтобы продемонстрировать то, что вы уже создали. Такой сайт выглядит мертвым и создает плохую репутацию. Анонсирование вашего веб-сайта (например, на форуме OSDev.org (opens new window)) или ссылка на него в вашей подписи, когда на нем нет ничего, кроме сообщения "добро пожаловать в <вставьте здесь супер необычное название проекта>", просто заставляет людей терять интерес к вашему проекту еще до того, как вы даже начали, и если/когда вы в конечном итоге создадите что-то стоящее, вы столкнетесь с уже ужасной репутацией, которую будет трудно преодолеть.
# Командная работа
Ошибка новичка номер один видна на форуме объявлений. Обычно он поставляется в одной из двух форм, хотя формы имеют довольно много совпадений:
# Проекты сообщества
Не переоценивайте свои шансы заинтересовать людей вашим проектом. Даже более успешные проекты обычно состоят из одного, возможно, двух человек, фактически работающих над кодом. И это не из-за отсутствия необходимости.
Закон Брукса гласит, что чем больше людей участвует в проекте, тем больше времени занимает проект. Единственный способ обойти это - разделить проект на части, над которыми вы заставляете людей работать, и только над ними. Удачи.
# Подбор персонала
Есть некоторые вещи, которые вам нужны для того, чтобы у вас был шанс (и избежать того, чтобы вам болезненно говорили, что вы неудачник):
- Если у вас нет установленной кодовой базы, люди не присоединятся, потому что они могут видеть, что вам не хватает опыта, и ожидать, что проект потерпит неудачу.
- Если у вас нет (разработанного) дизайна, люди не присоединятся к вам, потому что они не видят, насколько ваша ОС интереснее, чем их собственный дизайн.
- Если ваша репутация не опережает вас, особенно более опытные люди будут очень настороженно относиться к вам и не будут доверять вам.
- Если у вас нет навыков управления проектами, те немногие люди, которые присоединяются к вам, вскоре уйдут, потому что они обсуждают вещи и не приступают к разработке.
Люди, которые тем не менее присоединяются, обычно являются худшими программистами, чем люди, для которых был составлен этот список.