Diskussion:Grand Unified Bootloader

ISO mit GRUB 2

grub-mkrescue ist ja eigentlich nicht dazu gedacht, sich eine ISO für sein OS zu erstellen. Mein GRUB2-ISO-Skript funktioniert eigentlich ganz gut, wäre es angebracht das entsprechend einzuarbeiten? Zumal man dann auch kein Problem hätte, die Daten nachträglich auf das Image zu schieben. Zum ansehen des Skripts hier klicken TheThing 11:23, 22. Jun. 2011 (CEST)

Warum GRUB

Ich finde der Teil >Warum Grub< sollte überarbeitet werden, da er meiner Meinung nach ein völlig falsches Bild vermittelt. Es wird behauptet, dass ein eigener Bootloader daran scheitere, dass dafür tiefergehende Assemblerkentnisse notwendig sein. Ich finde dieses Argument insoweit falsch, als dass ein Projekt Betriebssystem natürlich in jedem Fall tiefergreifende Kentnisse in einer Programmiersprache erfordert. In welcher Sprache die Kentnisse vorhanden (oder auch nicht vorhanden) sind, ist hier eigentlich egal. Weiterhin erschließt sich mir nicht, wieso ein eigener Bootloader fehleranfällig sei. (Oder fehleranfälliger als alle anderen Projekte des Unwissenden.) Der berühmte Fehler, des Loaders, der da nur ein paar Kilobyte lädt, kann einem Anfänger natürlich passieren. Was ist schlimm daran? Was sollte den Anfänger daran hindern die Lösung im Internet zu finden? Wenn der Bootloader ein neues Feature braucht kann ich das selbstredend auch anständig implementieren und nicht nur hinzufriekeln. Wenn GRUB jedoch das Feature nicht hat, kann ich kaum das Feature nachrüsten. Natürlich verschlingt ein eigener Bootloader viel Zeit. Der Kernal aber nicht? Und der Bootvorgang des X86 erfordert es nicht, das A20 einzuschalten. Augenscheinlich soll hier dem Leser das Bild suggeriert werden, dass man seinen Kernal in C im PM schreibt und dann von GRUB laden soll. Das ist ein Weg. Aber nicht der einzige. Beispielsweise habe ich mein OS ausschließlich in RM Assembler geschrieben. Hier wäre GRUB völlig sinnlos. Mein Bootloader passt in den 1. Sektor und stellt sämtliche Dateisystemfunktionen bereit. Diesen Weg kann man auch gehen.

Für einen Bootloader braucht man auf jeden Fall weitere Assemblerkenntnisse, als diese für den Kernel unbedingt nötig sind, vor allem muss man für einen Bootloader RM-Assembler können. Wenn man kein Assembler kann, sollte man keinen Bootloader schreiben (es sei denn, man will dabei Assembler lernen). Mehr steht im Artikel dazu auch nicht drin.

Da die Überschrift des Abschnitts „Warum GRUB?“ lautet, geht es bei „fehleranfällig“ darum, dass der eigene Bootloader fehleranfälliger als GRUB ist; nicht darum, dass er fehleranfälliger als der Kernel wäre. Die meisten Hobby-OS-Entwickler zumindest auf Lowlevel sind der Ansicht, dass einen Kernel zu schreiben das wichtigste oder zumindest das erste Ziel in der OS-Entwicklung sein sollte[citation needed]; wenn der Bootloader dann noch Mist baut, lenkt das nur unnötig ab. „Unnötig“, weil es nach Ansicht der meisten interessanter ist, einen Kernel als einen Bootloader zu schreiben.

Die Lösung zu so etwas im Internet zu finden gestaltet sich meist schwierig, da man erstmal das Problem an sich finden muss (was im Artikel als „schwierig zu debuggen“ beschrieben wird), und dann vermutlich nicht mal etwas relevantes findet, wenn man danach googelt (“Boot loader only loads first 64 kB” wird vermutlich keine schrittweise Anleitung zum Lösen des Problems liefern). Was man machen kann, ist, im Forum oder im IRC zu fragen; dort werden die Leute in Bezug auf Bootloader aber eher weniger hilfsbereit sein und einfach sagen „Nimm GRUB“. Deshalb nimmt der Artikel genau das vorweg.

Ich möchte darauf hinweisen, dass der Artikel im bewussten Abschnitt sogar aufzeigt, dass es Vorteile haben kann, einen eigenen Bootloader zu schreiben. Was der Abschnitt also tut, ist keineswegs zu behaupten, dass jeder GRUB benutzen muss; vielmehr suggeriert er einfach, wie du richtig sagst, GRUB zu benutzen, denn das ist eine weitverbreitete Meinung auf Lowlevel[citation needed].

Wie gesagt, wenn jemand mit Problemen bei seinem eigenen Bootloader ins Forum oder ins IRC kommt, ist die Antwort im Allgemeinen einfach „Nimm GRUB“, weil es eben schwierig ist, Bootloader zu debuggen und es häufig kein allgemeines Rezept gibt. Außerdem ist es einfach so, dass viele, die einen Bootloader selbst schreiben, sich noch nicht sehr lange mit OS-Dev beschäftigt haben (Quelle: Erfahrung, und außerdem ich selbst). Das macht das Debuggen nicht gerade einfacher. Aus diesem Grund nimmt der Artikel genau diese Reaktion vorweg. Wir möchten niemanden ermutigen, seinen Bootloader selbst zu schreiben, wenn er dann bei Problemen einfach „Nimm GRUB“ gesagt bekommt. Ich persönlich halte es für besser, gleich GRUB zu empfehlen. Vielleicht wäre es besser, wenn wir Leuten, die Probleme mit einem eigenen Bootloader haben, einfach helfen würden. Weiß ich aber nicht, denn ich persönlich halte den Bootloader mittlerweile für ziemlich uninteressant. Alles, was der machen muss, muss auch der Kernel am Ende irgendwie machen.

