Thema: Buch zum Einstieg in OS-Programmierung

[Spiderschwein13]

Erstmal Hallo ans Forum!

Windows XP ist toll, es ist benutzerfreundlich und man braucht nicht viel PC-Verständnis.
Nur eine klitze kleine Frage stellt sich mir da immer: Wieso is das so ***** langsam? Schon allein der Bootscreen, was muss denn da alles geladen werden?
Deshalb wollten mein Freund und ich auch mal ein eigenes OS programmieren.
Ich habe davorn nur leider sehr wenig Ahnung.
Was kann ich alles in C programmieren? Was muss in Assembler geschrieben werden? Wie bring is das ganze auf CD (RW)? Welchen Emulator soll ich verwenden .. Oder wie sprech ich die Graphikkarte an? Denn mein OS soll wie oben angedeutet genauso benutzerfreundlich sein, wie XP, deshalb müsste von Anfang an ne graphische Oberfläche her.
Und wenn ich dann was in C programmier, kann ich das doch eh wieder in Maschienencode umwandeln? Dann müsste es genauso effizient sein, wie Assembler?

Über das Internet ist es immer schwer, so viele "zusammenhängende" Informationen zu finden.
Vllt könnt ihr mir schon ein paar Fragen beantworten, aber am besten wärs, wenn mir jemand ein gutes Buch empfehlen könnte, indem ich zum Einstieg ein bisschen begleitet werde.

Gruß
das Spiderschwein

[nooooooooos]

Also ein Buch zum OS-Dev gibts so nicht...Es gibt höchstens das PC-Hardwarebuch von Tannenbaum (oder so ähnlich) das hat dann etwa 2000 Seiten und ist vergriffen...

Wie du sagst müssen für ein OS wie XP sehr viele Sachen geladen werden. All diese Sachen musst du zuerst aber programmieren...Bis du bei einer einigermassen funktionalen GUI bist, können da ein paar Jahre ins Land gehen, wenn du deine Jugendnicht komplett im PC Keller verbringen willst (wie Linus)...

In Assembler musst du sicher mal den Bootloader machen, sofern du nicht einen vorgefertigten wie GRUB nimmst...Dann musst du noch einige Funktionen für den C Code damit machen...Du könntest aber auch alles in ASM schreiben, wenn dir das gefällt...Ich bin so einer und bin deshalb auch der Meinung dass du den Code besser optimieren kannst als ein Compiler, denn noch sind Computer bei weitem noch nicht so schlau wie ein menschliches Gehirn. Zudem ist Assembler gar nicht so schwer (mit 20-30 Anweisungen kommst du sehr weit, für den Rest gibts Referenzen).

Als Emulator ist Bochs für den Einstieg sicher das Beste. Er wird aber gerade in Zusammenhang mit Grafik sehr langsam...Grafikkarten ansprechen wie du das gerne möchtest ist extrem schwierig, da dazu kaum Spezifikationen zu kriegen sind. Das beste was du implementieren kannst ist VESA....Allerdings kannst du dir 3D-Funktionen usw. abschminken und deine GUI wird noch viel langsamer als die von Windows wenn du sie so aufwändig wie Aero machen willst, allerdings keine GPU mit Grafikbeschleunigung, Shadern und eingem RAM dazu nutzen kannst. Die Treiber für die individuellen Grafikkarten werden meinstens von den jeweiligen Herstellern geschrieben, die die Grafikkarte genaustens kennen und somit auch ausrezien können und sind closed source. Du musst also nur Nvidia, ATI dazu bringen Treiber für dein OS zu schreiben....

Zuerst musst du mal einen anständigen Kernel mit IPC, Task und Speicherverwaltung haben, dann kannst du anfangen die unterschiedlichen Treiber (Tastatur, von mir aus Maus, Vesa...) coden. Dazu gibts reihenweise Tutorials oder Spezifikationen (wenn halt manchmal auf Englisch). Du kannst auch einfach hier im Forum oder unserem Wiki nach den einzelnen Themen suchen, dir einmal ein grobes Design überlegen und dann systematisch zu coden beginnen.


