Thema: Fragen zum Bootloader und kernelübersetzung

[matheguru]

Ich habe drei Fragen:
1. Ich lasse mein Kernel von einer FAT32 Partition laden, dabei habe ich natürlich ein Problem die 32, ich befinde mich ja RM, also geht es nicht, oder doch ? In den PM schalten ist auch doof, wie soll ich dann einen ganzen Festplattentreiber in 512Byte bekommen. Gelöst habe ich das so, dass ab dem zweiten Cluster einfach der Kernel gespeichert ist, den Clusteroffsetberechnen und ab in den Speicher damit, denn sonst müsste ich ja vorher die ganze FAT in den speicher Laden und das würde den ganzen Arbeitspeicher sprengen. Was meint ihr dazu ??
2. Ich kann mit dem INT 13 ah=42 nicht mehr als ungefähr 10 Sektoren lesen, aber eig. kann man ja bis 127lesen, ist das von BIOS zu BIOS anders ?
3. Hat jemand schon versucht mit visual studio C++ den Ckernel zu kompilieren, denn der linkt immer die Bibliotheken rein, und in der Komandozeilenhilfe sthet nicht wie man das weg bekommt, geht das mit der IDE ? Wenn nicht dann muss ich halt gcc verwenden!
DAnke schon mal im voraus

[kevin]

Als erstes mal die Standardantwort: Wir empfehlen niemandem, selbst einen Bootloader zu schreiben. Ein guter Bootloader ist ein größeres Projekt für sich, und eigentlich bist du ja mit einem Betriebssystem vorerst ganz gut beschäftigt. Daher an dieser Stelle der obligatorische Verweis auf GRUB.

Warum allerdings FAT32 im Real Mode ein Problem sein sollte, verstehe ich nicht ganz. Dein Problem ist nur, daß du - wie du zutreffend sagst - in 512 Bytes schlicht keinen Platz hast für einen vernünftigen Bootloader. Man kann das dann so machen, daß man eine zweite Stufe des Bootloaders in eine Datei packt und im Bootsektor irgendwo ablegt, wo diese Datei genau liegt. Dann braucht der Bootsektor kein Dateisystem zu laden, sondern kann direkt seinen Rest nachziehen, der dann auch groß genug sein kann, um was vernünftiges zu implementieren.

[blitzmaster]

3. Du kannst zwar die IDE Visual Studio C++ verwenden, aber den Compiler nur schwer. Ich kenne mich nicht so gut mit dessen Kommandozeilenparametern aus, also kann ich dir auch nicht sagen, was du da hinschreiben musst. Auf jeden Fall erzeugt der Microsoft Compiler PE Dateien (also .exe).
Ich verwende zwar Visual Studio C++ als Editor (weil er einfach immens praktisch ist), aber zum kompilieren verwende ich einen selbst gebastelten crosscompiler. Den musst du wohl auch machen, wenn du von Windows aus z.B. elf Dateien erzeugen möchtest... Aber da gibt es in der Wiki einen sehr guten Eintrag. (such einfach nach crosscompiler)
Im Internet bin ich vor langer Zeit mal auf etwas gestoßen, wo ein C Kernel mit MSVC erstellt wird, such einfach mal in google nach C Kernel MSVC oder so.

[ScollPi]

Zu 1.:
32-Bit-Integer im RM sollte wohl kein Problem sein.
Das ein Bootloader in 512 Bytes nicht reinpasst ist auch klar. Aber FAT bietet da abhilfe, reservierte Sektoren nach dem Bootsektor. Nutze diese um deinen Bootloader dort rein zu puzzeln.

Zu 2.:
Laut Definition des Interrupts schon, in der Praxis aber nicht. Maximal kannst du die Anzahl an Sektoren in einem Zug laden, wieviele es max. pro Spur gibt. Weiterhin reduziert es sich mit dem Sektoroffset, ab dem du in der Spur lesen tust. Bspw. auf einer Diskette mit 18 Sektoren pro Spur willst du ab Sektor 2 (beginnend bei 0) alle noch möglichen Sektoren in dieser Spur laden, so sind dies dann nur noch 16. Rechne dazu einfach MaxSektor - SektorOffsetInSpur um die max. Anzahl an ladbaren Sektoren zu erlangen. Anderweitig quitiert das BIOS es mit einer Fehlermeldung.
Ob es nun mit dem Extended-Read (ah=42h) genauso ist, kann ich zum derzeitigen Zeitpunkt nicht bestätigen.

Zu 3.:
Unmöglich ist es mit MSVC jedoch nicht, jedoch hab ich mich an der IDE auch die Zähne ausgebissen. Zum editieren kannst du gern die IDE nutzen, dazu reicht sogar die Express-Version von MSVC aus. Zum Kompilieren und Linken benutze ich das Buildtool "MSBuild.exe" aus dem .NET-Framework.
Einen entsprechenden Artikel wollte ich dazu ins Wiki noch schreiben.
Mein OS selbst entwickle ich auf diese Weise. Abgeschaut habe ich es mir von Microsoft's Singularity.

[matheguru]

Danke für die Antworten, den Bootloader habe ich jetzt teilweise sozusagen ausgelagert auf die reservierten sektoren, bin auch schon fast fertig. Mein Kernel übersetzt ich jetzt mit MinGW funktioniert alles prima. Das mit den Extensions habe ich gelöst, indem ich einfach die anzahl der sektoren pro Cluster nehme, die Zahl ist nämlich max. 32. Das mit den Spuren könnte gut sein, aber irg. ist es klar das die menge an sektoren von HD-Controller zu HD-Controller anders sein kann! Na ja danke noch mal, wie findet ihr eig. meine Idee den Bootloader einfach vom NTLDR laden zu lassen, denn so mach ich das um weiterhin auch mein Windows benutzen zu können und ohne den NTLDR zu entfernen, denn den möchte ich auch behalten.

[bluecode]

Wenn du grub als bootloader verwenden würdest, dann könnte dieser genauso NTLDR chainloaden oder auch deinen Kernel laden. Wäre weitaus komfortabler.

[matheguru]

Ja ich weiß wohl, aber man kennt ja die Leute die sich zu einer bestimmten Sache nicht überreden lassen. Irgendwie ist alles eine Frage des Geschmacks oder wohl eher gesagt des Wollens.

[kevin]

Das ein Bootloader in 512 Bytes nicht reinpasst ist auch klar. Aber FAT bietet da abhilfe, reservierte Sektoren nach dem Bootsektor. Nutze diese um deinen Bootloader dort rein zu puzzeln.

Nicht gut. Du willst dich nicht an ein bestimmtes Dateisystem ketten.

Na ja danke noch mal, wie findet ihr eig. meine Idee den Bootloader einfach vom NTLDR laden zu lassen, denn so mach ich das um weiterhin auch mein Windows benutzen zu können und ohne den NTLDR zu entfernen, denn den möchte ich auch behalten.

Ebenfalls keine gute Idee. Du willst dich auch nicht an einen Bootloader ketten, für den du nicht das Recht zur Weiterverbreitung hast. Um es deutlich zu sagen: Ein funktionsfähiges Image deines OS weiterzugeben, ist damit illegal.

[ScollPi]

Das ein Bootloader in 512 Bytes nicht reinpasst ist auch klar. Aber FAT bietet da abhilfe, reservierte Sektoren nach dem Bootsektor. Nutze diese um deinen Bootloader dort rein zu puzzeln.

Nicht gut. Du willst dich nicht an ein bestimmtes Dateisystem ketten.

Sicher nicht, aber wer unbedingt einen eigenen Bootloader benutzen möchte, warum sollte er das FS nicht ausreizen?
Klar kann man es sich einfach machen und wie all zu oft schon heilig geredet zu GRUB greifen.

[matheguru]

Das Problem ist, das ich mich nicht immer der Masse anpassen möchte, deswegen ist jetzt mein größeres Projekt ersteinmal, einen vernünftigen Bootloader zu schreiben der auch andere OS´s laden kann. Wird ne weile dauern, auserdem habe ich dann die vollen Rechte für den Bootloader.

[ScollPi]

Bewundernswert ... aber wie taljeth schon schrieb, ist ein eigener Bootloader ein Projekt für sich selbst, zumal deiner ja auch noch andere OS laden können soll.

Zugegeben, ich möchte mich auch nicht immer der Masse anpassen, so auch was den Bootloader betrifft.
Daher mein Tipp: Bastel dir erst mal einen, der nur dein OS lädt, ob nun in deinem eigenen FS oder bspw. FAT(16/32).

[kevin]

Wenn man den Bootloader als eigenes Projekt angeht, wie das matheguru ja jetzt wohl vorhat, ist das in Ordnung. Dann bestehen auch Chancen, daß der Bootloader nicht als lästiges Beiwerk abgehandelt wird, das so schnell wie möglich irgendwie was machen muß, sondern wirklich was brauchbares rauskommt.

Es wäre vielleicht eine gute Idee, den Multiboot-Standard zu unterstützen, damit kann man schonmal eine ganze Menge Systeme booten.

ScollPi, dein Vorschlag, einen Minimalbootloader zu basteln, der grad mal irgendwie das eigene OS im Moment grad von der Floppy laden kann, ist Unsinn. So ein Ding wird dich ewig behindern, weil du es nicht weiter ausbauen willst (er paßt dann ja nicht mehr in 512 Byte und wird daher etwas komplexer, also ist der Aufwand zu groß) und anfängst, deinen Kernel an den Einschränkungen deines Bootloaders auszurichten.

[matheguru]

Jedenfalls bin ich ne weile bescchäftigt und habe den Vorteil das ich mich nicht mit linzensen herumschlagen muss, falls es jemals so weit kommt das es zum download bereitsteht, mein H4x0rOS. Das es eine multiboot dingens struktur gibt, wie auch immer, wusste ich gar nicht gleich mal googlen. Vieleicht auch ein paar anregungen von euch. ScollPI einen einfachen bootloader der aus dem zweiten Cluster (immer der zweite Cluser) eine fat32 partition mein Kernel provisorisch lädt hatte ich auch schon, aber jetzt bin ich ja nicht mehr weitergekommen damit!

[bluecode]

[...} habe den Vorteil das ich mich nicht mit linzensen herumschlagen muss, falls es jemals so weit kommt das es zum download bereitsteht, mein H4x0rOS.

Mit grub hast du da keine Probleme.

[ehenkes]

Wo ist das Kernproblem bei einem eigenen Tiny Bootloader? Man lädt Code als asm-Kernel nach, schaltet um nach PM und springt in den C-kernel. Wenn der Kernel wächst, muss man allerdings die nachzuladenden Sektoren erhöhen. Wo ist die wesentliche Beschränkung?

[kevin]

Man kann nur von Floppy, nur von FAT (wenn überhaupt, bei den meisten einfachen Bootloadern darf man gar kein Dateisystem benutzen) und nur seinen eigenen Kernel booten.

Im Vergleich zu einem ordentlichen Bootloader, mit dem man mehr oder weniger alle installierten Systeme von Diskette, Platte und CD laden kann, wobei die zu ladenden Dateien (die natürlich nicht nur den Kernel, sondern vor allem bei Mikrokernelsystemen auch grundlegende Treiber, z.B. für Festplatte umfassen)  nicht in bestimmten Sektoren liegen müssen, sondern beim Booten über die verschiedenen unterstützten Dateisysteme geladen werden können, sieht dieser Mini-Bootloader verdammt schlecht aus. Und sein OS an einem verdammt schlechten Stück Software auszurichten, das zufällig vorher läuft, ist keine gute Idee.

Wird der Unterschied deutlich?

[ehenkes]

Ja, das wird klarer, da werde ich mich wohl oder übel auch mal mit GRUB beschäftigen müssen, obwohl mir das gegen den Strich geht. Unter Linux ist man ja den GRUB gewohnt, Windows-User kennen dies nicht. Das ist wohl der wesentliche Grund, warum man unter Windows lieber mit einem eigenen Tiny Bootloader beginnt. 

[kevin]

Es ist ja nicht so, daß unter Linux GRUB schon immer existiert hätte. Früher war Lilo der unangefochtene Standard für Linux, und Lilo hatte so manche Eigenschaft mit diesen Mini-Bootloadern gemeinsam. Heute gibt es GRUB und Lilo ist tot. Zurecht. Und obwohl GRUB ja eigentlich ursprünglich der Bootloader für Hurd war, nicht der für Linux.

[ScollPi]

... Unter Linux ist man ja den GRUB gewohnt, Windows-User kennen dies nicht. Das ist wohl der wesentliche Grund, warum man unter Windows lieber mit einem eigenen Tiny Bootloader beginnt. 

Ironie oder Schicksal ... klar bin ich Windows-User, nur sehe ich mich nicht benachteiligt.

Mein Bootloader ist quasi ein "Tiny Bootloader", Bootmanager-Funktionen benötige ich für mein OS nicht, da mein OS als Netzwerk-OS im Dauereinsatz geplant ist und nicht ständig gebootet werden muss. Zudem ist mein Bootloader eher ein Hybrid, bestehen aus dem restlichen Bootcode der in die 512 Bytes nicht reingepasst hat, den PM-Einsprung und -Rücksprung, Legacy-Calls (überwiegend auf BIOS-Funktionen). Dazu reicht das und ich hab die Kontrolle. Hab ehrlich gesagt auch keine Lust mich mit Grub eventuell rumärgern zu müssen.

Ach was reg ich mich auf ... *prost* 

[matheguru]

Tja es scheint wohl noch mehr Leute zu geben die Grub nich verwenden wollen  und eher iren eigenen bootloader programmieren möchten! Ich mach es auf jedenfall so und mein Bootmanager hat auch schon einen Namen Haboma ( bedeutet: H4x0rOS Bootmanager ), nicht sehr fantasievoll aber ich mag den Namen. Na ja muss euch ja eh nicht interresieren. ich finde es ist besser ein eig. bootloader zuschreiben, denn die erfahrung hilft beim kernel ja auch weiter und wenn jemand einen vernünftigen kernel schreiben kann, dann kann er auch einen bootloader schreiben der mit grub mithalten kann.