Ähnlich dazu ist übrigens, dass wir fordern, dass die Leute C können, bevor sie einen Kernel in C schreiben. Das ist eigentlich ziemlicher Unsinn. Ein Kernel ist ein wunderbares Projekt, um C zu lernen (und ich bin nicht der einzige, der das sagt). Aber wir wollen vermeiden, dass im Forum oder im IRC Fragen zur Sprache C gestellt werden, weil das hier nicht die richtige Plattform dazu ist. Also sagen wir einfach, C muss man können, und dann ist klar, dass man sich Antworten dazu von woanders holen muss.

Zuletzt möchte ich noch darauf eingehen, dass du nicht findest, dass man seinen Kernel in C im PM schreiben sollte und im Zuge dessen sagst, das A20-Gate müsste beim Booten nicht eingeschaltet werden: Der RM ist obsolet, und seit der Einführung von UEFI ist es nicht mal unwahrscheinlich, dass er bald gar nicht mehr existiert. Um mehr als jedes zweite MB ansprechen zu können (was sich bei heutigen RAM-Größen durchaus als sinnvoll erweist), muss das A20-Gate eingeschaltet werden (wobei es heute teilweise schon fest eingeschaltet ist). Beides kann man ignorieren, wenn man will, aber das ist nunmal der Stand der Zeit seit zwei Jahrzehnten (oder mehr), und ich halte es für sehr sinnvoll, dieses Wiki daran auszurichten.

Zum Thema C: Der Artikel erwähnt nicht einmal, welche Sprache man zu verwenden hat, soweit ich das sehen kann. Man darf auch C++, D, Pascal, Sather, oder sogar Assembler für den Kernel benutzen. Die Annahme, die der einführende Abschnitt trifft, ist, dass man ein Betriebssystem mit einem Kernel im PM oder LM schreiben möchte. Dabei hilft GRUB, weil ein Bootloader meiner Ansicht nach kein Teil des Betriebssystems ist.

Ich möchte auch noch sagen, dass auch ich eine Menge Bootloader selber geschrieben habe und immer wieder Freude an 512-Byte-Spielereien finde. Ich glaube, wie es auch der Artikel sagt, dass man beim Schreiben eines Bootloaders (und eines Kernels) in Assembler eine Menge über die x86-Architektur lernt. Ich glaube allerdings auch, dass man C wunderbar bei der OS-Entwicklung lernen kann. Da müssen wir uns jetzt überlegen, ob das Wiki zielführend oder nicht ausgerichtet sein soll: Aktuell ist es recht zielführend. Was vermutlich auf lange Sicht nicht funktionieren wird, davon raten wir ab. Kernel in Sprachen außer C, ein eigener Bootloader, Real Mode… Das sind alles Dinge, die viele Leute ausprobiert haben, und die sich dann als nicht so gut erwiesen haben. Umgekehrt kann man das aber alles machen, wenn man Ahnung davon hat. Aber leider versuchen das auch Leute, die keine Ahnung haben, und das funktioniert dann eben häufig nicht so gut. Darauf könnten wir das Wiki aber auch ausrichten, und sagen, „Hey, da werdet ihr ein Jahr oder mehr dran sitzen, ihr werdet am Ende nichts funktionierendes haben, aber ihr habt eine Menge gelernt.“ So lief das für mich, und ich finde das auch gut so. Das wäre die nicht zielführende Variante.

Ich denke, Hobby-OS-Dev ist tatsächlich nicht zielführend. Am Ende hat fast niemand etwas wirklich benutzbares (Betonung auf „fast“), aber fast alle haben eine Menge gelernt. Aber das macht sich doof, wenn man das ins Wiki schreibt. Also bin ich eher dafür, dass da steht „Hey, nimm lieber GRUB, das funktioniert bei den meisten besser“ mit einer Notiz drunter, was man verpasst, wenn mans nicht tut, als dass da steht „Schreib erstmal einen eigenen Bootloader, bevor du dich für oder gegen GRUB entscheidest, dabei lernst du nämlich eine Menge“.

Vielleicht sollten wir eine dicke Notiz auf die Startseite packen, dass alle Vorschläge, wie man etwas zu tun oder zu lassen hat, subjektiv sind, und ausdrücklich empfehlen, dass man sich auch dagegen entscheiden kann. Nur sollte man dann keine Hilfe im Forum oder IRC erwarten (nicht, dass es sie auf keinen Fall gibt, aber na ja…). —Clici McXan 15:05, 2. Mai 2015 (CEST)

Ich versuche mal, die Grundidee etwas kürzer zu fassen: Wenn du ein OS entwickeln willst, dann ist der Bootloader – je nach Sichtweise – entweder gar nicht Teil des OS (so sehe ich das) oder einer der uninteressantesten Teile, die die wenigsten Auswirkungen auf das Endergebnis haben. Durch einen schlechten Bootloader kann man manches kaputtmachen, aber mehr als GRUB bietet, wirst du kaum brauchen, und kannst deswegen durch einen eigenen Bootloader nichts gewinnen. In anderen Worten: Wenn es dir ums OS geht, ist der Bootloader nur Arbeit, die nichts bringt.

Bleiben die Fälle, in denen jemand bewusst nicht an einem OS, sondern an einem Bootloader arbeiten will. Dann soll er gern einen Bootloader schreiben, aber dann wird er es vermutlich auch richtig machen wollen und nicht mit einem notdürftigen 512-Byte-Loader abhaken. Wenn es dir also um den Bootloader geht, und darum, RM-Assembler zu lernen, dann schreib einen guten Bootloader und lade damit ein anderes OS.

Wenn du übrigens einen RM-Kernel in Assembler geschrieben hast, dann würde ich, ohne dir zu nahe treten zu wollen, behaupten, dass dein OS noch nicht weit über die Hello-Welt-Phase hinaus ist und das der Grund ist, warum du den Bootloader noch als einen interessanten Teil ansiehst, über den es sich zu streiten lohnt. --Taljeth 17:11, 3. Mai 2015 (CEST)

