Thema: C Kernel starten

[DerHartmut]

All das was du da gerade sagst zeugt von beänstigender Unwissenheit.

Nimm dir doch bitte einfach die Zeit und lies' dich ein wenig durch unser Wiki.

1. Wenn du so viele Rechner wie möglich unterstützen willst willst du eher x86, 32-Bit und 64-Bit sowie in Zukunft ARM-Prozessoren unterstützen, denn die wenigstens haben noch einen 286er zu Hause stehen (geschweige denn produktiv) - was aber nicht heißt, dass das keine Nische sein könnte
2. qemu ist ein Emulator, kein Bootloader
3. Wenn dein OS so wenig RAM wie möglich verbrauchen soll ist Real Mode keine Lösung sondern vielmehr geschicktes Programmieren. Lies dich doch mal in Embedded Systeme ein, hier heißt es "Sparen am RAM so viel es geht"

Wie gesagt: Lies dich bitte durch das Wiki. Dir fehlen scheinbar viele Grundlagen zur x86-er Architektur und zu Betriebssystemen generell. Wenn dir eine Vorlesung nichts bringt dann vielleicht das selber lesen oder das nachfrage bei uns im IRC: #lost auf irc.euirc.net.

[MNemo]

SOVIEL ÜBER BETRIEBSSYSTEME LERNEN WIE MÖGLICH

Tu das, aber sei dir bewusst das RealMode mit halbwegs aktuellen Betriebssystemen nichts tun hat. Du lernst also nur historische Dinge.

[Fukano]

Moin

Qemu ist ein Emulator und kein Bootloader.
Das man im PMode mehr RAM verbaucht stimmt ein bisschen, denn da man im PMode über viel mehr RAM verfügen kann, achtet man da eben nicht auf jedes Byte sonden nimmt halt mal ne 32 Bit Variable anstatt einer 8Bit Variable, man muss aber nicht mehr RAM verbauchen, man kann genauso auf jedes Byte achten, aber dort sollte man die goldene Mitte nehmen, nicht zu verschwenderisch umgehen aber auch nicht zu kleinlich sein.

Das zu einem OS ein Bootloader gehört ist falsch, klar jedes OS braucht einen, aber man muss trotzdem nicht zu jedem OS ein eigenen Bootlaoder programmieren. Das ist im endeffekt Geschmackssache, falsch ist es auf jedenfall nicht sein OS Multiboot kompatibel zu schreiben, da dann der Bootloader gut austauschbar ist, so könnte man dann syslinux, GRUB usw. nehmen, oder wenn man dann doch irgendwann einen eigenen Bootlaoder schreiben will, den eigenen nehmen, der dann antürlich auch multibootkompatibel sein sollte.

Meine Persönliche Meinung ist, das man im PMode mehr lernt, weil man dort selber Treiber schreiben muss, im RM übernimmt das BIOS diese Aufgabe.
Der Realmode wird dich auch im PMode nicht in Ruhe lassen, zumindest wenn du mal VESA nutzen möchtest .


Fukano, der allen einen schönen Tag wünscht

EDIT: Hab die zweite Seite gesehen, daher stehen in meinem Post ein paar Sachen drin, die andere eben schon geschrieben haben.

[kevin]

Das zu einem OS ein Bootloader gehört ist falsch, klar jedes OS braucht einen, aber man muss trotzdem nicht zu jedem OS ein eigenen Bootlaoder programmieren.

Um das nochmal zu verdeutlichen: Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben. Dasselbe gilt übrigens auch für das Verhältnis zwischen Bootloader und BIOS.

Wenn du speichersparend programmieren willst, ist Real Mode übrigens nicht so toll: Von im Moment vielleicht 4096 MB Speicher, die ein Rechner hat, wirft dein OS allein durch die Einschränkungen des RM 4095 MB gleich mal weg.

[Fukano]

Das zu einem OS ein Bootloader gehört ist falsch, klar jedes OS braucht einen, aber man muss trotzdem nicht zu jedem OS ein eigenen Bootlaoder programmieren.

Um das nochmal zu verdeutlichen: Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben. Dasselbe gilt übrigens auch für das Verhältnis zwischen Bootloader und BIOS.

