Eigenes Betriebssystem schreiben ?

[shareholder]

Hallöle,

Ich würde gerne mal ein eigenes Betriebsystem entwerfen und ich
frage mich, wie ich da rangehen muss.

Mit dem Borland Delphi wird's wohl nix... Oder ? :idea:
Was für Vorkenntnisse muss ich haben etc.

Habt Ihr brauchbar links ?
und ganz besonders, was meint ihr dazu ?
Habt Ihr damit schon erfahrungen gemacht ?

Thanx ! :)

[Mirilin]

:hi:

ähm, . . . warte, . . . vergiss es :mrgreen:

such mal bei google, da findest Du einiges

mfg Tobias

[FackFaze]

:wiejetzt:

@shareholder: Da hat Mirilin leider recht. So einfach geht das leider nicht. Und mit Delphi auch nicht, da Delphi ja auf Windows aufsetzt.
Du musst ja das "Grundgerüst" drumherum bauen, insbesondere die Kommunikation mit der Hardware.
Darüberhinaus muß es ausbaufähig sein, es muß mit deinem "Grundgerüst-System" jede Hardware, Software etc. verwirklicht werden können. Hinzu kommt noch ein effektives Sicherheitssystem.
:arrow: ERGO: Kein Projekt für ein langes Wochenende :roll:
Und alleine wirds eh nix. Außer die Delphi-Praxis-Community hilft mit, Windoofs zu überholen!! :angle2:

[shareholder]

nee, windows wollt ich eh nicht toppen.
mich würde es nur allgem. interessieren, wie
es funktioniert. :)

[moritz]

Hallo

Also, wie oben bereits geschrieben: Vergiss es erstmal.
Du musst ein Assemblerprogramm schreiben, das irgendwie zum Ausführen bringen, mit dem I/O System kommunizieren, Hardware ansprechen, Arbeitsspeicher verwalten.
Ok, sagen wir das hast du und du hast eine Kommandozeile wo man "exit" eingeben kann.
Dann brauchst du erstmal deine eigene Programmiersprache, um es zu Erweitern. Befehle müssen natürlcihe viele unterstütz werden :D

Vergiss es :)

Gruß

[merlin17]

hi,

hatten schon andere die idee:

http://sourceforge.net/projects/pascalos/

http://delphine.sourceforge.net/

und "es gab mal" ein projekt in australien, PETROS,
http://www.petros-project.com/pages/info.htm
ich war mal kurz dabei, aber es ist ein riesenaufwand
und letztendlich kommt nur ein akademischer nutzen raus.
praxisrelevantes ist eher mangelware bei solchen spielprojekten....


:-) thomas

[FackFaze]

:arrow: Das eigentlich Problem ist, dass du am Anfang nur über Assembler programmieren kannst, da die sog. Hochsprachen C, C++, Delphi & Co. ja mehr oder weniger auf Assembler aufbauen.

(1) Du hast zuerst die unterste Ebene ( low-level). Das ist der Prozessor usw. Und die gehen leider nur über Assembler.
(2) "Darüber" benötigst du dann eine Art Schnittstelle, mit deren Hilfe du deine eigenen Sachen programmieren kannst.

Das ist ein mega Mammut Projekt. Falls du der anglo-amerikanischen Sprache mächtig bist, lies dir mal das folgende durch: Writing your own operating system

mFg f@CkfAze

[moritz]

Zitat:

Zitat von FackFaze

:arrow: Das eigentlich Problem ist, dass du am Anfang nur über Assembler programmieren kannst, da die sog. Hochsprachen C, C++, Delphi & Co. ja mehr oder weniger auf Assembler aufbauen.

Ich würde mal ganz sagen :D

Onz

[FackFaze]

KORREKTUR für Onz :wink:

Zitat:

Das riesen Mega-Problem ist, dass alles auf Assembler aufsetzt und kein normaler Mensch mit diesem Wahnsinn klar kommt :-D

[dizzy]

Es gab hier mal einen Riesen-Thread in dem einige Leute ein OS mit Delphi/Pascal schreiben wollten. Ich kann ihn leider net mehr finden, aber wenn man sich das ganze mal durchliest, merkt man sehr schnell, dass man das für "nur so zum Spaß" gehörig knicken kann.

Ohne wirklich tiefgehende Assemblerkenntnisse ist garnichts zu schaffen! Ich hatte mal irgendwo ein Pascal-OS als Source gefunden, und der Pascal-Anteil war so ca. 5%, Rest asm. Und WAS für asm... trotz dessen, das alles haarklein kommentiert war hab ich davon NIX verstanden.

Wenn du mal 5-10 Jahre nichts zu tun hast, ist das sicherlich eine interessante Sache. Aber so aus ner Laune heraus: Nö. ;)



gruss,
dizzy


edit: VERDAMMT BIN ICH LAHM! :mrgreen:

[Skiron]