Hallo Clici McXan, ehrlich gesagt verstehe ich deinen Beitrag nicht. Es ist meiner Auffassung nach eine etwas merkwürdige Haltung, eine Wiki mit Forum zu betreiben und gleichzeitig zu signalisieren, dass man Anfängern nur dann weiterhilft, wenn Sie einen gewissen Kentnisstand haben. So gesehen, wenn ich Grub nehme und perfekt C kann, wozu brauche ich dann dieses Forum bzw. dieses Wiki? Glücklicherweise bin ich seit Jahren in einem anderen Forum aktiv, dass nach der Philosophie arbeitet, dass auch blutigsten Anfängern geholfen wird. Und jemand mit viel Ahnung hat mal zu mir gesagt, (ich hatte da ein Problem mit so nem Hello World Loader), er hilft mir gerne, wenn ich selber einen Bootloader entwickle. Aber er fixt mir nicht dieses Hello World Ding zusammen. Ich habe auf diesen Rat gehört und dabei eine Menge gelernt. Will sagen nur Standardlösungen zu präsentieren (so wirds gemacht) ist vielleicht auch nicht der beste Weg. Ich habe nie gesagt, dass man Grub nicht nutzen soll. Aber man kann auch andere Wege gehen.

Hallo Taljeth, du trittst mir kein bisschen zu Nahe. Aber deine behauptung stimmt so nicht. Mein vollständig in RM Assembler geschriebenes OS umfasst z.Z. über 26.000 Zeilen Quelltext. Neben mehreren integrierten Programmen, einem vollständig eigenentwickelten Dateisystem verfügt es auch über eine 46 Befehle starke API mit deren Hilfe Programme für das OS Entwickelt werden können. Details findest du unter www.beepsoft.de Also anscheinend kann man mit dem völlig veralteten Realmode doch noch ganz nette Dinge anstellen. Und ich würde wetten, dass mir der GRUB nicht gestattet mein eigenes Dateisystem zu entwickeln.

Hi,

Wenn du perfekt C kannst, kannst du noch lange kein OS schreiben. Wenn ich einfach nur perfekt C++ kann, kann ich auch noch lange kein AAA-Spiel für den Massenmarkt entwickeln. Dieses Wiki und das Forum erklären (unter anderem), wie man mit C ein OS entwickelt.

Ich hoffe, ich habe nie gesagt, dass wir blutigsten Anfängern nicht helfen. Die Frage ist, worin sie Anfänger sind. Wir werden niemandem helfen, der zum ersten Mal einen Computer benutzt, gerade den Browser ausprobiert, und dabei auf diese Seite gestoßen ist, weil das nichts bringen würde. Wir helfen Leuten, die Anfänger bei der Betriebssystementwicklung sind und dazu Fragen haben, denn darum geht es auf dieser Seite. Grundsätzlich helfen wir aber nicht Leuten, die Schwierigkeiten haben, die nichts mit Betriebssystementwicklung zu tun haben, zum Beispiel mit der Programmiersprache, in der sie gern das OS schreiben würden (bspw. C). „Grundsätzlich“ heißt nicht, dass ihnen nie geholfen wird, aber es heißt, dass sie keine Hilfe erwarten dürfen.

Nach Meinung der meisten hier gehört der Bootloader nicht zum Betriebssystem. Das ist der Grund, warum Fragen zur Bootloaderentwicklung ebenso grundsätzlich nicht Thema dieser Seite sind. Wieder heißt „Grundsätzlich“, dass Hilfe dabei nicht bestraft wird, aber es heißt eben auch, dass wir im Zweifel eher von dem Thema wegsteuern.

Während wir bei Programmiersprachenfragen häufig sagen können „Dazu gibt es genug Seiten, lies dir die halt durch“, können wir das bei Bootloadern nicht, oder zumindest nicht guten Gewissens. Es wäre natürlich schön, wenn es eine Seite gäbe (möglichst im deutschsprachigen Raum), die sich intensiv mit der Bootloaderentwicklung auseinandersetzt. Dann könnten wir immer sagen „Geht doch dahin, da hilft man euch“. Gibt es nicht, also können wir das nicht. Das einzige, was wir deshalb machen können, ist zu sagen „Nimm GRUB“.

Wenn du eine konkrete Frage zu einem Bootloader hast, kannst du sicherlich ins Forum gehen und diese Frage stellen, mit nicht allzu wenig Glück bekommst du sogar eine Antwort; da Bootloader allerdings nicht das Thema dieser Seite sein sollen, haben wir uns entschieden, Leuten generell von eigenen Bootloadern abzuraten, damit das nicht zu oft passiert (das war ja das ursprüngliche Thema dieser Diskussion, soweit ich mich erinnere).

Falls du dir übrigens die Frage stellst, warum wir Bootloader nicht als Thema auf dieser Seite sehen, so ist für mich persönlich die Antwort: Weil fast alle Probleme, die beim Schreiben eines Bootloaders auftauchen, letzten Endes auch Probleme sind, die man beim Schreiben eines Kernels hat. Wenn man einen Kernel mit Gerätetreibern schreiben kann, sollte man auch einen Bootloader schreiben können.

Du hast vollkommen Recht, wenn du sagst, Standardlösungen zu präsentieren ist nicht unbedingt der beste Weg, das habe ich so ähnlich ja auch geschrieben:

Vielleicht sollten wir eine dicke Notiz auf die Startseite packen, dass alle Vorschläge, wie man etwas zu tun oder zu lassen hat, subjektiv sind, und ausdrücklich empfehlen, dass man sich auch dagegen entscheiden kann.

Leider sind wir nicht in der Lage, alle Lösungen zu präsentieren (das ist sogar ganz einfach unmöglich), deshalb müssen wir uns auf Standardlösungen beschränken. Abgesehen davon, was Bootloader angeht kenne ich keinerlei Form von Tutorial oder Grobanleitung zum Selberschreiben, die ich guten Gewissens als Alternative zu GRUB präsentieren könnte.

