Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

Ich entwickel mit ein paar anderen zusammen ein eigenes OS, finden kannst du es hier. Ist in C geschrieben und der Zweck ist denke ich klar :???:

Habe vor graumer Zeit mal angefangen, aber schon nach dem Multiboot Kernelloader aufgehört. War in C und Assembler...

Mfg.
way

zu welchem Zweck und in welcher Sprache (ASS, C oder C++)?

Ich habe mich auch mal mit einem eigenen OS in Assembler beschäftigt zwecks endlich mal den Protected Mode der Intel CPUs zu verstehen. Habe aber diesbezüglich versagt und daraus wurde nichts. Hm, vertane Lebenszeit... hätte lieber in was anderes und sinnvolleres investieren sollen.

Ich denke, dass es auch teilweise an der mangelnden Erklärung der Vorbilder und an langatmigen Theorie-Erklärungen liegt, wenn es in der Praxis schief geht. Beim Einstieg haben die wenigsten den kompletten Durchstieg durch alle Facetten. Also ist es wichtig, die Dinge detailliert zu erklären und vor allem auch Anregungen für eigene Experimente zu geben, damit die Dinge wirklich "glasklar" werden.

Bevor man bei einem Hobby- oder Experimental-OS auf den Protected Mode umschaltet, sollte man erst den Real Mode didaktisch komplett ausloten, damit der PM nicht zur Belastung wird, sondern zur Bereicherung.

Ich habe mir vorgenommen, didaktisch den Einstieg in die OS-Entwicklung zu erleichtern, denn es hilft, sowohl Assembler, C und auch die Hardware richtig zu verstehen, zumindest dann, wenn man dies möchte. Daher bitte ich euch mit zu helfen.

Hier die Seite:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

Bitte um konstruktive Kommentare/Ideen. Mir ist volles Verständnis und ein stufenweiser und leichter Einstieg wichtig. Kein blitzschnelles Voranhuschen einer Elite. Die brauchen solche Seiten nicht, sondern nur Datenblätter, Tabellen, ....

Wenn jemand mitmachen möchte, gerne. Bitte hier oder per mail. Im Kopf der Seite ist Platz für viele Namen. Hauptziel: Spaß und wirkliches Verständnis vermitteln. Ich möchte auch niemanden zwingen, zunächst Linux zu installieren, um zu beginnen.

Bisher haben sich für mich gvim [EDIT: notepad++ bringt mehr Komfort], nasm und bochs als wirklich brauchbar heraus kristallisiert. partcopy.exe kann sicher durch etwas anderes ersetzt werden. Wichtig ist, dass sich niemand die Festplatten "zerschießt".

Ich habe eine Floppy Disk zum Booten verwendet. Heutige PCs haben dies nicht mehr ohne weiteres. Viele haben aber noch alte PCs mit Floppy Disk und wollen wirklich "physisch booten". Didaktisch muss das einfach sein.

Euer Problem ist, daß ihr immer nur in x86 denkt. x86 ist nicht unbedingt die optimale Plattform für einen Einsteiger mit dem ganzen 20 Jahre alten Schrott wie Realmode, Callgates, Segmentregistern und dem ganzen anderen Mist. Ich verstehe nicht, warum immer alle Welt sowas immer unbedingt für die x86 Architektur machen muss. Die ist nicht nur hässlich, sondern auch klobig und extrem Noobunfreundlich.

da bin ich voll bei dir. erhard: mach was für 'ne ARM-plattform. ich wette es gibt mehr ARM-basierte systeme auf der welt als PC(x86)-kisten.

asdca schrieb:

Euer Problem ist, daß ihr immer nur in x86 denkt. x86 ist nicht unbedingt die optimale Plattform für einen Einsteiger mit dem ganzen 20 Jahre alten Schrott wie Realmode, Callgates, Segmentregistern und dem ganzen anderen Mist. Ich verstehe nicht, warum immer alle Welt sowas immer unbedingt für die x86 Architektur machen muss. Die ist nicht nur hässlich, sondern auch klobig und extrem Noobunfreundlich.

