(Fake) OS

[N10B]

Hallöchen,

ich wollt mal hören, was ihr so in die Richtung schon evtl. gemacht habt.

Mit FakeOS meine ich ein OS, das nur so tut, als ob es ein OS wäre, also praktisch z.B. eine Konsole auf der man alles das tun kann,
was ein "normales" OS auch kann, nur dass es eben nicht direkt auf ein System gepackt werden kann und es läuft.
Ist ca. klar was ich mein? ^^ ... könnt mans VM nennen? ^^

ich hab schon von FakeOS mit BASIC oder sonst irgendwelchen "niedrigen" Sprachen gehört.

und mit OS ... wird wohl jeder wissen ... hat jemand von euch sogar schonmal ein lauffähiges OS geschrieben?
Wenn ja, dann verklicker mal bissle was dazu.


Diesen Thread hab ich eröffnet, weil es grad danach aussieht,
dass wir mit einem kleinen Team eine Sprache entwickeln wollen, die OS-Fähig ist und wir dann ein Demo-OS schreiben wollen.
(Wer Lust und Laune hätte, kann sich auch gerne bei mir melden =) )
Wir wollen keine komplett neue Sprache erstellen, sondern einen frisierten BASIC Dialekt entwickeln.

Und da wär ich über Tipps und sonstige Infos froh ;)



lg,
n1ob

 

[Plankton]

Da ich eine sehr gute Fantasie habe, weiß ich glaube ich was du willst:
Man hat so etwas wie die cmd.exe oder eien Shell unter Linux.

Und dort kann man dann halt so sachen wie dir und Co eingeben, korrekt? Nur halt in eurem

frisierten BASIC Dialekt

, korrekt?

mfg Plankton

 

[N10B]

nein ... aber fast ^^

der "schöpfer" hat sich das so gedacht:

wir frisieren die sprache, schreiben einen compiler
(ich weiss, das wird ein riesen hack und ich hab keine ahnung wie wir das anstellen wollen, aber es soll möglich sein ;) )
und diese sprache soll dann so mächtig sein, dass man damit ein OS schreiben kann.
Zumindest sollte das theoretisch möglich sein. Ob irgendein Geek das dann im Endeffekt tut kann mir ja Hupe sein.

Ich hab vorher mit nem Freund telefoniert, der schonmal einen LoopCompiler geschrieben hat
[ (seine HP: www.corpsman.de.vu) <<-- wirklich coole sachen drauf. ]
und der hat mir einigermaßen beigebracht, dass es nicht grad ein Schlotzer ist ^^


ist jetzt klar, was wir da vorhaben?


>> Wer bock hat und einigermaßen was vom Programmieren versteht kann sich immernoch bei mir melden


lg,
n1ob

 

[JumperII]

Ganz ehrlich?

Sprache: Schöpfers Licht
Registers: §0000000000000000 ... §FFFFFFFFFFFFFFFF
Ports: %0000000000000000 ... %FFFFFFFFFFFFFFFF
Operationen: add[type] <target> <target_overflow> <source1> <source2>
             add[type] <target> <target_overflow> <source> <value>
             sub[type] <target> <target_overflow> <source1> <source2>
             sub[type] <target> <target_overflow> <source> <value>
             get[type] <target> <source>
             put[type] <target> <source>
             or[type] <target> <source1> <source2>
             and[type] <target> <source1> <source2>
             not[type] <target> <source>
             rotleft[type] <source> <bits>
             rotright[type] <source> <bits>
             shiftleft[type] <source> <bits>
             shiftright[type] <source> <bits>
             jump <label>
             jump[operator][type] <source1> <source2> <label>
             jump[operator][type] <source> <value> <label>
             int <interruptlevel>
             
Definitionen: label ::= "<name> :"
              type::= { 8, 16, 32, 64}
              operator ::= { EQ, NEQ, LEQ, LTH, GEQ, GTH}