na ja, also unmöglich ist es sicher nicht
mein systeme-prof hat sich sein eigenes Betriebssystem programmiert. Zwar nur eine art Dos-shell, aber man kann schon mit dateien arbeiten.
Ich schätze mal, dass wenn du das probieren willst, schon einiges draufhaben musst, du musst assembler perfekt beherrschen, und ein hohes Wissen über Kommunikation zwischen Hardware-Hardware und Hardware-Software, du musst dir die busse selbst steuern, dann kommen noch die treiber für die Tastatur (damit du die mal verwenden kannst), dann auch noch den Kernel...
wenn du für lange Zeit nicht weißt was machen, und 50 wände hast, an denen du dir den kopf zerschlagen kannst, :wall: :wall: :wall: :wall: :wall: :wall: :wall: :wall: , kannst dus ja versuchen

[Spurius]

im www.delphi-forum.de gibts auch so ein Project. Ich glaub unter Gemeinschaftsprojekte.
Gruß
Spurius

[Luckie]

Bitte vorher lesen, dann hier weiter posten: http://www.delphi-forum.de/viewtopic.php?t=16747 :mrgreen:

[FackFaze]

@ShareHolder:

Wenn du wirklich so was in der Art vor hast, dann baue dir doch ein "Pseudo-Betriebssystem", welches auf Windows aufbaut.
So ne Art JAVA für Arme :roll:
Baue dir ein Programm, was als "Betriebssystem" fungiert, dafür deine eigene Programmiersprache und daraus dann deine ShareJAWWA Programme. Damit hast sicherlich erst mal genug zu tun.

[dizzy]

@Luckie: Ah Oh, ja das ist der Thread, den ich meinte... Ich hätte schwören können, das der hier war... :gruebel: :wall:

[Luckie]

Nö, sowas haben wir ihr nicht. Obwohl, wenn ich mir diesen Thread so ankucke... :roll:

@shareholder: Wie lange programmierst du schon in Delphi? Und wie sieht es mit deinen ASM Kenntnissen aus?

[tommie-lie]

Immer diese Pessimisten.
Also wenn in einem Betriebssystem nur 5% Hochsprache und 95% Assembler benutzt wird, frage ich mich a) wie weit ist das Betriebssystem geworden? b) wenn es einigermaßen weit ist, wie bekloppt war der Programmierer?
In der Tat kommt man um Assembler nicht herum, mit den entsprechenden Tools und Compilern kriegt man aber schon relativ früh relativ viel in einer Hochsprache geregelt.
Wenn man tatsächlich ein Betriebssystem schreiben will und dies nicht alleine machen will, kann sich zum Beispiel dieser lustigen Truppe anschließen, die aus dem oben genannten Thread aus dem DF hervorgegangen ist.
Wer den Weg lieber alleine Beschreitet, dessen erste Anlaufstelle ist dieser kleine Berater zum Thema " "Operating System" Own ".
Ohne anständiges Buch bringt's natürlich alles nix, eine recht gute aber leicht verständliche (wenn auch ein wenig verwirrende da teilweise nicht ganz korrekte) Einführung in die Programmierung des Real und des Protected Mode bietet das "PC Hardwarebuch", erschienen im Addison-Wesley-Verlag, geschrieben von Hans-Peter Messmer (nein, nicht der mit dem heißen Getränk).

Und um zum Eingangsthema zurückzukehren:
Immer diese Pessimisten.
Und sie haben Recht!
Ohne passendes Equipment und wenigstens grundlegende Assemblerkenntnisse (muss ja nicht optimal sein, hauptsache es läuft) wird da nix raus. Und soll das geliebte Betriebssystem in Eigenarbeit auch noch Multitasking unterstützen, sind entsprechende Kenntnisse über Schedulingalgorithmen und Vermeidung von Deadlocks auch notwendig, schließlich soll ein Bluescreen nicht genauso häufig auftreten wie unter Windows, was es ja schließlich zu bekämpfen gilt.

Ansonsten empfehle ich zur praktischen Ausführung jedem, sich an den POSIX-Standard zu halten, dank vorhandener Software erleichtert man sich eine Menge Arbeit, da man sich weder um die ganzen Daemons, noch um eine funktionierende und zufreidenstellende Shell kümmern muss.

[Leuselator]

Mein Senf:

vor 20 Jahren habe ich mich mit OS-Programmierung beschäftigt. Es war ein CP/M Clone und wir haben unsere eigenen Diskettenformate dort eingebaut (höhere Spurdichte, mehr Sektoren je Spur=größere Kapazität). Das war i8086 wenn ich nicht irre und wir hatten die Sourcecodes des Systems (ASM - versteht sich). Es war viel Arbeit und hat schon damals nur einen vergleichsweise winzigen Ausschnitt des Gesamtsystems betroffen. Allerdings hat es auch das Verständnis für Computer und ihre Funktionsweise enorm verbessert.

Wenn also jemand glaubt, er könne so ein Projekt benutzen, um sein Wissen aufzubessern, so liegt er damit richtig. Er sollte sich dazu irgendeine museumsreife Kiste besorgen (weil damals die Komplexität der Systeme noch erträglich war, verglichen mit der heutiger Systeme) und damit ein wenig herumspielen. Sinnvoll wäre auch ein Betriebssystem als Source (ich meine CP/M wurde irgendwann später veröffentlicht), um nicht von Null anfangen zu müssen. Das ist in etwa so wie als Hobbypilot mit ein paar Freunden ein Modellflugzeug zu bauen - man lernt auch 'ne Menge übers Fliegen dabei.