da bin ich voll bei dir. erhard: mach was für 'ne ARM-plattform. ich wette es gibt mehr ARM-basierte systeme auf der welt als PC(x86)-kisten.

Ich könnt kotzen , da +fricky recht hat

Ich könnt kotzen , da +fricky recht hat

wie jetzt?!?
ach ja, erhard: wie wär's mit 'nem OS für nintendo-DS? die plattform ist weit verbreitet, einigermaßen gut 'reverse engineered' und es gibt, meines wissens, bisher nur ein hobbyisten-OS dafür.

Ich versuche die Reihenfolge:

1. Werkzeuge bereit stellen
2. Praktisches Arbeiten
3. Notwendiges Backgroundwissen praxisnah vermitteln
4. Experimentieren, um Auswirkungen zu zeigen

einzuhalten.

Wenn man einsteigt, benötigt man z.B. zunächst nur das Wissen über CPU, Register und Interrupts. Das findet man heute alles ordentlich bei wiki ...

Das Mittel, das viele an der Hand haben, die am Internet hängen und Tutorials lesen, ist nun mal der 80i86 PC mit MS Windows.

Das Mittel, das viele an der Hand haben, die am Internet hängen und Tutorials lesen, ist nun mal der 80i86 PC mit MS Windows.

klar, aber du nutzt doch sowieso 'nen simulator (bochs) für deine experimente. dann könntest du auch 'nen simulator für eine interessante plattform verwenden, und nicht für dieses stokelige x86-gedöns.

Im ersten praktischen Schritt habe ich den Mini-Kernel komplett bootbar in Sektor 1 geschrieben.

Im nächsten Schritt wird ein Bootloader in Sektor 1 vorgeschaltet, der den gleichen Mini-Kernel nun aus Sektor 2 lädt (BIOS INT für Floppy Disk) und im Speicher anspringt. Im Kernel wird dann lediglich die Boot-Signatur entfernt und die Segment-Adresse geändert.

Das ist technisch für den Ersteller einfach durchführbar:

nasm boot.asm -f bin -o boot.bin
nasm kernel.asm -f bin -o kernel.bin
copy /b boot.bin + kernel.bin myOS.img
partcopy myOS.img 0 400 -f0

siehe: http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

Bitte denken Sie daran, sich für solche Aufgaben entsprechende bat-Dateien zu schreiben, wenn Sie experimentieren.

Habe das Tutorial mal kurz überflogen und das ist der Satz, der mich persönlich "stört". Ich bin nämlich für den Einsatz von Makefiles. Man kann nämlich die Makefiles wie gewöhnliche Batch-Dateien schreiben mit dem Vorteil der "automatischen" Fehlerbehandlung:

all:
    nasm boot.asm -f bin -o boot.bin 
    nasm kernel.asm -f bin -o kernel.bin 
    copy /b boot.bin + kernel.bin myOS.img 
    partcopy myOS.img 0 400 -f0

Sollte in der einen oder anderen Zeile ein Fehler auftreten, wird Makeprozess sofort abgebrochen... Bei Batch-Dateien müsste man mit unübersichtlichen goto's arbeiten, was dann schnell unübersichtlich wird.

Ich bin nämlich für den Einsatz von Makefiles.

Danke für diesen wichtigen Hinweis! Ich denke, zu Beginn erleichtert dies die Sache für einen Einsteiger nicht wirklich. Da lässt man ihn besser die einzelnen Befehlszeilen immer wieder in die Konsole hacken, damit er sich daran gewöhnt. Welches make.exe ohne notwendige DLL würdest Du denn einsetzen? Download-Link? Wo wird der Einsatz möglichst einfach beschrieben? Vielleicht überzeugst Du mich doch noch.

Das waren die Gründe, warum ich mich - zumindest für die ersten Schritte - für bat-Dateien entschieden habe. Langfristig geht dies natürlich nicht, aber momentan habe ich noch keine C-Toolchain im Einsatz. Es gibt nur nasm.exe und partcopy.exe.

