Ich bin gerade dabei, mir mein eigenes kleines Betriebssystem zu programmieren. Als Bootloader nehme ich für den Anfang GRUB. Ich habe aber noch ein paar allgemeine Verständnisfragen: Ich verstehe nicht wirklich, wie ein Userprogramm "auf" einem Betriebssystem laufen soll. Es ist ja so: Irgendwo auf der Festplatte (oder Floppy) ist das OS gespeichert. Dieses wird dann vom Bootloader in den RAM geladen und die Befehle werden nacheinander ausgeführt. Irgendwann kommt dann der Befehl vom User, das Programm "Texteditor" soll gestartet werden. Dann lädt das OS dieses Programm aus dem Speicher in dem RAM... Und dann? Es kann ja nicht sein, dass der Prozessor einfach die ganzen Befehle vom Userprogramm durchläuft und dann wieder zum OS springt. Das geht ja schon nicht, weil die Userprogramme ja Kernelfunktionen verwenden. Wie wird das realisiert? mfg Samuel
:
Bearbeitet durch User
Das ist nicht schnell zu erklären, aber lies dich mal in Scheduling und Speicherschutz ein. Und orientier dich besser nicht an UniOS…
Samuel J. schrieb: > Ich bin gerade dabei, mir mein eigenes kleines Betriebssystem zu > programmieren. Anspruchsvolle Aufgabe, wenn du nicht einmal wirklich weisst, was ein Betriebssystem ist ;-). Du beschreibst kein Betriebssystem, sondern einen Bootloader. Ein Betriebssystem stellt dem Anwendungsprogramm definierte Schnittstellen zur Verfügung. Für Filesystem, Speicherverwaltung, Prozessverwaltung, ... Bei der Frage, wie man das macht, hast du freie Hand. Das hängt dann auch davon ab, ob es virtuelle Speicherverwaltung und Adressraumtrennung gibt, Privilegientrennung etc. Wenn nichts von alledem, dann tut es auch eine Sprungleiste für normale Funktionsaufrufe.
:
Bearbeitet durch User
A. K. schrieb: > Samuel J. schrieb: >> Ich bin gerade dabei, mir mein eigenes kleines Betriebssystem zu >> programmieren. > > Anspruchsvolle Aufgabe, wenn du nicht einmal wirklich weisst, was ein > Betriebssystem ist ;-). Bin gerade erst am Anfang ;) Bedeutet das, dass das Scheduling vom Bootloader übernommen wird? Meinst du mit "Schnittstellen" Syscalls? Danke für die Antwort!
Samuel J. schrieb: > Bedeutet das, dass das Scheduling vom Bootloader übernommen wird? Nein! Der Scheduler gehört zum OS.
Samuel J. schrieb: > Das geht ja schon nicht, weil die Userprogramme ja > Kernelfunktionen verwenden Das kommt drauf an, ob du eine Art "DOS" programmierst oder was multitaskingfähiges. "DOS-Style" ist ein Stapel Interrupts, in den sich auch irgendwelche TSR's einklinken könnten. Programme wie z.B. der Kommandointerpreter rufen gezielt Kernelfunktionen auf. Hübsch einfach läßt sich da drauf die dispatcher-Methode setzen: Dein Kommandointerpreter lädt verschiedene Programme, die bekommen nacheinander den Prozessor. Jedes Programm sorgt dafür, daß es sich selber nach spätestens xx ms in Urlaub schickt. Der Kommandointerpreter startet dann den nächsten Prozeß in seiner Liste. Läßt sich in den meisten Systemen implementieren. Viele SPSen laufen so, in der Art hab ich bereits Z80, 8051-Derivate, Pic programmiert. Bei embedded Systemen ist der Kommandointerpreter reduziert auf ein paar Sprungbefehle in einer Endlosschleife. Das ist alles noch weitweitweit von timeslices, Multiprocessing, geschütztem Speicher, IPC, klickibunti entfernt. Aufgrund der Fragestellung vermute ich allerdings, daß dir eher was einfacheres vorschwebt..??
Helge A. schrieb: > "DOS-Style" ist ein Stapel Interrupts, in den sich auch irgendwelche > TSR's einklinken könnten. Wobei der Begriff "Interrupts" hier etwas irreführend ist. DOS verwendet zwar dafür die gleichnamigen Befehle, weshalb man das Zeug in DOS so nennt, aber eigentlich sind es von der Funktion her Syscalls, keine Interrupts.
:
Bearbeitet durch User
Samuel J. schrieb: > ann lädt das OS dieses Programm aus dem Speicher > in dem RAM... Und dann? Springst (jmp) du da hin.
Samuel J. schrieb: > Und dann? Es kann ja nicht sein, dass der Prozessor > einfach die ganzen Befehle vom Userprogramm durchläuft und dann wieder > zum OS springt. Warum nicht? > Das geht ja schon nicht, weil die Userprogramme ja > Kernelfunktionen verwenden. Kann es doch auch machen. Die Funktionen kehren dann auch zum Userprogramm zurück. Zwischendurch können die aber auch noch was anderes machen. Das Aurufen kann man z.B. über Sprungtabellen oder Interrupts (ist eigentlcih auch nur eine Tabelle) machen. Microsoft hat gerade den Code von DOS 2 veröffentlich. Schau da doch mal rein.
OK! Vielen Danke mal zuerst an Alle. Ja ich wollte zuerst mal was einfacheres machen. ;) Das heißt, das einfachste währe es, wenn ich im Real Mode bleiben würde? Das bedeutet, nach dem der Bootloader seine Arbeit getan hat, läuft das OS seine Anfangsroutinen durch. Dann wartet es auf irgend eine Eingabe bzw. Befehl und führt diesen dann aus, indem es mit jmp (oder call, ist ja jetzt auch egal) dorthin springt und dann die Befehle dieses Programms ausführt. Wenn in dem Programm irgend ein Syscall drin ist, springt er mit "call" an die Funtion im OS, und springt dann mit "ret" wieder zurück. Wenn dann das Programm abgeschlossen ist, wartet das OS auf weitere Instruktionen. Habe ich das so jetzt richtig verstanden? :) Denn so wie das klingt, bleibe ich lieber bei dieser Variante und warte mit dem Multitasking etwas ;)
Samuel J. schrieb: > Denn so wie das klingt, bleibe ich lieber bei dieser Variante und warte > mit dem Multitasking etwas ;) Interrupts (Timer, Tastatur, IO) wirst du aber machen müssen.
Samuel J. schrieb: > Habe ich das so jetzt richtig verstanden? :) Noch nicht ganz, was du beschreibst, ist ein Kommandozeilen-Interpreter - den hat zwar fast jedes OS dabei, aber er gehört eigentlich nicht dazu, z.B. in Unix gibt es zahlreiche verschiedene. Andererseits wäre Windows immer noch Windows, wenn es das heissgeliebte "DOS-Fenster" garnicht gäbe. Das Verständnisproblem dürfte hauptsächlich darin bestehen, dass ein OS zunächst mal garnichts tut, es steht nur bereit was zu tun, wenn ein Anwendungsprogramm irgendwas von ihm will. Streng genommen ist auch die Anzeige der Uhrzeit, ja schon ein blinkender Cursor ein Anwendungsprogramm. Georg
@DirkB: Aber wenn ich im 16-Bit Mode bleibe, dann kann ich ja die BIOS-Interupts verwenden, oder? Dann müsste mein Betriebssystem nur die Interupts "handeln". @Georg: Das bedeutet, dass das OS eigentlich nur Funktionen (also Syscalls) zur verfügung stellt, die dann von den Userprogrammen benutzt werden können?
:
Bearbeitet durch User
Noch eine Frage: Wie kann ich dann Programme für mein OS schreiben? :D Ich weiß, die Frage klingt irgendwie blöd. Müsste ich dann einen eigenen Compiler für C für mein eigenes OS schreiben? Denn 1. ist es irgendwie blöd, wenn ich ein anderes OS brauche, um für mein OS ein Programm zu schreiben. Und 2. kann das ja gar nicht gehen, denn wenn ich es unter Windows compilier, dann ist es ja nur für Windows.
Samuel J. schrieb: > Denn 1. ist es irgendwie blöd, wenn ich ein anderes OS brauche, um für > mein OS ein Programm zu schreiben. Soll bei Mikrocontrollern schon vorgekommen sein. > Und 2. kann das ja gar nicht gehen, denn wenn ich es unter Windows > compilier, dann ist es ja nur für Windows. Öha. Du bist dir ganz sicher, dass du hier richtig bist?
A. K. schrieb: > Samuel J. schrieb: >> Denn 1. ist es irgendwie blöd, wenn ich ein anderes OS brauche, um für >> mein OS ein Programm zu schreiben. > > Soll bei Mikrocontrollern schon vorgekommen sein. Wenn ich z.B. ein OS für AVR entwickle, dann soll es so gut sein, dass ich kein anderes OS brauche, um etwas damit anzufangen. >> Und 2. kann das ja gar nicht gehen, denn wenn ich es unter Windows >> compilier, dann ist es ja nur für Windows. > > Öha. Du bist dir ganz sicher, dass du hier richtig bist? Wieso? Wenn ich nochmals das Beispiel mit dem AVR nehme, dann ist ja der Compiler (z.B. AVR-Studio) für Windows geschrieben. Und zwar so geschrieben, dass er verständlichen Code für den AVR erzeugt.
Du könntest ja zu irgendwas kompatibel bleiben. Zum Beispiel concurrentDOS/386. Irgendwo im Netz müßte man die Quellen finden können, hatte ich schon mal. Oder du hältst dich an eine der aktuelleren Freedos-Varianten, auf denen sollen ja auch Browser und Webserver laufen können. Da sind glaubich bei allen Varianten die Quellen offen zugänglich, und einiges davon baut auf DRDOS/concurrentDOS auf.
Samuel J. schrieb: > Wenn ich z.B. ein OS für AVR entwickle, dann soll es so gut sein, dass > ich kein anderes OS brauche, um etwas damit anzufangen. Mach einen Schritt nach dem anderen. Wer beide Füsse gleichzeitig bewegt fällt auf die Schnauze. Also entwickle erst dein Betriebssystem. Dann die für C übliche Library, ohne die kein normales Programm drauf laufen wird. Und dann kannst du den Compiler dafür entwickeln (zur Not auch portieren). Linus Torwalds hats auch nicht anders gemacht. Hat sein Linux mit Minix als Ausgangssystem gebaut. > Wieso? Wenn ich nochmals das Beispiel mit dem AVR nehme, dann ist ja der > Compiler (z.B. AVR-Studio) für Windows geschrieben. Für Windows übersetzt, nicht für Windows geschrieben. Ist ein klitzekleiner Unterschied.
:
Bearbeitet durch User
Samuel J. schrieb: > Das bedeutet, dass das OS eigentlich nur Funktionen (also Syscalls) zur > verfügung stellt, die dann von den Userprogrammen benutzt werden können? Streng genommen ja. Compiler: für dein eigenes OS musst du natürlich den C-Compiler selbst schreiben. Dabei kannst du dich entscheiden, ob er cross laufen soll, z.B. unter Windows, oder auf deinem System selbst. Dann allerdings hat das was von Münchhausen, denn es wäre schön, den Compiler in C zu schreiben - aber den C-Compiler schreibst du ja gerade erst. Deshalb fängt man oft mit einem Crosscompiler an. Georg
A. K. (prx) schrieb: Samuel J. schrieb: >> Wenn ich z.B. ein OS für AVR entwickle, dann soll es so gut sein, dass >> ich kein anderes OS brauche, um etwas damit anzufangen. > Mach einen Schritt nach dem anderen. Wer beide Füsse gleichzeitig bewegt > fällt auf die Schnauze. Also entwickle erst dein Betriebssystem. Dann > die für C übliche Library, ohne die kein normales Programm drauf laufen > wird. Und dann kannst du den Compiler dafür entwickeln (zur Not auch > portieren). > Linus Torwalds hats auch nicht anders gemacht. Hat sein Linux mit Minix > als Ausgangssystem gebaut. >> Wieso? Wenn ich nochmals das Beispiel mit dem AVR nehme, dann ist ja der >> Compiler (z.B. AVR-Studio) für Windows geschrieben. > Für Windows übersetzt, nicht für Windows geschrieben. Ist ein > klitzekleiner Unterschied. Ob ihm der Unterschied wirklich klar ist bei solchen Sätzen hier? Hier paart sich mal wieder gnadenlose Selbstüberschätzung mit dem Fehlen am heilsamen Zweifel, Dank erschreckendem Nichtwissen und latenter Rechercheunmündigkeit/Unlust beim Jungvolk. Ob ein paar schnelle Forenantworten genügen, sich den Stoff dazu nicht mühevoll in die Birne hauen zu müssen? Das erinnert uns auffällig an den Thread, wo einer aus einer Laune heraus in Windeseile sein eigenes eagle-CAD schreiben wollte. Tannenbaum? ReactOS? Nix gehört, nix wissen. Wieviel Mannjahre Entwicklungszeit stecken eigentlich inzwischen im "XP-Clone" ReactOS? Wo steht das Project jetzt? Bei glaube ich v0.4 .. MS hat die Sourcen ihres DOS 1.0 und 2.0 zum dl für Interessierte freigestellt. Nur mal so nebenbei erwähnt .. Oder man schaut sich mal die sourcen vom CP/M an ..
Samuel J. schrieb: > Das bedeutet, dass das OS eigentlich nur Funktionen (also Syscalls) zur > verfügung stellt, die dann von den Userprogrammen benutzt werden können? Ja, und es muß natürlich auch initial mal ein vorgegebenes Programm starten, also z.B. den Kommandozeilen-Interpreter. ja, ja, ein OS schreiben ;) schrieb: > Tannenbaum? Weihnachten? Oder meinst du den, der mal mit Torwalz gestritten hat?
Samuel J. schrieb: > Noch eine Frage: > > Wie kann ich dann Programme für mein OS schreiben? :D > Ich weiß, die Frage klingt irgendwie blöd. Müsste ich dann einen eigenen > Compiler für C für mein eigenes OS schreiben? Nein, must du nicht. Du must nur darauf achten, dass die Architektur stimmt und keine librarys nutzt, die nicht für dein System kompiliert wurde. Ausserdem muss dein Programm das Format der ausführbaten Datei unterstützen. Linux verwendet das elf format, um ein beispiel zu nennen. Du kanst auch dein eigenes Format erfinden, indem du ein Linkerskript nutzt. Ich empfehle den gcc zu verwenden, den kanst du dann mit gcc für dein OS kompilieren.
Schau Dir doch eifnach mal ein Quelloffenes Dos an, Freedos oder sows (k.a. ob das Quelloffen ist) Da gibt es sicher auch ein Forum zu. Da kannst Du sicher gute Auskünfte erhalten
@Georg: Ok ich verstehe. @ja, ja, ein OS schreiben ;) >Ob ihm der Unterschied wirklich klar ist bei solchen Sätzen hier? Ja, er ist mir klar. >Hier paart sich mal wieder gnadenlose Selbstüberschätzung mit dem Fehlen >am heilsamen Zweifel, Dank erschreckendem Nichtwissen und latenter >Rechercheunmündigkeit/Unlust beim Jungvolk. Und hier trifft mich wieder einer der Standardfloskeln des "Seniors" (nicht böse gemeint). Allerdings finde ich solche Antworten leider ziemlich oft in solchen Foren. Ich frage mich, ob es wirklich "gnadenlose Selbstüberschätzung mit dem Fehlen am heilsamen Zweifel" ist, wenn ich mir seit einem Monat Information aus zig-Stunden Videomaterial, zig-100 Seiten an PDF zusammenflicke. >Ob ein paar schnelle >Forenantworten genügen, sich den Stoff dazu nicht mühevoll in die Birne >hauen zu müssen? Ich frage mich, ob man solche Fragen stellen kann, wenn man sich nicht bereits intensiv mit diesem Thema befasst hat? Ich nutze dieses Forum nur als zusätzliche Informationsquelle, um Lücken zu schließen. Und dann kommen Leute wie du, und sagen ich bin zu faul, mir Informationen im Internet zu besorgen. Es ist aber auch nicht gerade einfach, neben der Schule (mit 40 Wochenstunden) noch intensive Recherche zu betreiben. Dazu nutze ich eh schon (fast) mein ganzes Wochenende. >Tannenbaum? ReactOS? Nix gehört, nix wissen. Wie bereits gesagt, ich habe schon genug recherchiert, um zu wissen wer und was das ist. Obwohl, um zu wissen wer Tannenbaum ist, muss man sich nicht wirklich lange mit Betriebssystemen auseinandersetzen. Aber trotzdem Danke, dass du dir die Mühe gemacht hast, um mir zu antworten. @Daniel A. >Linux verwendet das elf format Hat sich Linus Torwald also gar keinen Compiler für sein Linux geschrieben? Also wenn mein OS das efl-Format "versteht" brauche ich keinen eigenen Compiler? @Kim Schmidt Danke für den Tipp. Werde ich machen.
Samuel J. schrieb: > Hat sich Linus Torwald also gar keinen Compiler für sein Linux > geschrieben? Natürlich nicht.
Samuel J. schrieb: >>Linux verwendet das elf format > Hat sich Linus Torwald also gar keinen Compiler für sein Linux > geschrieben? Er hat sich gewissermassen ein Betriebssysteme für einen bereits vorhandenen Compiler geschrieben. Denn er hat ein Betriebssysteme geschrieben, das die bekannten Unix-Systemaufrufe implementierte und ein bereits vorhandenes Binärformat für Programme verdaute. Damit war die ganze Welt der GNU Programme einsetzbar. NB: Der Tannenbaum gehört in den Wald, der Tanenbaum ins Regal.
:
Bearbeitet durch User
Also er hat die Syscalls in Linux einfach gleich wie in Unix genannt und Linux so programmiert, dass es das elf-Format versteht?
Schau dich mal auf www.lowlevel.eu um. Da gibt es ein Tutorial um einen sehr minimalistischen Kernel zu bauen. Inklusive Speicherverwaltung und Multitasking. Denke wenn du das Tutorial durch hast zwar noch viele Fragen für dich offen sein werden, aber du hast dann ein recht gutes Grundverständnis wie so ein Kernel prinzipiell funktioniert. Außerdem wäre es ganz gut, den Unterschied zwischen den Begriffen "Kernel" und "Betriebssystem" zu kennen. Ein Kernel ist das eigentliche Herz eines Betriebssystem, aber alleine nutzlos. Dinge, wie grafische Oberflächen, Editoren, Compiler,... eben Anwenderprogramme gehören zum Betriebssystem. Wenn es dich wirklich interessiert ein eigenes Betriebssystem zu schreiben, würde ich mich nur auf den Kernel konzentrieren. Sonst artet das sehr schnell in unglaublicher Arbeit aus, denn allein mit einem sehr kleinen lauffähigem Kernel ist man schon seeehr beschäftigt.
Sven schrieb: > Außerdem wäre es ganz gut, den Unterschied zwischen den Begriffen > "Kernel" und "Betriebssystem" zu kennen. Stimmt, das hätte ich besser formulieren sollen. Weshalb Linux etwas genauer auch als GNU/Linux bezeichnet wird. Linus baute den Kernel, nicht das gesamte System.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.