Ein zeitgemäßes OS mal eben so als Freizeitprojekt zu coden ist zu vergleichen mit dem Vorhaben eines Hobbypiloten, mal eben mit ein paar Kumpels ein weltraumfähiges Spaceshuttle zu bauen. Aber man lernt 'ne Menge übers "auf die Fresse fliegen" dabei.

Gruß

[marvin.maybe]

Hallo,

ich denke nicht, dass man ein OS nur in Assembler programmieren kann. Schätze dass gut 99% von Windows oder Linux in C/C++ geschrieben sind.
Starten kann man sein eigenes OS ja erstmal unter Windows und wenn es dann fertig wäre, könnte man sich weitere Gedanken machen.

Vielleicht macht es Sinn erstmal mit einem kleinen Teil anzufangen: Wie Speicherverwaltung (vielleicht gleich mit virtual memory) oder ein nettes schnelles Dateisystem (B-Baum-basiert und Fragmentierungsfrei).

Meine Empfehlung wäre erstmal etwas Basisliteratur: "Moderne Betriebssysteme" von Andrew S. Tanenbaum, 2002, ISBN: 3827370191

Gruß,
Marvin.

[dizzy]

Was glaubst du ist ein OS?
Es stellt grundlegende Funktionen für den sinnvollen Betrieb eines Personalcomputers bereit. Alles was über die grundlegenden Funktionen hinaus geht sind "Features". Und deine 99% nonAssembler finden sich grösteneils in selbigen - die wiederum zum Großteil als Anwendungen realisiert sind, und somit "eigentlich" nicht mehr fest zum OS gehören. Das war eine Idee von M$ um Fremdanbieter unnötig zu machen.
Um aber erstmal Anwendungen erstellen zu können brauchts halt das "eigenliche" OS. Und ein Compiler IST eine Anwendung. D.h. solange du nicht eine Speicherverwaltung, grundlegende Treiberstruktur, Festplatten und generell Datenträgerverwaltung, Tastatur- und Maussteuerung, BIOS-Schnittstellen, IRQ-Implementierung und so weiter hast, ists einfach Essig mit einer Hochsprache. Bis dahin ist das 100% pures unverfälschtes Assembler, ohne Komfort und Schaumstoff ;).
(Nicht zu vergessen bei Multithreading: Eine Prozessverwaltung, die zu dem möglichst wenig Ticks verbraucht, egal wie viele Prozesse zu verwalten sind. Dann aber bitte auch virtuelle Adressräume, Paging, Swapping und weiss der Teufel was... manches davon wär aber schon wieder sekundär -> mit einer Hochsprache zumindest teilweise lösbar.)

\\edit: Auch ein GUI wie z.B. Windows ist nur ein Feature! Der Kern ist und bleibt asm. Win selber (also die Shell) ist jedoch fast nur C glaub ich.


:gruebel: ich WILL gar kein OS schreiben müssen *g*.


gruss,
dizzy

[mwiesbau]

Wenn du mit Delphi (Pascal) ein eigenes Betriebsystem schreiben willst musst du dir zu erst einen Bootloader schreiben.

Du musst nur deinen Kernel soweit entwickeln um Delphi sourcecode kompilieren und verarbeiten zu können.


Mein tipp für alle die ein eigenes Betriebsystem Programmieren wollen:

nehmt euch ein mini Linux und entwickelt es weiter.



http://web105.essen082.server4free.de/lowlevel/

Das nimmst du und Speicherst es in einem file z.b.: Bootloader.asm
------

org 0x7C00
;--------------------------------------------------------
;Bootloader
;--------------------------------------------------------
start:
cli ; Keine Interrupts verwenden!
mov ax, 0x9000 ; Adresse des Stack speichern
mov ss, ax ; Stackadresse festlegen
mov sp, 0 ; Stackpointer auf 0 setzen
sti ; Jetzt lassen wir wieder Interrupts zu

mov [bootdriv], dl ; Bootlaufwerk aus DL speichern

call load ; Lade Kernel
mov ax, 0x1000 ; 0x1000 ist die Speicheradresse unserer Shell
mov es, ax
mov ds, ax
push ax
mov ax, 0
push ax
retf

bootdriv db 0 ; Das Bootlaufwerk
loadmsg db "Lade ...WieOS 0.09",13,10,0

; Mit dieser Funktion geben wir einen String aus
putstr:
lodsb
or al,al
jz short putstrd
mov ah,0x0E
mov bx,0x0007
int 0x10
jmp putstr
putstrd:
retn

; Mit dieser Funktion laden wir unseren Kernel vom Bootlaufwerk
load:
push ds
mov ax, 0
mov dl, [bootdriv]
int 13h
pop ds
jc load

