Nachrichten

1

OS-Design / Statt C++ mit C#?

« am: 01. May 2006, 19:58 »

Ich wäre auch an einer .NET Implementation interessiert, melde dich bei mir, wenn du damit anfängst XD

2

tyndur / repository

« am: 02. April 2006, 19:32 »

Ich würde auch empfehlen, SVN statt CVS zu nehmen, CVS kann keine Verzeichnisse verwalten und die Versionsverwaltung von SVN ist auch besser.

3

tyndur / Ladeprozess

« am: 02. April 2006, 19:30 »

Wäre es nicht besser, den Bootloader/GRUB den OS-Loader laden zu lassen? (Also nicht GRUB direkt den Kernel laden zu lassen?)
Dann könnte der OS-Loader auf den Kernel angepasst sein und nicht kompatibel zu GRUB sein. So könnte man ausserdem jeden beliebigen Bootloader nutzen um LOST zu laden.

4

tyndur / Ein letztes Mal noch...

« am: 01. April 2006, 12:59 »

Ich denke mal, bevor man mit dem Programmieren anfängt, sollte erstmal ein umfassendes Konzept über das gesammte Betriebsystem vorhanden sein.
-> Wie wird der Kernel geladen?
-> Wer schaltet in den PM?
-> Was macht der Kernel?
-> Wie sind Treiber aufgebaut?
-> Wie komunizieren Treiber mit dem Kernel?
-> Wie komunizieren Programme mit dem Kernel?
-> Kernelmodule?
-> IPC?
-> RPC?
-> Memory Management?
-> Prozesse?
-> Threads?
Ich denke, wir sollten verschiedene Konzepte vorschlagen und danach abstimmen, welches wir benutzen.

Ich stelle hier mal mein Kernelkonzept vor, das ich in mein OS einbauen werde. Vieleicht ist es ja auch für LOST interessant.
-> Der Kernel wird von einem Minibootloader geladen, der nur in den PM schaltet, den Kernel an die richtige Stelle mapt usw.
-> Dieser Minibootloader kann selbstständig den Kernel laden oder z.B. von GRUB geladen werden.
-> Der Kernel ist nur für Prozesse, Threads, IPC und Memory zuständig.
-> Treiber sind in einer bytecode-basierten Sprache geschrieben (Java, C# usw.)
-> Ein JIT Compiler (ein Compiler, der den Bytecode wärend der Ausführung zu x86 Code kompiliert) führt diesen Bytecode aus. (Durch einen JIT erreicht man extrem hohe Geschwindigkeiten, die fast denen von C++ entsprechen)
-> Der Bootloader läd den JIT sowie einige Bytecode Module.
-> Alle Programme die in einer bytecode Sprache geschrieben sind laufen in Ring0. Der JIT kann mehrere Programme in ein Pagedirectory kompilieren. Ausserdem werden so aufwendige Syscalls überflüssig.
-> Alle Programme die nicht in einer bytecode basierten Sprache geschrieben sind, laufen in Ring3 und kommunizieren über Systemcalls mit dem Kernel und den Treibern.
-> Der JIT verwaltet die Rechte (Portzugriffe, IRQs usw.) für alle Programme und Treiber.

Da aller Code der in Ring0 läuft (nur der Kernel und der JIT nicht), in einer sicheren Sprache geschrieben ist, kann der Kernel nicht abstürtzen. Ausserdem sind die Treiber und Programme extrem portabel und würden ohne Veränderungen auf anderen Plattformen laufen. Ausserdem kann man auf eine Vielzahl von Javaprogrammen usw. zugreifen und kann sie ohne Veränderung auf den OS laufen lassen.

Ich werde mich erstmal aus der Entwicklung raushalten und abwarten, was bei dem Konzept rauskommt.

5

OS-Design / Hat euer OS einen Compiler?

« am: 02. March 2006, 15:41 »

Schreib den Compiler in einer portablen Sprache, die er selber unterstützt. Dann kannst du ihn mit einem Windows/Linux/was-auch-immer Compiler kompilieren und die EXE danach benutzen, um ihn in dein Format zu kompilieren. Für ein eigenes EXE Format bräuchtest du eigentlich auch nur einen neuen Linker, was viel einfacher ist als ein ganzer Compiler.

6

Offtopic / Kleines Projekt zum Theme Spieleprogrammierung

« am: 25. February 2006, 18:08 »

Das liegt dann daran, dass zusätzliche Libraries mitgelinkt werden. Eine MessageBox wird nicht zu 20kB Code kompiliert.

7

Offtopic / Kleines Projekt zum Theme Spieleprogrammierung

« am: 25. February 2006, 10:51 »

Naja, Assembler ist aber das unportabelste was es gibt.
Ausserdem brauchst du sehr viel länger, ein Assemblerprogramm zu schreiben, als ein C Programm zu schreiben. Die Ausführungsgeschwindigkeit wird nicht sehr stark beeinflusst, heutige Compiler können schon sehr guten Code generieren. Oft benutzte Funktionen können ja immernoch in inline Assembler etc. geschrieben werden. Ausserdem ist Assemblercode nicht so gut zu verstehen wie C Code.

8

Lowlevel-Coding / zwei Assembler-Dateien linken

« am: 24. February 2006, 19:54 »

Wenn du mit ld linkst hast du nix anderes darbei, mit den Windows Libs werden sie nur gelinkt, wenn du gcc benutzt.

9

Lowlevel-Coding / zwei Assembler-Dateien linken

« am: 22. February 2006, 22:15 »

ld -o programm code1.o code2.o
oder (wenn du die c lib benötigst):
gcc -o programm code1.o code2.o

10

Lowlevel-Coding / Pagingproblem bei Sprung auf neue Adresse

« am: 19. February 2006, 19:08 »

Sobald du cr0 setzt, benutzt die CPU Paging um auf den Speicher zuzugreifen. Wenn beim cr0-Setzen die Addresse, auf die EIP zeigt, nicht gemappt ist, gibts natürlich eine Fault, sobald die CPU versucht, die nächste Instruction aus dem Speicher zu lesen.

11

Lowlevel-Coding / Assembler

« am: 18. February 2006, 12:54 »

Ich benutze gedit (Linux/Gnome) oder notepad2 (Windows).

12

Offtopic / Hosen runter! Zeigt eure OS ;)

« am: 15. February 2006, 21:17 »

Bochs hat eine Option, um die richtigen Zeitwerte zu nutzen. (Ich weiß nicht genau wie sie heißt, benutz das Textconfig-Menu)

13

Lowlevel-Coding / erzeugen einer *.lib

« am: 13. February 2006, 16:17 »

Das gleiche wie die Executeable auch (enthällt also Code und Daten, und BSS-Sektionen), nur enthällt die Relocateable (die .obj Datei) auch Informationen über die Symbole (Globale Variablen, Funktionen) und die Relocations (Stellen im Code oder den Daten, wo beim linken eine neue Addresse eingetragen werden muss.)
Der Linker nimmt dann mehrere Relocateables und ersetzt die Speicherstellen mit den richtigen Symbolen.

14

Offtopic / Neues Jahr, neue Website, bessere Website?

« am: 13. February 2006, 13:48 »

Ich habe in meinem Kernel Mehrprozessorsupport (noch nicht vollständig, z.b. habe ich noch keinen Mehrprozessor Scheduler). Grundsätzlich muss man im BIOS Datenbereich nach einer Struktur mit Prozessorinformationen suchen, den lokalen APIC benutzen, um sie zu booten und mit ihnen zu kommunizieren (über IPCs - Inter-Processor Interrupts, verhalten sich wie normale Interrupts). Dann kann man noch den IO APIC nutzen, um IRQs zu ihnen weiterzuleiten.

Informationen gibts darüber in der Intel Multiprocessor Specification, im Intel Manual Nr. 3 und durch Tutorials (z.B. auf osdever.net) und Sourcebeispiele.

15

Offtopic / Neues Jahr, neue Website, bessere Website?

« am: 12. February 2006, 20:17 »

Naja, selbst wenn man das Betriebssystem verschenkt, wird es niemand nutzen, solange keine ordentlichen Programme darauf laufen. (Highperformance Datenbanksysteme, Verschiedene Deamons (Webserver, Mailserver, Server für andere Anwendungen), eine umfangreiche Standardbibliothek für verschiedene Sprachen (C, C++, Java, Python, PHP usw.) bereitsteht, Compiler um diese Programme überhaupt zum laufen zu kriegen (GCC, binutils) usw., Möglichkeiten für Remoteadministration (dazu gehört auch eine Shell))
Ausserdem muss das OS Treiber für die gängige Hardware haben (Netzwerkanbindung, Mehrprozessorsysteme).
Du solltest deine Chancen nicht zu hoch einschätzen, auch nur einen Cent mit dem OS zu verdienen . Selbst wenn alles oben genannte zutrifft, haben Linux und BSD immernoch Vorteile. (Von Windows als Serversystem will ich mal nicht reden ) Dein OS hat eigentlich keine Innovativen Vorteile, die andere OSs nicht haben.

Aber hier gehts ja um die Website und ich komme vom Thema ab.^^

16

Offtopic / Neues Jahr, neue Website, bessere Website?

« am: 12. February 2006, 12:35 »

Naja, ein kommerzielles OS zu entwickeln, was noch nichtmal Netzwerkunterstützung hat, ist eh recht aussichtslos, es wird sich kaum Geld damit verdienen lassen. Das OS ist ja noch nicht sehr weit, da macht das eh keinen Sinn. Deshalb würde ich auch kostenlosen Webspace nutzen, sonst zahlst du ja praktisch umsonst Geld für den Webspace, so viele werden eh nicht (zumindest zum jetztigen Zeitpunkt) an dem OS interessiert sein,

Teilweise sind die englischen Texte grammatikalisch falsch, vieleicht solltest du sie nochmal überarbeiten.

17

OS-Design / Kompilieren von Bedingungen

« am: 11. February 2006, 20:35 »

Habe ich schon, aber mein Problem liegt eher darin, den Code aus dem Parsetree zu erstellen. Der gcc macht das so:

Code: [Auswählen]

cmp eax, 5
je label1
cmp eax, 3
jle label2
cmp eax, 7
jge label2

label2:
; hier steht der code innerhalb des ifs

label1:
; der code nach dem if

18

OS-Design / Kompilieren von Bedingungen

« am: 11. February 2006, 19:13 »

Ich habe folgendes C Statement (i ist eine Integer Variable):

Code: [Auswählen]

if (i == 5 || (i > 3 && i < 7)) { }
Welchen Parsetree sollte ich daraus erstellen? Ich hatte mir sowas gedacht:

Code: [Auswählen]

IF
OR
EQUALS
i
5
AND
GREATER
i
3
LESS
i
7
Was wäre der beste x86 Code, den man daraus erstellen kann? (Angenommen i befindet sich in einem Register)
Ich finde keinen guten Weg, den Parsetree in x86 Code umzuwandeln. Hat jemand eine Idee? :/

19

Lowlevel-Coding / Zeiger auf lokale Variablen

« am: 11. February 2006, 18:29 »

Ja, ich würde auch einen kleinen Bereich für den Kernel reservieren. Es gibt ein Bit in jeder Pagetable, mit dem du Zugriffe von Ring3 Anwendungen sperren kannst. Der Kernel wird dann also in alle Prozesse gemappt, und kann über INTs oder andere Prozessorfunktionen aufgerufen werden. (SYSENTER, SYSCALL, Callgates usw.)

20

Lowlevel-Coding / Zeiger auf lokale Variablen

« am: 11. February 2006, 15:09 »

Alle Segmente auf Basis 0, Limit 0xFFFFFFFF setzen, und Paging für den Speicherschutz benutzen. Das machen alle modernen x86 Betriebssysteme, Windows benutzt glaubich FS oder GS um auf Threadspezifische Daten zuzugreifen.
C ist nicht gut für segmentierte Addressräume geeignet, da es auf Daten auf dem Stack und dem Heap gleich zugreift. Wenn du deinen eignen Compiler nutzt, kannst du dass eventuell lösen, indem du auf alle Daten über ein Segment zugreifst, oder halt mehrere Segmente überlappen lässt, das flache Speichermodell ist aber am einfachsten und wohl auch am schnellsten.