Eigenes OS?
-
endlich gehts los mit dem OS *daumen_hoch*
Ich sagte doch, dass Du etwas Geduld mitbringen musst. Jedes OS wandert im gewissen Sinne durch eine autistische Phase. Bei PrettyOS wurde das durch Verweigern der "Gehhilfe" GRUB noch vertieft. Der Kontakt zur Außenwelt gehört bei vielen Entwürfen im Sinne eines Mikrokernels nicht wirklich zum Systemkern, sondern wird an den User-Space delegiert. Nun wird sich PrettyOS allerdings verstärkt öffnen, sowohl gegenüber dem User als auch dem Computerumfeld.
Damit ist allerdings auch die wirklich spannende Phase vorbei.
Nun verstehe ich Autisten.
Danke für den interessanten Link!
-
Nachdem die Version 97 (incl. initrd) überall stabil läuft, habe ich dies nun auch beschrieben.
Besonders interessant finde ich die Analyse der Datenstrukturen auf Diskette mit dem Hex-Editor: http://www.henkessoft.de/OS_Dev/Bilder/FAT12_HexEditor.PNG
Man erkennt sehr schön den Bootsektor, FAT1, FAT2, die Root-Directory und dahinter die Daten. Eine Analyse der Clusterketten in der FAT zeigt die Linked List (folgt noch). Damit wird das Ganze sehr klar und konkret.
-
^^wieso willste eigentlich FAT12 und nicht gleich FAT16 nehmen?
-
Na ja, ich überlasse die Formatierung noch MS Windows. Der Format-Befehl von MS Windows 98, ME und XP wird eine Diskette immer mit FAT12 und nur alle anderen Laufwerke mit FAT32 bzw. NTFS formatieren. Der Format-Befehl von MS DOS und MS Windows 95A, der nur FAT12 und FAT16 kennt, formatiert eine Diskette mit FAT12 und alle anderen Laufwerke mit FAT16. Daher ist FAT12 das zu erwartende Format, in der unsere Daten mit einem copy BOOT2.SYS A:\BOOT2.SYS bzw. copy CKERNEL.SYS A:\CKERNEL.SYS auf Diskette übertragen und dort abgelegt werden. Mir gefällt das Umgehen mit halben Bytes auch nicht, wäre bei 16 Bit einfacher.
-
Ich habe nun noch diese Abbildung hinzugefügt, damit die - prinzipiell einfachen - Zusammenhänge und Berechnungsformeln klar werden: http://www.henkessoft.de/OS_Dev/Bilder/FAT1_FAT2_Root.PNG
-
Ich habe gerade mal etwas in dem Tutorial gelesen über das OS und hab mir mal aus spass direkt das Programm Bochs runtergeladen ( hab zwar noch n Disketten Laufwerk aber die Diskette sind nicht mehr so gut ^^ ) funktionierte auch sofort alles mit dem Kernel.bin am Anfang.
Aber jetzt würde mich mal interessieren wie viele Leute an dem Tutorial mit arbeiten, das ist ja wahnsinn wie viel da steht da kann man eine menge lernen.
-
n1 schrieb:
Ich habe gerade mal etwas in dem Tutorial gelesen über das OS und hab mir mal aus spass direkt das Programm Bochs runtergeladen ( hab zwar noch n Disketten Laufwerk aber die Diskette sind nicht mehr so gut ^^ ) funktionierte auch sofort alles mit dem Kernel.bin am Anfang.
Aber jetzt würde mich mal interessieren wie viele Leute an dem Tutorial mit arbeiten, das ist ja wahnsinn wie viel da steht da kann man eine menge lernen.
naja das sind doch alles basics, die lernst du in jedem informatik erstsemester
-
O_o Glaub ich nicht^^
-
n1 schrieb:
O_o Glaub ich nicht^^
Die Theorie wird schon in den ersten beiden Semestern behandelt. Dabei wird nur nicht auf technische Besonderheiten einer bestimmten Architektur eingegangen. Aufbau/Funktionsweise einer CPU, Assembler (nicht unbedingt x86), Speicher-/Ressourcenmanagement, Scheduling, sind alles Themen die dran kommen.
-
Aber jetzt würde mich mal interessieren wie viele Leute an dem Tutorial mit arbeiten
Ich arbeite bisher alleine an diesem Tutorial, seit etwa Mitte März diesen Jahres. Schön wäre es, wenn sich so eine Art OS Community bilden würde, habe diesbezüglich aber keine klaren Vorstellungen.
naja das sind doch alles basics, die lernst du in jedem informatik erstsemester
Man hört zumindest davon. Ob man es rein theoretisch versteht, ist allerdings eine andere Sache. Aus den flüchtigen Universitäts-Skripten, die man so im Internet findet, könnte ich allerdings kein OS zimmern. Selbst mit dem Tanenbaum in der Hand ist dies nicht möglich. Man benötigt "echte" Vorbilder. Linux hatte Minix, DOS hatte CP/M als Vorbild, so sieht das aus.
Mich freut es, wenn ich mitbekomme, dass junge Leute mit etwa 13 - 15 Jahren diesbezüglich konkret los legen und nicht nur zu Konsumenten von fertigen OS, Programmen und Spielen werden. Ich denke dies ist die Hauptzielgruppe. Daher schreibe ich das Tutorial auch in Deutsch und nicht in Englisch.
Die Theorie wird schon in den ersten beiden Semestern behandelt. Dabei wird nur nicht auf technische Besonderheiten einer bestimmten Architektur eingegangen.
Die technischen Besonderheiten, gerade bei 80x86, sind aber genau der Clou! Grau, grau ist alle Theorie.
Ich würde übrigens empfehlen, parallel mit der Programmierung eines kleinen "Roboters" wie ASURO oder Nibo zu beginnen, damit man auch µC als Vergleich kennen lernt:
http://www.henkessoft.de/Roboter/ASURO.htm
http://www.henkessoft.de/Roboter/Nibo.htm
-
Ich weiß, dass das Thema hier zu genüge durchgekaut wurde. Aber gerade ich als jemand, der in deiner Zielgruppe liegt, frage ich mich doch, ob es denn gerade so sinnvoll ist, ständig vom eigentlichen Kern abzulenken, nur weil der liebe x86er unbedingt auf seine Extrawurst besteht.
Das Anschalten des A20-Gates - beispielsweise - könnte sich, ob der nicht unbedingt offensichtlichen Notwendigkeit dieses Gefrickels, für so manchen zum Stolperstein entwickeln. In dieselbe Nische schlägt da auch das gesamte Umschalten zwischen PM / RM usw. usf.
Trotzdem muss ich dir ein dickes Lob aussprechen.
Dein Tutorial ist eine unglaublich willkommene Abwechslung zu den teilweise sehr schwer auffindbaren und verstreuten Informationen zum Thema im Netz.
Weiter so
-
Danke für das positive Feedback! Es ist eine abwechslungsreiche und interessante Materie, aber auch verflixt viel Arbeit, die Zusammenhänge verständlich und dennoch auf das Wesentliche konzentriert darzustellen. Für konkrete konstruktive Anregungen bin ich dankbar.
-
Für konkrete konstruktive Anregungen bin ich dankbar.
In Sachen fachlicher Korrektheit kann dir die "Forenprominenz" ja bestens zur Seite stehen. Was das Hauptproblem der Didaktik angeht, so kann ich eigentlich keine wirklichen Kritikpunkte finden. Allgemein würde ich dir - zumindest was meinen Standpunkt angeht - dazu raten, nicht mit Theorie und Hintergrundinformation zu geizen. Absätze überspringen und im Notfall nachlesen kann man jederzeit, aber nichts ärgert mich mehr, als wenn ein Detail ungeklärt bleibt oder nicht erwähnt wird.
-
Tobiking2 schrieb:
Dabei wird nur nicht auf technische Besonderheiten einer bestimmten Architektur eingegangen.
ach das wär zu schön. schätzungsweise 90% der dozenten, die diese dinge lehren, haben ihr skript, was sie ca. 1983 kompiliert haben, worin sie die studenten mit gelaber über uralten x86 kram wie real mode, protected mode, xms, x86 isa und co nerven
die meisten dozenten sind leider vor 20 jahren in der zeit stehen geblieben, als sie selbst das letzte mal irgendwas programmiert haben
-
die meisten dozenten sind leider vor 20 jahren in der zeit stehen geblieben
So etwas ist eine Schande für unser Ausbildungssystem!
Für was zahle ich denn Unmengen von Steuern? Diesen Damen und Herren müsst ihr mal richtig Bescheid stoßen.Die Abwehr gegen den "x86 Kram" finde ich prinzipiell unberechtigt, denn diese CPUs beherrschen heute immer noch den PC-Markt, nun in 64-Bit-Qualität, was die ganze Sache noch mehr verkompliziert. Ich fände eine vergleichende konkrete Darstellung der Pros und Cons sinnvoll mit Blick auf Windows, Linux, Symbian OS und einem Roboter-Betriebssystem.
Mit "abstrakter" Software kann man zunächst wenig bewegen. Zum Schluss müssen immer auch die "Basics" bedient werden, und diese sind zumeist komplex, weil diese wirtschaftlich und nicht didaktisch getrieben sind, eben Bit-Gefrickel.
Mir geht es bei meinem Tutorial darum, dass man alles praktisch durchführen und analysieren kann, was zu einem grundlegenden OS dazu gehört, vom Bootloader angefangen bis hin zum Dateisystem. Dinge wie kompliziertes Scheduling oder Deadlock-Verhindern kann man im Tanenbaum sehr gut nachlesen und bei einem einfacheren System leicht nachrüsten.
Die größten Probleme bereitet in der Regel der Umgang mit Assemblercode oder das Präparieren von Stacks, soweit ich das bisher sehen kann. Treiber- oder User-Space-Programmierung ist eher Fleissarbeit.
-
Die technischen Besonderheiten, gerade bei 80x86, sind aber genau der Clou! Grau, grau ist alle Theorie.
Man braucht aber zum verstehen von Paging nicht zu wissen, welches Bit in welchem Register gesetzt werden muss, um es beim x86 zu aktivieren. Es ist natürlich in einem Tutorial wie deinem wichtig zu erwähnen, aber wer selber ein Betriebsystem schreibt und nicht auf ein Tutorial aufbaut, kann sich das auch aus dem Intel Manual oder aus einem der recht guten Wikis zu dem Thema raussuchen. Das sehe ich noch nicht als spannend an. Zu dem Wechsel in den PM dürften sich auch schon genug negativ geäußert haben.
Ich find dann erst wieder interessant, wie die verschiedenen Techniken dann in der Praxis wirklich genutzt werden. Das steht dann aber auch oft im Tanenbaum. Ich denke zudem schon das man mit soliden Assembler/C Kenntnissen, dem Tanenbaum und dem Intel Manual ein Betriebsystem schreiben könnte. Es kann ja nicht jeder irgendwo abgucken, irgendwer muss angefangen haben.
Die Zielgruppe 13-15 find ich etwas niedrig. Den meisten dürfte es selbst mit dem Tutorial an Vorwissen fehlen und es endet mit stumpfen copy and paste.
Daher schreibe ich das Tutorial auch in Deutsch und nicht in Englisch.
Und wieso kommentierst du den Code (vor allem die Codebeispiele) auf Englisch und nicht auf Deutsch?
ach das wär zu schön. schätzungsweise 90% der dozenten, die diese dinge lehren, haben ihr skript, was sie ca. 1983 kompiliert haben, worin sie die studenten mit gelaber über uralten x86 kram wie real mode, protected mode, xms, x86 isa und co nerven
die meisten dozenten sind leider vor 20 jahren in der zeit stehen geblieben, als sie selbst das letzte mal irgendwas programmiert haben Wir haben teilweise Glück gehabt. Die Hardware Grundlagen kamen von einem Dozenten der am Lehrstuhl Eingebettete Systeme tätig ist. Das ist warscheinlich der Grund dafür gewesen, dass wir jedes mal MIPS als Referenzarchitektur genommen haben wenn etwas konkret behandelt wurde.
Die Betriebsystem Vorlesung war dafür dann das Tanenbaum Buch in Kurzform. Sogar die Folien waren original von Tanenbaum auf Englisch und zwischendurch mal ein Deutscher Satz als Zusatz drunter gesetzt.
So etwas ist eine Schande für unser Ausbildungssystem!
Für was zahle ich denn Unmengen von Steuern? Diesen Damen und Herren müsst ihr mal richtig Bescheid stoßen.Ich zahl sogar noch 500 Euro pro Semester an Studiengebühren...
-
es endet mit stumpfen copy and paste
Das ist erstmal nicht schlimm. Man will sehen, dass etwas geht, bevor man sich tiefer beschäftigt. RM->PM ist blöd, dass BIOS weg ist. Gibt es da keinen Weg, das doch noch zu nutzen? Einschalten A20 kopiert man einfach, basta. Interessant ist Einsatz von FAT12, hoffentlich bald USB, wäre toll.
Tutorial ist bisher glaube ich bestes, was es gibt in deutsch, oder?
-
Tobiking2: ja dan hattest du wohl Glück. Ich verstehe auch nicht, warum nicht mehr Dozenten einfach auf die wirklich gute Literatur wie Tanenbaum, Silberschatz und Co. zurückgreifen, die es zu diesem Thema ja zur Genüge gibt. Viele Dozenten haben stattdessen ihr didaktisch absolut miserabel gestaltetes Skript, was zusätzlich halt veraltet ist. Schade, daß die Dozenten so ziemlich in jeder Hinsicht tun und lassen können, was sie wollen. Da sollte es mal mehr Vorgaben geben oder so :o
-
Mich würde interessieren, welches Skript zum Thema OS Development das beste an der Hochschule ist.
-
Erhard Henkes schrieb:
Die Abwehr gegen den "x86 Kram" finde ich prinzipiell unberechtigt, denn diese CPUs beherrschen heute immer noch den PC-Markt, nun in 64-Bit-Qualität, was die ganze Sache noch mehr verkompliziert. Ich fände eine vergleichende konkrete Darstellung der Pros und Cons sinnvoll mit Blick auf Windows, Linux, Symbian OS und einem Roboter-Betriebssystem.
der 'x86-kram' stellt aber eine äusserst miserabel zusammengeflickte architektur dar (im vergleich z.b. zu ARM-systemen). das design der ersten X86-CPUs war nun mal nicht darauf ausgelegt, immer neue derivate (bis in die heutige zeit) hervorzubringen. dementsprechenden haben wir heute übelsten pfusch in unserern PCs.
Erhard Henkes schrieb:
Mit "abstrakter" Software kann man zunächst wenig bewegen. Zum Schluss müssen immer auch die "Basics" bedient werden, und diese sind zumeist komplex, weil diese wirtschaftlich und nicht didaktisch getrieben sind, eben Bit-Gefrickel.
deshalb sollte man auch besser 'hardware abstraction layer' einsetzen, im einfachsten fall I/O-bitgefummel über makros machen und für komplexere komponenten (z.b. die RTC, RS232, speichermedien usw.) treiber mit 'nem einheitlichen interface schreiben. sowas wie scheduling-algorithmus, exception und interrupt-handling z.b. kann man in portablem C coden, wobei nur sehr wenig plattformabhängiger assembler-code verwendet werden muss (den man hinter funktionen verstecken kann, z.b. switch_context()). wenn ich z.b. so'n tutorial wie deins (bis jetzt) machen würde, dann würde ich es nicht 'betriebssystementwicklung' sondern eher 'programmierung unter nackten x86 systemen' o.ä. nennen.