load1:
mov ax,0x1000
mov es,ax
mov bx, 0
mov ah, 2
mov al, 5
mov cx, 2
mov dx, 0
int 13h
jc load1
mov si,loadmsg
call putstr
retn
times 512-($-$$)-2 db 0
dw 0AA55h

----------------------------------

Wenn du das hast besorgst du dir gleich den NASM (Netwide Asembler)
und machst dir eine Binary daraus --> nasm -f bin -o bootloader.bin bootloader.asm

Als nächstes kommt dein eigener Kernel
--------------------------------------------------------
mov ax, 1000h
mov ds, ax
mov es, ax

start: ; Hier fängt unser eigentliches "Betriebssystem" an
mov si, msg_0 ; Wir zeigen einfach nur einen String an
call schreiben

mov si, msg_1
call schreiben

mov si, msg_2
call schreiben ; "schreiben" gibt den String am Bildschirm aus

call lesen ; "lesen" wartet bis eine Taste gedrückt wurde
jmp reset ; Danach wird die Funktion "reset" aufgerufen

msg_0 db "WieOS 0.09 started...",13,10,0
msg_1 db "Programmed and Developped by hdkiller",10,0
msg_2 db "Press any key to reboot",10,0

schreiben:
lodsb
or al, al
jz short schreiben_d
mov ah, 0x0E
mov bx, 0x0007
int 0x10
jmp schreiben

schreiben_d:
retn

lesen:
mov ah, 0
int 016h
ret

reset:
db 0Eah
dw 0000h
dw 0FFFFh
-----------------------------------------
Wieder Speichern in z.b.: Kernel.asm
und natürlich wieder die binary erzeugen.

jezt Fügst du die beiden binarys zu einem Image zusammen --> copy bootloader.bin+kernel.bin betriebssystem.raw

das ganze jetzt mit rawrite auf diskette schreiben und booten


War doch nicht so schwer oder ??

[tommie-lie]

@dizzy: Mag sein, daß die 99% ein wenig übertrieben sind (60%-80%, wenn Inline-Assembler mitzählt und man nur das zum OS zählt, was wirklich benötigt wird) und daß eine GUI nicht zum OS gehört, aber sämtliche Strukturen kann man in C oder Pascal schreiben. Scheduling z.B. Den Timer programmiert man mit Assembler (sind ein paar Zeilen an INs und OUTs und ein bisschen Eumgeschiebe), den Handler an sich in C oder Pascal. Alles, was z.B. an einem Scheduler in Assembler sein muss, ist das eigentliche Ausführen der Aktion, also Taskstatussegment aktualisieren, coderegister aktualisieren, LDT austauschen, usw. Der eigentliche Algorithmus kann durchaus in C geschrieben sein, und die Algorithmen und Strukturen, die dahinter stecken, sind teilweise viel bequemer in einer Hochsprache geschrieben.
Der benötigte Anteil an Assembler wird meist überschätzt, obwohl man sogar den Videospeicher im RealMode in C ansprechen kann, wenn man einen entsprechenden Compiler hat der 16bit-Code erzeugt.


@mwiesbau: Linux erweitern um ein Betriebssystem zu programmieren? :gruebel:
Ich weiß ja nicht, ob du sowas schonmal gemacht hast, aber bevor ich mich du ein so komplexes System wie das weit vorgeschrittene Linux mache, schreib ich mir eher ein Betriebssystem selbst...
Außerdem ist alles, was man so braucht, schon sehr lange in Linux enthalten. Alles, was sich lohnen würde, wären irgendwelche Spezialtreiber für exotischste Hardware, und da muss man mehr über die Hardware an sich wissen, als über ein Betriebssystem. Dann schon eher DOS 5.0 mit anständigen Treibern, ProtectedMode und 'ner neuen command.com ausstatten, das wäre wesentlich einfacher.
-----
Und warum soll der Kernel den Delphi-Quellcode kompilieren? Wieso meint jeder, zu einem Betriebssystem gehört ein eigener Compiler (kürzlich schonmal gesehen)?
Wenn man den Kernel soweit hat, daß er den PE32-Header interpretieren kann und entsprechend die EXE laden kann, muss man "nur noch" die Laufzeitumgebung aufbauen. Denn selbst wenn man keine API-Aufrufe hat, verbergen sich in der VCL genug davon. Und wie schwierig es ist, die Windows-API-Calls zu reimplementieren, zeigt das WinE-Projekt...
Delphi hat den großen Nachteil, daß es ganz streng an Windows gebunden ist, daher ist Delphi für Betriebssystementwicklung nicht zu gebrauchen. Wer Pascal nehmen will, findet in FreePascal und dem GPC-Frontend zur GCC zwei gute Alternativen.

[dizzy]

Überzeugt - es lässt sich sicher einiges via C oder Pascal lösen. Nur allein schon einen Bootloader zu entwickeln finde ich schon relativ deftig. Grundvoraussetung bleibt aber nach wie vor das in- und auswendige kennen der x86-Specs und der calls an das BIOS.
Wenn man sich genügend damit beschäftigt mag das auch gehen, aber "genügend" ist hier schon nicht mehr sooo wenig :zwinker: .