Übrigens wird dich vermutlich niemand daran hindern, Eigener Bootloader (o. ä.) zu füllen. Wenn der Inhalt gut genug ist, sodass man dabei tatsächlich von einem ordentlichen Bootloader sprechen kann (und nicht nur von etwas, was halt schnell den eigenen Kernel lädt, mit hartkodierten Offsets, Maximallängen, und was weiß ich, das heißt, was man üblicherweise so bei eigenen Bootloadern sieht), dann können wir gern den strittigen Abschnitt im Artikel hier überarbeiten, und wir hätten alle was gewonnen.

PS: GRUB kann mit Blocklisten statt Dateinamen umgehen. Damit kann man auch Dateien von GRUB unbekannten Dateisystemen laden.

PPS: Ja, der Real Mode und insbesondere das BIOS sind übrigens völlig veraltet, wenn das ironisch gemeint war. Spätestens seit UEFI sind deren Tage endgültig gezählt.

—Clici McXan 21:13, 31. Jul. 2015 (CEST)

Hi,

ich möchte da auch mal kurz meine Senf dazugeben. Zunächst einmal kann ich Clici McXan da zustimmen was die Empfehlung von GRUB angeht. Natürlich kann es durchaus sinnvoll sein eine angepasste oder gar eigene Lösung zu verwenden (vor allem wenn man es der Herausforderung wegen macht), aber in 90% der Fälle ist GRUB nicht nur mehr als ausreichend, sondern sogar besser als Selbstentwickeltes. Ich sehe das in etwa so, dass jemand fragt, wie er denn ein für Linux geschriebenes Programm auf einem PC ausführen kann. Natürlich kann man ihm empfehlen FreeBSD zu installieren und die Linux-Emulation zu verwenden, oder Windows zu installieren und ein Linux in Virtualbox laufen zu lassen, aber im Allgemeinen wird der Rat eben lauten: Installier dir ein Linux. Viele Wege führen nach Rom, und es ist sicher nicht falsch einen breiten Weg mit wenig Schlaglöchern zu empfehlen.

Nun zu deinem Realmode-Argument. Zahlen alleine sagen da nicht viel aus, entscheidend ist, was sie bewirken. Sicherlich kann man im Realmode so einiges anstellen, einige haben das sogar zu einer Kunstform erhoben, aber wenn ich dann ein "OS" sehe, bei dem ein amoklaufender Texteditor den Kernel zu Fall bringt, dann spreche ich dem ganzen schon ein Stück weit die Existenzberechtigung ab. Der Realmode ist nun einmal ein Relikt der Vergangenheit, mehr Bürde als Feature, und hat im 21. Jahrhundert abseits von Kompatibilitätsgründen (und die werden auch weniger) keinen Platz mehr. Und das nicht nur aufgrund des Fehlens von elementaren Mechanismen wie Speicherschutz, sondern auch, weil ich mir nicht 16GB RAM in den Rechner stecke nur um dann mehr als 99% davon nicht benutzen zu können. Dass GRUB die Verwendung des Realmodes erschwert ist meiner Meinung nach eher gut als schlecht, da so eventuell Anfänger davon abgehalten werden auf die Idee zu kommen, der Realmode sei irgendetwas anderes als eine Sackgasse.

Auch dein Dateisystem-Argument ist eher ein Anti-Argument. Die meisten Hobby-Dateisysteme sind nur miese Reimplementierungen von FAT, und das leider besonders oft bei vehementen Realmode-Verfechtern (nicht, dass ich deine Leistung schmälern oder gar dein Werk beleidigen will, aber es ist nun einmal der häufigste Fall. Richtige Innovationen bei Dateisystemen finden heute in Richtung ZFS/XFS/BTRFS usw. statt, mir wäre nicht bekannt dass ein Hobby-OS ein Dateisystem mit handfesten Vorteilen hervorgebracht hat). FAT gibt es schon, es ist sinnlos es zum hundertsten "neu zu erfinden" statt einfach FAT selbst zu verwenden. Auch hier sehe ich GRUB eher positiv, da es Anfänger hier einen Stein in den Weg, der in die falsche Richtung führt, legt.

Um nochmal etwas taljeths letztes Argument aufzugreifen: Vergleiche dein OS mal mit den etwas "größeren" Hobby-OS. Beispielsweise Tyndur, ToAruOS, Μxoµcota, oder auch Ghost. Und verdeutliche dir dabei, warum die Entwickler dieser OS eben diesen Weg gegangen sind, und sich nicht zu sehr vom not-invented-here-Syndrom haben verleiten lassen. Manchmal kann ein Sonderweg sinnvoll sein, aber es hat eben einen Grund, warum zu manchen Dingen so vehement geraten wird.

--TheThing 23:23, 31. Jul. 2015 (CEST)

Hallo Clici McXan: ich lese ja schon seit einiger Zeit diese Seite und war immer der Meinung, dass es hier um Betriebssystemprogrammierung im allgemeinen ginge, nicht nur um selbige mit C. Hab ich mich wohl geiirt. Gern werde ich demnächst einen Artikel auf meiner Seite veröffentlichen, wie man (aus meiner Sicht) einen Bootloader programmieren (kann!) Dieser Artikel kann dann gerne geprüft werden. Ich hoffe unter den Gesichtspunkten der Qualität und nicht unter der Prämisse, ob etwas standardconform geschrieben wurde. Also heißt das, dass Grub meinen Kernal laden könnte? Ich bezweifle stark, dass das BIOS veraltet ist. Das Konzept einer Firmware, die zum Start eines PCs Hardware initialisiert wird es sicherlich noch eine Weile geben. Und ob sich jetzt das UEFI durchsetzt, dass gerade unter dem Gesichtspunkt Sicherheit doch schon fragwürdig ist. (Stichwort UEFI Rootkit)... Wir werden es erleben. Und was heißt, der Realmode ist veraltet. Meines Wissens nach ist der Realmode in jedem PC nach wie vor implementiert. Ob jetzt der Realmode nur deshalb veraltete ist, weil ich mit dem Protectedmode (übrigens auch nicht mehr ganz taufrisch) mehr Speicher laden kann, weiß ich nicht.

