Nachrichten

241

OS-Design / blubbOS Design

« am: 15. November 2005, 19:38 »

Von der Sprache her:
-> Keine Mehrfachvererbung, dafür gibt es Interfaces, die jede Klasse implementieren kann, die eingentlich nur abstarkte Klassen sind.

Da mit kenne ich micht nicht so gut aus.

-> Kein Operatoroverloading

Ich wollte in dem Sinne auch eine recht undynamische Sprache machen, die nichts der gleichen unterstützt.

-> (Leider) keine unsigned Variablen

Warum nicht? Ich weiß jetzt wirklich nicht warum unsigned nicht benutzt werden sollten/können...

-> Bessere, umfangreichere Standardlib.

Damit sind wahrscheinlich die ganzen API aufrufe gemeint, die nicht vom Programm erzeugbare Funktionen zur verfügung stellen.

-> Es fehlt sicher noch sehr viel, das was hier steht ist mir grad mal so eingefallen.

Hat mir dennoch einen tieferen Einblicke gegeben.

Vom Design her:
-> Wird zu Bytecode kompiliert.

OK, das war klar.

242

OS-Design / blubbOS Design

« am: 15. November 2005, 18:43 »

@SSJ7Gohan:
Vergleiche habe ich bei Arithmetik untergeordnet. Das ist mein momentaner Weg alles auf wenige Grundlagen zu reduzieren. Z. B. in C (C++?) ist der Wert 0=false und 0<>true. Daher bekommen bedingte Sprünge eigentlich nur einen Zahlenwert.

Code: [Auswählen]

2 == 2 ist 1
2 == 3 ist 0
2 <> 2 ist 0
2 <> 3 ist 1

@Legend:
Den einzigen großen Unterschied von C++ und Jave, den ich kenn ist der Verzicht auf direkte Pointer in Java. Was gibt es da sonst noch? Habe von Jave leider keine Ahnung.

243

Das Wiki / Ausgabe 8

« am: 15. November 2005, 17:18 »

Aber mal ehrlich, jeder der nicht ins Forum schaut und das hier gelesen hat, glaubt doch sicher, dass das Magazin, wie viele andere sachen im INet, eingesttelt wurde.

244

OS-Design / blubbOS Design

« am: 15. November 2005, 17:11 »

Sichere Sprache ist meiner Meinung nach eine schlechte Definition. Nur die Ausführung muss halt sicher sein. Denn im Endefekt machst du aus einem Quellcode einer Sprache (sicher oder nicht) eine "Binärdatei", welche aber nicht vor Veränderungen geschützt ist oder halt anders erstellt wurde.
Man könnte als besser "sichere Ausführungsschicht" sagen.

Und wie ruft man diese externen Methoden auf? Über I/O Funktionen der Programmiersprache!
Ich meinte auch nicht die Hardware-I/O sondern Funktionsaufrufe zu externen quellen. Die Module müssen ja auch irgendwie meiteinander und mit dem Kernel kommunizieren. Das Eingabe-Verarbeitung-Ausgabe Prinzip dürfte dir ja bakannt sein.

Und was genau meinst du mit Kontrollfluss?

245

OS-Design / blubbOS Design

« am: 15. November 2005, 16:34 »

Naja was heißt unsichere Sprache? Wenn du es durch deinen eigenen JIT durchlaufen lässt hast du auch die endgültige kontrolle über das Programm.
Ich für meien Teil habe mir vorgenommen NUR mein (noch nicht exestirendes) VBin Format zu benutzen.
Und das Problem von puren x86 Code leigt ganz einfach darin, dass ich nur im Ring 0 arbeiten will, und ich x86 Code erst paranoit überprüfen/modifizieren müsste um die Systemsicherheit zu erhalten.

Zur eigenen Progsprache:
Ich habe noch nichts konkretes in der Hand. Momentan bin ich noch dabei die Grundlagen der Informatik auseinanderzunehmen.
Dabei habe ich schon große Fortschritte gemacht bin jetzt aber bei solchen Sachen wie Platformunabhängigkeit, Template, Datentypen, Reduktionismuss, ... noch stark am grübeln.  :-k

Aber für alle die ihren eigene Sprache schreieben wollen, es geht eigentlich nur um:
Ein-/Ausgabe, Arithmetik (auch Binärlogik und Vergleiche), Verzweigungen und Variablen.