Als kleines Freizeitprojekt für nebenbei für meinen Geschmack zu dick. Wer allerdings ausreichend Zeit über hat... okay. (Hätt' ich wohl auch gerne... Je mehr ich feststelle, das das nicht so einfach ist, desto mehr bekomm ich Bock drauf :mrgreen: )

Einen Loader oder Kernel(-ansatz) kopieren fände ich alledings nicht wirklich toll. Damit Lerneffekt und Stolz voll zur Geltung kommen können muss man schon bei null anfangen ;) .

[tommie-lie]

Zitat:

Zitat von dizzy

Überzeugt - es lässt sich sicher einiges via C oder Pascal lösen. Nur allein schon einen Bootloader zu entwickeln finde ich schon relativ deftig. Grundvoraussetung bleibt aber nach wie vor das in- und auswendige kennen der x86-Specs und der calls an das BIOS.

In- und Auswendig? Ganz so isses ja nicht. Man sollte vielleicht wissen, was der Unterschied zwischen Protected und RealMode ist, aber in- und auswendig kann keiner die x86-Spezifikationen kennen. Genauso wie die BIOS-funktionen. Es gibt zwar nur 256 mögliche Interrupts, aber die, die das BIOS verwaltet haben beinahe alle Unterfunktionen, und das nicht zu knapp.
Zusammen mit einem guten Hardwarebuch, ein paar Beispielcodes und "Ralf Brown's Interrupt List" ist man für alles gewappnet. Am Anfang schlägt man alles nach, nach einer Woche kennt man die Parameter für die Textausgabe auswendig (leider braucht man sie nach einer Woche auch nicht mehr, wenn man schnell ist...), für die selteneres Befehle steht ja weiterhin die RBIL bereit.

[marvin.maybe]

Hallo,

Zitat:

Zitat von dizzy

Was glaubst du ist ein OS?

Habe mal an der Uni "Betriebssysteme" als Vertiefungsfach gehabt (und dort auch Diplom gemacht) und denke, dass ich eine ungefähre Vorstellung davon habe, was ein OS ist.

Vielleicht versuche ich mal so zu argumentieren: Jeden Algorithmus, den man in Assembler programmieren kann, den kann man auch in einer Hochsprache entwickeln und auch Betriebssysteme bestehen nicht nur aus Treibern, sondern zum großen Teil aus anderen Dingen. Ich gebe Dir Recht, dass man einige Funktionen besser in Assembler programmieren kann (wie vielleicht den Boot Loader).

Nochmal zurück zum Assembler-Anteil an Betriebssystem: Wie groß ist das Betriebssystem Windows? 100 MB 200 MB, keine Ahnung. Wie groß ist der Anteil der Assemblerteile? 1 MB? (Und das ist wohl schon übertrieben).
Werden bei Linux nicht megabyteweise Sourcen mitgeliefert? Sind die in Assembler? Nein. in C/C++.

Zitat:

Zitat von dizzy

Um aber erstmal Anwendungen erstellen zu können brauchts halt das "eigenliche" OS. Und ein Compiler IST eine Anwendung.

Die Sachen gibt es doch schon... oder hast Du im Hinterkopf, die auch programmieren zu wollen?

Zitat:

Zitat von dizzy

D.h. solange du nicht eine Speicherverwaltung, grundlegende Treiberstruktur, Festplatten und generell Datenträgerverwaltung, Tastatur- und Maussteuerung, BIOS-Schnittstellen, IRQ-Implementierung und so weiter hast, ists einfach Essig mit einer Hochsprache.

Ich denke nicht, dass Tastatur oder Maustreiber die grundlegenden Probleme bei der OS Entwicklung sind.
IRQ-Implementierung? Ich hoffe mal, dass nicht mal in Assembler jemand wieder mit dem Unsinn anfängt. Glücklicherweise ist mit ASM32 dieser Quatsch selbst auf x86-Platforms ausgestorben.

Zitat:

Zitat von dizzy

:gruebel: ich WILL gar kein OS schreiben müssen *g*.

Auf ein schickes Filesystem hätte ich fast Lust :-)

Gruß,
Marvin.

[edit=sakura] BB-Code zugelassen. Mfg, sakura[/edit]

[Plague]

Ich habe in Nero 6.0 nun mal gesehen, dass man da eine CD mit Boot-Sektor brennen kann. Nun stellt sich mir dir Frage, ob ich da theoretisch einfach eine *.exe Datei reinkopieren kann und die dann gebootet wird. Wie seht ihr das?
Die Idee ein eigenes kleines Betriebssystem zu schreiben hatte ich auch schon mal, hab sie dann aber wieder verworfen. Interessant wäre es aber schon mal.
Gleichzeitig denke ich aber, dass es theoretisch möglich sein müsste mit Delphi ein Betriebssystem zu schreiben da es ja auch Kylix gibt, das im Prinzip Delphi auf Linux Basis ist und nichts mit Windows zu tun hat.
Mein Lehrer in Info meinte auch mal, dass es möglich sein müsste man aber ein paar umwege gehen müsse.

:coder: Thomas

[dizzy]