Hallo TheThing: Grundsätzlich wird Linux/Windows immer besser sein, als etwas Selbstentwickeltes. Insofern, was machen wir uns die Mühe? Du steckst dir also 16GB RAM in den Rechner. Ich vermute, das machst du damit die nur mäßig gut entwickelte Software weiterhin funktioniert. Ließ dir mal die Systemanforderungen vom Windowsmediaplayer durch und vergleiche die mit dem QV Player für DOS. Warum führt der RM in eine Sackgasse. Du machst in deinem Beitrag verschiedene Andeutungen über mein OS. Ich lade dich hiermit ein, mein OS zu testen und dann gerne sachliche Kritik darüber zu äußern. Also ich habe es bisher noch nicht geschafft mit meinem Editor meinen Kernal zum Absturz zu bringen. Auch hat mein Dateisystem nicht wirklich etwas mit FAT gemein. Zum Schluss: Ich habe mir alle von dir angegebenen OS angesehen. Erkläre mir doch jetzt mal bitte, was der von dir angeführte Vergleich ergeben soll. Berücksichtige dabei bitte, dass vielleicht nicht alle Projekte das selbe Ziel verfolgen.

Hi,

ich möchte hier einmal abschnittsweise auf deinen Post eingehen.

• ich lese ja schon seit einiger Zeit diese Seite und war immer der Meinung, dass es hier um Betriebssystemprogrammierung im allgemeinen ginge, nicht nur um selbige mit C. Hab ich mich wohl geiirt.

Tut es auch. Jedoch ist es schlicht unmöglich, hier Beispiele für jede existierende und für OS-dev geeignete Sprache aufzuzeigen. Deswegen wird hier C verwendet, weil C nicht nur sehr weit verbreitet ist (und man somit einen möglichst großen Teil des potenziellen Publikums abdeckt), sondern auch, weil C stark verwandt mit vielen anderen Sprachen ist. Wer den C-Code versteht, kann das gelernte dann auch in seine eigene Sprache übertragen. Und ganz nebenbei hält C auch weniger unangenehme Überraschungen für OS-Entwickler bereit als z.B. C++.

Das heißt jetzt aber nicht, als nicht-C-User hier mit Fackeln und Mistgabeln gejagt werden. Im Forum wurde schon auf Fragen zu so ziemlich Allem von ASM bis Pascal eingegangen, nur sollte man eben nicht erwarten hier Hilfe zu seiner selbstgewählten Programmiersprache zu bekommen. Wenn ich jetzt z.B. ein OS in FreeBASIC anfange, und dann hier nachfrage warum ich Probleme bekomme wenn ich den Datentyp "String" verwende, dann wird im Forum sicher der eine oder andere völlig zu Recht gering begeistert sein, weil es eben kein OS-dev Problem ist, sondern ein Problem meines Wissensstandes im Bezug auf meine Programmiersprache.

• Ich bezweifle stark, dass das BIOS veraltet ist

Da brauchst du nicht lange zu zweifeln, es ist veraltet, und das im Grunde schon seit 20 Jahren. Im meine mich zu erinnern dass es vor kurzem erst einen Post auf osdev.org gab, in dem das Warum ausführlich erläutert wurde. Mit der fehlenden Unterstützung von GPT fangen die Probleme nämlich gerade erst an...

• Das Konzept einer Firmware, die zum Start eines PCs Hardware initialisiert wird es sicherlich noch eine Weile geben.

"BIOS" ist kein Synonym zu "Firmware". Natürlich wird weiterhin eine Firmware zum Einsatz kommen, aber diese Firmware wird eben kein BIOS mehr sein.

• Und ob sich jetzt das UEFI durchsetzt, dass gerade unter dem Gesichtspunkt Sicherheit doch schon fragwürdig ist. (Stichwort UEFI Rootkit)... Wir werden es erleben.

Nein, wir haben es bereits erlebt, UEFI hat sich schon längst durchgesetzt. Nahezu alle heute verkauften Systeme haben kein BIOS mehr, natürlich abgesehen von Kleinkram wie den apu1d-Systemen von PC Engines und Hardware aus älteren Generationen. Und bitte mach nicht den Fehler anzunehmen das BIOS sei sicherer als UEFI gewesen - das war es nämlich nicht. Die Liste der BIOS-Lücken und Fehler ist gigantisch, und die Idee, Malware in Firmware unterzubringen, gab es bereits lange vor UEFI, in vielerlei Hinsicht war das mit dem BIOS sogar noch einfacher. Wenigstens gibt es überhaupt Bestrebungen UEFI sicherer zu machen, während man sich beim BIOS auf den Glauben, dass Ignorieren auch eine Art der Problemlösung wäre, verlassen hat.

• Und was heißt, der Realmode ist veraltet.

Das heißt, dass er völlig außerstande ist, moderne Anforderungen zu erfüllen.

• Meines Wissens nach ist der Realmode in jedem PC nach wie vor implementiert.

In den meisten x86-PCs, ja, aber nicht weil er so modern ist, sondern weil er aus Gründen der Abwärtskompatibilität erforderlich ist. Andernfalls wäre er schon längst weg, und in manchen x86-Prozessoren ist er das schon. Nur weil es Räder aus Holz noch gibt, heißt das nicht, dass sie modern oder heute noch brauchbar sind, und kein geistig gesunder Mensch würde sich so ein Ding an sein Auto schrauben.

• Ob jetzt der Realmode nur deshalb veraltete ist, weil ich mit dem Protectedmode (übrigens auch nicht mehr ganz taufrisch) mehr Speicher laden kann, weiß ich nicht.

