Thema: Ein letztes Mal noch...

[bluecode]

Mehrere Programmiersprachen zu "mixen" sollte kein Problem sein, solang die Koordination funktioniert.
Dabei sollte sich die Programmiersprache nur Modulweise wechseln, sonst gäbs wirklich ein durcheinander.

Naja, ich denke das der Kernel und die Module schon mit einer Sprache (also zB C/C++) + Assembler (inline oder net is ja egal) geschrieben werden sollten, da die meisten ABI's ziemlich inkompatibel sind (schau dir mal die C++ ABI an [wobeis da auch schon mehrere gibt ], die dürfte an komplexität sogut wie alles in den Schatten stellen)

Prinzipiell würd ich auch a biserl mitcoden, aber noch net am Anfang... Und zuerst sollte mal ein Konzept gemacht werden, wie die grundsätzlichen Dinge implementiert werden sollen.

Noch ne kleine Empfehlung: Subversion + trac. Benutz ich mit DarkThing auch für unseren Emulator. Wir haben unser Repository bei http://opensvn.csie.org. Bei denen kriegt man alles kostenlos (also svn + trac) und man muss keine bestimmte Lizenz benutzen wie bei zB. sourceforge, d.h. man kann auch closed source sein.

[T0ast3r]

um ehrlich zu sein ich hab mit repositorys noch nicht viel zu tun gehabt...
dann würde ich vorschlagen LOST dort gleich zu registrieren und allen LOST mitmachern passwort usw. zu geben

[Damian]

Das bezweifle ich ja gar nicht, daß es leicht ist, irgendeinen Bootloader zu schreiben. Aber einen Bootloader mit der Funktionalität von GRUB zu schreiben, ist sicher nicht mehr ganz so leicht.

Welche Funktionalität hat grub denn?

[kevin]

Der größte Vorteil ist imho, daß es einen Bootprompt zur Verfügung stellt, der mit Dateisystemen umgehen kann. Damit kann ich jeden beliebigen Kernel starten, der irgendwo auf der Platte rumliegt. Kann aber auch noch mehr, z.B. Module in den Speicher laden (wäre sicher sehr interessant, wenn wir beim Microkernelkonzept bleiben). Und aus Endbenutzersicht betrachtet, könnte es neben LOST auch noch so ziemlich alle anderen Betriebssysteme starten.

[T0ast3r]

nochmal wegen den Programmiersprachen:

nach möglichkeit wird definitiv C++ und Assembler genommen, wobei auf den "Überblick" geachtet wird (lesbarkeit usw.)

[Osbios]

Wirklich C++? Nicht lieber C?

[SSJ7Gohan]

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.

[mastermesh]

Aus gegebenem Anlass melde ich mich mal wieder.

Ersmtal finde ich es toll, dass hier immer noch Interesse besteht, an LOST zu arbeiten. Wie ihr vielleicht wisst, habe ich in letzter Zeit nur sehr wenig mit Programmierung oder gar OS-Programmierung zu tun gehabt. Beruf, Freundin, neue Aufgaben und Ziele stehen vor mir und... naja... es ist nicht einfach für mich.

1. Toaster ist ab sofort Team-Lead vom LOST-Projekt, ich bitte ihn jedoch, größere Änderungen mit mir abzusprechen.

2. Das Forum (und überhaupt die ganze Lowlevel-Seite) scheint technisch ein wenig zu verkommen. Hannibal scheint sich auch nicht wirklich zu melden. Wenn niemand was dagegen hat, würde ich die Seite gern auf meinen dedizierten Server umziehen, ich denke, das wäre für alle von Vorteil. Weiterhin würde ich (wenn Interesse besteht) die Domain lowlevel-mag.de registrieren.

3. Weiß eigentlich jemand was von joachim_neu? Der scheint sich in letzter Zeit auch nicht mehr zu melden... brauchen wir evtl. wieder einen neuen Chefredakteur?

[T0ast3r]

du hast recht dass wir noch viel planen und festlegen müssen, aber dass kommt alles noch zu seiner zeit

ich lehne aber (wie bei deinem vorschlag) es ab, eine bytecodebasierte sprache zu verwenden, sei es für treiber oder für den kernel
es geht hier nicht darum einen interpreter (das ist sehr viel arbeit) zu schreiben, sondern ein OS

ich hab mir schon gedacht dass ein paar C bevorzugen und C++ vorziehen
ich würde es eher einheitlich in C++ machen, jedoch will ich auch andere meinungen hören

können viele (die meisten, bekannten) C++ koompiler auch C compilieren?
dass wäre nämlich sehr nützlich und würde es erlauben beide einfach nebeneinander zu verwenden

ich selbst bin ja kein großer  C/C++ schreiber
wie groß sind die unterschiede im allgemeinen zwischen C und C++
sind sie hauptsächlich portierbar?
und wie scher bzw. machtbar wäre es wenn du, osbios c++ lernen würdest?

[T0ast3r]

@mastermesh:
Es freut mich, dass du dich mal wieder zu Wort meldest und auch über die Zukunft (Website usw.) sprichst.

Geht klar, ich geb dir bescheid wenn sich etwas Entscheidendes ändert.
(und selbstverständlich werde ich dann mich mit dir absprechen)

Joachim ist in letzter Zeit ziemlich gestresst, er hat jetzt auch ein (online) Spiel und hat so wenig Zeit für lowlevel.
Soll ich ihn mal kontaktieren?