Zitat:

Zitat von marvin.maybe

Habe mal an der Uni "Betriebssysteme" als Vertiefungsfach gehabt (und dort auch Diplom gemacht) und denke, dass ich eine ungefähre Vorstellung davon habe, was ein OS ist.

oki :angle2:

Zitat:

Zitat von marvin.maybe

Vielleicht versuche ich mal so zu argumentieren: Jeden Algorithmus, den man in Assembler programmieren kann, den kann man auch in einer Hochsprache entwickeln und auch Betriebssysteme bestehen nicht nur aus Treibern, sondern zum großen Teil aus anderen Dingen. Ich gebe Dir Recht, dass man einige Funktionen besser in Assembler programmieren kann (wie vielleicht den Boot Loader).

Okay, ich ging jetzt davon aus, dass man auf seinem eignen OS auch die weiteren Klamotten entwickelt. Dann wörds wohl echt ekelig...

Zitat:

Zitat von marvin.maybe

Nochmal zurück zum Assembler-Anteil an Betriebssystem: Wie groß ist das Betriebssystem Windows? 100 MB 200 MB, keine Ahnung. Wie groß ist der Anteil der Assemblerteile? 1 MB? (Und das ist wohl schon übertrieben).
Werden bei Linux nicht megabyteweise Sourcen mitgeliefert? Sind die in Assembler? Nein. in C/C++.

s.o.

Zitat:

Zitat von marvin.maybe

Die Sachen gibt es doch schon... oder hast Du im Hinterkopf, die auch programmieren zu wollen?

s.o. :mrgreen:

Zitat:

Zitat von marvin.maybe

Ich denke nicht, dass Tastatur oder Maustreiber die grundlegenden Probleme bei der OS Entwicklung sind.

s.o. ...

Zitat:

Zitat von marvin.maybe

IRQ-Implementierung? Ich hoffe mal, dass nicht mal in Assembler jemand wieder mit dem Unsinn anfängt. Glücklicherweise ist mit ASM32 dieser Quatsch selbst auf x86-Platforms ausgestorben.

wär doch hübsch!? :stupid:

Zitat:

Zitat von marvin.maybe

Auf ein schickes Filesystem hätte ich fast Lust :-)

Na wie gut, dass du nicht größenwahnsinnig bischt :gruebel: :mrgreen:
(Aber wenn, dann mach ich mit! *inputwill*)

gruss,
dizzy

[dizzy]

Zitat:

Zitat von Plague

Gleichzeitig denke ich aber, dass es theoretisch möglich sein müsste mit Delphi ein Betriebssystem zu schreiben [...]
Mein Lehrer in Info meinte auch mal, dass es möglich sein müsste man aber ein paar umwege gehen müsse.

Irgendwo hatte ich mal gelesen, dass der Delphi-Compiler nicht in der Lage dazu ist Binaries zu erstellen, die ohne Win lauffähig sind. Einzig für FreePascal soll es eine Lösung geben, die aber auch alles andere als einfach wäre.

=> OS mit Delphi: Fehlanzeige

[Chewie]

Zitat:

Zitat von Plague

Gleichzeitig denke ich aber, dass es theoretisch möglich sein müsste mit Delphi ein Betriebssystem zu schreiben da es ja auch Kylix gibt, das im Prinzip Delphi auf Linux Basis ist und nichts mit Windows zu tun hat.
Mein Lehrer in Info meinte auch mal, dass es möglich sein müsste man aber ein paar umwege gehen müsse.

:coder: Thomas

Delphi erzeugt 1. nur Dateien im PE-Format (dem Windows-Dateiformat für ausführbare Dateien) und 2. erzeugt teilweise betriebssystemabhängigen Code (kann ich nichts weiter zu sagen, da kenn ich mich nicht aus). Kylix kompiliert wohl Dateien im Linux-Pendant zu PE. Deshlab ist es nicht möglich, mit dem Delphi-Compiler Betriebssysteme zu erzeugen.

[Luckie]

Delphi ruft im Endeffekt nur Windows API's auf und Kylix eben Linux API's. Und wenn der Unterbau des OS nicht da ist, geht gar nichts.

[Plague]

nagut, du hast mich überzeugt. Aber mal kurz und knapp, mit welcher Programmiersprache kann man ein Betriebssystem programmieren?

:gruebel:

[neolithos]

Nicht die Programmiersprache ist entscheidend!

Sondern wie die Binärdateien aussehen!

[w3seek]

du kannst ja gerne mal bei uns vorbeischauen ;) wir haben wohl etwa 0.5% asm, der rest ist Ansi C und ein ganz minimaler Teil noch C++ ;-)

[mwiesbau]

Hallo TommiLi,

wenn du mich wegen meines kürzlich geschriebenen Textes korrigieren möchtest dann muss ich dich doch auch fragen warum du glaubst der kernel müsse ein EXE file lesen können.

Ich würde einmal behaupten für den kernel muss es keine exe sein (siehe linux).