Soll das heißen, dass du nicht einmal weißt, warum (fast) alle anderen den Realmode meiden, und trotzdem fängst du hier eine Diskussion darüber an? Da hätte dir schon Wikipedia weiterhelfen können (Flat Address Space, Virtual Memory, NX-Bit, breitere Register, mehr Register...).

• Protectedmode (übrigens auch nicht mehr ganz taufrisch)

Es gibt einen großen Unterschied zwischen alt und veraltet. Die Idee des Autos mit vier Rädern ist alt, die Idee, Räder aus Holz zu machen, ist veraltet. Die Idee, Motoren mit Benzin und Luft zu betreiben, ist alt, die Idee, dafür einen Vergaser zu verwenden, ist veraltet.

• Grundsätzlich wird Linux/Windows immer besser sein, als etwas Selbstentwickeltes. Insofern, was machen wir uns die Mühe?

Ich kann hier zwar nur für mich selbst sprechen, aber ich entwickle mein OS nicht mit dem Ziel, ein besseres Linux oder besseres Windows zu erschaffen, sondern zum einen, weil es mir Spaß macht (und wie ich oben schon sagte, kann das Argument "Spaß an der Herausforderung" auch für das Beschäftigen mit veralteter Technologie gelten) und zum anderen, weil ich andere Wege gehen will als die bereits existierenden OS. Ich entwickle mein OS nicht, weil ich der Auffassung bin, dass alle anderen dumm sind und nur ich weiß wie man es richtig macht.

• Du steckst dir also 16GB RAM in den Rechner. Ich vermute, das machst du damit die nur mäßig gut entwickelte Software weiterhin funktioniert.

Da vermutest du leider völlig falsch. Ich habe so viel RAM, damit ich weder meine permanent laufenden Programme (Firefox, Thunderbird, putty...) noch meine im Hintergrund build-Prozesse kauenden VMs beenden muss, nur weil ein Kumpel mich zu eine Runde GTA V Online einlädt, und trotzdem noch genug RAM für Caches frei ist. Sag mir bescheid, sobald das im Realmode auch geht.

• Ließ dir mal die Systemanforderungen vom Windowsmediaplayer durch und vergleiche die mit dem QV Player für DOS.

Systemanforderungen alleine sind nicht im geringsten aussagekräftig. Ein MySQL Server hat viel höhere Anforderungen als ein Texteditor, trotzdem käme niemand auf die Idee, ab sofort auf notepad statt MySQL zu setzen. Der Windows Media Player erledigt viel mehr als das reine Abspielen von Medien (nachinstallierbare Codecs, Windows-Integration, DRM, Medienbibliothek, Ripping-Funktionen...), und auch wennn ich den WMP nicht als Beispiel für gute Software heranziehen würde, so hinkt dein Vergleich doch gewaltig. Außerdem zitiere ich von der Website des QV Players: "The Pro version (protected mode) also supports MP4,[...]". In der Realmode-Version sind die Features nämlich "sehr überschaubar", um es mal nett auszudrücken.

• Warum führt der RM in eine Sackgasse

Ich denke, dass meine obige Aufzählung und Wikipedia, lowlevel und osdev.org da genug Informationen bieten. Als kleine Zusatznotiz möchte ich anmerken, dass die reinen Rohpixel des Bildschirms, auf dem ich das hier gerade schreibe, ungefähr 8-mal soviel RAM benötigen wie der Realmode addressieren kann.

• Du machst in deinem Beitrag verschiedene Andeutungen über mein OS.

Das waren keine Andeutungen, sondern Argumente dafür, dass GRUB eben keine Steine in den Weg legt, es sei denn, man geht den falschen Weg. Obwohl statistisch wahrscheinlich, kann ich nicht mit Sicherheit sagen, dass oben aufgeführte Dinge auch auf den OS zutreffen, da ich es nicht angesehen habe.

• Ich lade dich hiermit ein, mein OS zu testen und dann gerne sachliche Kritik darüber zu äußern.

Da sowohl deine nicht-öffentliche Downloadmöglichkeit als auch deine Lizenzbedingungen höchst bedenklich sind, verzichte ich.

• Also ich habe es bisher noch nicht geschafft mit meinem Editor meinen Kernal zum Absturz zu bringen.

Soll das jetzt heißen, dass deine Auffassung von Sicherheit die ist, dem Nutzer und der Software blind zu vertrauen?

• Auch hat mein Dateisystem nicht wirklich etwas mit FAT gemein.

Das bezweifle ich, aber da du keine öffentlich zugängliche Dokumentation pflegst, lässt sich das nicht nachprüfen. Du darfst mich aber gerne widerlegen.

• Zum Schluss: Ich habe mir alle von dir angegebenen OS angesehen. Erkläre mir doch jetzt mal bitte, was der von dir angeführte Vergleich ergeben soll. Berücksichtige dabei bitte, dass vielleicht nicht alle Projekte das selbe Ziel verfolgen.

Ich bezweifle, dass du dir in einem solch kurzen Zeitraum diese Projekte detailliert ansehen konntest. Außerdem war das kein Vergleich, sondern sollte dir verdeutlichen, dass es eben meistens gute Gründe gibt, warum bestimmte Dinge getan bzw. nicht getan werden. Es gibt gute Gründe, warum Assembler nicht die meistverwendete Programmiersprache ist, genau so, wie es gute Gründe gibt eben nicht den Realmode zu verwenden oder keinen eigenen Bootloader zu entwickeln.

PS: Bitte signiere deine Posts. Eine korrekte Einrückung wäre auch hilfreich.

--TheThing 16:50, 1. Aug. 2015 (CEST)

Ich stimme der Kritik am Tenor des Artikels zu. Entweder, man weiß, was man tut, oder man weiß es nicht. Wenn nicht, wird auch der Versuch, einen Kernel zu schreiben, scheitern. Wenn doch, trifft die Kritik des Artikels am Schreiben eines eigenen Bootloaders nicht zu. Außerdem reden wir hier von der Entwicklung von Hobbybetriebssystemen... Erwartet da irgendwer Perfektion? Nein. Also warum diese Erwartung an den Bootloader? Wenn es jedoch dem Entwickler des Hobbybetriebssystems darum geht, zu verstehen, was auf einem x86-PC ab dem Start vor sich geht, dann muss man ja gerade dazu raten, auch den Bootloader selbst zu entwickeln, egal wie toll oder furchtbar das Resultat ist. --Mr. X 23:51, 8. Aug. 2015 (CEST)

Dem kann ich nicht zustimmen. Dieses Wiki widmet sich der Entwicklung von Betriebssystemen, und gerade Anfängern sollte man dringed davon abraten zusätzlich zum Betriebssystem noch einen Nebenkriegsschauplatz zu eröffnen, zumal sich das dann schnell in Überforderung verwandeln kann, wenn eventuelle Bootloader-Probleme dann Kernel-Probleme verursachen oder beeinflussen. Es ist nicht schwer einen Bootloader zu schreiben, aber es ist schwer, einen guten Bootloader zu schreiben. Die grundlegenden Mechanismen hinter einem Bootloader sind im Wiki hinreichend erklärt, zum Verständnis ist eine Implementierung hier nicht unbedingt erforderlich.

GRUB ist nun einmal aus gutem Grund der "Standard", nicht nur wegen der guten Interoperabilität und der Features, sondern eben auch, weil er Anfängern eine verlässliche Basis bietet. Anfängern zu signalisieren, es wäre zum Verständnis erforderlich (oder abseits des Reizes der Herausforderung überhaupt eine gute Idee) einen eigenen Bootloader zu entwickeln ist in meinen Augen ein Bärendienst.

--TheThing 04:54, 9. Aug. 2015 (CEST)

Moinsen,

> Wenn es jedoch dem Entwickler des Hobbybetriebssystems darum geht, zu verstehen, was auf einem x86-PC ab dem Start vor sich geht, dann muss man ja gerade dazu raten, auch den Bootloader selbst zu entwickeln

Dann muss man ihm auch raten, ein eigenes BIOS zu schreiben. Denn eine x86-CPU startet nicht an 0x0000:0x7c00 mit netten Software-Interrupts, die einem das Lesen von USB-Sticks erlauben, sondern zumindest früher eher an 0xffff:0x0000 vor dem POST, da funktioniert vermutlich noch nicht mal der Arbeitsspeicher.

Weiter oben kam irgendwo der Punkt auf, dass es ja bei Hobby-OS-Dev darum geht, etwas zu lernen oder anders zu machen, und eben nicht darum, das allerbeste OS zu schreiben. Deshalb könne man ja auch einen eigenen Bootloader entwickeln. Klar, kann man, aber ich glaube mich zu erinnern, schon noch weiter oben geschrieben zu haben, dass ein Bootloader nicht viel andere Sachen als ein Kernel auch macht. Ich habe ein paar Bootloader geschrieben und sehe absolut keinen Nutzen darin, wenn es um OS-Dev geht. Man lernt nichts, was man nicht auch bei der Kernelentwicklung lernen würde, und man kann sich nicht wirklich von bestehenden Betriebssystemen abgrenzen, indem man einen eigenen Bootloader schreibt. Wenn es um den Spaß an der Freude geht, klar, nur zu. Ich liebe auch 512-Byte-Sachen.

Niemand erwartet vom Bootloader Perfektion, aber ich persönlich (und andere Leute hier) sehen absolut keinen Grund, einen Bootloader zu schreiben, und bisher habe ich in dieser Diskussion auch kein gutes Argument dafür gehört. Wer es will, kann es natürlich, weil es Spaß macht, aber es geht in dieser Diskussion darum, was wir Anfängern empfehlen. Wer neu hierher kommt, will im Allgemeinen kein „Na, das kann man alles machen, wie man gerade lustig ist.“ Klar wäre das am ehrlichsten, aber das bringt denen rein gar nichts. Irgendeine Linie, die sich bewährt hat, müssen wir empfehlen, und diese Linie ist aktuell nun mal „Nimm GRUB und schreib den Kernel in C“. Das ist, wofür wir hier die besten Tutorials und die besten Seiten haben. Es bringt absolut gar nichts, Anfängern einen eigenen Bootloader und einen Rubykernel zu empfehlen, nicht zuletzt weil wir dazu praktisch keine Ressourcen haben. —Clici McXan 22:53, 11. Aug. 2015 (CEST)

Der Abschnitt Warum Grub? gehört komplett neu geschrieben. Welche Arbeit und Probleme ein eigener Bootloader konkret macht hat hier nichts verloren, und gehört nach: Eigener Bootloader. Unter GRUB gehört was GRUB bietet, einfacher Einstieg in OS-Dev, Multiboot, Dataisystem, Objekt-format etc. und evtl. einen Hinweis darauf das ein Bootloader ein Projekt für sich ist.

Aber auch für „Eigener Bootloader“ können die Punkte hier nicht einfach 1:1 übernommen werden. Aussagen wie „Man wird scheitern oder Code Kopieren“ können nicht so stehen bleiben. IIRC haben wir zum Thema Kernel auch irgendwo den Hinweis „Ist ein Kernel wirklich das was du willst?“ Viel mehr sollte IMHO beim Bootloader auch nicht stehen. --MNemo 07:08, 10. Aug. 2015 (CEST)

Moin,

Dann schreib ihn komplett neu. Das hier ist ein Wiki. Wenn es jemandem nicht passt, soll er das wieder umschreiben. Wenn es einen Edit War gibt, wissen wir, dass wir weiter diskutieren müssen.

Der Artikel Eigener Bootloader sieht sehr veraltet aus und müsste komplett neu geschrieben werden, ich glaube, 2010 wurde nicht viel vom Inhalt an sich geändert. Dass er eigentlich nur fertigen Code präsentiert, ist genau das, was mit „Man wird Code kopieren“ gemeint ist.

Was übrigens ein sehr guter Punkt ist. Ich stehe voll und ganz hinter „Man wird scheitern oder Code kopieren“. Der Bootloader steht am Anfang des Bootprozesses, also werden die meisten eher damit anfangen, als dass sie sich fünf Jahre mit Kernelentwicklung beschäftigen und sich dann mal an den Bootloader machen (warum sollten sie auch, dann sind sie offenbar fünf Jahre mit GRUB ausgekommen und das war immer gut genug). Naturgemäß kopiert man am Anfang viel Code, das ist halt bei den allermeisten bei OS-Dev so. Ein anfänglicher Bootloader ist nicht groß, der ist also schnell zusammenkopiert und dann läuft der auch so einigermaßen. Wenn er wirklich läuft, fasst man den auch nie wieder an. Warum auch, läuft ja. Beim Kernel ist das was anderes, an dem schraubt man die ganze Zeit rum. Wenn der also am Anfang zusammenkopiert ist, wird man den trotzdem nach einiger Zeit wohl mal selbst von Grund auf neu schreiben. Da man aber praktisch nie am Bootloader arbeitet, wird das dort nie passieren.

Natürlich mag es Leute geben, die nach einiger Zeit sehen, wie doof der zusammenkopierte Bootloader ist, und sich mal einen eigenen ordentlichen schreiben, wenn sie schon ein paar Jahre Kernelentwicklungserfahrung haben. Aber das werden nicht viele sein, behaupte ich, denn dann merkt man, dass ein Bootloader uninteressant ist und nur die gleichen Probleme wie im Kernel zu lösen sind. Also bleibt man dann halt bei seinem alten Bootloader oder nimmt lieber einfach GRUB.

Die einzige Ausnahme, die mir dazu spontan einfällt, ist PrettyOS, aber dort ist es erstens in meinen Augen eine Prinzipienfrage, weil wir eben sehr energisch GRUB empfohlen haben und ein gewisser Jemand sich halt nichts von der naiven Jugend sagen lässt, zweitens habe ich daran sogar selbst mitgeschrieben (u. a. weil die Kernelgröße beschränkt war, eine nette und sehr typische Kinderkrankheit von Bootloadern), und drittens ist es immer noch ein recht einfacher Bootloader, aus dem ich jetzt nicht erkennen kann, ob er tatsächlich ein Argument für eigene Bootloader sein soll.

Man lernt da also, wie man FAT12 in Real-Mode-Assembler liest, wie man in den PM springt, wie man den URM benutzt, wie man die BIOS-Memory-Map liest, und wie man die BIOS-API zum Lesen von Datenträgern benutzt. Ich will jetzt nicht wieder betonen, dass das alles veraltet ist, aber das ist es halt.

(Ein richtiges Gegenargument dazu ist übrigens: Ja, alles, was man so typischerweise bei OS-Dev benutzt, ist veraltet: PIT und PIC zum Beispiel; dazu ist mein Gegengegenargument aber wieder, dass das nur insofern vergleichbar ist, wenn man dann auch einen RM-Kernel schreibt. Wenn man einen RM-Bootloader und einen PM-Kernel hat, ist das so, als würde man am Anfang im Kernel PIT/PIC und irgendwann später HPET/APIC benutzen. Da stellt sich dann die Frage, warum man überhaupt PIT/PIC benutzt hat.)

Zusammenfassend: Ich hab selber schon einige Bootloader geschrieben. Ich hab nicht wenige Sachen im RM gemacht. Ich finde, es macht großen Spaß und freue mich, wenn andere mitmachen. Ich hab übrigens auch den Sather-Artikel geschrieben, von wegen „Immer nur C :<“ und so. Wie ich schon mehrfach geschrieben hab, gibt es bei OS-Dev niemals „den einen Weg“, sondern immer viele. Das können wir gern überall betonen, aber das scheint ja auch in dieser Diskussion dauernd überlesen zu werden, obwohl ich das mindestens zweimal geschrieben habe, das bringt also offensichtlich schonmal nichts. Worum es hier geht, ist, Anfängern einen bewährten Weg vorzugeben, den sie gehen können und auf dem sie hier Hilfe erwarten können. Und dieser Weg ist nunmal, und das ist unser aller Schuld, ein C-Kernel mit GRUB als Bootloader. Ja, nicht nur die Schuld der Leute, die das so in Ordnung finden, sondern vor allem die Schuld der Leute, die das nicht tun. Schreibt gute Artikel für andere Wege, haltet euch bitte auch immer im Forum bereit, um Fragen zu beantworten, und dann sieht die Sache schon ganz anders aus!

Aber bitte schreibt nicht in den Artikel „Ja, GRUB ist doch nur ein Weg, guckt mal, ihr könnt auch einen eigenen Bootloader schreiben!“, ohne dass ihr Eigener Bootloader grundlegend überarbeitet habt, und ohne dass ihr im Forum aktiv seid, um Fragen zum Thema zu beantworten. Das ist, was ich hier zu verhindern versuche, dass wir Anfängern Wege vorschlagen, auf denen wir ihnen dann nicht helfen können. Auf dem Weg GRUB+C können wir das, und deshalb ist das der eine Weg, den wir aktiv empfehlen. Außerdem funktioniert er tatsächlich recht gut, insbesondere für Anfänger, um erstmal mit OS-Dev anzufangen.

Sobald die Leute über ihre absolute Anfängerphase hinweg sind, sind sie im Allgemeinen auch zu eigenen Gedankengängen fähig. Und dann merken sie, dass man ja auch alles ganz, ganz anders machen kann. Und genau dann sind sie bereit für einen Rubykernel mit eigenem Bootloader. Bevor sie in der Lage sind zu begreifen, dass hier vorgeschlagene Wege nicht die einzigen möglichen sind, werden sie den meisten Code einfach kopieren und eher versuchen, andere ihre Probleme lösen zu lassen, statt sich selbst daran zu machen. —Clici McXan 22:53, 11. Aug. 2015 (CEST)