Gruss
Noooooooooooos

[kevin]

Windows XP ist toll, es ist benutzerfreundlich und man braucht nicht viel PC-Verständnis.

Das ist m.E. ein Widerspruch in sich, aber gut...

Was kann ich alles in C programmieren? Was muss in Assembler geschrieben werden?

In Assembler muß geschrieben werden, was du nicht in C (oder irgendeiner anderen Hochsprache) ausdrücken kannst - Hardwarezugriffe durch IO-Ports, Zugriff auf Kontrollregister des Prozessors und sowas. Den Rest kannst du in C schreiben. Der Assemblerteil beschränkt sich im allgemeinen auf ein paar kleine Funktionen.

Welchen Emulator soll ich verwenden

Die meisten hier nehmen bochs und qemu.

Oder wie sprech ich die Graphikkarte an? Denn mein OS soll wie oben angedeutet genauso benutzerfreundlich sein, wie XP, deshalb müsste von Anfang an ne graphische Oberfläche her.

Gutgemeinter Tip: Vergiß es und denk in einem Jahr nochmal drüber nach, wenn die Grundlagen stehen. Das ist sonst, wie wenn du an einem Haus zuerst das Dach bauen willst - vollkommener Schwachsinn.

Und wenn ich dann was in C programmier, kann ich das doch eh wieder in Maschienencode umwandeln? Dann müsste es genauso effizient sein, wie Assembler?

Darüber kann man lang und breit diskutieren. Ich halt das mal so fest: Was du in C ausdrücken kannst, schreibst du auch in C. Schlechter handgeschriebener Assemblercode ist langsamer als das, was der Compiler ausgibt.

Vllt könnt ihr mir schon ein paar Fragen beantworten, aber am besten wärs, wenn mir jemand ein gutes Buch empfehlen könnte, indem ich zum Einstieg ein bisschen begleitet werde.

Tutorials im Internet sollten es eigentlich tun. Erster Schritt: Ein "Hello World" auf den Bildschirm bringen. Danach kann du dann mal weitersehen.

[kevin]

In Assembler musst du sicher mal den Bootloader machen, sofern du nicht einen vorgefertigten wie GRUB nimmst...

Richtig, die obligatorische Empfehlung, GRUB zu nehmen, darf natürlich nicht fehlen.

Ich bin so einer und bin deshalb auch der Meinung dass du den Code besser optimieren kannst als ein Compiler, denn noch sind Computer bei weitem noch nicht so schlau wie ein menschliches Gehirn. Zudem ist Assembler gar nicht so schwer (mit 20-30 Anweisungen kommst du sehr weit, für den Rest gibts Referenzen).

Das war das, was ich mit lang und breit diskutieren meinte. Ich möchte die Diskussionen hier nicht wiederholen, daher nur so viel: Diese Aussage ist - vorsichtig ausgedrückt - hier nicht allgemein anerkannt.

[bluecode]

Also ein Buch zum OS-Dev gibts so nicht...Es gibt höchstens das PC-Hardwarebuch von Tannenbaum (oder so ähnlich) das hat dann etwa 2000 Seiten und ist vergriffen...

