Heute schreiben wir ein Betriebssystem - wer macht mit?
- Ersteller i_hasser
- Erstellt am
Hi
Da ich schon immer recht gerne sehr nah an der Hardware geproggt habe bin ich irgendwann mal auf diese Idee gekommen... und hab irgendwann auch mal aus Spaß damit angefangen
Am Anfang war es nur ein einfacher Bootsektor, der ein typisches "Hello World" ausgegeben hat ohne viel Planung dahinter, dann kamen kleine Ansätze zu einem Realmode OS (ist deutlich einfacher).
Das ist nun inzwischen ein paar Jahre her und ich hab in der Zeit immer mal wieder darüber nachgedacht, und ich denke mir sind auch recht gute Ideen dazu gekommen.
Aber ein 32bit OS allein zu machen ist ein bisschen viel Abgesehen davon kenn ich mich auch net in allen Bereichen aus was den Protected Mode betrifft (bin zb. durch Paging und die LDT noch net komplett durchgestiegen) und man kann ja auch net alles wissen.
Desswegen wollt ich hier einfach mal fragen, ob wer Lust hat mitzumachen. Aber bitte nur wenns auch ernst gemeint ist.
Vorkenntinisse? Naja, also Assembler müsste man schon können, oder sich wenigstens mal angeschaut und nachvollzogen haben.
Wenn Interesse besteht einfach eine Mail schreiben: i#nte#l##_has##ser@g#m##x.net (ohne #)
MfG
Da ich schon immer recht gerne sehr nah an der Hardware geproggt habe bin ich irgendwann mal auf diese Idee gekommen... und hab irgendwann auch mal aus Spaß damit angefangen
Am Anfang war es nur ein einfacher Bootsektor, der ein typisches "Hello World" ausgegeben hat ohne viel Planung dahinter, dann kamen kleine Ansätze zu einem Realmode OS (ist deutlich einfacher).
Das ist nun inzwischen ein paar Jahre her und ich hab in der Zeit immer mal wieder darüber nachgedacht, und ich denke mir sind auch recht gute Ideen dazu gekommen.
Aber ein 32bit OS allein zu machen ist ein bisschen viel
Abgesehen davon kenn ich mich auch net in allen Bereichen aus was den Protected Mode betrifft (bin zb. durch Paging und die LDT noch net komplett durchgestiegen) und man kann ja auch net alles wissen.Desswegen wollt ich hier einfach mal fragen, ob wer Lust hat mitzumachen. Aber bitte nur wenns auch ernst gemeint ist.
Vorkenntinisse? Naja, also Assembler müsste man schon können, oder sich wenigstens mal angeschaut und nachvollzogen haben.
Wenn Interesse besteht einfach eine Mail schreiben: i#nte#l##_has##ser@g#m##x.net (ohne #
)MfG
hört sich interesant an. dazu gleich mal ne frage. ich hab mir überlegt im nächsten symester kurse in Computer Science zu belegen. hab selber aber kein plan wo ich anfangen soll und ich kenn mich auch null mit programieren aus. wie könnte also so eine reienfolge aussehen. also womit anfangen und dann weiter machen. ich hab bereits so ein standard IT kurs (Information Communication Technology) Kurs gemacht. so nen allgemeiner IT Kurs. würde mich aber interessieren mehr programmieren zu können.
ist zwar jetzt etwas OT, aber was solls :
Willst du programmieren lernen oder verstehen?
Ist eine wichtige Frage dabei. Wenn du es nur lernen willst, es gibt genug C/++ Tutorials im Netz.
Das Verstehen, was dabei abläuft etc ist aber finde ich die schönere Sache. Da geht es zwar erstmal relativ Praxisentfernt zur Sache, aber danach weist du, was programmieren bedeutet, was unten drunter passiert etc.
Da solltest du dir erstmal ein bisschen Assembler anschauen. Du musst da nicht Assembler können, sondern das Prinzip verstanden haben. Dazu vielleicht auch noch was über den RealMode, der ist schön einfach und von der Funktionsweise her ist der Weg zum Protected Mode nicht weit.
Nun gehts erstmal zu den einfachen Hochsprachen, zb. wäre da Turbo C (1.0 gibts kostenlos) interessant. Vor allem weil du damit Binärdateien erzeugen kannst, die du später wieder disassemblieren kannst -> so sieht ein Hochsprachenprog in Assembler (also letztendlich für die CPU) aus.
Dann vielleicht ein bisschen was über Betriebssystemarchitektur - DOS ist zwar einfach, bietet aber auch einen guten Einstieg (und mehr brauchste net)
Dann weist du so ungefähr, wie die Dinge funktionieren, was du brauchst etc.
Jetzt geht das eigentliche Programmieren los, dazu zählt objektorientiertes Proggen etc......
Der Vorteil ist, dass du dann auch noch nachvollziehen kannst wie nun zb. deine Klasse die du in C++ erstellt hast in Assembler realisiert wird. Und Zeiger werden dir dann bestimmt keine Probleme bereiten
Der Nachteil ist eben, dass du am Anfang relativ wenig sehen wirst. Aber wenn du ein bisschen über Assembler weist kannst du relativ schnell zb. einen Bootsektor schreiben der eine Meldung ausgibt und solche Sachen, das funktioniert ganz unten drunter eben ohne irgendwelche vorgefertigten Funktionen.
Ansonsten können wir ja auch per Mail weiterquatschen, da kann ich dir noch ein bisschen was dazu erzählen.
:Willst du programmieren lernen oder verstehen?
Ist eine wichtige Frage dabei. Wenn du es nur lernen willst, es gibt genug C/++ Tutorials im Netz.
Das Verstehen, was dabei abläuft etc ist aber finde ich die schönere Sache. Da geht es zwar erstmal relativ Praxisentfernt zur Sache, aber danach weist du, was programmieren bedeutet, was unten drunter passiert etc.
Da solltest du dir erstmal ein bisschen Assembler anschauen. Du musst da nicht Assembler können, sondern das Prinzip verstanden haben. Dazu vielleicht auch noch was über den RealMode, der ist schön einfach und von der Funktionsweise her ist der Weg zum Protected Mode nicht weit.
Nun gehts erstmal zu den einfachen Hochsprachen, zb. wäre da Turbo C (1.0 gibts kostenlos) interessant. Vor allem weil du damit Binärdateien erzeugen kannst, die du später wieder disassemblieren kannst -> so sieht ein Hochsprachenprog in Assembler (also letztendlich für die CPU) aus.
Dann vielleicht ein bisschen was über Betriebssystemarchitektur - DOS ist zwar einfach, bietet aber auch einen guten Einstieg (und mehr brauchste net
)Dann weist du so ungefähr, wie die Dinge funktionieren, was du brauchst etc.
Jetzt geht das eigentliche Programmieren los, dazu zählt objektorientiertes Proggen etc......
Der Vorteil ist, dass du dann auch noch nachvollziehen kannst wie nun zb. deine Klasse die du in C++ erstellt hast in Assembler realisiert wird. Und Zeiger werden dir dann bestimmt keine Probleme bereiten
Der Nachteil ist eben, dass du am Anfang relativ wenig sehen wirst. Aber wenn du ein bisschen über Assembler weist kannst du relativ schnell zb. einen Bootsektor schreiben der eine Meldung ausgibt und solche Sachen, das funktioniert ganz unten drunter eben ohne irgendwelche vorgefertigten Funktionen.
Ansonsten können wir ja auch per Mail weiterquatschen, da kann ich dir noch ein bisschen was dazu erzählen.
Es geht auch ohne Assembler. Ich habe mir zum Beispiel das Programmieren erst mit dem Basic-Dialekt meines Taschenrechners und später auf'm PC mit Visual Basic beigebracht.
Es kommt drauf an was man später mal vorrangig programmieren möchte. Wenn man hauptsächlich Anwendungsprogramme schreiben will, ist die Assembler- und DOS-Geschichte im Grunde Zeitverschwendung. Viel wichtiger ist da, dass man die "Innereien" des jeweiligen Betriebssystems kennt. Geht man mehr Richtung Hardware (Treiberprogrammierung, Betriebssystementwicklung, High-Performance-Sachen wie Videobearbeitung), hast Du natürlich Recht, da ist es doch ganz hilfreich, wenn man Assembler kann und weiß wie die Hardware funktioniert.
Ich habe mir zum Beispiel das Programmieren erst mit dem Basic-Dialekt meines Taschenrechners und später auf'm PC mit Visual Basic beigebracht.Es kommt drauf an was man später mal vorrangig programmieren möchte. Wenn man hauptsächlich Anwendungsprogramme schreiben will, ist die Assembler- und DOS-Geschichte im Grunde Zeitverschwendung. Viel wichtiger ist da, dass man die "Innereien" des jeweiligen Betriebssystems kennt. Geht man mehr Richtung Hardware (Treiberprogrammierung, Betriebssystementwicklung, High-Performance-Sachen wie Videobearbeitung), hast Du natürlich Recht, da ist es doch ganz hilfreich, wenn man Assembler kann und weiß wie die Hardware funktioniert.
super danke...auch wenn das alles noch alles bahnhof fuer mich ist. ich wuerde es auch gerne lernen. womit waere also gut an zu fangen.
hier die moeglichkeiten:
QUOTEPROGRAMMING LOGIC
DATA STRUCTURES WITH C++
DATA STRUCTURES WITH JAVA
VISUAL BASIC .NET PROGRAMMING
Visual Basic .Net
DATABASE PROGRAMMING IN VISUAL BASIC.NET
C# PROGRAMMING
FORTRAN PROGRAMMING
OPERATING SYSTEMS
This course provides a functional understanding of operating systems. Topics include key hardware architecture concepts, computer interfaces, file systems, multiprogramming, resource management, and virtual memory. DOS and UNIX are used to demonstrate operating system internals, commands, and batch/shell programming languages.
C PROGRAMMING
JAVA PROGRAMMING
DATABASE CONCEPTS AND APPLICATIONS
This course provides an introduction to modern database concepts, emphasizing the relational database model. Topics include design methodologies, normalization of tables, referential integrity, SQL, security, and event driven programming. Principles are applied by performing exercises using Microsoft Access.
MICROSOFT SQL SERVER DATABASE
ORACLE PROGRAMMING
und weiter web-programming courses.
einiges kann ich nun schon verstehen, aber ich weiss nicht wie nuetzlich es waere z.b. zuerst java zu lernen oder gleich C. Was meinst du eigentlich mit assembler
projekt hoert sich gut an. das waere etwas fuer die naechsten jahre....
hier die moeglichkeiten:
QUOTEPROGRAMMING LOGIC
DATA STRUCTURES WITH C++
DATA STRUCTURES WITH JAVA
VISUAL BASIC .NET PROGRAMMING
Visual Basic .Net
DATABASE PROGRAMMING IN VISUAL BASIC.NET
C# PROGRAMMING
FORTRAN PROGRAMMING
OPERATING SYSTEMS
This course provides a functional understanding of operating systems. Topics include key hardware architecture concepts, computer interfaces, file systems, multiprogramming, resource management, and virtual memory. DOS and UNIX are used to demonstrate operating system internals, commands, and batch/shell programming languages.
C PROGRAMMING
JAVA PROGRAMMING
DATABASE CONCEPTS AND APPLICATIONS
This course provides an introduction to modern database concepts, emphasizing the relational database model. Topics include design methodologies, normalization of tables, referential integrity, SQL, security, and event driven programming. Principles are applied by performing exercises using Microsoft Access.
MICROSOFT SQL SERVER DATABASE
ORACLE PROGRAMMING
und weiter web-programming courses.
einiges kann ich nun schon verstehen, aber ich weiss nicht wie nuetzlich es waere z.b. zuerst java zu lernen oder gleich C. Was meinst du eigentlich mit assembler
projekt hoert sich gut an. das waere etwas fuer die naechsten jahre....
Da würd ich einfach mal bei Operating Systems reinschauen.
Auch wenn du später Datenbankanwendungen oder Spiele schreiben willst ist es nie schlecht zu wissen was unten drunter abgeht.
Und durch Assembler lernst du, was du eigentlich alles umsetzen kannst - was in Assembler net geht, geht auch in sämtlichen Hochsprachen nicht.
PS Will hier keiner bei einem OS mitmachen?
PPS @sir_max Wenn du privat erstmal ein bisschen anfangen möchtest schau dir mal Dev-C++ an - kostenloser port vom Gnu C Compiler zu Windoofs, da kannst du auch erstmal konsolenanwendungen schreiben bei denen du recht wenig drumherum wissen musst.
Auch wenn du später Datenbankanwendungen oder Spiele schreiben willst ist es nie schlecht zu wissen was unten drunter abgeht.
Und durch Assembler lernst du, was du eigentlich alles umsetzen kannst - was in Assembler net geht, geht auch in sämtlichen Hochsprachen nicht.
PS Will hier keiner bei einem OS mitmachen?
PPS @sir_max Wenn du privat erstmal ein bisschen anfangen möchtest schau dir mal Dev-C++ an - kostenloser port vom Gnu C Compiler zu Windoofs, da kannst du auch erstmal konsolenanwendungen schreiben bei denen du recht wenig drumherum wissen musst.
Zuletzt bearbeitet:
@aths
Klar, und ich habe auch nicht vor großartig Assembler zu nehmen.
Höchstens der Header für den Multiboot-kompatibelen Kernel wird in Assembler gemacht, aber das sind nur ein paar Zeilen - der Rest in C/++.
Allerdings müssen einige Dinge der Speicherverwaltung in Assembler gemacht werden, und ich denke der Speichermanager nutzt auch noch segmentierung (damit wird das zwar theoretisch ein reiner x86 Kernel, aber andererseits gehören Buffer Overflows damit der Vergangenheit an und man kann alles wirklich gut voneinander trennen).
Assembler muss man trotzdem können, zumindest in den Anfangsstadien - sonst versteht man einfach net was unten drunter abläuft. In C++ bekommst du zb. rein garnix von den einzelnen Segmenten mit, aber genau das ist gleich wieder ein komplexes Thema mit dem man sich gleich Anfangs auseinandersetzen muss (-> Speichermanager).
Klar, und ich habe auch nicht vor großartig Assembler zu nehmen.
Höchstens der Header für den Multiboot-kompatibelen Kernel wird in Assembler gemacht, aber das sind nur ein paar Zeilen - der Rest in C/++.
Allerdings müssen einige Dinge der Speicherverwaltung in Assembler gemacht werden, und ich denke der Speichermanager nutzt auch noch segmentierung (damit wird das zwar theoretisch ein reiner x86 Kernel, aber andererseits gehören Buffer Overflows damit der Vergangenheit an und man kann alles wirklich gut voneinander trennen).
Assembler muss man trotzdem können, zumindest in den Anfangsstadien - sonst versteht man einfach net was unten drunter abläuft. In C++ bekommst du zb. rein garnix von den einzelnen Segmenten mit, aber genau das ist gleich wieder ein komplexes Thema mit dem man sich gleich Anfangs auseinandersetzen muss (-> Speichermanager).
Hmmm, verlockend klingt das ganze ja schon. Aber ich habe weder die Zeit noch ausreichende Kenntnisse, um an einem OS zu schreiben. Aber melde Dich später mal, wenn Du jemanden suchst, der für die GUI (ich hoffe, es wird eine geben) so Standardcontrols wie TreeView, TextBox usw. schreibt.
) so Standardcontrols wie TreeView, TextBox usw. schreibt.
Psycho-Dad
Admiral Special
Ich könnte höchstens meine höchst unzulänglichen PERL Kenntnisse anbieten 
. Na Intel_Hasser ein Interessantes Projekt ist es ja und selbst wenn daraus nicht das nächste grosse Super BS wird zum verstehn wie ein Computerfunktioniert ist es bestimmt toll.
Heute bei P3D "Wie schreib ich mir mein eigenes BS"
CU
P-D
. Na Intel_Hasser ein Interessantes Projekt ist es ja und selbst wenn daraus nicht das nächste grosse Super BS wird zum verstehn wie ein Computerfunktioniert ist es bestimmt toll.Heute bei P3D "Wie schreib ich mir mein eigenes BS"
CU
P-D
Na das OS wird erstmal ganz einfach
Das soll erstmal rein:
-> Prozessverwaltung (hier sind mir ein paar wie ich finde wirklich sehr gute Ideen gekommen, das enthält auch gleich sowas wie Treiberverwaltung etc)
-> Speichermanager (bestehend aus so ca. 5 Komponenten)
-> Video Treiber (Textmodus, nix besonderes)
-> Tastaturtreiber
-> eine einfache Konsole
Und damit würde das erstmal halbwegs laufen. Das ganze soll als 100%iger µ-Kernel entstehen, das bedeutet, dass der Kernel komplett aus Modulen besteht, und die Treiberverwaltung (oder wie auch immer Verwaltung, da kommen Treiber, Anwendungen und Dienste rein) hätte einen entscheidenden Vorteil: Nix da mit ein Modul für eine Kernel-Version, da würden alle Module immer laufen - sowas wie eine kernelversion gibt es nicht mehr weil eben der gesamte Kernel eine Sammlung von einzelnen Modulen ist.
Dazu würde die Treiberverwaltung auch noch ein paar andere Vorteile bieten, so könnte man problemlos ein wirklich gutes Multitasking realisieren. Gleichzeitig wären die einzelnen Komponenten wirklich getrennt.
Na mal sehen, ob ich das so auf die Beine bekomme. Bin halt im Protected Mode noch nicht Fit genug, da muss ich noch etwas Lektüre lesen.
Ach ja, übrigens werden alle Prozesse etc. nicht wie bisher üblich in Ringe einsortiert (so ist es zumindest bei OS/2 und Windoofs, bei Linux wird es ähnlich sein) sondern das ist alles in einem sehr verästeltem Baum organisiert.
Das soll erstmal rein:
-> Prozessverwaltung (hier sind mir ein paar wie ich finde wirklich sehr gute Ideen gekommen, das enthält auch gleich sowas wie Treiberverwaltung etc)
-> Speichermanager (bestehend aus so ca. 5 Komponenten)
-> Video Treiber (Textmodus, nix besonderes)
-> Tastaturtreiber
-> eine einfache Konsole
Und damit würde das erstmal halbwegs laufen. Das ganze soll als 100%iger µ-Kernel entstehen, das bedeutet, dass der Kernel komplett aus Modulen besteht, und die Treiberverwaltung (oder wie auch immer Verwaltung, da kommen Treiber, Anwendungen und Dienste rein) hätte einen entscheidenden Vorteil: Nix da mit ein Modul für eine Kernel-Version, da würden alle Module immer laufen - sowas wie eine kernelversion gibt es nicht mehr weil eben der gesamte Kernel eine Sammlung von einzelnen Modulen ist.
Dazu würde die Treiberverwaltung auch noch ein paar andere Vorteile bieten, so könnte man problemlos ein wirklich gutes Multitasking realisieren. Gleichzeitig wären die einzelnen Komponenten wirklich getrennt.
Na mal sehen, ob ich das so auf die Beine bekomme. Bin halt im Protected Mode noch nicht Fit genug, da muss ich noch etwas Lektüre lesen.
Ach ja, übrigens werden alle Prozesse etc. nicht wie bisher üblich in Ringe einsortiert (so ist es zumindest bei OS/2 und Windoofs, bei Linux wird es ähnlich sein) sondern das ist alles in einem sehr verästeltem Baum organisiert.
Zuletzt bearbeitet:
noch ein paar fragen:
wird alles in C/++ geschrieben. also auch treiber?
wie wichtig ist mathematik fürs programieren. ich mach zwar mathe ganz gerne, aber meine stärke ist das nicht. zur zeit bin ich einem finite math kurs. sachen wie wahr/falsch aussagen, linear programming und statistik.
würde es ein unterschied machen, das betriebsystem auf einem z.b windows, mac oder linux OS zu schreiben und aus zu probieren....logischer weise doch nicht
ist ja alles so spannend...kann es gar nicht erwarten bis zum nächsten symester, wenn ich mein (wahrscheinlich) OS und C kurs mache.
wird alles in C/++ geschrieben. also auch treiber?
wie wichtig ist mathematik fürs programieren. ich mach zwar mathe ganz gerne, aber meine stärke ist das nicht. zur zeit bin ich einem finite math kurs. sachen wie wahr/falsch aussagen, linear programming und statistik.
würde es ein unterschied machen, das betriebsystem auf einem z.b windows, mac oder linux OS zu schreiben und aus zu probieren....logischer weise doch nicht
ist ja alles so spannend...kann es gar nicht erwarten bis zum nächsten symester, wenn ich mein (wahrscheinlich) OS und C kurs mache.
Meinst Du generell oder nur bei intel_hasser's OS? Treiber werden meistens in C/C++ geschrieben, das heißt aber nicht, dass es nur mit C/C++ möglich ist.
Mein Informatik-Studium besteht zum größten Teil aus Mathe. Zum Programmieren sehr wichtig sind Mathe und ein gutes Logikverständnis.
Schreiben: Nö, eigentlich nicht. Man programmiert ja jeweils ein fremdes OS - egal ob unter Windows, Linux oder Mac. Da sollte es ziemlich egal sein, was man nimmt. Zum Testen nimmt man wahrscheinlich anfangs eh eine Virtual Machine. Von daher müsste auch beim Testen das Host-OS egal sein.würde es ein unterschied machen, das betriebsystem auf einem z.b windows, mac oder linux OS zu schreiben und aus zu probieren....logischer weise doch nicht
Früher hab ich die OSs mit VMWare emuliert, das ist mir aber ein bisschen zu klobig - jetzt nehm ich Bochs (freeware PC Emulator für viele OSs, da laufen auch so ziemlich alle GastOS).
Letztendlich wird das OS praktisch komplett in eine Hochsprache entstehen. Zur Kommunikation mit den einzelnen Treibern wird es festgelegte Protokolle geben, daher auch die Unabhängigkeit von irgendwelchen Versionen. Der Vorteil ist eben die strikte Abkapselung, man kann hier mit C/++, da mit zb. Pascal, dort mit Java etc programmieren... ich selber werd aber nur C/++ nutzen (wer kommt schon auf die Idee ein OS in Pascal zu schreiben).
Ob man Mathe braucht kommt drauf an, was man programmiert. Aber die Logik darf eben nie fehlen
Ich hab vor einer Weile mit einem Image Editor angefangen (hab ich inzwischen aber auf Eis gelegt, weil ich auf Linux umgestiegen bin, sry@TiKu aber vll mach ich den irgendwann ja mal weiter - das Konzept kannst du von mir aber gerne haben, ist sehr modular aufgebaut), da braucht man so ziemlich 0 Mathe.
Wenn man dagegen irgendwas mit Graphik macht (und sei es nur ein einfacher 2D-Weltraumshooter wie Asteroids) braucht man recht viel Mathe.
Dann gibts da natürlich noch andere Bereiche wo Mathe nicht fehlen sollte.
Also in der Regel braucht man direkt Mathe nicht, aber in nicht seltenen Gebieten kommt man ohne nicht aus.
Letztendlich wird das OS praktisch komplett in eine Hochsprache entstehen. Zur Kommunikation mit den einzelnen Treibern wird es festgelegte Protokolle geben, daher auch die Unabhängigkeit von irgendwelchen Versionen. Der Vorteil ist eben die strikte Abkapselung, man kann hier mit C/++, da mit zb. Pascal, dort mit Java etc programmieren... ich selber werd aber nur C/++ nutzen (wer kommt schon auf die Idee ein OS in Pascal zu schreiben
).Ob man Mathe braucht kommt drauf an, was man programmiert. Aber die Logik darf eben nie fehlen
Ich hab vor einer Weile mit einem Image Editor angefangen (hab ich inzwischen aber auf Eis gelegt, weil ich auf Linux umgestiegen bin, sry@TiKu aber vll mach ich den irgendwann ja mal weiter - das Konzept kannst du von mir aber gerne haben, ist sehr modular aufgebaut), da braucht man so ziemlich 0 Mathe.
Wenn man dagegen irgendwas mit Graphik macht (und sei es nur ein einfacher 2D-Weltraumshooter wie Asteroids) braucht man recht viel Mathe.
Dann gibts da natürlich noch andere Bereiche wo Mathe nicht fehlen sollte.
Also in der Regel braucht man direkt Mathe nicht, aber in nicht seltenen Gebieten kommt man ohne nicht aus.
Chilli999
Cadet
Hi würde mich auch dazu bereit erklären mitzumachen zudem ich im moment seeeehhhrrr viiielll zeit habe nur leider weiss ich auch nicht wo ich anfangen soll da ich mich mit solchen dingen wie programmieren nie befast habe obwohl mir das thema schon seit einigen jahren unterm nagel brennt wo fange ich an währe es sinvoll mit Visual Basic anzufangen?
Kannst ja mal ne pm schicken mit adressen wo man sich schlau machen kann die auch nicht so schwer zu verstehen sind
Jeder fängt mal klein an, ja aber wenns fertig ist dann .........
Kannst ja mal ne pm schicken mit adressen wo man sich schlau machen kann die auch nicht so schwer zu verstehen sind
Jeder fängt mal klein an, ja aber wenns fertig ist dann .........
Sorry, aber ohne Grundkenntnisse mit einem OS anzufangen geht schief. Wenn man nicht wenigstens 3 Jahre sich intensiv mit der Materie Softwareentwicklung auseinandergesetzt hat, braucht man IMHO nicht mit einem OS anfangen. Ein OS ist "etwas" komplizierter als "Hello world!"
Ich glaube, intel_hasser hat sich eher an die "alten Hasen" hier gewendet.
EDIT: Mit VB anzufangen ist prinzipiell sinnvoll. Allerdings wird VB in seiner bisherigen Form nicht mehr weiterentwickelt. Von daher empfehle ich, beizeiten auf C#, C++, Visual Basic .net, Delphi oder Java umzusteigen.
Ich glaube, intel_hasser hat sich eher an die "alten Hasen" hier gewendet.
EDIT: Mit VB anzufangen ist prinzipiell sinnvoll. Allerdings wird VB in seiner bisherigen Form nicht mehr weiterentwickelt. Von daher empfehle ich, beizeiten auf C#, C++, Visual Basic .net, Delphi oder Java umzusteigen.
Zuletzt bearbeitet:
Genau.
Ich überleg jetzt auch schon 3 Jahre ein kleines OS zu schreiben, aber ich programmiere schon viel länger - trotzdem gingen die ersten Versuche vorn Baum. Das Problem ist auch, dass man am Anfang viel zu schnell was sehen will - im Realmode ist das noch halbwegs verzeihlich (immerhin hat es DOS ja auch lange geschafft
), bei einem Protected Mode OS braucht man erst garnet anfangen. Da merkst du dann auch, ob du wirklich ein OS schreiben willst oder ob es nur mal eben interessant klang - wenn ja fängst du immer wieder an darüber nachzudenken, selbst wenn du schon länger nichts mehr direkt programmiert hast. So ist mir auch ein großteil vom Design eingefallen, hier und da mal was aufgeschnappt oder eine Inspiration bekommen und das dann weitergedacht - nur sollte man sich das alles irgendwo aufschreiben, weil man es sonst schnell wieder vergessen hat.ist die frage, was das os können soll. was großes nützliches wird wohl nur im team gehen. spielereien wie 'nen bootsektor a la "das ist MEINE diskette" hab ich auch gemacht, auch probeweise ein os angefangen (funktionierte auch ganz gut), aber da sowas mit nichts kompatibel ist habe ich damit wieder aufgehört. meine, wenn ich dos nachschreibe, um die kompatibilität herzustellen, kann ich auch gleich dos verwenden.
Soll ein komplett modulares OS werden bei dem im Gegensatz zu allen mir bekannten Betriebssystemen die Komminukation aller Komponenten nicht direkt abläuft.
Das hat Vorteile und Nachteile... Vorteile:
Verschiedene Versionen verschiedener Komponenten laufen immer zusammen.
Support für verschiedenste Dinge (zb. USB) kann durch einfaches dazuladen eines Modules realisiert werden
Es wird echtes Multithreading möglich, da jede Anwendung von vornherein aus mehreren Threads besteht.
Es ist viel leichter zu kontrollieren ob eine Komponente zb. auf die Platte zugreift etc - das kann auch unterbunden werden.
Es gibt nicht einen großen Kernel mit einer Versionsnummer sondern sowas Zentrales existiert einfach nicht mehr
Es ließen sich auch Emulationsschichten für Windoofs und Linux Treiber implementieren
Man könnte auch Emulationsschichten für den Realmode implementieren -> Vorteil: Zb. laufen dann Pseudo-Hardware-Raids problemlos ohne passenden Treiber, wo Linux vor nicht allzulanger Zeit zb. noch einfach 2 IDE Kanäle erkannt hat
Die Baumstruktur wäre auch sehr gut für die Verbindung 2er oder mehrerer Rechner geeignet, der Rechner ist auch nur ein Element im Baum und nicht die Wurzel
Man könnte ein völlig anderes (und meiner Meinung nach besseres) Multitasking realisieren
Viel flexibler - möglich wäre auch eine Art Skriptsprache zur Treiberprogrammierung, damit wäre dann zb. ein verschlüsselndes Loopdevice überhauptkein Problem - ohne auch nur einmal einen Compiler zu benutzen
Nachteile:
Langsamer.
Vom Grund her soll das ganze so aufgebaut sein:
Es gibt einen Zentralen Manager für alle Prozesse/Treiber.
Jeder Treiber bekommt zu Kommunikation mit allen anderen Komponenten vom OS nur einige wenige Funktionsadressen vom Manager übergeben. Der Manager sortiert den Prozess in einen Baum ein, weist ihm also eine eindeutige, an der Baumposition festgemachte Nummer zu (bzw. den Pfad dort hin). Also zb. 051 könnte sowas bedeuten: 0 -> Rechner 0, 5 -> Blocktreiber, 1 -> 1. installierter Blocktreiber (zb. Festplattentreiber, vielleicht auch nur ein Loopdevice etc.).
Wenn nun ein Prozess zb. etwas ausgeben will muss er das dem Manager sagen. Dafür fordert der Prozess etwas speziellen Speicher an, schreibt da in einem Binärcode (kein MaschinenCode!) rein was er will und sagt dem Manager zu welchem Prozess im Baum das geschickt werden soll. Der Manager prüft, ob dieser Prozess zugriff auf diesen Dienst haben darf und leitet das Packet zum betreffenden Dienst weiter... von der Sache her wir früher das Telefonieren mit Vermittlungsstelle. Dann erzeugt der Manager eine neue Instanz eines bestimmten Threads vom Empfänger und übergibt dem das Packet. Der interpretiert den Binärcode und tut das was drinnen steht.
Alternativ könnte man auch nicht die Prozesse extra dort eintragen, sondern das nur als Device Tree nehmen. Oder man realisiert beides in diesem Baum.
Man könnte auch für jede Geräteklasse (zb. Blocktreiber) einen Verwaltungstreiber dazunehmen, dem werden dann die einzelnen Module (zb. Festplattentreiber) untergeordnet. Der "Kopftreiber" fasst dann alle diese Module zusammen, oder (was bei einem Konsolentreiber sinnvoll wäre) leitet alle Anfragen an ihn an ein definiertes Standart-Untergrerät weiter.
Der riesige Vorteil besteht darin: Die einzelnen Komponenten sind jetzt vollkommen voneinander getrennt. Wenn ein Programm eine Funktion aufruft wird bisher mit der Ausführung des eigentlichen Programms gestoppt, bzw. führt die Instanz ein anderes Programm aus (mit Instanz meine ich hier einen Task, also praktisch beim MultiTasking einer der Tasks der immer wieder für eine kurze Zeit ausgeführt wird).
Also so:
Programm -> Ruft externe Funktion auf
Externe Funktion arbeitet
Externe Funktion kehrt zurück
Programm arbeitet weiter
Mit dem Modell oben könnte man das deutlich eleganter lösen:
Programm -> Sagt dem Manger was bei welcher Funktion getan werden soll
Manager erzeugt eine neue Instanz und kehrt zum Programm zurück.
(von hier an gibt es 2 Parallel arbeitende Instanzen, 1 und 2)
1: Programm arbeitet weiter, wartet vielleicht auf das Resultat der Funktion... oder macht was völlig anderes
2: Führt in der Zeit die Funktion aus
.
.
.
2: Meldet dem Manager dass er fertig ist
Manager meldet 1, dass 2 fertig ist und beendet Instanz 2
1: Wertet das resultat aus und macht weiter
Da liegt ein großer Vorteil. Nach dem einfachen Prinzip weiter oben kann das eigentliche Programm solange die Funktion arbeitet nix machen - nach dem 2. Prinzip schon. Wenn die Funktion sich irgendwo verheddert und abschmiert ist bei dem 1. Prinzip das gesamte Programm abgestürzt, weil das Programm ja von der selben Instanz ausgeführt wurde wie die Funktion und bei zb. Zugriffsverletzungen die komplette Instanz beendet wird. Bei dem 2. Prinzip bekommt das eigentliche Programm einfach die Meldung vom Manager, dass die Funktion nicht so ganz richtig lief und das Programm arbeitet weiter.
Nochmal was zu den Binärprotokollen: Die müssen dann natürlich für jeden Gerätetyp/klasse festgelegt werden. Die Vorteile sind aber trotzdem finde ich überwiegend, da nicht mehr mit irgendwelchen Funktionszeigern rumgehandelt wird ist sowas dann komplett Versionsunabhängig.
Tja, das fällt mir jetzt dazu noch ein. In den Jahren sind mir auch noch einige Ideen mehr gekommen. So ungefähr könnte ein Prozess aussehen:
-> Dem Empfangsteil. Wenn dieser Prozess/Dienst eine Nachricht empfängt wird eine neue Instanz erzeugt die diesen Code ausführt. Parallel läuft der 2. Teil, nämlich
-> Das eigentliche Programm - kann auch aus mehreren Threads etc. bestehen, kein Prolem. Muss auch nicht immer im Hintergrund laufen, bei einem Treiber der nur auf Anfrage etwas machen muss wäre es sinnlos den alle paar ms auszuführen damit der dann gleich wieder aufhört weil nix zu tun ist.
Noch ein kleiner Nachteil ist, dass 350 Threads wie bei Windoofs nich zu unterbieten sind. Das werden dann eher einige tausend Threads und Instanzen, was das alles eben etwas herunterbremst. Aber in Zeiten von 2GHz CPUs macht das denke ich wenig Unterschied. Dafür ist das ganze wirklich extrem modular.
Das hat Vorteile und Nachteile... Vorteile:
Verschiedene Versionen verschiedener Komponenten laufen immer zusammen.
Support für verschiedenste Dinge (zb. USB) kann durch einfaches dazuladen eines Modules realisiert werden
Es wird echtes Multithreading möglich, da jede Anwendung von vornherein aus mehreren Threads besteht.
Es ist viel leichter zu kontrollieren ob eine Komponente zb. auf die Platte zugreift etc - das kann auch unterbunden werden.
Es gibt nicht einen großen Kernel mit einer Versionsnummer sondern sowas Zentrales existiert einfach nicht mehr
Es ließen sich auch Emulationsschichten für Windoofs und Linux Treiber implementieren
Man könnte auch Emulationsschichten für den Realmode implementieren -> Vorteil: Zb. laufen dann Pseudo-Hardware-Raids problemlos ohne passenden Treiber, wo Linux vor nicht allzulanger Zeit zb. noch einfach 2 IDE Kanäle erkannt hat
Die Baumstruktur wäre auch sehr gut für die Verbindung 2er oder mehrerer Rechner geeignet, der Rechner ist auch nur ein Element im Baum und nicht die Wurzel
Man könnte ein völlig anderes (und meiner Meinung nach besseres) Multitasking realisieren
Viel flexibler - möglich wäre auch eine Art Skriptsprache zur Treiberprogrammierung, damit wäre dann zb. ein verschlüsselndes Loopdevice überhauptkein Problem - ohne auch nur einmal einen Compiler zu benutzen
Nachteile:
Langsamer.
Vom Grund her soll das ganze so aufgebaut sein:
Es gibt einen Zentralen Manager für alle Prozesse/Treiber.
Jeder Treiber bekommt zu Kommunikation mit allen anderen Komponenten vom OS nur einige wenige Funktionsadressen vom Manager übergeben. Der Manager sortiert den Prozess in einen Baum ein, weist ihm also eine eindeutige, an der Baumposition festgemachte Nummer zu (bzw. den Pfad dort hin). Also zb. 051 könnte sowas bedeuten: 0 -> Rechner 0, 5 -> Blocktreiber, 1 -> 1. installierter Blocktreiber (zb. Festplattentreiber, vielleicht auch nur ein Loopdevice etc.).
Wenn nun ein Prozess zb. etwas ausgeben will muss er das dem Manager sagen. Dafür fordert der Prozess etwas speziellen Speicher an, schreibt da in einem Binärcode (kein MaschinenCode!) rein was er will und sagt dem Manager zu welchem Prozess im Baum das geschickt werden soll. Der Manager prüft, ob dieser Prozess zugriff auf diesen Dienst haben darf und leitet das Packet zum betreffenden Dienst weiter... von der Sache her wir früher das Telefonieren mit Vermittlungsstelle. Dann erzeugt der Manager eine neue Instanz eines bestimmten Threads vom Empfänger und übergibt dem das Packet. Der interpretiert den Binärcode und tut das was drinnen steht.
Alternativ könnte man auch nicht die Prozesse extra dort eintragen, sondern das nur als Device Tree nehmen. Oder man realisiert beides in diesem Baum.
Man könnte auch für jede Geräteklasse (zb. Blocktreiber) einen Verwaltungstreiber dazunehmen, dem werden dann die einzelnen Module (zb. Festplattentreiber) untergeordnet. Der "Kopftreiber" fasst dann alle diese Module zusammen, oder (was bei einem Konsolentreiber sinnvoll wäre) leitet alle Anfragen an ihn an ein definiertes Standart-Untergrerät weiter.
Der riesige Vorteil besteht darin: Die einzelnen Komponenten sind jetzt vollkommen voneinander getrennt. Wenn ein Programm eine Funktion aufruft wird bisher mit der Ausführung des eigentlichen Programms gestoppt, bzw. führt die Instanz ein anderes Programm aus (mit Instanz meine ich hier einen Task, also praktisch beim MultiTasking einer der Tasks der immer wieder für eine kurze Zeit ausgeführt wird).
Also so:
Programm -> Ruft externe Funktion auf
Externe Funktion arbeitet
Externe Funktion kehrt zurück
Programm arbeitet weiter
Mit dem Modell oben könnte man das deutlich eleganter lösen:
Programm -> Sagt dem Manger was bei welcher Funktion getan werden soll
Manager erzeugt eine neue Instanz und kehrt zum Programm zurück.
(von hier an gibt es 2 Parallel arbeitende Instanzen, 1 und 2)
1: Programm arbeitet weiter, wartet vielleicht auf das Resultat der Funktion... oder macht was völlig anderes
2: Führt in der Zeit die Funktion aus
.
.
.
2: Meldet dem Manager dass er fertig ist
Manager meldet 1, dass 2 fertig ist und beendet Instanz 2
1: Wertet das resultat aus und macht weiter
Da liegt ein großer Vorteil. Nach dem einfachen Prinzip weiter oben kann das eigentliche Programm solange die Funktion arbeitet nix machen - nach dem 2. Prinzip schon. Wenn die Funktion sich irgendwo verheddert und abschmiert ist bei dem 1. Prinzip das gesamte Programm abgestürzt, weil das Programm ja von der selben Instanz ausgeführt wurde wie die Funktion und bei zb. Zugriffsverletzungen die komplette Instanz beendet wird. Bei dem 2. Prinzip bekommt das eigentliche Programm einfach die Meldung vom Manager, dass die Funktion nicht so ganz richtig lief und das Programm arbeitet weiter.
Nochmal was zu den Binärprotokollen: Die müssen dann natürlich für jeden Gerätetyp/klasse festgelegt werden. Die Vorteile sind aber trotzdem finde ich überwiegend, da nicht mehr mit irgendwelchen Funktionszeigern rumgehandelt wird ist sowas dann komplett Versionsunabhängig.
Tja, das fällt mir jetzt dazu noch ein. In den Jahren sind mir auch noch einige Ideen mehr gekommen. So ungefähr könnte ein Prozess aussehen:
-> Dem Empfangsteil. Wenn dieser Prozess/Dienst eine Nachricht empfängt wird eine neue Instanz erzeugt die diesen Code ausführt. Parallel läuft der 2. Teil, nämlich
-> Das eigentliche Programm - kann auch aus mehreren Threads etc. bestehen, kein Prolem. Muss auch nicht immer im Hintergrund laufen, bei einem Treiber der nur auf Anfrage etwas machen muss wäre es sinnlos den alle paar ms auszuführen damit der dann gleich wieder aufhört weil nix zu tun ist.
Noch ein kleiner Nachteil ist, dass 350 Threads wie bei Windoofs nich zu unterbieten sind. Das werden dann eher einige tausend Threads und Instanzen, was das alles eben etwas herunterbremst. Aber in Zeiten von 2GHz CPUs macht das denke ich wenig Unterschied. Dafür ist das ganze wirklich extrem modular.
alles schön und gut - und wie schaut's mit der sicherheit aus ? damit ich das system nicht unterwandern kann, müßte man verhindern, daß ausgeführte programme deinen "manager" simulieren und prozesse direkt ansprechen. solange niemand das system angreifen will, mag das wunderbar funktionieren, aber es gibt immer noch ein paar zeitgenossen, die dem anwender da stress machen wollen.
übrigens sollte das os auch absturzsicherheit bieten. eine zerstörung der manager-daten z.b. hätte fatale folgen für die systemstabilität - du kannst ja mal spaßenshalber unter dos booten und das erste kb des dos-speichers überschreiben...
übrigens sollte das os auch absturzsicherheit bieten. eine zerstörung der manager-daten z.b. hätte fatale folgen für die systemstabilität - du kannst ja mal spaßenshalber unter dos booten und das erste kb des dos-speichers überschreiben...
Das ist bei jedem OS so - du brauchst nur den Speichermanager zerballern und jedes OS ist übern Jordan (auch Linux/Unix).
Für sowas gibt es außerdem geschützten Speicher, der sowas verhindern soll. Damit kann man auch gleich den Manager schützen, sowie natürlich auch den Speichermanager.
Andere Prozesse direkt aufzurufen geht immer schief - einfach weil ein Prozess niemals eine Funktionsadresse eines anderen Prozesses mitbekommt. Und dank des veränderten MultiThreadings werden einzelne Funktion nicht mehr durch einen Return Befehl beendet, sondern durch einen Befehl an den Manager die betreffende Instanz zu löschen bzw. auszusetzen.
Und wie gesagt, bei 4gb Speicher bekommt man nicht so schnell eine Funktionsadresse raus. Die für den Manager könnte man noch an einer konstanten Position im Speicher, oder bei einem konstanten Segment speicher... oder beim Prozessaufruf neu übergeben.
Gerade auch sicherheitsmäßig bietet dieses Konzept viele Möglichkeiten. Unter Windoofs reicht ein aufruf an die falsche DLL und die PLatte ist leer.
PS Du bekommst DOS aus einem ganz einfachen Grund zum Absturz wenn du etwas in die ersten 1024bytes des Speichers schreibst: Da liegt nach dem booten die Interrupt Vektor Tabelle, und die wird in der Regel auch nicht mehr verschoben. Wenn ein Interrupt aufgerufen wird (sei es durch einen Tastendruck, oder zb. die Systemuhr die 18.2mal pro Sekunde einen Int aufruft) steht in der Interrupt Vektor Tabelle ein Zeiger auf eine zugehörige Position, wo sich eine Funktion die den INT Aufruf verarbeitet befinden sollte.
Geht das ins leere ist Sense mit dem System, im Realmode wird dann einfach quer im Speicher Code ausgeführt, auch wenn da vielleicht eigentlich Daten gelegen haben.
Das Format der Int Vektor Tabelle sieht so aus:
Da wird dann der entsprechende Wert ins Code Segment und den Instruction Pointer geladen - wenn da irgendwas steht, wird auch irgendwas ausgeführt... da im Speicher meißt mehr Daten als code ist meißt irgendwas sinnloses.
Als Schmankerl hat der Realmode ja auch noch eine überlappende Adressierung (1230:0008 ist die selbe Adresse wie 1000:2308) - also da kann CS:IP selbst auf eine Funktion oder auf sinnvollen Code zeigen, wenn nicht genau CS und IP stimmen gehts trotzdem schief (dann kommen meißt lustige Meldungen die einem die gesamte Fülle der ASCII Zeichen eröffnen)
Für sowas gibt es außerdem geschützten Speicher, der sowas verhindern soll. Damit kann man auch gleich den Manager schützen, sowie natürlich auch den Speichermanager.
Andere Prozesse direkt aufzurufen geht immer schief - einfach weil ein Prozess niemals eine Funktionsadresse eines anderen Prozesses mitbekommt. Und dank des veränderten MultiThreadings werden einzelne Funktion nicht mehr durch einen Return Befehl beendet, sondern durch einen Befehl an den Manager die betreffende Instanz zu löschen bzw. auszusetzen.
Und wie gesagt, bei 4gb Speicher bekommt man nicht so schnell eine Funktionsadresse raus. Die für den Manager könnte man noch an einer konstanten Position im Speicher, oder bei einem konstanten Segment speicher... oder beim Prozessaufruf neu übergeben.
Gerade auch sicherheitsmäßig bietet dieses Konzept viele Möglichkeiten. Unter Windoofs reicht ein aufruf an die falsche DLL und die PLatte ist leer.
PS Du bekommst DOS aus einem ganz einfachen Grund zum Absturz wenn du etwas in die ersten 1024bytes des Speichers schreibst: Da liegt nach dem booten die Interrupt Vektor Tabelle, und die wird in der Regel auch nicht mehr verschoben. Wenn ein Interrupt aufgerufen wird (sei es durch einen Tastendruck, oder zb. die Systemuhr die 18.2mal pro Sekunde einen Int aufruft) steht in der Interrupt Vektor Tabelle ein Zeiger auf eine zugehörige Position, wo sich eine Funktion die den INT Aufruf verarbeitet befinden sollte.
Geht das ins leere ist Sense mit dem System, im Realmode wird dann einfach quer im Speicher Code ausgeführt, auch wenn da vielleicht eigentlich Daten gelegen haben.
Das Format der Int Vektor Tabelle sieht so aus:
Code:
struct IntVektor {
16bit Integer CS;
16bit Integer IP;
} IntVecTable[256];Da wird dann der entsprechende Wert ins Code Segment und den Instruction Pointer geladen - wenn da irgendwas steht, wird auch irgendwas ausgeführt... da im Speicher meißt mehr Daten als code ist meißt irgendwas sinnloses.
Als Schmankerl hat der Realmode ja auch noch eine überlappende Adressierung (1230:0008 ist die selbe Adresse wie 1000:2308) - also da kann CS:IP selbst auf eine Funktion oder auf sinnvollen Code zeigen, wenn nicht genau CS und IP stimmen gehts trotzdem schief (dann kommen meißt lustige Meldungen die einem die gesamte Fülle der ASCII Zeichen eröffnen
)hmm... vielleicht hätte ich erwähnen sollen, daß ich jahrelang in assembler programmiert habe ? ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
habe aber immer noch keine ahnung, wie deine multitasking-engine funktionieren soll. wenn ich eine funktion durch ein kommando an den manager aufrufe (analog zu einer dos-funktion), dann muß das programm selber warten (multithreading) oder vom manager angehalten werden, bis das angeforderte ergebnis vorliegt. bei dos kein problem, da die funktion per interrupt return beendet wird, nachdem die ergebnisse vorliegen. aber mir scheint bei dir muß jedes modul oder programm vollständiges multithreading unterstützen...
habe aber immer noch keine ahnung, wie deine multitasking-engine funktionieren soll. wenn ich eine funktion durch ein kommando an den manager aufrufe (analog zu einer dos-funktion), dann muß das programm selber warten (multithreading) oder vom manager angehalten werden, bis das angeforderte ergebnis vorliegt. bei dos kein problem, da die funktion per interrupt return beendet wird, nachdem die ergebnisse vorliegen. aber mir scheint bei dir muß jedes modul oder programm vollständiges multithreading unterstützen...
Klar, das Programm muss dann wirklich Multithreading können. Aber ein Prog kann zb. schon Dateien laden wärend es noch was anderes macht, also im Hintergrund. Ist zwar mehr Programmieraufwand aber ich denke es lohnt sich.
Man kann ja auch noch eine Funktion in den Manager machen, dass der auf Wunsch die Instanz vom Programm anhält bis die Funktion fertig ist -> Vertane Zeit mit Warten strebt gegen 0.
Man kann ja auch noch eine Funktion in den Manager machen, dass der auf Wunsch die Instanz vom Programm anhält bis die Funktion fertig ist -> Vertane Zeit mit Warten strebt gegen 0.
