Thema: Wie geht ihr an die Entwicklung eures OS heran?

[babyrabbit]

Bis jetzt bin ich über den Bootloader nicht wirklich hinausgekommen - ich habe einfach zu wenig Zeit neben der Arbeit.
In den letzten Tagen beschäftigt mich aber dennoch ein paar Fragen:

Wo beginnt man?
=> TOP-DOWN oder BOTTOM-UP

Designed man zuerst das was man als Endergebnis erwartet (das was man später mit dem OS machen kann) oder entwickelt man zuerst den Bootloader, etc. bis ins kleinste Detail?
Setzt man auf "Objektorientierung" oder rein prozeduralen Code?

Mehrere Wege führen ans Ziel, doch welcher Weg ist einfacher, besser, performanter?

LG

[Svenska]

Hallo,

die Fragen sind alle theoretischer Natur. Mach, was dir persönlich am besten gefällt oder was du am besten kannst, was du für sinnvoll erachtest oder oder oder.

Ich vermute, du wirst eher keine 20 Jahre deines Lebens mit der Planung eines Betriebssystems verbringen, ehe du die Implementation anfängst (und wenn, dann ist die Planung eh schon veraltet). Jedes Einzelteil auf Anhieb fehlerfrei hinzubekommen, ist unmöglich.

C++ im Kernel ist möglich. Ob du es nutzen willst, obliegt deiner persönlichen Präferenz. (Wenn du es magst, nimm es, sonst, lass es. )

Es ist hier allgemein üblicher Konsenz, dass man, wenn man ein Betriebssystem schreiben möchte, nicht mit dem Bootloader anfängt.

Gruß,
Svenska

[Dimension]

Du brauchst:
-einen Bootloader, ich empfehle GRUB. Für GRUB brauchst du meines Wissens aber ein filesystem. Ansonsten geht ein Bootloader mit ein paar Zeilen Assembler und INT 13h, das Bootdevice sollte in dl liegen. Abgesehen davon stellt GRUB eine Menge nützlicher Informationen bereit, welche erst mühsam aus dem BIOS gelesen werden müssen.
-Interrupt-Handler
-Paging/Segmetierung
-Protected Mode
-Tasks
-Hardware-Zugriff, möglicherweise eine Abstraktionsschicht (HAL)
-Einen Überblick über das Speicherlayout im RAM (memory map)
-Speicherverwaltung (malloc)

Um die Feinheiten ausarbeiten zu können, solltest du das möglichst einfachste System zum laufen bekommen, das deinen Vorstellungen entspricht. Ob du im Kernel mit C++ arbeiten willst/kannst entscheidest du voraussichtlich beim design der Speicherverwaltung. Ob du den Bootloader universell verwendbar haben willst entscheidest du voraussichtlich beim Design deiner HAL, oder du nimmst GRUB.

Du bist mit den Eigenheiten von x86/IBM-PC bereits vertraut? Wenn nicht, brauchst du viel Geduld und starke Nerven.

[kevin]

-einen Bootloader, ich empfehle GRUB. Für GRUB brauchst du meines Wissens aber ein filesystem.

Brauchen nicht unbedingt (du kannst GRUB auch Blocklisten geben, also z.B. der Kernel sind 5 Sektoren ab Sektor 2), aber auf Dauer will man sowieso ein Dateisystem auf dem Image haben und warum nicht gleich richtig?

Ansonsten geht ein Bootloader mit ein paar Zeilen Assembler und INT 13h, das Bootdevice sollte in dl liegen.

Das ist dann aber kein Bootloader, sondern eine Krankheit. Typischerweise liefert dir so ein "aus Prinzip" geschriebener Bootloader so gut wie keine Features (was dein Kerneldesign einschränken kann, weil du den Bootloader nicht aufbohren willst - schon oft gesehen), aber hat dafür in der Regel einige Bugs oder Einschränkungen, an denen man immer wieder arbeiten muss.

Ein guter Bootloader ist eine schwierige Sache und mit einem OS hat man sich sowieso schon genug vorgenommen. Deswegen direkt mit dem OS anfangen und sich nicht auf Nebenkriegsschauplätzen verlieren. Wenn man wirklich will, kann man den eigenen Bootloader noch machen, wenn das OS funktioniert.

[Sannaj]

