ORANGE-Forum

Hallo
es gibt viel zu entscheiden wenn man ein OS (Operating System oder BS Betriebssystem) entwickelt. Die wichtigste Entscheidung ist die über den Typ des Betriebssystems:

Entweder man hat die Möglichkeit neue Programme direkt zu installieren oder man muss das OS neu kompilieren um neue Programme zu bekommen. Vergleichbar ist dies mit dem Betriebssystem einer Waschmaschine oder DOS bzw. Windows.

Typen:
1. „Fixes Programm“ (Waschmaschine o.ä. „Echtzeit“-OS):
a. Vorteile:
i. Schnell und einfach zu entwickeln
ii. Definiertes Verhalten (Zeitdauer, Echtzeit)
iii. Einfach zu Bedienen
iv. Über Hash überprüfbar (Viren oder Veränderungen)
v. „Keine“ Viren
vi. Kann als Fenster oder Kommandozeile implementiert werden.
b. Nachteile:
i. Individualisierungen nicht einfach
ii. Begrenzter Funktionsumfang

2. „Um eigene Programme erweiterbar“ (single threading):
a. Vorteile:
i. Mit anderen Entwicklern können Programme getauscht werden
ii. …
b. Nachteile:
i. Viren, Deadlocks, Speicherüberläufe,
ii. Nicht nachprüfbarer Speicher auf Gefahren
iii. Ohne Threading läuft nur ein Programm (bis dieses sich selbst beendet und in den Programmlauf des OS zurückkehrt, vlg. „DOS“)

3. „Multithreading“
a. Vorteile:
i. Es können mehrere Programme gleichzeitig gestartet werden
ii. Größte Flexibilität bei der Programmauswahl
b. Nachteile:
i. Threading zu implementieren ist eine große Aufgabe (viel, viel zu tun)
ii. Scheduler und Dispatcher muss implementiert werden, damit die Threads sich abwechseln und kein Thread Daten verliert.
iii. Multi-Stack-Betrieb.
iv. Systemverwaltung ist nötig um Endlosschleifen von Programmen zu beenden.
v. Wenn jemand auf den Monitor zeichnet, dann wird es alle x ein anderes Bild gezeichnet… (Hier muss dann jeder Thread seinen eigenen Video Speicher verwenden -> Systemverwaltung)

Dies ist mal alles was ich so aus Echtzeit-Betriebssystem-Entwicklungsvorlesungen an Vor- und Nachteilen schnell zusammenschreiben kann. Andere Gruppen schreiben von Threading usw. was sie in ihr OS einbauen wollen, da muss ich persönlich sagen, dass wird lange dauern zu entwickeln und zu pflegen.

Mein Vorschlag ist daher ein Typ 1 OS: Es wird ein geschlossenes Programm mit definierten Verhaltensweisen auf welche man sich verlassen kann. Die Eingabe kann dann entweder über „Fenstermenüs“ oder eine Kommandozeile erfolgen. Ein OS mit einer kleinen Menüstruktur wäre hier mein Favorit. Die anderen Typen kann man dann nach und nach Entwickeln wenn man einen Wert darin sieht.

Gibt es an dem Plan zum OS Einwände?

Ich denke Punkt 2, single threading, ist am beste. Mit Punkt 1 lässt sich zu wenig anfangen und mit Punkt 3 brauchen wir eine Ewigkeit, bis es fertig ist und keine Bugs mehr enthält. Das Problem mit den Viren, lässt sich lösen in dem wir am Anfang einfach alle Programme ganz genau "Filetieren", bevor sie als "sicher" eingestuft werden. Allerdings verstehe ich nicht sehr viel vom Programmieren an sich, erst recht nicht von so etwas komplexen wie einem eigenen operating system. Aber wenn du dich an so eine Aufgabe machen würdest, Black, dann wär das echt verdammt super. Dankeschön.

Naja Typ 2 dauert zwar nicht solange, aber da sollten wir schon mehr als 3 Entwickler die Ahnung haben sich gefunden haben um es umzusetzen. Wie viele gibts denn hier noch?

Ich finde es immer noch am besten, eine Linux-Distribution zu nehmen, alle nicht unbedingt nötigen Kernelelemente rauszuschmeissen, alle nicht unbedingt nötigen Programme rauszuschmeissen, und den neuen Kernel und die Übriggebliebenen Programme mit einem DCPU-C-Kompiler neu zu kompilieren, aber das sollten wir als Werbung für ORANGE veröffentlichen, sodass ChaOS einen guten Kokurrenten hat. Man könnte das dann zum Beispiel DCP-Linux nennen.
Oder wir nehmen einfach FreeDOS und kompilieren das für den DCPU (obwohl ich DOS und die Familie (z.B. Windows) eigentlich nicht mag)