Es ist eine gute Idee wenn die Website auf einen anderen Server umzieht, vielleicht auch mal mit Umlauten.

Ein paar Ideen hätte ich für die lowlevel seite, ich würde Vorschlagen deswegen einen eigenen Thread in Offtopic zu erstellen.

[kevin]

Einigen wir uns als Kompromiß doch einfach auf Pascal.

können viele (die meisten, bekannten) C++ koompiler auch C compilieren?

C ist eine Teilmenge von C++, insofern ist es für die Compilerhersteller zu hoffen, daß die Compiler das hinbekommen... Das hat dann aber nichts mehr mit C++ zu tun, auch wenn du einen C++-Compiler benutzt.

[Damian]

Achnee ich wollte es mit blitzbasic machen.
Ne mal im ernst, ich glaube Assembler/C/C++ können benutzt werden.

[Damian]

Einigen wir uns als Kompromiß doch einfach auf Pascal.

können viele (die meisten, bekannten) C++ koompiler auch C compilieren?

C ist eine Teilmenge von C++, insofern ist es für die Compilerhersteller zu hoffen, daß die Compiler das hinbekommen... Das hat dann aber nichts mehr mit C++ zu tun, auch wenn du einen C++-Compiler benutzt.

hmm C und C++ unterscheiden sich in ein teil besonders. C++ braucht meistens die iostream.h wobei C die nicht braucht.
2. Zwischen windows entwickler die MS visual C++ benutzen, und andere, kann es vorkommen dass einige entwicker folgendes machen

Code: [Auswählen]

void main() Dies muss unbedingt vermieden werden, benutze

Code: [Auswählen]

int main() weil soviel ich weiß dass linux das nicht akzeptiert.
3. Linux benutzern haben eine C und eine C++ compiler. C => gcc ;;;;; C++ => g++

[kevin]

hmm C und C++ unterscheiden sich in ein teil besonders. C++ braucht meistens die iostream.h wobei C die nicht braucht.

Genau dann, wenn du die Streams benutzen willst. Aber wenn du dich auf das beschränkst, was dir deine C-Bibliothek bietet, dann nicht. Jedes C-Programm ist auch ein C++-Programm, nur umgekehrt nicht.

2. Zwischen windows entwickler die MS visual C++ benutzen, und andere, kann es vorkommen dass einige entwicker folgendes machen

Code: [Auswählen]

void main() Dies muss unbedingt vermieden werden, benutze

Code: [Auswählen]

int main() weil soviel ich weiß dass linux das nicht akzeptiert.

gcc gibt dann standardmäßig eine Warnung raus, soweit ich weiß. Mit int ist es auf jeden Fall korrekter.

3. Linux benutzern haben eine C und eine C++ compiler. C => gcc ;;;;; C++ => g++

Wobei g++ ohne weiteres auch C-Code verarbeitet, weil C ja wie gesagt eine Teilmenge von C++ ist.

[Damian]

Nja dan gib mir mal eine C++ code den ich mit ein C compiler kompilieren kann. Und/oder ein C code die ich mit ein C++ compiler kompilieren kann.

Das will ich sehen  

[joachim_neu]

3. Weiß eigentlich jemand was von joachim_neu? Der scheint sich in letzter Zeit auch nicht mehr zu melden... brauchen wir evtl. wieder einen neuen Chefredakteur?

Doch, mich gibts noch. Aber wie's aussieht muss jemand anderes den Job in Zukunft übernehmen, ich komm' sonst mit der Arbeit nichtmehr nach. Es hat mir viel Spaß gemacht, wenns auch manchmal einige Nerven gekostet hat, und ich würds gerne weitermachen, aber derzeit ist bei mir einfach nicht die Zeit da, die dieses Projekt bräuchte.

[joachim_neu]

ADD: Ansonsten stimme ich (was LOST angeht) SSJ7Gohan absolut zu. Eine gute Planung ist quasi das A und O, ansonsten bekommt man etwas wie MenuetOS, was zwar viele Features an sich aber kein Grundkonzept und Design hat.

[Damian]

mal eine frage, was muss ein redakteur machen?

[Damian]

2. Das Forum (und überhaupt die ganze Lowlevel-Seite) scheint technisch ein wenig zu verkommen. Hannibal scheint sich auch nicht wirklich zu melden. Wenn niemand was dagegen hat, würde ich die Seite gern auf meinen dedizierten Server umziehen, ich denke, das wäre für alle von Vorteil. Weiterhin würde ich (wenn Interesse besteht) die Domain lowlevel-mag.de registrieren.

Jo da hast du vollkommen recht, diese site system ist schrott  

[bluecode]

Also, C und C++ unterscheiden sich vom design her schon sehr stark imho. Bei C nimmt man zB eher weniger ein Objekt-orientiertes Design. Desweiteren braucht man für mache C++ Features auch extra runtime support (abhängig von dem Feature kann des verdammt komplex sein und Compiler ABI abhängig). Ich würd aber ein einheitliches Design einem "hier ein Treiber in C, da ein Treiber in C++"-Model vorziehen. Das is dann einfacher nachzuvollziehen und man muss nicht entweder ne C API bereitstellen und dann einen C++ Wrapper für Treiber, welche C++ schreiben drumrum, oder eine C++ API, die man eher nicht in C verwenden kann und zusätzlich noch ne C API...

PS: Das void main() legitimes C++ ist halte ich für ein Gerücht Und im Kernel wird man eher net iostream (in C++ sowieso OHNE .h) verwenden