Naja, ich bin ehr so der Planer. Da ich mir aber vorgenommen habe, kein OS zu schreiben. Das wird eh nichts und ich will ja schon einen Compiler bauen Deshalb sind die OS-Ideen ehr wenig konkret. Auf der anderen Seite probiere ich natürlich trotzdem das ein oder andere aus, auch im OS Dev Bereich.

[DerHartmut]

Am einfachsten und performantesten ist natürlich Assembler, weil man hier alles optimieren kann. Der eigene geschriebene Bootloader darf natürlich auch nicht fehlen wie das eigene Dateisystem und die Shell im Kernel - hochperformant und super schnell.

Nein, um zum Ernst zurückzukommen: Mach, wie du's für richtig hältst. Einige schreiben das OS in C weil sie auf C schwören, andere in C++ weil ihnen das objektorientierte Paradigma gefällt, andere wiederrum schreiben in Pascal weil es etwas anderes ist, andere schreiben in Assembler weil sie denken ihr OS kann nur so viel schneller sein als Windows 7.

Den einzig wahren Weg gibt es nicht - du kannst sowohl in C als auch in C++ oder in Pascal schlechten und unperformanten Code schreiben. Mach es so wie es für dich am einfachsten ist (außer du legst Wert darauf dich besonders herauszufordern): Nimm die Sprache die du einwandfrei mitsamt Tools berherrscht - wenn du erst Pascal von der Pike auf lernen musst wirst du arge Schwierigkeiten haben dich komplett auf die pure Planung und Entwicklung des OS konzentrieren zu müssen.

Doch um zurück zum Thema zu kehren:
Du kannst dich hinsetzen und alles bis ins kleinste Detail planen - du wirst aber vermutlich viel über den Haufen während der Entwicklung werfen (wenn du noch nicht viel Erfahrung hast) weil du merkst, dass das so, wie du es geplant hast nicht funktionieren kann oder du es gar nicht mehr möchtest. Du solltest auf jeden Fall einen grundlegenden Weg einschlagen, also monolithisch oder nicht z.B. und die vielleicht ein vernünftiges Treiberinterface überlegen.

Aber eins muss es immer machen: Spaß Wenn du Stunden um Stunden für das perfekte Design verbringst und dir den Kopf zermaterst über das einzig wahre und perfekte Design ohne bislang eine Zeile Code zu schreiben machst du in meinen Augen etwas falsch. Wenn du planst und nicht weiterkommst programmiere erstmal bis zu dem Schritt. Vielleicht weißt du dann, wie du weitermachst oder merkst, dass du dir noch gar keinen Gedanken über den Schritt machen zu brauchst, weil du noch sehr lange brauchst, bis du dort angekommen bist.

[TheThing]

Einige schreiben das OS in C weil sie auf C schwören, andere in C++ weil ihnen das objektorientierte Paradigma gefällt, andere wiederrum schreiben in Pascal weil es etwas anderes ist, andere schreiben in Assembler weil sie denken ihr OS kann nur so viel schneller sein als Windows 7.

Andere schreiben ihr OS in FreeBASIC, weil sie einen Dachschaden haben 

Ich gehöre auch eher zu der Fraktion, die weniger plant und mehr bastelt. Ich hab auch schon einen Kernel weggeschmissen, habs aber nicht bereut, denn ich habe daraus gelernt und die Fehler bei meinem zweiten vermieden.
Ich denke aber, dass jeder so seine eigene Herangehensweise hat und haben sollte. Grundlegende Entscheidungen sollte man aber vielleicht vorher treffen z.B. Microkernel oder Monolith (wie DerHartmut schon sagte). Die beste Lösung für manch andere Dinge sieht man erst, wenn man beim basteln erkennt, welche Anforderungen gestellt werden.

Ansonsten habe ich festgestellt, dass Abwechslung sehr hilfreich ist. Momentan z.B. habe ich zwar mein kmalloc grob geplant, habe aber gerade keine Lust, es umzusetzen, also habe ich mich wieder meiner Game-Engine gewidmet. So hab ich für eine Weile keinen OS-Kram im Kopf und kann später mit frischer Motivation weitermachen.
Wobei da eins wichtig ist: Kommentare. Man sollte seinen Code nicht "überkommentieren", aber komplexe Stellen etwas zu beschreiben/erklären schadet nie und hilft sehr, wenn man nach einiger Zeit mal wieder in den Code sieht.