Zur Beschreibung:
§... sind Speicherzellen, in denen man Informationen ablegen kann. Die Speicherzellen sind immer 64 bit breit. Mit dem Type 8 werden die 8 niedrigsten Bits ausgelesen, mit 16 die 16 niedrigsten usw.
%... sind Port Adressen. Sie sind ebenfalls 64 bit breit und können wie die Speicherzellen behandelt werden. Im Unterschied zu den Speicherzellen sind sie aber nicht persistente Speicher. Der Inhalt hängt vom Verhalten des dahinter liegenden Geräts ab und deren Reaktion auf Zeit, Raum und den Aktivitäten von Schöpfers Licht ....
target ist immer das Ziel-Register bzw. der Ziel-Port. Das Ergebnis einer Operation wird dort hinein geschrieben. target_overflow wird bei einem Overflow bei einer Berechnung gesetzt, d.h. wenn das 65'te bit angesprochen wird, wird es mit 1, ansonsten mit 0 besetzt.
source ist natürlich das Quell-Register bzw. der Quell-Port.
Besonders Wichtig: Es gibt eine grundsätzliche Vereinbarung, dass im %0000000000000000 der Zeiger auf den nächsten Befehl steht und in %0000000000000001 der Zeiger auf den Stack. Einen Zugriff auf den Programmcode wird dabei aus der Sprache nicht direkt vorgesehen, der Stackzeiger hingegen zeigt immer auf eine Speicherzelle. %0000000000000002 ist für die Maskierung der Interrupts zuständig, spricht alle Stellen mit dem Bit-Wert 1 dürfen als Interrept-Level ausgeführt werden. Das Bit 0 ist dabei ohne Wirkung und wird immer mit 1 belegt.
Die nächsten 64 stellen enthalten die Positionen, die beim Auslösen des entsprechenden Interrupt-Level angesprungen werden.



Befehlsbeschreibungen:
add -> Addition
sub -> Subtraktion
get -> Schreibe einen Wert in target, welcher aus der Adresse, die wiederrum in dem Register/Port source steht, ausgelesen wird.
put -> das Gegenteil von get, es schreibt in den Register/Port den wert aus source, welcher in target steht.
or -> bitweises ODER
and -> bitweises UND
not -> bitweise Negation
rotleft, rotright -> bitweises rotieren nach links/rechts, wobei das herausgeschobene Bit aus dem Bereich an der anderen Stelle wieder eingeschoben wird (z.B. rotleft 10001 -> 00011)
shiftleft, shiftright -> bitweises verschieben nach links/rechts, wobei leerstellen mit 0 aufgefüllt werden (z.B. shiftleft 1001 -> 00010)
jump -> Springe an Position "label:"; Sonderfälle mit bewertung von Inhalten entsprechend den Vergleichsoperatoren.
int -> Händisches Auslösen eines Interrupts. 0 -> NMI, 1...63 hierarischer INT-Typ

Natürlich enthält diese Sprache bereits redundant ausgelegte Strukturen. So könnte man natürlich schon mal alle sub-Befehle entfernen. Auch die Shift-Befehle sind anders realisierbar. Und die Vergleichsoperatoren könnte man natürlich auch auf EQ, LTH, GTH reduzieren .... theoretisch könnte man sogar auf eines von LTH und GTH verzichten....

Gruß,
Jumper, the II.

/EDIT:
Wir sind schon nahe am RISK-Code dran .... und auf RISK laufen OS ... ergo auch mit diesem hier ....

/EDIT2:
Ups .... jetzt habe ich das Interrupt vergessen *grummel*

 

[N10B]

heisst das jetzt, du willst mitmachen jumper?
xD

ganz ehrlich, ich kann mit dem Schöpfer seinem Licht wenig anfangen ... ist das eine Sprache, die du gebastelt hast?


lg,
n1ob

 

[byspeed]

Du willst ein OS schreiben? ok!
Hast du dir schonmal die Bauweise eines PCs angeschaut?
1. Wie willst du die Ports ansteuern, also die I/O Ports, USB, MIDI, usw.?

2.Welche Angriffspunkte im BIOS (welches überhaupt? Auch selber eins schrieben? ) hast du?

3.Compiler kann in C++, C oder C# geschrieben werden. Da lerne ich mich grad rein!

4. An was soll die Sprache orientiert sein? "schreibe dein eigenes OS mit FRBASIC!", oder was?

5.WIll hier jemand einen PC zum rumexperimentieren stellen, der mit Ami BIOS, und AwardBIOS läuft? ->siehe Frage 2!

6.Wenn diese Fragen geklärt sind, bin ich dabei!

7.Google mal nach FDOS und BASIC++!

Gruß byspeed
<EDIT>Wenn ich mitmache, dann wird die Sprahe so ausgelegt sein, dass eine Richtige Dokumentation herkommt und dass man damit nNUR sein eigenes OS schreiben kann!</EDIT>

 

[Plankton]

Fassen wir zusammen:
a) es klingt verdammt freakig und abgedreht
b) es wird nicht einfach - nicht zu schaffen
c) ich hab keine ahnung von Basic
-> Ich bin dabei Leute;ugl

Allerdings müssen byspeeds Fragen beantwortet sein;)

mfg Plankton

 

[JumperII]

heisst das jetzt, du willst mitmachen jumper?
xD

ganz ehrlich, ich kann mit dem Schöpfer seinem Licht wenig anfangen ... ist das eine Sprache, die du gebastelt hast?


lg,
n1ob

*lol* Wenn ich mal wieder etwas Zeit habe, schreibe ich mir mal einen Compiler und vielleicht auch einen Linker gegen ein bestehendes Betriebssystem. Aber definitiv nicht gegen eine Maschine ....

a) Nein, ich mache nicht bei Euch mit .... Ich will Euch einfach nicht entmutigen :lol:
b) Wie willst Du denn Betriebssysteme programmieren? Ein BS ist immer mit einigen Komponenten nahe an der Hardware .... da helfen nicht einmal C/C++ geschweige denn C# .... das muss z.Tl. ganz nahe auf Assembler Niveau oder tiefer heruntergebrochen werden. Und diese "Schöpfung" geht so tief.

Gruß,
Jumper, the II.

 

[Plankton]

JumperII, er wollte doch quasi ein VM-Artiges Teil bauen.
Also ein OS im OS, so hab ich es aus dem ersten Post gelesen. Im zweiten widerspricht er sich aber grad;)

Was is dnen nu Sache?

mfg Plankton

 

[N10B]

Also wie gesagt, ich bin nicht der "Schöpfer" dieses Vorhabens, ich fände es selber nur sehr geil, wenn etwas draus werden würde.

Lasst mir eure ICQ Nummern da bzw. schreibt mich an. Dann gibts soviele Infos, wie ich habe.

Byspeed ... nein ... ^^ wir wollen einen Compiler schreiben, mit dessen Sprache man dann ein OS coden kann. D.H. man muss dem "Endverbraucher" nur die Werkzeuge in die Hände legen alles zu können, was benötigt wird.
Du wirst dir sicher im Klaren sein, dass das kein Windows oder Linux wird, deßhalb müssen wir uns ERSTMAL über nix wie USB / MIDI o.Ä kümmern.

Wenn ihr drei noch dabei wärt, wären wir mindestens 8.


lg,
n1ob.

Plankton - die Einstellung gefällt mir ;)

 

[JumperII]

JumperII, er wollte doch quasi ein VM-Artiges Teil bauen.
Also ein OS im OS, so hab ich es aus dem ersten Post gelesen. Im zweiten widerspricht er sich aber grad;)

Jo und? Der Sprache ist das egal, ob echt oder unecht. Wenn er ein OS schreiben will, muss er so tief rein, wie immer die virtuelle oder physische Maschine aussieht. Was anderes ist, wenn er ein Framework entwickeln will, in der Standard-Funktionen umgesetzt sind ... z.b. als Alternative zur Verwendung von glib, bzw. etwas tiefer die Verwaltung von Programmen im ELF- oder Microsoft-Exec-Format, ohne dass er unmittelbar die Betriebssysteme ausschließt. In diesem Fall wird es einfacher, Hochsprachen zu verwenden. Wichtig ist aber immer, in welcher Umgebung "Schöpfers Licht" arbeiten soll. Diese Umgebung muss definiert sein, denn nur dann kann man darauf aufsetzend programmieren.

Übrigens .... Schöpfers Licht ist nicht nur als Sprache geeignet ... Sie eignet sich auch als Basis für eben eine solche "virtuelle Maschine" bzw. halt die Umgebung. Zwar fehlen noch ein paar Definitionen, aber gehen sollte es im Groben ...

Gruß,
Jumper, the II.

 

[Plankton]

n10B, ich hab nur noch eien Frage:
Nutzt es was, wenn ich als c++-Anfänger mitmache? Ich meien, ich hab in der Schule noch Delphi an den Hacken und den ganzen andern Kram.:roll:

mfg Plankton

EDIT: **** of, wenn es euch nicht stört, dass ich kein basic kann, dann bin ich dabei^^

 

[N10B]

Jumper,

ja, schon klar, dass mind. asm benötigt wird.
Wenn du kein Bock hast oder aus irgendwelchen anderen Gründen nicht mitmachen kannst oder willst, ist das doch ok.
Es beißt keiner, wenn jemand nicht will. Jeder hat seine Projekte an denen er arbeitet. Man kann eben nicht alles können und machen.
Wenn du aber trotzdem mitmachen willst - gerne.

@ Plankton:

klar...jeder der lust und etwas ahnung hat kann mitmachen. Ich weiss nicht, inwiefern du jetzt ein c-Noob bist, aber ich denke es sollte reichen ^^
ich selbst bin auch nicht der C-Guru, auch erst 15 und geh zur schule.
Und wenn du in der Schule Delphi lernst und das kannst, auch nicht schlecht.
Irgendwas wird sich damit schon anstellen lassen =)


lg
n1ob

 

[Plankton]

Bin an Bord

mfg Plankton

 

[JumperII]

Schreit, wenn Ihr Probleme habt .... ;-)

 

[N10B]

sowas hört man gern =)

 

[Prophet]

Also wenn ihr schon so ein fake OS schreibt solltet ihr glaube ich schon auf die high level routinen zugreifen. Ich glaube einen eigenen assembler dafür zu schreiben ist überflüssig oder?

Oder soll es eine virtuelle umgebung werden?

 

[JumperII]

Ich persönlich halte einen Ansatz, wir schreiben eine Sprache/Compiler für die Entwicklung eines OS für eine Echte, bereits existierene Maschine, für machbar aber äußerst anstrengend. Hier muss man tatsächlich auf die einzelnen Hardware-Komponenten eingehen. Dabei meine ich tatsächlich solche extentiellen Elemente wie Speicherverwaltung, Interrupt-Handling, Timer, Uhren-Chip, ...

Hinzu kommt, dass für erste sinnvolle Tests auch sinnvolle Umgebungen existieren müssen. Da muss man schon auf vmware oder Parallels zurückgreifen, setzt man auf die x86 Architektur.

Sind die Ambitionen, ein OS beschreibbar zu machen, weiterhin vorhanden, muss die Sprache ein Low-Level-Modus a la Assembler beherrschen. Ausschließlich auf High-Livel-Sprachen zurückziehen kann man sich, wenn man stattdessen z.B. auf einen µKernel aufsetzt. Der µKernel enthält alle maschinennahen Komponenten und bietet für die zu entwickelnden Schichten drum herum passende APIs an.

Gruß,
Jumper, the II.

 

[Prophet]

Ich dachte ziel ist es ein fake OS zu schreiben. Was du dort beschreibst ist der ansatz eines richtigen betriebssystems, und ich glaube du unterschätzt den aufwand dafür

 

[JumperII]

a) Ich unterschätze den Aufwand bestimmt nicht *lol*
b) Definiere Fake OS ... wieviel Fake und wieviel OS darf es sein?

Oder anders, wenn man eine Sprache und den zugehörigen Compiler designen will, welches die Fähigkeit besitzen soll, ein OS zu entwickeln, muss man auch tief hinunter. Die Alternative ist statt eines OS ein Framework zu programmieren. Ansonsten kann man natürlich mit jeder Sprache eine Kommandozeile programmieren, die eine OS-Meldung präsentiert und auf Eingaben mit einer Reaktion bedient. Wenn man das als FakeOS verstehen will, ist mir das auch recht. In diesem Fall brauchen wir alle wohl dann keine Gedanken machen, bei der Umsetzung zu helfen.

Gruß,
Jumper, the II.