Forum: PC Hard- und Software Frage zu Betriebssystem - Allgemein


von Samuel J. (capstrovor)


Lesenswert?

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
von Dussel (Gast)


Lesenswert?

Das ist nicht schnell zu erklären, aber lies dich mal in Scheduling und 
Speicherschutz ein.

Und orientier dich besser nicht an UniOS…

von (prx) A. K. (prx)


Lesenswert?

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
von Samuel J. (capstrovor)


Lesenswert?

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!

von Kaj (Gast)


Lesenswert?

Samuel J. schrieb:
> Bedeutet das, dass das Scheduling vom Bootloader übernommen wird?
Nein! Der Scheduler gehört zum OS.

von Helge A. (besupreme)


Lesenswert?

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..??

von (prx) A. K. (prx)


Lesenswert?

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
von Höhlenproll (Gast)


Lesenswert?

Samuel J. schrieb:
> ann lädt das OS dieses Programm aus dem Speicher
> in dem RAM... Und dann?

Springst (jmp) du da hin.

von DirkB (Gast)


Lesenswert?

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.

von Samuel J. (capstrovor)


Lesenswert?

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 ;)

von DirkB (Gast)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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

von Samuel J. (capstrovor)


Lesenswert?

@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
von Samuel J. (capstrovor)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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?

von Samuel J. (capstrovor)


Lesenswert?

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.

von Helge A. (besupreme)


Lesenswert?

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.

von Samuel J. (capstrovor)


Lesenswert?

Ok ich werde mich da etwas umsehen.
Danke!

von (prx) A. K. (prx)


Lesenswert?

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
von Georg (Gast)


Lesenswert?

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

von ja, ja, ein OS schreiben ;) (Gast)


Lesenswert?

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 ..

von Rolf Magnus (Gast)


Lesenswert?

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?

von Daniel A. (daniel-a)


Lesenswert?

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.

von Kim S. (Gast)


Lesenswert?

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

von Samuel J. (capstrovor)


Lesenswert?

@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.

von Fred (Gast)


Lesenswert?

Samuel J. schrieb:
> Hat sich Linus Torwald also gar keinen Compiler für sein Linux
> geschrieben?

Natürlich nicht.

von (prx) A. K. (prx)


Lesenswert?

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
von Samuel J. (capstrovor)


Lesenswert?

Also er hat die Syscalls in Linux einfach gleich wie in Unix genannt und 
Linux so programmiert, dass es das elf-Format versteht?

von Sven (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Dirk B. (dirkb2)


Lesenswert?

Hast du http://prettyos.de/ schon gefunden?
Die sind auch schon fünf Jahre dabei.

von kernel (Gast)


Lesenswert?


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
Noch kein Account? Hier anmelden.