Du meinst sicher "Verhältnis zwischen Bootloader und OS", oder meinst du tatsächlich BIOS?

Fukano

[kevin]

Ja, ich meine das BIOS. Wer einen Bootloader schreibt, braucht das BIOS, aber er kommt in der Regel nicht auf die Idee, sich sein BIOS deswegen selber zu schreiben.

[Fukano]

Ah ok ich konnte mir nur irgend wie nicht denken das du tatsächlich das BIOS meinst, weil das sehr Mainboard abhängig ist, aber ok so gesehen hast du natürlich recht.

[kevin]

Es geht ja darum, ob man auf die Arbeit anderer aufsetzen darf oder ob man alles selber machen muss. ("Ein OS ohne Bootloader ist kein ganzes OS")

Du kannst das Spiel mindestens bis zur Kupferförderung weitertreiben, aber meistens merken die Leute schon früher, dass das absurd ist und versuchen sich damit rauszureden, dass der Vergleich aus irgendeinem Grund hinke.

[Fukano]

("Ein OS ohne Bootloader ist kein ganzes OS")

Das ist eindeutig Geschmackssache, ich sehe das so, das ein OS auch dann ein OS ist wenn es keinen eigenen Bootloader hat, deinen Aussagen nach zu Urteilen siehst du das ähnlich.

Fukano

[Svenska]

Klar will ich was lernen. Aber all die leider viel zu theoretischen Betriebssystemvorlesungen hab mir nicht besonders viel gebracht.

Das hat vielleicht sogar Gründe.

Mein Wunsch ist es nur, ein Betriebssystem zu programmieren. Das mit Assembler klappt schon ganz gut und mir wurde gesagt, dass zu einem Betriebssystem auch ein Bootloader gehört, den man ebenfalls selber programmieren sollte.

Naja. "Klappt schon ganz gut" klingt jetzt nicht besonders vertrauenswürdig und dass zu einem Betriebssystem auch ein Bootloader gehört, halte ich für Blödsinn. Gegenbeispiele findest du bei Mikrocontrollern.

Dann fällt mir vieles leichter, wenn ich bereits vorgefertigte Programme nehm, die mir das abnehmen ?

Wenn du die Hilfen und Erfahrungen annimmst, die andere bereits vor dir gemacht haben, ja, dann wird es einfacher. Du darfst Erfahrungen und Hinweise auch ignorieren, du solltest dann aber wenigstens wissen, warum!

Über die ganzen Bootloader, die es gibt (qemu,...) weiss ich nicht viel, außer dass diese Booten und in den Protected Mode schalten. Und mein OS sollte eben auf sovielen Rechnern wie möglich funktionieren, dazu gehören evtl. auch Rechner<386, d.h. nix mit Protected Mode.

Auch das zeugt von wenig Wissen: Die Hardware um einen 8086 (PC/XT) herum ist äußerst verschieden von der Hardware um einen 80386+ (AT) herum (weniger IRQs, weniger DRQs, andere Hardwarekomponenten, andere Adressen, kein Probing, beschränktes BIOS, kein Booten von HDD, ...) und im Real Mode hast du eh keinen Platz für spezialisierte Hardwaretreiber, geschweige denn für beide Varianten. Die CPU-Architektur ist kompatibel, die Plattform nicht. Außerdem sind die BIOS-Treiber für moderne Hardware nur begrenzt einsatzfähig (z.B. können nicht mit großen Festplatten und modernen Grafikkarten umgehen).

Vielleicht solltest du dich erstmal mit Emulatoren (wie Qemu) und mit Bootloadern (wie GRUB oder Syslinux) befassen, ehe du sie ablehnst. Oder zumindest, was sie normalerweise tun sollten.

das OS das ich schreiben will, sollte eigentlich nur so wenig Arbeitsspeicher wie möglich brauchen und auch auf älteren Rechnern noch funktionieren. Und im Protected Mode verbraucht man soviel ich weiß, wesentlich mehr RAM als im Real-Mode.

Ein vernünftiges Betriebssystem braucht wesentlich mehr RAM als 640 KB (der Rest ist ROM - kein RAM!). Jeder beschissene 386er, den du auf dem Schrott findest - wenn du ihn überhaupt noch findest - hat mindestens 4 MB RAM. Und nein, DOS ist nicht vernünftig.
Was die "älteren Rechner" angeht: Vor ziemlich genau 15 Jahren (mitte 1996) wurde der Pentium 200 angekündigt, vor 20 Jahren (1991) gab es bereits 486er (der 386er erschien 1985, der 486er 1989). Wie alt bist du?

Aber wenn dann vieles leichter fällt mit z.B. QEMU, dann lernt man doch nicht, was hinter QEMU abläuft, oder ?

Wenn es dir um das Verstehen geht, dann beschäftige dich mit Mikrocontrollern. Die sind noch überschaubar, weil recht einfach gestrickt. Da hast du auch nur wenig RAM (meist im KB-Bereich).

PS: Und ich will eigentlich nur SOVIEL ÜBER BETRIEBSSYSTEME LERNEN WIE MÖGLICH.

Das lernst du nicht durch rumschreien.
Und auch nicht, wenn du nicht auf die Leute hörst. Die meisten Tips hier sind wirklich gut begründet.

Gruß,
Svenska

[bscreator]

Vielen Dank, ihr haubt mich überzeugt.
Meine anderen Fragen sind in "Softwareentwicklung", hauptsächlich fragen zu GRUB.


Vielen Dank,
bsc

[erik.vikinger]

Hallo,

Mein Wunsch ist es nur, ein Betriebssystem zu programmieren.

Dann beschränke Dich auch darauf, ein OS alleine ist komplex genug. Flat-Memory ist ein recht simples und überschaubares Konzept, dagegen hat der x86-Real-Mode ziemlich viele exotische Stolperfallen zu bieten und mit dem segmentierten x86-Protected-Mode möchtest Du Dich ja auch gar nicht beschäftigen.

und mir wurde gesagt, dass zu einem Betriebssystem auch ein Bootloader gehört, den man ebenfalls selber programmieren sollte.

Dann solltest Du mal anfangen die Aussagen anderer kritisch zu hinterfragen. Zu einem OS gehört auch der Computer auf dem es läuft aber das hat taljeth ja schon ausreichend verdeutlicht.

Dann fällt mir vieles leichter, wenn ich bereits vorgefertigte Programme nehm, die mir das abnehmen?

Ja. Die Kunst besteht darin sich auf sein eigentliches Problem zu beschränken. Es ist gut wenn man auch nach links und rechts schaut aber wenn Du Dir zu viele Nebenschauplätze aufhalst verlierst Du mit hoher Wahrscheinlichkeit Dein eigentliches Ziel aus den Augen.

Und mein OS sollte eben auf sovielen Rechnern wie möglich funktionieren

Gerade deswegen solltest Du den x86-Real-Mode konsequent ignorieren, etwas derartiges gibt es aktuell (also in den letzten 10 Jahren) bei keiner anderen Plattform. Alle CPUs der letzten >20 Jahre konzentrieren sich auf Flat-Memory (selbst bei den Micro-Controllern kenne ich nur eine einzige Familie die sowas ähnliches wie die Segmentierung des x86-Real-Mode bietet und die ist auch schon vor einigen Jahren ausgelaufen) und das solltest Du auch tun. Davon abzuweichen bedeutet das Du extrem viel mehr Arbeit vor Dir hast und dafür auch extrem viel mehr an Wissen und Erfahrung benötigst (nebst dessen das Du extrem weniger an Hilfe bekommen kannst).

auch Rechner<386, d.h. nix mit Protected Mode.

Auch der 286 hat einen Protected-Mode, sogar einen der vom Speicherschutz her besser ist als das was heutige CPUs im Flat-Memory zu bieten haben, trotzdem wurde Segmentierung vom Mainstream abgelehnt und daher von keinen Tools/OSen usw. unterstützt.


Grüße
Erik

[freecrac]

.....Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben....

Wie jetzt, einen einfachen Texteditor kann man gar nicht ohne ein OS zur Ausführung bringen, wie kommst du denn auf diese Idee?

Wenn du speichersparend programmieren willst, ist Real Mode übrigens nicht so toll: Von im Moment vielleicht 4096 MB Speicher, die ein Rechner hat, wirft dein OS allein durch die Einschränkungen des RM 4095 MB gleich mal weg.

Wer wirft denn im RM 4095 MByte Speicher weg?

Bereits seit MS-DOS 6.22 konnte HIMEM.SYS 64 MByte Speicher für den RM verwalten. Mit MS-DOS 7.0 (Windows 95) bereits 256 MByte und ab der Version 3.0 von Himem.sys (MS-DOS 7.1/Windows98) 4 GByte verwalten: http://de.wikipedia.org/wiki/Himem.sys

Dirk

[kevin]

Ich bleibe lieber im eigenen Wiki: http://www.lowlevel.eu/wiki/MS-DOS#Zugriff_auf_hohen_Speicher

Extended Memory Blocks beginnen nach dem Ende der HMA. Die API erlaubt es, im erweiterten Speicher Blöcke zu reservieren, freizugeben und zu kopieren (die Speicherverwaltung schaltet dazu kurzzeitig in den Protected Mode).

Also nichts mit Real Mode.

[freecrac]

Ich bleibe lieber im eigenen Wiki: http://www.lowlevel.eu/wiki/MS-DOS#Zugriff_auf_hohen_Speicher

Extended Memory Blocks beginnen nach dem Ende der HMA. Die API erlaubt es, im erweiterten Speicher Blöcke zu reservieren, freizugeben und zu kopieren (die Speicherverwaltung schaltet dazu kurzzeitig in den Protected Mode).

Also nichts mit Real Mode.

Aber sicher doch mit dem Real Mode! Himem.sys verwalten den Speicher für den Real Mode und nicht für den Protect Mode und so kann man im RM sehr wohl mehr als die untersten 640 KByte an Speicher verwenden. Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten. Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant. Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.

Dirk

[erik.vikinger]

Hallo,

Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben.

Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR

Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten.

DOS verwendet den XMS aber nicht, auch die Verwaltung des XMS wird von himem.sys und nicht von DOS erledigt. Für DOS ist himem.sys einfach nur ein Treiber/TSR der irgendeinen Service anbietet. Das es Speicher hinter der HMA gibt weiß DOS (also der Kernel msdos.sys) noch nicht einmal. Es gibt aber im Lieferumfang von DOS (als OS-Distribution) einige Tools die XMS benutzen können (z.B. smartdrv.exe).

Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant.

Das ist sehr wohl relevant! Speicher der nicht direkt nutzbar ist läst sich weder für Code noch für statische Daten oder Heap oder Stack nutzen. Der XMS kann von reinen Real-Mode-Programmen/OSen nur als große externe Datenablage (wie z.B. eine Datei) benutzt werden aber nicht als aktiven Teil des Programms. Mit EMS ist das etwas anders aber auch ziemlich umständlich.

Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.

Egal ob kurz oder lang, wenn das OS auch auf Systemen ohne Protected-Mode laufen können soll dann ist der einfach nicht verfügbar und fertig.


Grüße
Erik

[kevin]

Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR

Keinen Texteditor.

Ich habe noch daran gedacht und mir überlegt, ob ich irgendwas einschränkendes dazuschreiben soll. Hätte ich wohl doch besser gemacht, so viele Haarspalter wie hier inzwischen rumlaufen.

[erik.vikinger]

Hallo,

Keinen Texteditor.

Stimmt.

Wenn Du möchtest das ich zur nächsten Präzisionshaarspaltung ansetze wüste ich aber schon gerne was Du mit "irgendwas einschränkendes" meinst.


Grüße
Erik

[freecrac]

Hallo,

Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben.

Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR

Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten.

DOS verwendet den XMS aber nicht, auch die Verwaltung des XMS wird von himem.sys und nicht von DOS erledigt. Für DOS ist himem.sys einfach nur ein Treiber/TSR der irgendeinen Service anbietet. Das es Speicher hinter der HMA gibt weiß DOS (also der Kernel msdos.sys) noch nicht einmal. Es gibt aber im Lieferumfang von DOS (als OS-Distribution) einige Tools die XMS benutzen können (z.B. smartdrv.exe).

Jedes Realmode-OS das einen vergleichbaren XMS-Extender direkt in seinen Kernel implementiert kann aber den Speicher selber verwalten und auch selber nutzen. Es muss ja nicht ein Treiber werden und ausgehend von Thema (selber ein OS zu entwickeln) ist es doch eher unwichtig ob DOS es hier mit einem Treiber macht, oder auch nicht. Die Möglichkeit für den Realmode den gesamten XMS-Speicher zu benutzen zeigt ja nur das es eben möglich ist weit aus mehr Speicher zu verwenden, als nur die erwähnten 640 KByte.

Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant.

Das ist sehr wohl relevant! Speicher der nicht direkt nutzbar ist läst sich weder für Code noch für statische Daten oder Heap oder Stack nutzen. Der XMS kann von reinen Real-Mode-Programmen/OSen nur als große externe Datenablage (wie z.B. eine Datei) benutzt werden aber nicht als aktiven Teil des Programms.

Für den Benutzer eines verwendenten Realmode-OS ist es irrelevant wie nun auf den XMS-Speicher zugegriffen werden kann. Auch kann ein beliebiger RM-Opcode von einem langsameren Datenträger in den XMS-Speicher zunächst als Daten eingelagert werden und bei Bedarf heruntergeholt und dann ausgeführt werden, ganz ohne sich dabei um Privilege levels und möglichen Schutzverletzungen zu kümmern, wenn im Datenbereich nun ein Opcode zur Ausführung kommt.

Mit EMS ist das etwas anders aber auch ziemlich umständlich.

Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.

Egal ob kurz oder lang, wenn das OS auch auf Systemen ohne Protected-Mode laufen können soll dann ist der einfach nicht verfügbar und fertig.


Grüße
Erik

LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet?

Dirk

[freecrac]

Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR

Keinen Texteditor.

Ich habe noch daran gedacht und mir überlegt, ob ich irgendwas einschränkendes dazuschreiben soll. Hätte ich wohl doch besser gemacht, so viele Haarspalter wie hier inzwischen rumlaufen.

Ja ich verstehe was du meinst, du hast dich etwas unglücklich ausgedrückt, aber du kannst doch jederzeit erneut darauf Antworten und deine Sichtweise hierbei vertiefen, bzw. entstandene Missverständnisse aufklären.

Um eine kleine Anwendung(wie einen schlichten Texteditor) zur Ausführung zu bringen braucht man nicht unbedingt ein OS!!!
Deine Aussage das jeder Texteditor auch immer ein OS benötigt ist somit falsch und auch im verwendeten Beispiel daher irreführend. Ein OS kann nun mal ohne ein Booteintrag auf einem Datenträger nicht gestartet werden, wobei ein schlichter Texteditor auch ohne ein OS zur Ausführung gebracht werden kann. Mir geht es hierbei darum solche Fehlinformationen rund um den Realmode richtig zu stellen, damit eine Entscheidung des zu verwendenden Betriebsmodes für ein OS auch mit allen relevanten Fakten vollzogen werden kann und nicht nur einem Teil davon, der alleine ein doch eher schiefes Bild auf diesen Teilbereich wirft. Also das mit den nur verfügbaren 640 KB die man angeblich bei der Verwendung eines RM-OS nur zur Verfügung stehen hat wird hierbei völlig ausser acht gelassen, dass man vom einem RM-OS jederzeit ebenfalls in den PM schalten kann und trotzdem können wir diese OS als ein RM-OS bezeichnen.

Ich finde es daher besser alle Möglichkeiten auszuloten, um eine Entscheidung des zu verwendenden Betriebsmodes machen zu können. Hierbei wären dann auch die Möglichkeiten des PM anzugeben, dessen Fähighkeiten weit über den des RM hinausgehen, als nur den RM mit unzulänglichen Fehlinformationen schlechter dastehen zu lassen als er in Wirklichkeit ist.

Dirk