Ich habe auch das img gegen bin getauscht, um nicht zu verwirren:

nasm boot.asm   -f bin -o boot.bin
nasm kernel.asm -f bin -o kernel.bin
copy /b boot.bin + kernel.bin MyOS.bin
partcopy MyOS.bin 0 400 -f0

EDIT: Habe doch noch ein einfaches make.exe ohne DLL gefunden:
http://www.steve.org.uk/Software/make/make.zip
EDIT1: Bei den Bin-Tools von gcc 2.03 ist auch ein alleinstehendes make.exe dabei: http://www.osdever.net/downloads/compilers/DJGPP-Installer-nocpp.exe

Ich werde dies im Tutorial abändern, weil der Einsatz von make.exe / makefile langfristig wirklich der richtige Weg ist.

Ist als Alternative zu den bat-Dateien dargestellt, siehe
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId748324 (Kapitel 4.5.3)
Praktisches Hindernis können die notwendigen Separatoren im makefile sein, aber gvim zeigt dies sehr gut durch fehlende bzw. vorhandene rote Schriftfarbe an.
Ein Einstieg in den make-Prozess muss auf jeden Fall erfolgen. Da führt wahrlich kein Weg beim OS Development vorbei.

Bootloader + Kommandozeile + FAT-Dateisystem + Interpreter (Sah aus wie Assembler, wurde aber interpretiert...).

bootloader + command-line interpreter ist nun vorhanden, zumindest im Real Mode. Einige Befehle und strcmp wurden bereits implementiert, damit man Experimente mit eigenen Befehlen leicht beginnen kann. Vielfach wird hier in Tutorials nur der Reboot eingebaut und man wird mit "Go wild!" oder "Viel Spaß!" alleine gelassen.
Den Reboot haben wir mit "exit" natürlich auch schon. Ich hoffe, dass ich bisher alles möglichst verständlich und zum praktischen Nachmachen einladend dargestellt habe, sonst kann ich gleich aufhören. Diesbezüglich bitte ich um ernsthaftes Feedback.

Der Tipp mit dem make-Prozess wurde inzwischen umgesetzt. Danke!

Vielleicht könnt ihr auch über den Code schauen, denn bei einem OS sollte alles möglichst performant laufen.

@/rant/: Wenn Du Lust hast, kannst Du mich gerne unterstützen, soweit Du kannst.
Hier steht nichts unter Zeitdruck. Didaktische Qualität und leichte Umsetzung ist wichtig und geht vor Quantität.

Die Umschaltung von RM nach PM übernehme ich gerne. Da knoble ich noch an der Didaktik.

habe mal aus Neugier das Tutorial "durchgearbeitet" (mit copy-paste natürlich ;)).
Habe mit bochs folgende Erfahrung gemacht: Booten funktioniert auch mit von nasm erzeugten Binärdateien. D.h. man benötigt nicht unbedingt ein Diskettenlaufwerk oder sonstiges. In der bochsrc.txt reicht z.B. folgendes:

floppya: 1_44=c:\BochsMyOS\MyOS.bin, status=inserted

Und die Datei MyOS.bin erzeugen wie immer:

nasm.exe kernel.asm -f bin -o MyOS.bin

Finde ich schön, weil wer hat denn heutzutage ein Diskettenlaufwerk...

Und ein Problem habe ich mit meinem Makefile gehabt. Folgende Zeile wollte make irgendwie nicht akzeptieren:

...
    copy /b bootloader.bin + kernel.bin MyOS.bin

Da kommt bei mir immer folgende Fehlermeldung:

process_begin: CreateProcess(NULL, copy /b bootloader.bin + kernel.bin MyOS.bin, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
mingw32-make: *** [OS3] Error 2

Und hier ein "Workaround":

...
    cmd /c copy /b bootloader.bin + kernel.bin MyOS.bin

Man muss also eine neue Instanz der Windows Befehlsinterpreters cmd starten und das eine Kommando übergeben. Warum auch immer. Aber wie dem auch sei, mein Makefile sieht jetzt so aus:

all:
	@echo Please select target: OS1 or OS2 or OS3

OS1:
	@echo OS1 selected.
	rm -fv kernel.bin bootloader.bin MyOS.bin
	c:\nasm-2.06rc6\nasm.exe kernel.asm -f bin -o MyOS.bin
	@echo Ready.

OS2:
	@echo OS2 selected.
	rm -fv kernel.bin bootloader.bin MyOS.bin
	c:\nasm-2.06rc6\nasm.exe kernel2.asm -f bin -o MyOS.bin
	@echo Ready.

OS3:
	@echo OS3 selected.
	rm -fv kernel.bin bootloader.bin MyOS.bin
	c:\nasm-2.06rc6\nasm.exe bootloader.asm -f bin -o bootloader.bin
	c:\nasm-2.06rc6\nasm.exe kernel3.asm -f bin -o kernel.bin
	cmd /c copy /b bootloader.bin + kernel.bin MyOS.bin
	@echo Ready.

clean:
	rm -fv kernel.bin bootloader.bin MyOS.bin

Man kann also mit make OS1 oder make OS2 oder make OS3 das eine oder andere assemblieren lassen...
Ansonsten hat alles wunderbar funktioniert (unter bochs) Bin gespannt auf Protected Mode.

habe mal aus Neugier das Tutorial "durchgearbeitet"

Danke für den Test und das positive Feedback.

floppya: 1_44=c:\BochsMyOS\MyOS.bin, status=inserted

Darauf habe ich sofort im Tutorial als Alternative für das config-File hingewiesen.
Heute gibt es wirklich kaum noch Floppy Disk Laufwerke. Aber es ist für viele Coder einfach ein tolles Gefühl, wenn man einen (alten) PC mit einem selbst gebastelten OS physisch von einer Floppy booten lassen kann.
Da ich selbst noch eines an meinem PC eingebaut habe, verwende ich es natürlich. Ich mag einfach dieses Klack-Geräusch und das aufleuchtende Lämpchen, wenn die Floppy angesprungen wird. Aber man muss mit der Zeit gehen.

Danke für den "Workaround" bezüglich copy. Ich verwende noch Win XP. Vielleicht klappt es deshalb. Weiß eigentlich jemand wo dieses copy heutzutage auf der Platte steckt? In win/system32 habe ich es nicht gefunden.

Das ausgefeilte makefile wird sicher auch noch Verwendung finden, ich möchte aber nicht zu früh vom eigentlichen OS ablenken. Die Tools sind vor allem Mittel zum Zweck, und gerade beim Thema makefile blicken viele - durch die IDEs - nicht mehr durch.

1. Beispiel:
Z. 19 (mov si, ...) ist ueberfluessig
(Auf Kosten der Uebersicht haette man das und evtl. einiges Andere nat. insgesamt auch effizienter loesen koennen...)

Z. 103, 104 (mov ah, ...; mov al, ...) ist uebelste x86-Suende: sowas schreibt man wenn irgendwie moeglich immer auf einmal in das uebergeordnete Register (hier ax)

Z. 119, 120 das gleiche

Das strcmp koennte man IMHO nun aber wirklich effizienter machen:
Z. 130 ist ueberfluessig. Vergleiche besser direkt al mit [di]
"cmp reg, 0" kannst du gegen "or al, al" o.Ae. tauschen (wie du es schon in print_string machst)
ich bevorzuge da "test reg, reg", AFAIR belegt das weniger Platz... Zumindest solltest du dich mal fuer eins entscheiden.
Es waere auch sinnvoller, das Ergebnis im Z-Flag zurueck zu geben. Das ist naemlich bei deinem Code so wie so schon 0, wenn eq und 1, wenn nicht eq... -> Kram mit CF weg und nur ein Ruecksprung-Label.

Z. 96 wieder der 0-Vergleich...

Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.
Ich bin mir nicht mal sicher, wo das BIOS den Stack anfangs hinzaubert. AFAIK gilt das als undefiniert. Da sollte man eigentlich nicht so einfach reinschreiben. Ein ueberwaeltigender Aufwand ist das nun wirklich auch nicht. Um dem Vorzubeugen: um das mov ss,.. und mov sp,.. gehoeren keine cli/sti, da man bei Intel so schlau war, bei "mov ss, ... " automatisch die Interrupts fuer die naechste Instruktion zu unterdruecken.

Den "buffer" haette man um Platz zu sparen zB. auch auf den Stack packen koennen.

Beispiel "Bootloader":
Z. 30: xor ax, ax waere kuerzer... (Z. 37 dito)
Z. 41-45: Wieder direkt hintereinander 8Bit-Register mit Konstanten geladen: Boese!

insgesamt ist das nat. ein *sehr* rudimentaerer BL, aber ich gehe mal davon aus, das war beabsichtigt...

Beispiel in 4.5.2:
IMHO wenig sinnvoll, es und ds in BL und Kern direkt hintereinander auf den selben Wert zu setzen. Das im Kern wuerde reichen.

Weiß eigentlich jemand wo dieses copy heutzutage auf der Platte steckt? In win/system32 habe ich es nicht gefunden.

COPY ist als "Funktion" in der cmd.exe integriert. Ist deshalb nur verfügbar in einer Konsole.

Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

hab auf dos einen multitasking aufsatz gecodet, damit konnte ich dann unter dos mehrere programme gleichzeitig laufen lassen (und ein TSR was im hintergrund per timer interrupt 92mal in 5sekunden die tasks gewechselt hat, wenn ich das noch recht im kopf habe.
hab ein game os in flat-memory-mode geschrieben, darin funktionierten die 16bit treiber usw. leider nicht, war damit man auf den ganzen speicher zugreifen konnte ohne XMM usw.
fuer gameboy ein simples OS das mir noch erlaubt hat primitiv den speicher zu begutachten nach nem absturz.
fuer ps3 hab ich nen simples OS erweitert damit ich andere aufloesungen und den zweiten ppu-thread nutzen kann. hab dann noch ein lightweith task system geschrieben.

Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.

Ich hatte einen geschrieben, selbstverständlich ohne cli/sti, habe ihn aber im Tutorial gelöscht, weil es auch so lief (Didaktik ;)).
Reicht es, wenn man den Stack erst im Kernel implementiert? Im BL (bewusst primitiv gehalten, weil ansonsten immer zu GRUB geraten wird) hat der Stack m.E. noch nichts zu suchen.

Die al/ah vs. ax Geschichte macht Sinn (werde ich abändern auf ax), weil wir auf jeden Fall nicht unter 16 bit anfangen müssen.

Welche Speicheradressen würdet ihr verwenden?
0x0000:0x07C0 für den Bootloader ist klar
0x1000:0x0000 für den Kernel?
0x9000:0x0000 für den noch einzurichtenden Stack?

Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.

Ich hatte einen geschrieben, selbstverständlich ohne cli/sti, habe ihn aber im Tutorial gelöscht, weil es auch so lief (Didaktik ;)).
Reicht es, wenn man den Stack erst im Kernel implementiert? Im BL (bewusst primitiv gehalten, weil ansonsten immer zu GRUB geraten wird) hat der Stack m.E. noch nichts zu suchen.

Dafuer, dass er im BL "noch nichts zu suchen hat", machst du aber doch regen Gebrauch davon.
Wenn du es ganz sauber haben willst, kannst du ihn im Kern nochmal an eine ausgekluegeltere Stelle verfrachten.

Das bleibt! Hier geht die Didaktik vor.
Ansonsten danke für die Tipps!
Ich habe alle Helfer bereits "namentlich" im Tutorial erwähnt.

http://www.henkessoft.de/OS_Dev/OS_Dev1.htm