Dass können wir auch machen. Nach den FAQ wird es anscheinend bis zu 3 Computer auf dem Raumschiff geben, da kann man auch auf jeden ein eigenes System laufen lassen.

@david23x: kannst du die Ideen umsetzen? Oder gibts da bereits erstellte Versionen zum Testen?

Nein, das ist nur eine Idee, aber das könnte ich schaffen, aber das mit dem Kernel weniger.

Denke, ent weder ST oder davids Vorschlag wären das beste, aber bei ST wär auch wie benannt die Frage an alle: Wer kann das hier eigentlich?

Ich kenne mich ein bisschen mit dem theoretischen bei Betriebssystemen aus, aber Assembler kann ich nicht so gut (will es aber üben), aber spätere Teile des Kernels kann man sich ja auch mit C(++) programmieren

Mir ist gerade aufgefallen, dass Linux zurzeit gar nicht für den DCPU angepasst werden kann, da ihm, für Multithreading wichtige Komponenten wie das MMU (sorgt dafür, dass die Prozesse sich nicht in die Quere kommen) fehlen.
Die einzige Lösung dafür, die mir eingefallen ist, wäre, eine virtuelle Maschine (z.B ein modifiziertes Java) in den Kernel einzubauen oder den Kernel in ihr laufen zu lassen, was aber nicht ganz so schnell ist. Man könnte auch die normale Variante und virtuelle Maschinen vermischen, womit es schneller werden würde.

Hab zwar null praktische und wenig theoretische Erfahrung, aber nen Gedanken für ne erste Richtung:
Im System läuft eine Routine immer und immer wieder durch.
Dabei wir der Reihe nach von jedem laufenden Programm je eine Zeile ausgeführt (eigene OSBefehle wohl nötig), wenn alle Programme behandelt wurden, kommt die nächste Zeile des nächsten Programmes.
Jedes Programm sollte 2 nach jeweiligem index festgelegte konstante Abschnitte im Speicher, einer mit der Liste der Befehle, einer mit einer Reihe jeweils eigener Variablen.
(Reservierte Words).

Ungefähr so funktioniert ein Multi-Thread-OS

Zitat von »Drenius«

Jedes Programm sollte 2 nach jeweiligem index festgelegte konstante Abschnitte im Speicher, einer mit der Liste der Befehle, einer mit einer Reihe jeweils eigener Variablen.
(Reservierte Words).

Aber dafür braucht man irgendeine Hardware, die dafür sorgt, dass das funktioniert. Per Software geht das nicht, da die Programme ja direkt vom Prozessor ausgeführt werden, und die Software darauf nur begrenzt Einfluss nehmen kann. Dieses Teil heißt halt MMU, und sorgt dafür, dass es für einen Prozess aussieht, als hätte er den gesamten RAM zur Verfügung. Die Adressen, auf denen ein Programm lesen oder schrieben will, wandelt er dann, nach Vorgaben des OS, in andere um.
Z.B könnte ein Programm den vom OS Speicherbereich 0x20 bis 0x2F zur Verfügung bekommen. Wenn er dann etwas auf Adresse 0x05 schreiben will, wird das vom MMU in 0x25 umgewandelt. Der Speicherbereich muss nicht zusammenhängen.

Ja, deshalb auch die befehlszeilen in EIGENER OSSPRACHE.

erstes programm zeile eins interpretieren, ausführen.
zweites programm zeile eins interpretieren, ausführen.
drittes programm zeile eins interpretieren, ausführen.
erstes programm zeile zwei interpretieren, ausführen.
zweites programm zeile zwei interpretieren, ausführen.
drittes programm zeile zwei interpretieren, ausführen.
und so weiter ...

er führt nur ein programm aus, das OS, aber das führt die Programme ANNÄHERND gleichzeitig aus, sodass sie prinzipiell wie eins behandelt werden, aber zusammengeschnitten aus allen...
Auseinandergehalten werden sie halt durch verschidene Speicherstellen im Gesamtspeicher...

EDIT: Kann sein, dass der letzte Teil Probleme auffwirft, aber der erste Teil ist nur ne umfunktionierung vom normalen singlethreading.

Das wäre auch meine Idee um trotzdem ein Multithread-OS zu machen. Wird halt ein bisschen langsamer, was beim DCPU-16 echt schlimm ist.

Es steht zu bezweifeln, dass wir fürs erste ein schnelles System brauchen.
Gut ist, was funktioniert...