Übrigens: kann mir jemand was über Variablen ohne genaue Datentypen erzählen? Gibt es ja auch bei Net oder Java. Und ich meine nich nur bei Templates.

246

OS-Design / blubbOS Design

« am: 15. November 2005, 15:12 »

Ich bin vom Design her auch auf ein Virtualisiertes OS gekommen. Bzw. dass nur die eigentlichen Grundstrukturen als Binäri vorliegen.
Der Grund dafür war ursprünglich die Nichtbenutzung der Protected Funktionen. Also wenn die eigentlichen Programme selber keine direkten Zugriff auf den Speicher haben, dann kann auch alles im Ring 0 laufen und man erspart sich "teure" Sprünge zwischen den System- und Benutzrebenen.
Der Vorteil bei einem hier eingesetzen JIT ist, dass alle benötigten Module zu einer einheit zusammengeschmolzen werden, also dass man alle Module als Einheit sehen kann und es in der Optimierung keine wirklichen Grenzen zwischen diesen gibt.

Bei mir würden sich Treiber von Diensten und Programmen nur in ihrer Berechtigung für I/O-Schnitstellen (Ports, IRQs, spezifische Speicherbereiche)
 unterscheiden. Also auch dei Treiber werden als Virtualbinäri geschrieben.

Kernel:
Verwaltung von Speicher, I/O-Ports und IRQs

Module mit Hardwarerechten:
Treibermodule

Module ohne Hardwarerechte:
Dienste
Programme

Die grundlegende API, die das OS bereitstellt ist NUR die Verwaltung der Systemresourcen und das Ausführen von Modulen.

Ich würde aber nicht versuchen zu irgendwelchen Standards kompatibel zu sein.

Ein großes Augenmerk habe ich auf die Programmiersprache gerichtet. Ich habe vor eine eigene Sprache zu entwickeln, wobei der Programmierer sich nicht mehr auf die Geschwindigkeitsoptimierung des Quellcodes konzentrieren müssen. Die Sprache soll so strukturierd werden, dass sie mit einem Compiler ohne Probleme optimiert werden kann.

Ist zwar ein bisschen schwieriger, aber ich arbeite dran...

BTW: Diese Abgränzung zwischen einer Kernelbasis(PORTS, IRQs, MEM-Bereiche) und Module könnte der OS-Dev Zene endlich zu Standarformaten für Treiber verhelfen. Man müsste sich nur auf ein Virtualbinärformat einigen. Wie das ganze dann erstellt wird oder wie ein Kernel es interpretiert kann dann der Programmierer entscheiden.

247

OS-Design / memory map vom ersten MB des RAM

« am: 13. November 2005, 10:16 »

Code: [Auswählen]

;      start        end      size  region/exception       description
;          0 -      3FF       400  RAM                    Real-Mode Interrupt Vector Table (IVT)
;        400 -      4FF       100  RAM                    BIOS data area (BDA)
;        500 -    9FBFF     9F700  RAM/free for use       Conventional memory
;-      7C00 -     7DFF       200  RAM                     Operating System BootSector
;      9FC00 -    9FFFF       400  RAM                    Extended BIOS data area (EBDA)
;      A0000 -   100000     60000  various                ROM ARREA (384 KiB)
;     100000 - FEBFFFFF  FEB00000  RAM?/free for use?     Extended memory
;-   1000000 -  10FFFFF    100000  ?                       ISA 15-16MB (only with ISA bus?)
;   FEC00000 - FFFFFFFF   1400000  various                PnP NVRAM?, LAPIC, ...

;Standard usage of ROM ARREA:
;-     A0000 -    BFFFF     20000  video RAM               VGA Mem (128 KiB)
;-  -  A0000 -    AFFFF     10000  video RAM                VGA framebuffer (64 KiB)
;-  -  B0000 -    B7FFF      8000  video RAM                text monochrom  (32 KiB)
;-  -  B8000 -    BFFFF      8000  video RAM                text color      (32 KiB)
;-     C0000 -    C7FFF      8000  ROM                     Video BIOS* (32 KiB is typical size)
;-     F0000 -    FFFFF     10000  ROM                     Motherboard BIOS* (64 KiB is typical size)