Ich möchte dir deine fähigkeiten in puncto Betriebsystem programmierung nicht abstreiten, jedoch gehört meiner meinung etwas mehr zu einem forumsbeitrag als diverse abküzungen in so stark vereinfachtem text, dass es darin genau so gut um das destillieren von wasser gehen könnte.


Kritisiere mich nicht auf diese art wenn du selbst nicht Perfekt bist.

Danke.

[Pseudemys Nelsoni]

nachdem ich gelernt habe wie man variablen deklariert und ihnen was zuweist, wollte ich auch gleich n OS coden :mrgreen:


naja

[Phoenix]

Also Linus hat mit einem Editor angefangen. Um vom System (damals Minix) unabhängig zu sein hat er begonnen, einen Bootloader und eine komplette Laufzeitumgebung für seinen Editor zu programmieren. Im Prinzip ein OS das für ein einziges Tool programmiert wurde.

Dafür hat er 2 Monate gebraucht, und der Code (ja, ASM) war haarsträubend. Aus reiner Neugier wie es besser ginge wurde daraus dann Stück für Stück der erste Linux-Kernel (Nachzulesen in 'Just for Fun', Linus Torvals, ISBN hab ich leider grad nich bei Hand, aber Amazon sollte da weiterhelfen :) ).

Es geht also, es ist ein riesen-Aufwand, aber man lernt dabei Unmengen über seinen Rechner.