Das "PC-Hardwarebuch - Aufbau, Funktionsweise, Programmierung" ist von Hans-Peter Messmer und Klaus Dembowski. Es ist in der 7ten Auflage bei amazon zu finden. Leider haben die in dieser Auflage einige Themen einfach weggelassen (und dafür andere breiter erklärt) und das sind vor allem die Sachen die am Anfang interessieren: PS/2 Maus/Tastatur und Diskettenlaufwerk. Deswegen kann ich es auch in der 6ten Auflage empfehlen (siehe amazon).
Das andere Buch ist von Andrew S. Tanenbaum und heißt "Moderne Betriebssysteme". Das Buch beschäftigt sich eher mit der theoretischen Seite: also was sind Prozesse/Threads, wie kann IPC aussehen, wo liegen Probleme dabei, wie kann man Threads schedulen, was sind Deadlocks, wie kann man sie verhindern, wie sieht eine Speicherverwaltung aus, generelles zu Dateisystemen, etwas zu Multiprozessorsystemen, etwas zu IT-Sicherheit und ein Kapitel zum Design/Implementation von Unix/Linux und eins zu Windows2000. Ich muss leider sagen, dass das Buch beim Programmieren eines OS nicht so hilfreich ist.

Welchen Emulator soll ich verwenden

Die meisten hier nehmen bochs und qemu.

Ich würde mal sagen so viele du finden kannst. Es gibt noch VMWare Server (ist auch kostenlos), VirtualBox und VirtualPC. Am Anfang wird bochs jedoch die weit besten Debuggingmöglichkeiten bieten. Mein Tipp hier wäre, dir diese Debuggingmöglichkeiten mal zuerst anzuschauen (evtl. musst du dir dazu einen handkonfigurierten bochs bauen).

Und wenn ich dann was in C programmier, kann ich das doch eh wieder in Maschienencode umwandeln? Dann müsste es genauso effizient sein, wie Assembler?

Darüber kann man lang und breit diskutieren. Ich halt das mal so fest: Was du in C ausdrücken kannst, schreibst du auch in C. [...]

Ein Grund dafür ist, dass der (sowieso schon langsame) Entwicklungsprozess in einer höheren Sprache schneller geht als in Assembler. Außerdem ist meistens sowieso der Algorithmus und die Datenstruktur die benutzt werden weit entscheidender für die Geschwindigkeit als die Programmiersprache. Dazu kommt noch, dass es in Assembler mittlerweile extrem schwer geworden ist zu optimieren, da viel zu viele Dinge bedacht werden müssen: Caches, mehrere Pipelines, verschiedene Instruktionen sind langsamer/schneller auf einer bestimmten Prozessorgeneration.
Das soll nicht heißen, dass man Assembler nicht mehr braucht. Ab und an muss man schon mal seinen C/C++ Kernel disassemblieren und schauen was da überhaupt vor sich geht.


Zum Thema GUI kann ich taljeth nur zustimmen: Vergiss es für die ersten 1-2 Jahre. Und nach 1-2Jahren ist das beste was du erstmal kriegen kannst VESA und das hat einfach keine 2/3d Beschleunigung und ist deshalb saulahm. Danach kannst du dir mal die open-source 2D-Treiber in X.org, Haiku oder anderen OS anschauen/portieren.
An der Zeitangabe solltest du schon sehen, dass das Programmieren eines OS kein Job ist, den man in mehreren Wochen machen kann. Es geht vielmehr um Jahre. Schau dir am besten dazu mal die HobbyOS an, die von Leuten in diesem Forum geschrieben werden/wurden und wie lang die Personen gebraucht haben um dahin zu kommen.

Jetzt schonmal viel Spaß und Erfolg. Mögest du es besser/schneller machen als wir.

edit: Family Guy? Oh Mist... Die Simpsons.

[Spiderschwein13]

Family Guy?
wie meinen, ob ich das OS mit meiner Family programmier?^^ also wenn du das meinst, nein.
Also anscheinend gibt es kein "wunder Buch"?
Dann mal ein paar Fragen zu dem Tutorial, das jeder kennt:
http://www.tutorials.de/forum/programming-tutorials/20706-ein-eigenes-kleines-betriebssystem.html

Eigentlich wollte ich das eigentliche Betriebssystem ja ganz gerne in C schreiben, aber da die Header-Dateien jeweils an ein bestimmtes Betriebssystem gebunden sind, können wir in unserem Kernel keine Funktionen einbinden. Wir schreiben unseren Kernel also mit Assembler.

Wenn ich aber nun mein C doch schon unter Windows ins Assembler kompilier?
.. weiter unten steht, dass die Funktion printf() kein Bestandteil der Sprache selbst ist .. wenn ich mir diese selbst schreiben würde, könnte ich auch in C arbeiten? .. ansonsten müsste ich mich wirklich erstmal lääänger mit Assembler beschäftigen.

Noch eine kleine Sache:
Ich hab das Tutorial von oben wie schon so viele auch mal per copy & paste gemacht (und hier http://entwickler-forum.de/archive/index.php/t-43462.html nachgeschaut, warum der Befehl für nasm nichmehr funktioniert).
Allerding habe ich keine Diskettenlaufwerk, deshalb wollte ich Virtual PC verwenden, aber dieses will mir weißmachen, dass meine .img Datei iwi 700kB oda 1,44MB (hald Diskettengröße) groß ein sein muss. Wie schaff ich das am dümmsten?

[bluecode]

Kleiner Nachtrag: Wer hofft anhand der Spezifikationen, die AMD/ATI freigegeben hat (siehe hier), Treiber schreiben zu können, vergesst es auf absehbare Zeit. Schaut euch die Dokumente an. Das sind hunderte Seiten die sich ausschließlich mit den Bits der Register beschäftigen. Kein Wort Erklärung, nur Tabellen. Und so wie ich das verstanden hab, ist das nur das 2D Zeugs...

Family Guy? wie meinen, ob ich das OS mit meiner Family programmier?^^ also wenn du das meinst, nein.

Ich meinte eigentlich eher woher ich "Spiderschwein" kenne und es sind die Simpsons und nicht Family guy

Eigentlich wollte ich das eigentliche Betriebssystem ja ganz gerne in C schreiben, aber da die Header-Dateien jeweils an ein bestimmtes Betriebssystem gebunden sind, können wir in unserem Kernel keine Funktionen einbinden. Wir schreiben unseren Kernel also mit Assembler.

Damit ist gemeint, dass teilweise die Funktionen aus den Standardheadern auf das Betriebssystem zugreifen müssen. zB muss fread dem Betriebssystem irgendwie mitteilen, dass es aus einer Datei lesen will. Dass das betriebssystemanbhängig ist, ist wohl klar.

.. weiter unten steht, dass die Funktion printf() kein Bestandteil der Sprache selbst ist .. wenn ich mir diese selbst schreiben würde, könnte ich auch in C arbeiten? .. ansonsten müsste ich mich wirklich erstmal lääänger mit Assembler beschäftigen.

printf gehört zur Sprache C. Es steht im ISO C Standard und muss von einem Compiler/Betriebssystem bereitgestellt werden. Das wichtige ist aber, dass es nicht zur Syntax, also zu den grundlegenden Primitiven der Sprache gehört, d.h. man kann printf in C implementieren.
Und da printf halt auf betriebssystemspezifische Sachen zugreifen muss (Datei I/O), musst du es selbst für dein Betriebssystem implementieren. Gcc/VisualC kann ja nicht wissen über welchen Interrupt, welches Call-gate, über die Instruktion 'syscall' oder doch über 'sysenter' ein Prozess mit dem Betriebssystemkernel kommuniziert und wie die Parameter übergeben werden sollen.

ansonsten müsste ich mich wirklich erstmal lääänger mit Assembler beschäftigen.

Das ist auf jeden Fall ratsam. Meine ersten Schritte im Bereich OSdev waren auch komplett in Assembler (auch wenn mir das jetzt manche hier im Forum nicht glauben werden, aber es war wirklich so ).

dass meine .img Datei iwi 700kB oda 1,44MB (hald Diskettengröße) groß ein sein muss. Wie schaff ich das am dümmsten?

afaik geht das unter Windows zB mit partcopy (Direktlink: pcopy02.zip). Das osdev.org wiki hat auch eine Seite mit Tools. Aber vertrau mir da mal nicht und warte auf andere Kommentare.

[Spiderschwein13]

Und wie bring ich mein Image nun auf eine Größe von 720KB? Leere Nullen hinzufügen?

[nooooooooos]

jap

kannst das an deine kernel.asm datei anfügen:

Code: [Auswählen]

times 736768-($-$$) db 0
Gruss
Nooooooooooos

[bluecode]

Es sollte afaik 737280 (1440 Sektoren * 512 Byte) sein nooooos. Nur zur Erklärung: Der Code sagt dem Assembler, dass es ab dem Offset an dem das times steht bis Offset 737280 nur 0en in die resultierende Datei schreiben soll.

[nooooooooos]

Und der Bootloader?

[bluecode]

Oh ok, das Tutorial hat ja sogar einen Bootloader Das hab ich jetzt übersehen...

[Spiderschwein13]

Hmmmm, des obige stimmt schon iwi (736768) allerdings muss ich wegen "meinem Bootloader" noch 512 abziehen? denn dann wird mein Img auch genau 720KB groß, das ganze aktzeptiert er allerding immer noch nich.
Hab mein ganzes Zeug mal in ne Zip-File gepackt.
http://rapidshare.com/files/81474835/BS.zip.html

beim Klick auf "asm zu img.bat" sollte sich eigentlich eine funktionierende a.img Datei bilden .. so ein gefummel .. ich brauch doch jetz "nur noch" die Richtige Zahl in meiner kernel.asm?
... genau diese komischen Kleinigkeiten, vllt kauf ich mir ein Buch über Assembler, das sich auch ein bissl emulieren beschäftigt

Edit:
Ihr seit jetz auch schon auf den bootloader gestoßen, dann muss ich 512 Bytes abziehen?

[nooooooooos]

ich hab in meiner berechnung den bootloader schon abgezogen...


Gruss

[Spiderschwein13]

@noooooooooooooooooooooooooooooos
VDF (http://www.osdev.org/wiki/Virtual_Floppy_Disk) sagt dazu
Failed to mount the Virtual FD  image "%s".
Invalid image file size.

ich hab deine Berechnung ( times 736768-($-$$) db 0) genommen

[nooooooooos]

hmm...du hast diese codezeile ganz am ende des kernels eingefügt?
Sonst probier mal 1474048 für 1.44MB...

Gruss
Nooooooooooos

[Spiderschwein13]

hmm...du hast diese codezeile ganz am ende des kernels eingefügt?

Jo.

Sonst probier mal 1474048 für 1.44MB...

Funktioniert auch nicht.
Du hast gerechnet 1439,5 * 1024 oda?
.. ich versteh nich, warum des nich funktioniert.
Ihr habt wohl alle ein Diskettenlaufwerk am PC?^

[nooooooooos]

Ja oder Bochs, Qemu, VmWare ...

[Spiderschwein13]

Dann installier ich jetz mal VMWare

[bluecode]

Ihr habt wohl alle ein Diskettenlaufwerk am PC?^

Oder Linux und ein Dateisystem auf dem Image

Zur Rechnung: Eine 1,44MB Floppy hat 2880 Sektoren. Man nimmt einen weg für den Bootsektor. Den Rest der Sektoren muss der Kernel ausfüllen: 2880 * 512 = 1474048.

Problem mit Virtual Floppy Disk ist, dass du kein Dateisystem auf deinem Image hast, sondern nur rohe Daten. Deswegen schlägt das Einbinden in das Dateisystem (sprich das mounten auf A:/ B:/ oder wo auch immer) fehl. Was willst du gerade überhaupt mit dem Programm erreichen? Nasm gibt dir eigentlich so bereits ein Image aus, dass du mit dem Emulator deiner Wahl testen könntest.