[erik.vikinger]

Hallo,


ich persönlich bevorzuge TOP-DOWN. Ich entwickle erst mal eine grobe Idee was ich eigentlich erreichen möchte, danach zerlege ich die sich ergebenen Probleme in ihre Teile und fange dann für jedes einzelne Teil-Problem von vorne an. Das klingt aufwendig und das ist es auch aber es ist IMHO die einzigste Methode mit der man wirklich ein gutes Ergebnis erreichen kann. Für einzelne Module macht das im Prinzip jeder so, man überlegt sich was soll dieses Modul machen und dann überlegt man sich wie man diese Aufgabenstellung in Funktionen und letztendlich in einzelne Anweisungen zerlegen kann. Das Problem dabei ist eher das die so gebauten Module insich zwar oft einigermaßen korrekt sind aber nicht immer mit den anderen Modulen anständig zusammenspielen, das kommt daher das beim Entwurf des Moduls selber eben keine von oben gekommenen Design-Ziele zur Verfügung standen so das diese Module dann eben nicht richtig zusammenpassen.
Auf jeden Fall kostet eine sauber strukturierte Vorgehensweise einiges an Disziplin und Zeit aber ich behaupte das man mit der chaotischen Variante, erst mal Code tippen und dann hinterher herausfinden was nicht stimmt, für das selbe Ergebnis in Summe mehr Zeit aufwenden muss (wegen den vielen Fehlschlägen) und letztendlich doch von oben nach unten plant (nur merkt man das dann nicht so deutlich weil es iterativ und eben als chaotischer Prozess passiert).

Ich bin mir sicher das hier bestimmt etliche Leute glauben das ich nicht mal aufs Klo gehe ohne mir vorher einen wirklich gut durchdachten Plan zurecht zu legen (ob das die Wahrheit ist werde ich nicht kommentieren), aber ich bleibe trotzdem bei der Meinung das eine gute Planung die Erfolgsaussichten eines jeden Projekts (das mehr als 10 Stunden Zeitbedarf beinhaltet) signifikant steigert.

Jedes Einzelteil auf Anhieb fehlerfrei hinzubekommen, ist unmöglich.

Kannst Du das beweisen?


Grüße
Erik


PS.: von einem eigenen Boot-Loader würde ich auch nur dann nicht abraten wenn Dich Deine masochistische Ader unbedingt zwingt Dir so tolle Dinge wie den x86-Real-Mode anzutun. Wenn ich näher darüber nachdenke komme ich zu dem Schluss dass das Programmieren eines OS für die x86-Plattform grundsätzlich eine ausgeprägte masochistische Ader erfordert, aber ich vermute das hier auch ziemlich viele Leute ähnlich über Segmentierung denken.

[kevin]

Du kannst für etwas, von dem du noch keine Ahnung hast, keine gute Planung machen. Aber Thema hatten wir schon öfter.

[erik.vikinger]

Hallo,

Du kannst für etwas, von dem du noch keine Ahnung hast, keine gute Planung machen.

Meine Berufspraxis sagt mir da was anderes, ich hab noch nie ein Projekt bekommen bei dem ich schon vorher die volle Ahnung hatte sondern es lief immer auf "learning by doing" hinaus. Beim Top-Down-Ansatz wird man dann früher oder später auf einen Punkt stoßen an dem einem das nötige Wissen fehlt und dann muss man sich dieses eben besorgen.

Aber Thema hatten wir schon öfter.

Stimmt auffallend, ebenso wie die Tatsache das wir hier wohl nie eine eindeutige Antwort auf dieses Thema finden werden. Vielleicht sollten wir zukünftig derartige Fragen mit einem freundlichen Hinweis auf die Suchfunktion beantworten.


Ich wünsche Euch allen fröhliche Weihnachten
Erik

[babyrabbit]

Erstmal Frohe Weihnachten im Nachhinein!
Danke für die vielen Inspirationen

Deswegen direkt mit dem OS anfangen und sich nicht auf Nebenkriegsschauplätzen verlieren. Wenn man wirklich will, kann man den eigenen Bootloader noch machen, wenn das OS funktioniert.

Find ich gut! Also werd ich mich mal in GRUB einarbeiten, um dann mein Projekt endlich ordentlich beginnen zu können.

Am einfachsten und performantesten ist natürlich Assembler, weil man hier alles optimieren kann. Der eigene geschriebene Bootloader darf natürlich auch nicht fehlen wie das eigene Dateisystem und die Shell im Kernel - hochperformant und super schnell.

Das ist dann mein vorletztes Ziel Wobei mir da wieder die Frage im Kopf herumschwirrt: GUI auf Shell aufsetzen oder direkt auf den Kernel?
In der Planung würd ich mich spontan eher für zweiteres entscheiden.

Als persönliche Königsdisziplin will ich das ganze noch in einer eigenen Programmiersprache umsetzen
Ich weiß dass sich das nicht in 30 Jahren ausgehen wird, aber ich bleib optimistisch.

Aber eins muss es immer machen: Spaß Wenn du Stunden um Stunden für das perfekte Design verbringst und dir den Kopf zermaterst über das einzig wahre und perfekte Design ohne bislang eine Zeile Code zu schreiben machst du in meinen Augen etwas falsch.

Definitiv ist meine Entwicklung festgefahren, weil ich mich zu sehr auf den "perfekten" Bootloader konzentriert habe.

ich persönlich bevorzuge TOP-DOWN. Ich entwickle erst mal eine grobe Idee was ich eigentlich erreichen möchte, danach zerlege ich die sich ergebenen Probleme in ihre Teile und fange dann für jedes einzelne Teil-Problem von vorne an. Das klingt aufwendig und das ist es auch aber es ist IMHO die einzigste Methode mit der man wirklich ein gutes Ergebnis erreichen kann.

Das "gute" Ergebnis ist nach meinen Erfahrungen nur logisch gut.
Wenn man die Hardware-Spezifikationen und die Optimierungshintertürchen kennt, kann man das bei der Planung berücksichtigen und gleich ein physisch gutes Ergebnis erzielen.

Auf jeden Fall kostet eine sauber strukturierte Vorgehensweise einiges an Disziplin und Zeit aber ich behaupte das man mit der chaotischen Variante, erst mal Code tippen und dann hinterher herausfinden was nicht stimmt, für das selbe Ergebnis in Summe mehr Zeit aufwenden muss (wegen den vielen Fehlschlägen) und letztendlich doch von oben nach unten plant (nur merkt man das dann nicht so deutlich weil es iterativ und eben als chaotischer Prozess passiert).

Zeit ist bei mir rar geworden :/
Wenn ich ein kleines Java-Tool schreibe, dann überleg ich mir on-the-fly das passende Design von oben herab - bei kleinen Programmen mag das funktionieren, aber sobald es über 3K Zeilen hinausgeht steigt die Schwierigkeit, alle Details im Kopf zu behalten.

[kevin]

GUI auf Shell aufsetzen oder direkt auf den Kernel?

Wie genau würdest du eine GUI auf die Shell aufsetzen? Die ganze GUI als Shellskript schreiben?

Oder meinst du eher, wie du Textmodus- und Grafikterminals unter einen Hut bekommst?

Als persönliche Königsdisziplin will ich das ganze noch in einer eigenen Programmiersprache umsetzen
Ich weiß dass sich das nicht in 30 Jahren ausgehen wird, aber ich bleib optimistisch.

Okay, kannst du machen. Dann sind wir aber wieder bei der Bootloader-Argumentation zurück: Mach nur eins, und das dafür richtig. Stell also vorerst deine Überlegungen zum OS zurück und definiere erstmal deine Sprache und mach dich daran, einen Compiler dafür zu schreiben. Hast du irgendwelche besonderen Ziele für die Sprache, oder geht es einfach darum, sowas mal gemacht zu haben?

Wenn du einen groben Entwurf für die Sprache hast, kannst du ihn gern mal posten, dass wir ihn auseinandernehmen.

[Dimension]

GUI auf Shell aufsetzen oder direkt auf den Kernel?

Wie genau würdest du eine GUI auf die Shell aufsetzen? Die ganze GUI als Shellskript schreiben?

Hihi, das habe ich mich auch gefragt. Ich dachte, entweder ist das wirklich quatsch, oder ich verstehs bloss nicht.