Übrigens: Um seine Sourcen für das neue System auch auf dem laufenden System zu kompilieren (und erst dann ist es wirklich ein OS: wenn es auf sich selber aufbauen kann und von anderen OS's unabhängig ist) musste er freilich einen eigenen Compiler schreiben. Er konnte allerdings viel vom damals vorhanden C-Compiler für Minix benutzen, da er sich auch an den Posix-Standard halten wollte.

[frankg]

Hallo Leute!

Ein interessantes Buch zum Thema OS ist das Buch Operating System Concepts von Silberschatz, Galvin und Gagne. Da ist sogar ein kleines Betriebssystem zum Spielen (heisst glaube ich Nachos) beschrieben, dass man sich aus dem Internet saugen kann und dann einfach mal probieren kann. Ich fand die Beschreibung der einzelnen Bertriebssystem-Teile recht anschaulich und verständlich.

Viele Grüsse

Frank

[Tyrael Y.]

..ihr seid ja alle so negativ eingestellt :?
.. klar kann man ein OS auch alleine schreiben, siehe Linus Torvalds (Linux)
.. zumindest das Grundgerüst - I/O, Speichermanagement, ....

.. am besten nimmt man sich wie der gute Linus ein vorhandenes Betriebssystem, wie es auch Linus gemacht hat (Unix), und benutzt ähnliche vorgehensweisen wie es dieses OS anbietet...

...aber mindestens nen Jahr bist du aber daran...

.. das meiste wurd ja schon in den Beiträgen vor mir schon gesagt und gute Links zu
diesem Thema wurden auch gesetzt...

.. also nicht entmutigen lassen, ran an den Speck ... (sehr gute ASM -Kenntnisse sind Pflicht)

und in einem Jahr stellst du das Grundsystem uns dann mal vor :mrgreen:

..also diese Jahr kein Urlaub und nix sonstiges machen, hast ja keine Zeit dafür :twisted: ...

bis bald

[tommie-lie]

Zitat:

Zitat von mwiesbau

wenn du mich wegen meines kürzlich geschriebenen Textes korrigieren möchtest dann muss ich dich doch auch fragen warum du glaubst der kernel müsse ein EXE file lesen können.

Hmm, hast eigentlich Recht, einen Prozess zu erzeugen reicht theoretisch schon, wenn man den aufrufenden Prozess die Binärdatei einlesen und relozieren lässt. Theoretisch kann man das auch so machen, klappt wunderbar.
Problematisch wird es nur dann, wenn auch andere leute außer der eigentliche Hersteller Programme schreiben sollen, die andere Dateien laden, dann kann nämlich theoretisch jeder sein eigenes Süppchen kochen. Das Laden kann schnell zu eienm Chaos werden, wenn sich nciht jeder exakt an den Standard hält. Deswegen sollte man entweder in den Kernel oder in die Laufzeitbibliothek eine Funktion einbauen, die eine Binärdatei in einem fest definierten Rahmen lädt, ohne daß jeder da selber was rumbasteln kann.

Zitat:

Zitat von mwiesbau

Ich würde einmal behaupten für den kernel muss es keine exe sein (siehe linux).

Habe ich gesagt, daß der Kernel selbst eine EXE sein muss?
Aber im nachhinein: er sollte eine relozierbare Binärdatei sein (ELF, PE32, was auch immer man gerne hätte), damit erspart man sich das Leben ungemein. Der Lader muss natürlich ein Flat Binary ohne jegliche Header sein, immerhin muss er von einem Programm geladen werden, das kleiner als 512 Bytes ist. Der Kernel selbst sollte im Sinne der Zukunftsplanung an beliebige Stellen im Speicher geladen werden können, das ist zwar am Anfang von der Implementierung her schwerer, erleichtert aber späetere Erweiterungen. Genauso sieht es mit den Treibern aus, feste Speicherpositionen limitieren hier die Menge an Treibern und machen spätere Erweitrungen schwieriger.

Zitat:

Zitat von mwiesbau

Ich möchte dir deine fähigkeiten in puncto Betriebsystem programmierung nicht abstreiten, jedoch gehört meiner meinung etwas mehr zu einem forumsbeitrag als diverse abküzungen in so stark vereinfachtem text, dass es darin genau so gut um das destillieren von wasser gehen könnte.

Ich bin mir nicht sicher, ob wie von dem gleichen Beitrag reden :gruebel:
Wo benutze ich Abkürzungen, die nicht allgemeinverständlich sind? IN und OUT sind Intel-Mnemonics, soll ich die erklären? API ist bekannt und wird sogar vom Forum erklärt, GPC ist einfach ein Name, ähnlich wie GCC (jaja, GCC = GNU Compiler Collection, ursprünglich GNU C Compiler -- GPC = GNU Pascal Compiler).

Daß es um das Destillieren von Wasser gehen könnte kann ich auch nicht nachvollziehen.
In dem Teil als Antwort auf dizzy merke ich an, daß Assembler in einem Kernel nicht notwendig und meist auch überflüssig(e Arbeit) ist. Dabei gehe ich einfach mal davon aus, daß Leute, die ein Betriebssystem schreiben wollen, wissen, was eine LDT und eine GDT beim x86er ist und wa die Aufgaben eines Schedulers sind. Ich hoffe daß ich "C" und "Pascal" als Fremdwort anführen darf...
In dem Teil als Antwort auf deinen Beitrag sage ich konkret, daß eine Erweiterung von Linux für einen Anfänger sinnlos da aussichtslos und zu komplex ist, um einen praktischen Nutzen zu haben (klar, komplex ist es nicht, wenn man einen Tastaturtreiber schreibt, aber wieviele tausend Tastaturtreiber für Unixe gibt es schon, die verhältnismäßig eifnach portiert werden können? Praktischer Nutzen wäre gleich Null...). In dem Teil unter dem Strich zähle ich die Probleme auf, die Delphi-Quellcode macht und merke an, daß es unnötig ist, daß ein Betriebssystem sich um die Interpretation eines Quellcodes macht. Interpretation ist (auch wenn Sun das anscheinend anders sieht...) schon seit 2 Jahrzehnten außer Mode und ein JIT-Compiling ist in meinen Augen (auch wenn MS das anscheinend anders sieht) so hilfreich wie ein Kropf.

Zitat:

Zitat von mwiesbau

Kritisiere mich nicht auf diese art wenn du selbst nicht Perfekt bist.

Ich habe nicht behauptet ich sei Perfekt und ich habe nicht nicht herablassend kritisiert. Zugegeben mein Schreibstil ist teilweise sehr zynisch, aber ist nicht herablassend gemeint.
Ich bin für Kritik immer offen, wenn ich sie aber (wie oben) einfach wiederlegen kann, finde ich solche Sätze wie den eben zitierten ("Kritisiere mich nicht...") unverschämt und frech. Sowas kann man meiner Meinung nach sagen, wenn die Diskussion beendet ist und es erwiesen ist, daß ich dich zu unrecht von oben herab behandelt habe, aber nicht so.



@Pheonix: Eigentlich war es ein Terminalemulator, weil ihm das von Minix zu beschränkt war. Zu dem Terminalprogramm kam ein Festplatten- und Dateisystemtreiber hinzu, damit er Dateien von dem Uni-Server runterladen konnte. Irgendwann kam ihm die Idee, daß es ja schon fast ein Betriebssystem sei, wenn er jetzt noch Dateien ausführen kann und eine anständige Speicherverwaltung implementiert, und so hat er sich auf den Weg gemacht, seinen Terminalemulator in einen "GNU-Emacs unter den Terminalemulatoren" (Zitat aus Just for Fun) zu machen und baute alles ein, was ein Terminalemulator gar nicht braucht (ein Spülbecken suche ich bis heute allerdings vergeblich... liegt vermutlich am fehlenden Wasseranschluss in meinem Zimmer, vielleicht sollte ich einen Schlauch vom Bad in den Rechner legen...)


P.S.: ISBN von "Just for Fun": 3-423-36299-5

[Stanlay Hanks]

Ich hab mir jetzt die x Seiten im DF nicht durchgelesen, weil ich nach der ersten schon lachend auf dem Boden gelegen bin :mrgreen:...

Aber ich frage mich immer wieder, wie die Leute darauf kommen: "Ich programmier mir mein eigenes Betriebssystem - kann ja nicht soooo schwer sein" :gruebel:

Das soll jetzt keine Kritik sein, aber wieviele wirklich gute und verbreitete (was sich nicht unbedingt bedingt :mrgreen:) Betriebssysteme gibts denn? Die kann man wahrscheinlich an zwei Händen abzählen, oder? Ich persönlich beschränk mich lieber auf Delphi, sollte ich das mal wirklich perfekt können, schau ich weiter :mrgreen:

Man liest sich, Stanlay :hi: