Diskussion:Eigener Bootloader

Wie sinnvoll ist dieses Tutorial eigentlich? Das hier behandelte Programm ist einfach ein Realmode-„Kernel“ und hat nichts mit „Booten“ zu tun. Oder habe ich den zweiten Teil verpasst?

Also ich finde, hier müsste entweder der besagte zweite Teil geschrieben werden oder der Artikel komplett überarbeitet bzw. erweitert werden, sodass ein echter Bootloader draus wird (mindestens chainloadermäßig ein paar vordefinierte Blöcke laden, von FAT12 oder ELF wage ich ja fast gar nicht zu sprechen). —Clici McXan 14:19, 29. Mär. 2010 (CEST)

Ich würde mich diesem hier gerne annehmen und ein allgemeines Tutorial schreiben (beinhaltet Bootsektor und Bootloader), welches in erster Linie die allgemeinen Vorgehensweisen beinhaltet, egal ob für FAT (FAT12, FAT16, FAT32), NTFS, CDFS, ROFS. Wer sich mit EXT, RaiserFS und Co auskennt, kann gerne dazu eine Ableitung verfassen. Bin nämlich eh grad dabei einen universellen Aufbau für meinen Bootsektor (inkl. Bootloader) zu entwickeln. --ScollPi 16:47, 29. Mär. 2010 (CEST)

Das Problem bassiert auf einer in meinen augen fälschlichen umbenennung des Aktikels in "Eigener Bootloader". --Termite 18:36, 2. Jan. 2011 (CET)

---

Ist der Artikelname nicht eigentlich falsch? Der Begriff "Boot Record" bezeichnet doch nur den ersten Sektor einer Speichermediums. Schlauer wäre es doch, den Artikel in "Eigener Bootloader" umzubenennen. --Bjork 16:52, 29. Mär. 2010 (CEST)

Denke ich auch, da ja ein Tutorial nur für einen Bootsektor nicht viel nützen würde, da dessen Platz mit seinen 512 Bytes doch ehrlich gesagt recht eng sind. OK, bei den neuen HDDs mit 4k-Sektoren sieht das schon anders aus. Außerdem soll ja der Kernel eines OS geladen werden und eventuelle Module, ergo, "Eigener Bootloader" wäre da angemessen. --ScollPi 17:00, 29. Mär. 2010 (CEST)

Das hier ist aber eigentlich schon ein Tutorial für ein "Programm im Bootsektor", wie es in dem Artikel heißt, nicht für einen Bootloader. Ich denke der Sinn dieses Artikels ist doch überhaupt erstmal Code auf der Maschine laufen zu haben. Meinetwegen kann jemand einen Artikel "Eigener Bootloader" schrieben. Aber trotzdem kann dieser Artikel doch zumindest in seiner alten Bestimmung erhalten werden. --Jidder 18:04, 29. Mär. 2010 (CEST)

Hallo, bin wohl mehr als ein Jahr zu spät dran um einspruch zu erheben. Das Tutorial sollte nur die erstellung eines BootRecords mit einem kleinen Programm beschreiben. Ein Boolt Loader ist das noch lange nicht. Es stellt den anfang einer Boot loader implementierung dar. Der fehldende Teil 2 sollte dann statisch ein programm nachladen, in verschiedenen Varianten. ohne dateisystem / mit Dateisystem die probleme vor und nachteile aufzeigen --Termite 18:36, 2. Jan. 2011 (CET)

Tutorial zu komplex?

Wollen wir wirklich die Sache komplizierter machen als nötig? Im Grunde geht es in diesem Turorial doch darum, einen einfachen Bootloader für eine Diskette zu schreiben. Und das Tutorial ist doch auch eher an Anfänger gerichtet. Deswegen würde ich auch

Unser Ziel ist aber keineswegs für jedes Dateisystem einen eigenen Bootloader (ausschließlich dem Bootsektor) zu entwickeln,  sondern viel mehr ein universelles Modell auf die Beine zu stellen, bei dem nur der Bootsektor individuell dem Dateisystem vorliegt und der Bootloader (Binärdatei) für alle unterstützten Dateisystemen gleich bleibt.

weglassen und den Loader nur auf EIN Dateisystem beschränken (FAT würde ich vorschlagen). Dann kann man die Sache mit dem MBR auch vorerst weglassen. Würde uns viel Arbeit ersparen und dem geneigten Leser Nerven. --Bjork 23:09, 31. Mär. 2010 (CEST)

Also für Anfänger ist Real-Mode-Programmierung mit starrer Segmentierung in Assembler sicher nicht geeignet! Die Anfänger werden da nur verdorben und haben dann im Protected-Mode mit dem Flat-Memory Probleme. --Erik.vikinger 12:54, 1. Apr. 2010 (CEST)

Mh, ich hatte damit damals eigentlich kein Problem. Vielleicht sollte man aber einen Hinweis über den Artikel setzen, dass dieser nicht für 'Anfänger' (blöde Bezeichnung für jemanden, der ein OS programmieren möchte...) geeignet ist. Bleibt noch die Frage, ob man hier einen universellen Bootloader für viele Dateisysteme/Datenträger oder doch nur einen speziellen für EIN Dateisystem/Datenträger erklären möchte. --Bjork 17:50, 1. Apr. 2010 (CEST)

Man könnte auf GRUB#Warum GRUB? verweisen--Bluecode 18:48, 1. Apr. 2010 (CEST)

Zu komplex??? Dann schau dir mal den USB-Artikel an. Dieses Tutorial ist für die gedacht, die es nach etlichen Empfehlungen trotzdem nicht lassen können und umbedingt einen eigenen Bootloader (und ausdrücklich keinen Boot-Manager) programmieren wollen. Um genau zu sein wird dieses Tutorial keine Komplettlösung, sondern viel mehr ein Wegweise. Ein Anfänger sollte sich sowieso mal einen originalen Bootsektor diassemblert anschauen. Aber letztenende wird er nicht drum herum kommen und selbst experiementieren müssen, wenn er eigenen Code (also nicht abgetippt) erzeugen will. Und genau dahin soll dieses Tutorial gehen, d.h. den Bootloader zu laden, der den eigentlichen Kernel lädt. Protect Mode zum Beispiel ist dabei nicht bestandteil dieses Tutorial, denn es geht nur um einen Bootloader. Denn welche Funktionalitäten ihr in den Bootloader baut, ist eurer Fantasie und Kreativität überlassen. Ein OS zu schreiben ist eben nun mal nicht mit einem "Hello World!" Programm zu vergleichen. Das es komplex wird, sollte einem sowieso klar sein. -- ScollPi 17:42, 3. Apr. 2010 (CEST)

Ich wollte doch nur auf das Dateisystem für den BL hinaus. Welches denn nun? --Bjork 21:24, 6. Apr. 2010 (CEST)

In diesem Tutorial beziehe ich mich ausschließlich auf FAT12, FAT16 & FAT32. ISO9660 (CDFS), NTFS und ROFS werde ich optional per Link anbieten, sonst würde das zu sehr ausarten, besonders bei NTFS. -- ScollPi 21:29, 6. Apr. 2010 (CEST)

Danke, mehr wollte ich doch gar nicht :) --Bjork 17:39, 7. Apr. 2010 (CEST)

Könnte man den Teil unter der Überschrift Tools nicht entfernen bzw. in die Einleitung packen welche Tools verwendet werden und da nur auf die Artikel zu den jeweiligen Tools verweisen (und falls hier Teile sind die in dem Artikel zu dem jeweiligen Tool nicht zu finden sind die dorthin verschieben)? --Bluecode 16:46, 7. Apr. 2010 (CEST)

Ich finde auch, dass das nicht in dieses Tutorial gehört. --Bjork 17:39, 7. Apr. 2010 (CEST)

Sehe ich ebenso, man braucht kein extra Kapitel für Tools. Ein Aufzählung im allgemeinen am Anfang dürfte genügen. Welcher Editor genommen wird, welcher Assembler oder welcher Linker sollte jeder nach eigene Ermessen entscheiden. -- ScollPi 17:50, 7. Apr. 2010 (CEST)

zum damaligen Zeitpunkt waren die Artikel noch gar nicht vorhanden oder erst in Entstehung. Ich habe die verwendete Toolchain mit angegeben, und wo man sie ggf herbekommt, da ich mich teilweise z.B. bei Compilerschaltern, Linkerparametern, ... darauf beziehe. --Termite 18:36, 2. Jan. 2011 (CET)

Wir können doch einfach eine Vorlage "Tutorial" anlegen, die Punkte wie "Schwierigkeit", "ähnliche Tutorials", "benötigtes Vorwissen" und einen Link auf die Kategorie:Werkzeuge enthält. --Bjork 21:45, 8. Apr. 2010 (CEST)

Das ist mal ein echt genialer Einfall, den man für alle Tutorials übernehmen könnte. -- ScollPi 21:54, 8. Apr. 2010 (CEST)

Sektorgröße bei HDDs

Ich hab mal ne Frage: Warum wird eigentlich so ein Aufstand um Festplatten mit 4 kByte großen Sektoren gemacht? Diese Festplatten präsentieren sich dem System gegenüber immer noch mit 512 Byte großen Sektoren, welche man auch noch wie gewohnt einzeln lesen und beschreiben kann. Nur das beschreiben wird etwas langsamer sein da oft erst der komplette physische Sektor mit 4 kByte gelesen, das richtige 512 Byte Häppchen modifiziert und dann der physische Sektor wieder komplett geschrieben werden muss. Die Festplattenhersteller machen das damit der Anteil an Verwaltungsstrukturen kleiner wird (vor allem die nötigen Lücken zwischen den Sektoren kosten viel Platz auf einer Spur) also die effektiv nutzbare Kapazität steigt. Flash-Basierte Massenspeicher arbeiten normalerweise mit deutlich größeren physischen "Sektoren" (weil man in einem Flash-Chip nicht so kleine Stücke einzeln löschen kann, dort sind 32 kByte keine Seltenheit mehr) und da ist auch niemand auf die Idee gekommen extra dafür die Boot-Sektoren oder MBRs anzupassen. --Erik.vikinger 23:06, 8. Apr. 2010 (CEST)

Was für ein Aufstand denn? --Bluecode 16:45, 9. Apr. 2010 (CEST)

Einen Aufstand macht hier niemand, es wird lediglich erwähnt, das Festplatten mit 4 KiB Sektoren immer mehr im Kommen sind. Das Problem ergibt sich erst beim Partitionieren, da üblicherweise immer in 63-Sektoren-Blöcken partitioniert wird. D.h. zwei Partitionen könnten sich somit einen Sektor teilen, was aber ganz schnell böse enden kann. OK, der Oberbegriff hier heißt ja "kaputt". Soweit mir bekannt ist, hat man diesen 4K-Platten eine Abwärtskompatiblität eingebaut, damit sie auch 512-Byte-Sektoren zurückgeben, aber deren Performanz soll darunter leiden. -- ScollPi 13:13, 10. Apr. 2010 (CEST)

Okay, "Aufstand" ist das falsche Wort. Das mit den 4 kByte Sektoren trifft eher die Verwaltungstools (fdisk, format u.ä.) und die Datei-System-Designer, aber eben nicht den Boot-Loader. Der Performance-Verlust beim Lesen dürfte unter der Messbarkeitsgrenze liegen und beim Schreiben nur wenig darüber. Was meinst Du eigentlich mit "Abwärtskompatibilität"? Die Platten melden sich nach außen doch immer noch ganz normal mit 512 Byte Sektoren, die 4 kByte Sektoren sind eine interne Angelegenheit der HDDs. --Erik.vikinger 16:18, 11. Apr. 2010 (CEST)

Falls das einzige was dazu im Artikel steht "Auch zukünftige Festplatten mit einer physikalischen Sektorgröße von 4096 Bytes mögen dem entgegen wirken." ist, sehe ich nicht, warum man da von einem Aufstand sprechen könnte. Abgesehen davon sehe ich nichtmal ansatzweise was daran falsch/verbesserungsbedürftig wäre. Die Aussage ist doch eher, dass sich die der Software präsentierte Sektorgröße in Zukunft ändern könnte, insofern trifft nichts deines Posts zu.--Bluecode 20:52, 11. Apr. 2010 (CEST)

Warum sollte sich die Sektorgröße für die SW ändern? Damit machen es sich die HDD-Hersteller auch nicht einfacher. Ich denke die werden das auch in Zukunft vor der SW verstecken um die physikalische Sektorgröße nach eigenen Bedürfnissen flexibel anpassen zu können. Vergleich doch mal mit den Flash-Basierten Speichermedien, dort gibt es intern etliche verschiedene Sektorgrößen (bedingt durch die Menge an Daten die auf einmal gelöscht oder auf einmal geschrieben werden können, sind beides übrigens verschiedene Mengen). Wenn die HDD-Hersteller anfangen würden die Sektorgröße nach aktueller Mode (Fertigungstechnologie usw.) zu ändern dann müsste jede SW die direkt mit Massenspeichern arbeitet flexibel damit umgehen können und das ist von einem Boot-Loader kaum zu erwarten und vom Code im Boot-Sektor/MBR erst recht nicht. Daher bin ich der Meinung das für einen Boot-Loader und anderen Code noch davor die physikalische Sektorgröße völlig irrelevant ist (der marginale Performance-Verlust ist wohl ziemlich uninteressant). Erst die Massenspeicher-Verwaltungsprogramme (fdisk usw.) und die Datei-System-Designer bzw. die zugehörigen Formatierungstools sollten die physikalische Sektorgröße kennen und beachten.
Das mit den 4kByte-Sektoren hab ich auch noch in anderen Wiki-Artikeln gesehen. Ich wollte eigentlich nur wissen warum dieser Umstand überhaupt so deutlich angesprochen wird (ich sehe dazu eben keine Notwendigkeit). Wenn meine Einwände unbegründet sind dann löscht bitte einfach diese Diskussion. --Erik.vikinger 19:34, 13. Apr. 2010 (CEST)

Um es endlich mal auf den Punkt zu bringen ... soweit mir bekannt ist, besitzen diese 4k-Platten eine Abwärtskompatiblität zu 512byte-Platten, d.h. sie unterstützen auch die Adressierung für 512-Bytes-Sektoren (neben 4k-Sektoren). Wobei es mir hier geht ist, wie das BIOS den Boot-Sektor laden wird, kompatible mit 512 Bytes oder volle physikalische 4k?? Sollte letzteres der fall sein, bekommt man den ganzen Code rein und brauch in nicht splitten. Der Bootloader brauch nicht angepasst werden, wenn man genau an die Spezifikation eines Dateisystem bspw. FAT hält. FAT enthält im BIOS-Parameter-Block auch die Größe eines Sektors, hiermit ist die physikalische Größe gemeint. Und genau mit dieser sollte gerechtnet werden, nicht mit Konstanten. Kurz gesagt, booten von einem USB-Stick sollte damit kein Problem sein. -- ScollPi 21:01, 13. Apr. 2010 (CEST)

Ich hab gerade, in der aktuellen c't (hier), gesehen das die Hersteller tatsächlich planen das die neuen HDDs sich mit 4 kByte Sektorgröße melden sollen. Aufgrund der umfangreichen und kaum abschätzbaren Folgen hätte ich nie damit gerechnet das die sich das tatsächlich trauen. Zumindest dafür das die wirklich die heilige Kuh der Kompatibilität zum Schlachter führen gibt es meinen Respekt. Vor wenigen Jahren wurde bei der Festlegung des SD-HC-Standards noch auf 512 Byte Sektorgröße gesetzt, obwohl damals schon kein Flash-Chip mehr verfügbar war der noch 512 Byte als physikalische Sektorgröße unterstützt (zumindest beim lesen, gelöscht und geschrieben wird eh in größeren Einheiten). Aktuell sind bei Flash-Chips 2 kByte und demnächst wohl auch 8 kByte. Und bei den SSDs, wo die Daten über mehrere Flash-Chips verteilt werden (wahrscheinlich mit einer Art RAID 0), dürften die Hersteller sicher gerne noch größere Sektoren wollen.
Worauf ich hinaus will ist das von variablen Sektorgrößen eine enorme Menge an Software betroffen ist. Gerade viele kleine Programme für Embedded-Systeme oder andere Hobby-Projekte dürften darunter leiden. Wer will schon einen richtigen UDF-Dateisystem-Treiber in einen Mikrocontroller quetschen nur weil es auf dem PC kein Format-Tool gibt das auf der neuen HDD noch mit FAT formatieren will (ich weiß das FAT theoretisch mit vielen Sektorgrößen umgehen kann aber ob Microsoft da mitspielt ist IMHO fraglich).
Von einer geänderten Sektorgröße ist u.a. das BIOS betroffen, im c't-Artikel ist dazu ausgeführt das damit wohl ein weiterer Vorschub für EFI eintritt (was prinzipiell sehr zu begrüßen ist), was wohl wieder Auswirkungen auf Boot-Loader usw. hat. Ich frage mich an welches Offset dann die 0xAA55-Signatur kommt. Auch viele Dateisystem-Treiber dürften davon betroffen sein, ich glaube nicht das man alle Dateisystem-Strukturen (iNodes usw.) einfach so auf größere Sektoren skalieren kann (FAT als primitiv-Dateisystem ist da noch ein äußerst simples Beispiel). Auf Grund dieser massiven Auswirkungen hätte ich bis heute Früh nie geträumt das die HDD-Hersteller wirklich die logische Sektorgröße ändern würden, Gründe dafür gibt es eigentlich schon länger aber bis jetzt hat sich das noch keiner getraut.
Mit dieser Info sollten wir mal überlegen was noch alles betroffen ist und in den betreffenden Wiki-Artikeln passende Hinweise geben.
Sorry das ich erst in die andere Richtung gewettert habe. --Erik.vikinger 22:29, 14. Apr. 2010 (CEST)

Dann bist du ja weiter mit dem Lesen als ich. Na jedenfalls, die Frage, wo die 0xAA55-Signatur stehen wird, ist doch logisch ... immer die letzten zwei Bytes des physikalischen Sektor. Bsp. Daten-CDs haben 2048 Bytes große Sektoren und da steht eben die Signatur an Offset 0x07FE, also am Ende des Sektors. Bei 4k-Platten wird es also bei 0x0FFE sein. Aber so idiotisch es auch klingt, FAT kann (sollte, vom Treiber abhängig) 4k-Sektoren verwalten. -- ScollPi 22:48, 14. Apr. 2010 (CEST)

Dazu möchte ich gerne die FAT-Spezifikation zitieren: "There is one other important note about Sector 0 of a FAT volume. If we consider the contents of the sector as a byte array, it must be true that sector[510] equals 0x55, and sector[511] equals 0xAA. NOTE: Many FAT documents mistakenly say that this 0xAA55 signature occupies the “last 2 bytes of the boot sector”. This statement is correct if — and only if — BPB_BytsPerSec is 512. If BPB_BytsPerSec is greater than 512, the offsets of these signature bytes do not change (although it is perfectly OK for the last two bytes at the end of the boot sector to also contain this signature)." --Sur3 25.08.2011 17:00 MEZ

Danke für Deinen Hinweis. Meine Frage nach der Signatur hat sich aber nicht nur auf FAT-Bootsektoren bezogen sondern auf Boot-Sektoren allgemein und auch auf dem MBR. Gerade beim MBR ist ja auch das Offset der Partition-Table betroffen. Trotzdem dürfte von allen Datei-Systemen FAT noch extrem leicht auf andere Sektor-Größen skalierbar sein. Wobei sich mir dann auch die Frage stellt ob damit auch größere Cluster möglich werden (die 32kB-Obergrenze hatte ja was mit dem Real-Mode von DOS und BIOS zu tun, in Windows NT war von Anfang an die Obergrenze bei 64kB und auf heutiger HW mit heutigen OSen sollten auch noch größere Cluster kein Problem sein, vom Verschnitt mal abgesehen).--Erik.vikinger 19:30, 27. Aug. 2011 (CEST)

Damit die Diskussion nicht endet: Die FAT-Spezifikation sagt explizit, dass Cluster nicht größer als 32 kB sein sollten. Übrigens: Bei 64 kB Clustern kommt man schon in die lustige Situation, dass ein Datenträger mit etwas weniger als 250 MB Kapazität mit FAT12 formatiert werden muss. Wer hätte das gedacht? ¯\_(ツ)_/¯ --Jidder 00:02, 28. Aug. 2011 (CEST)

Okay, bezüglich FAT hätten wir das Thema hiermit ausführlich genug erörtert. Ich denke mal das man mit größeren Sektoren auch alles andere bei FAT größer skalieren kann, zumindest aus Sicht der Praxis, von eher organisatorischen Empfehlungen einmal abgesehen. Trotzdem gibt es noch unzählige andere Strukturen (MBR, Dateisysteme usw.) die von der Sektorgröße des benutzten Block-Devices abhängig sind, auch hier wäre es schön mal klare Informationen zu haben. (OT: Wo hast Du denn dieses gar niedlich Emoticon her und was soll das bedeuten?) --Erik.vikinger 12:46, 28. Aug. 2011 (CEST)

Aus dem Internet (reddit). Bedeutung:

--Jidder 13:43, 28. Aug. 2011 (CEST)

DS auf 7C0h ist ganz schlecht ...

... weil nähmlich sich im Segment 0 die Interrupt Vektoren und die BIOSdaten befinden, die mit hoher warscheinlichtkeit während der nächsten Schritte benötigt werden, wenn man die Segmente so setzt, dann muss man jedesmal das Segment wechseln, um auf BIOS-Informationen zuzugreifen oder Interruptvektoren zu ändern, Besser ist: Alle Segmente auf 0h, SP auf 7BFEh.

Beispiel :

org 100h ;damit man es Assemblieren kann

org 7C00h

jmp START

(Laufwerksdaten)

START:

xor ax,ax
mov ds,ax
mov es,ax
cli
mov ss,ax
mov sp,7BFEh ; nicht hinter dem Bootsektor, weil man erst wissen muss, wo die Erweiterten BIOS-Daten sind

... rest vom Bootsektor

org 7DFEh

dw 0AA55h ; (höhere Ziffern stehen hinten)

nun kann man die erste Datei laden, und Interrupt Vektoren darauf setzten, Die erste Datei muss dann widerum nicht erst die Segmente verändern, um die BIOSdaten zu lesen.

letzte Änderung (.bin auf Diskette schreiben)

Im Artiekl wird ja gesagt das grade das nicht beabsichtigt ist, und was macht dieses Programm "debug"? Ich kenne es nicht, es wird afaik im Artikel nicht erwähnt und auf meinem System ist scheinbar nicht vorhanden. --DesL 00:58, 15. Apr. 2011 (CEST)

Dass du debug nicht kennst erstaunt mich ein wenig ^^ Gucken Sie hier --DerHartmut 10:37, 15. Apr. 2011 (CEST)

Awww, ich habe hier ein x86, deswegen kennt mein System das nicht Oo Ich wäre ja immerhin davon ausgegangen, das Microsoft dazu in der Lage ist solche Tools auch beizubehalten/portieren. Aber es passt immer noch nciht zum Text im Wiki. --DesL 14:12, 15. Apr. 2011 (CEST)