Lowlevel
Lowlevel => tyndur => Thema gestartet von: T0ast3r am 29. March 2006, 21:08
-
Hi,
wie die meisten ja wissen, wollt ich das LOST Projekt leiten (schon 2 mal :roll: )
jaa, aber da waren ein paar dagegen, will aber nicht näher darauf eingehen
in letzter zeit ist ja so gut wie nichts weitergegangen, weshalb ich vorschlagen würde LOST zu leiten und daraus etwas zu machen
dabei würde ich alles neu beginnen, und jeder könnte dabei mitmachen und mitwirken
Zudem habe ich nun eine Menge erfahrung in Betriebssystementwicklung, mein OS ist nun ziemlich weit was die API betrifft (GUI fehlt...), weswegen ich auch Code von ToasterOS übernehmen kann.
Feedbacks und eure persöhnlichen Meinungen sind gerne erwünscht,
Toaster
-
Finde ich eine sehr gute Idee. Aber dann wirklich alles selber machen. Also auch den Bootstrap etc. und nicht grob (oder wie heißt der?) verwenden. Ich könnte auch mithelfen. Ich kann aber nur Assembler, also kein C/C++ etc. Auch wenn ich mehr Zeit für mein eigenes OS investiere könnte ich einiges mitmachen. Vielleicht den Bootstrap schreiben. Wie soll es denn am Anfang sein? Direkt Dateisystem, oder lieber erst einzelde Sektore als Kernel laden? Würde mir bestimmt spass machen.
bitmaster
-
So, habe schon die ersten sachen gemacht. Ein kleiner Bootstrap und ein noch kleinerer Kernel. Hier der Code:
boot.asm:
org 7C00h
xor ax,ax
mov ds,ax
mov es,ax
mov si,Msg
call WriteMsg
mov ax,1000h
mov es,ax ;Segment = 1000h
xor bx,bx ;Offset = Null
mov ah,02h ;lade Sektor(e)
mov al,01h ;erstmal einen
mov cl,02h ;zweiter Sektor
xor ch,ch ;Spur Null
xor dl,dl ;Disk0 = Floppy0
xor dh,dh ;Seite Null
int 13h
;Segmentregister setzen
mov ax,1000h
mov ds,ax
mov es,ax
db 0EAh ;jmp
dw 0000h ;Offset
dw 1000h ;Segment
WriteMsg:
lodsb
or al,al
jz WriteMsgBack
mov ah,0Eh
int 10h
jmp WriteMsg
WriteMsgBack:
ret
Msg db "LOST wird geladen...",00h
times 510-($-$$) db 0
dw 0AA55h
kernel.asm:
org 0
mov si,Msg
call WriteMsg
jmp $
WriteMsg:
lodsb
or al,al
jz WriteMsgBack
mov ah,0Eh
int 10h
jmp WriteMsg
WriteMsgBack:
ret
Msg db 13,10,13,10,"LOST:>",00h
Wie man sieht, noch sehr klein. Aber wir können es ja erweitern.
bitmaster
-
würde das heißen, dass alles neu gemacht wird? (die unterschiedlichen teams, der ganze quelltext, die planung, etc)
kann am commos jeder teilnehmen, der öfters hier im forum und/oder auf der lowlevel-seite ist? muss man dafür einiges an grundwissen haben oder reicht es auch, wenn man ein klein wenig wissen hat?
ich hätte nämlich theoretisch auch lust auf sowas, weiß nur nicht, ob ich (schon) dafür geeignet bin.
-
hi,
ersteinmal eine sehr gute Idee !
ich könnte ja auch ein wenig mithelfen :lol:
jeder sollte mitmachen dürfen, egal wieviel man weiss, hauptsache man ist motiviert bei der Sache, dass nicht nach ein oder zwei Monaten das Projekt eingestellt wird !
Wichtig ist auch dass alles gut dokumentiert ist und ein Design Sheet oder so erstellt wird, wo alles genau festgehalten wird. Im Optimalfall muss man diesen als "neuer" Entwickler nur durchlesen und man weiss wie das OS aufgebaut ist.
mfg,
stefan
-
Aber dann wirklich alles selber machen. Also auch den Bootstrap etc. und nicht grob (oder wie heißt der?) verwenden.
Bitte nicht. GRUB ist eine tolle Sache und vermutlich hat ihn sowieso jeder installiert, der mal mit Linux zu tun hatte. Ein Bootmenü, wo ich bequem den zu bootenden Kernel auswählen kann, würde dein Bootloader vermutlich nicht bieten. Manche Sachen muß man einfach nicht ständig neu erfinden.
Vielleicht ließe es sich für die Puristen einrichten, daß der Kernel zwar GRUB-kompatibel ist, aber zusätzlich noch ein eigener Bootloader geschrieben wird. Aus Benutzersicht macht das zwar keinen Sinn, aber wenn es drum geht, zu demonstrieren, wie man so was schreibt - meinetwegen.
-
Aber dann wirklich alles selber machen. Also auch den Bootstrap etc. und nicht grob (oder wie heißt der?) verwenden.
Bitte nicht. GRUB ist eine tolle Sache und vermutlich hat ihn sowieso jeder installiert, der mal mit Linux zu tun hatte. Ein Bootmenü, wo ich bequem den zu bootenden Kernel auswählen kann, würde dein Bootloader vermutlich nicht bieten. Manche Sachen muß man einfach nicht ständig neu erfinden.
Vielleicht ließe es sich für die Puristen einrichten, daß der Kernel zwar GRUB-kompatibel ist, aber zusätzlich noch ein eigener Bootloader geschrieben wird. Aus Benutzersicht macht das zwar keinen Sinn, aber wenn es drum geht, zu demonstrieren, wie man so was schreibt - meinetwegen.
Also das sehe ich ganz anders. Ich finde nicht das wir etwas vorgekautes kopieren bzw. einbinden sollten. Wenn ich von Betriebssystem etwicklung spreche, dann meine ich alles an dem OS (Bootstrap+Kernel+GUI etc.) selber zu machen. Und ja, ich hatte Linux mal eine Zeit lang installiert (war grauenhaft), aber GRUB reizt mich nicht besonders (wegen den oben genannten Gründen). Wer hier der Chef von LOST ist, sollte entscheiden wie es gemacht wird. Der Chef bzw. Leiter von LOST ist doch jetzt T0ast3r, oder? Also er muss dann wissen wie wir es machen. Aber wie gesagt wenn dann C/C++ verwendet wird, mache ich nicht mehr mit (weil ich diese Programmiersprachen nicht kann). Also wie machen wir es? Nur Assembler und alles selber machen? Oder C/C++ drin und/oder mit GRUB?
bitmaster
-
Wegen dem bootloader (und ev. dem bootstrap loader - Partitionen) schließe ich mich bitmaster an, man sollte etwas eigenes programmieren.
einen bootloader zu schreiben ist nicht so schwer, bitmaster hat schon einen anfang geschrieben.
Grub ist eigentlich nur ein Multiboot boot loader, also damit man mehrere Betriebssysteme auf verschiendenen Partitionen benutzen kann.
Darüber hinaus kann man (glaub ich) auch einen (dem OS betreffenden) Kernel laden.
Jedoch denke ich, es ist besser einen eigenen. (ist ja auch nicht so schwer)
Jeder der will kann und soll bei LOST mitmachen, egal ob viel oder wenig.
Und geeignet ist auch jeder!
Wegen der Programmiersprache, ich beherrsche Assembler aber auch C++. (und andere)
Ich bin dafür, dass wir mit mehreren Programmiersprachen arbeiten.
Dann müssen wir ein einheitliches Interface und Format festlegen.
Ich finds toll dass ihr euch so schnell gemeldet habt!
Am besten wir warten noch ein paar Tage, und beginnen dann mit der Entwicklung. (des Bootloaders, usw.)
Einsteigen kann aber trotzdem immer jeder.
-
einen bootloader zu schreiben ist nicht so schwer, bitmaster hat schon einen anfang geschrieben.
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.
Grub ist eigentlich nur ein Multiboot boot loader, also damit man mehrere Betriebssysteme auf verschiendenen Partitionen benutzen kann.
Darüber hinaus kann man (glaub ich) auch einen (dem OS betreffenden) Kernel laden.
Jedoch denke ich, es ist besser einen eigenen. (ist ja auch nicht so schwer)
GRUB lädt im allgemeinen den Kernel von der Platte, kann auch noch Module mitladen (ich glaube, Hurd benutzt das) und startet das dann. Was auch geht, ist per chainloader einen anderen Bootloader aufzurufen.
Was ist jetzt an der ersten Methode so viel besser? GRUB kann mit Dateisystemen umgehen, ich kann also direkt mit dem Dateinamen des Kernels hantieren und z.B. auch mehrere Versionen des Kernels nebeneinander haben. Wenn ich den chainloader benutzen will, muß ich dem System mit seinem eigenen Bootloader schonmal eine eigene Partition spendieren (kann aber zumindest das Dateisystem nicht mehr benutzen, sondern brauche die physische Position).
Andererseits sehe ich natürlich auch ein, daß LOST zum Lernen gedacht ist, insofern ist ein eigener Bootloader sicher auch nicht verkehrt. Daher mein Vorschlag, ob wir es nicht vielleicht schaffen, zweigleisig zu fahren und sowohl GRUB als auch einen eigenen, einfacheren Bootloader zu unterstützen.
Wegen der Programmiersprache, ich beherrsche Assembler aber auch C++. (und andere)
Ich bin dafür, dass wir mit mehreren Programmiersprachen arbeiten.
Dann müssen wir ein einheitliches Interface und Format festlegen.
Wir mischen ASM, C, Pascal, Ada und Brainfuck? ;) Hm, naja, warum eigentlich nicht (außer daß man alle Sprachen zumindest verstehen muß, wenn man das komplette OS verstehen will). Aber spätestens wenn OOP ins Spiel kommen soll, kannst du das vergessen, weil nichts mehr kompatibel ist.
Ich finds toll dass ihr euch so schnell gemeldet habt!
Das GUI-Team braucht eben endlich einen Unterbau. ;)
Bleibt es eigentlich bei der grundsätzlichen Überlegung, daß es ein Microkernel werden soll?
-
Der Chef bzw. Leiter von LOST ist doch jetzt T0ast3r, oder?
Ich würd sagen der chef ist mastermesh, solange er diesen titel nicht ausdrücklich an T0ast3r abgibt.
Ich find wir (wenn dann will ich auch mit machen!) können nicht einfach anfangen. Es MUSS erstmal das design FESTSTEHEN, d.h. einen Bootloader kann man erst schreiben, wenn die Dateisystemfrage, Kernelformat usw. geklärt sind.
Zudem habe ich nun eine Menge erfahrung in Betriebssystementwicklung, mein OS ist nun ziemlich weit was die API betrifft (GUI fehlt...), weswegen ich auch Code von ToasterOS übernehmen kann.
Ich behaupte mal auch erfahrung zu haben. Aber ich dachte ihr wolltet ALLES neu schreiben, code wird also nicht übernommen!
Wegen der Programmiersprache, ich beherrsche Assembler aber auch C++. (und andere)
Ich bin dafür, dass wir mit mehreren Programmiersprachen arbeiten.
Jeder der sich PRORAMMIERER nennen will sollte in der lage sein eine programmiersprache innerhalb kürzester zeit (wenns nicht gerade asm ist...) zu lernen. Der Kernel sollte aber trotzdem in einer sprache geschrieben sein. Die UserProgramme können dann ja immer noch in ner anderen sein.
-
hi,
hmmm mastermesh meldet sich aber hier nicht mehr so oft !?
Mehrere Sprachen wäre schon nicht schlecht, was mir aber eigentlich eher egal ist :)
Man könnte evt. das Windows PE Format hernehmen für Kernel/Module und Treiber. Die haben schöne Features wie Import/Export/Fixup Tables und werden auch von vielen Sprachen wie Assembler und C/C++, aber auch Delphi (:lol: ) unterstützt !
Bevor aber richtig zum programmieren angefangen wird, sollte erstmal ein Design Dokument existieren und genügend Mithelfer gefunden werden und dass es dann nicht so ausschaut dass ein oder zwei die ganze Arbeit alleine machen und der Rest sich abgeseilt hat. :D
mfg,
stefan
-
Also das mit dem Leiter, just don't know... (sollt aber auch nicht so wichtig sein)
Das zweigleisig GRUB und selbstgeschrieben verwendet wird halt ich für eine gute Idee, für die beste.
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.
Natührlich ist ein guter Programmierer in der Lage eine neue Sprache zu lernen, aber ich glaub nicht dass hier jeder Lust und Zeit dazu, nochdazu ist es ja nicht kommerziell.
Wegen dem Kernel würde ich extra nen Thread aufmachen, ist ja auch ziemlich umfassend.
Klar ist auch dass erst programmiert wird wenn alle fragen geklärt sind und die aufgabenstellung.
Ich werde demnächst einen Thread für den Bootloader öffnen.
-
ich finde, man sollte allen, die bisher an lost mitgewirkt haben, bescheid sagen und fragen, ob noch einige davon wieder mitmachen.
insbesondere mit mastermesh sollte das wohl abgesprochen werden, bevor man hier sowas einfach macht.
falls es dazu kommt, wäre ein irc-channel oder ähnliches (vllt mit festgelegten treffzeiten) meiner meinung nach sinnvoll, da man dadurch einfach mehr und besseren kontakt hat, als über einzelgespräche oder forum.
so, das wollte ich nur mal loswerden.
cu
nore
-
Ich finde es sollte nicht immer groß rumdiskudiert werden ob mastermash damit einverstanden ist. Dann wird sich wieder nichts tuen. Also einfach mal Anfangen. Wenns um Dateisysteme geht, kann ich mithelfen. Ich habe nämlich schon ein eigenes für mein OS. Ich würde aber vorschlagen für LOST das FAT12 Dateisystem zu nehmen. Später dann natürlich auch mehrere und eigene.
bitmaster
-
ich schließe mich bitmaster an, wozu alle benachrichtigen, und auf mastermesh warten?
wofür soll das gut sein?
in den letzten Monaten ist bei LOST nichts (gar nichts) weitergegangen, und wer mitmachen will soll sich einfach melden
und mit wem sollte man etwas absprechen? (mit mastermesh?)
ich glaube nicht dass er etwas gegen LOST (und diesem Neuanfang) hat
wegen eines IRC channels, dass müsste konkret wer übernehmen...
(auch eine eindeutige website)
aber ich glaube nicht, dass viele dann den IRC chat verwenden werden, es gibt ja auch das forum und viele wollen LOST nicht zu ihren Lebenswerk machen :roll: (die zeit...)
-
also ich könnte zumindest mal nen irc-channel registrieren. das ist ja glaub ich nicht allzu schwer.
ich meinte ja auch nicht, dass man dann ständig da ist, sondern dass man sich dort meinetwegen einmal die woche treffen könnte und je nachdem wie viele leute mitmachen, man uhrzeiten verabredet, an denen man, wenn man grade zeit hat auch so mal vorbeischaut.
-
hi,
ja IRC ist ganz sinnvoll.
Bevor angefangen wird, muss erst mal ne ganze reihge besprochen werden, was in einem Forum nicht ganz so gut geht :)
mfg,
stefan
-
ok, ich hab jetzt mal nen channel registriert:
#lost auf euIRC (irc.euirc.net)
ob er später benutzt wird oder nicht, das können wir ja dann sehen.
-
ich hab noch nicht viel mit irc gearbeitet, welches programm ist "das beste" dafür und wie stelle ich den channel ein?
ich würde es nicht so machen, dass jede woche ein meeting stattfindet, sondern an festgelegten Terminen
ich glaube dass viele eben nicht lust und zeit dazu haben jede woche zur selben zeit in den chat zu gehen
-
hi,
nimm den Client: mIRC, damit hab ichs auch (als Neuling in IRC) geschafft !!!
Wäre gut wenn man mehere festgelegte termine in der woche hat wo man reinschaun könnte (oder einfach immer online sein :D )
mfg,
stefan
-
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 (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.
-
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
-
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?
-
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.
-
nochmal wegen den Programmiersprachen:
nach möglichkeit wird definitiv C++ und Assembler genommen, wobei auf den "Überblick" geachtet wird (lesbarkeit usw.)
-
Wirklich C++? Nicht lieber C?
-
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.
-
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?
-
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?
-
@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.
-
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.
-
Achnee ich wollte es mit blitzbasic machen.
Ne mal im ernst, ich glaube Assembler/C/C++ können benutzt werden.
-
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 void main() Dies muss unbedingt vermieden werden, benutze 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++
-
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 void main() Dies muss unbedingt vermieden werden, benutze 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.
-
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 :D
-
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.
-
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.
-
mal eine frage, was muss ein redakteur machen?
-
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 8)
-
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 ;)
-
#include <iostream.h>
void main()
{
cout << "Hallo\n";
}
gibt er beim kompilieren folgendes aus:
damian@lokal-server:~$ g++ test.cpp -Wno-deprecated
test.cpp:3: error: `main' must return `int'
test.cpp:5:2: Warnung: Kein Newline am Dateiende
damian@lokal-server:~$
aber bei int main()
#include <iostream.h>
int main()
{
cout << "Hallo\n";
}
kompilierlog: damian@lokal-server:~$ g++ test.cpp -Wno-deprecated
test.cpp:5:2: Warnung: Kein Newline am Dateiende
damian@lokal-server:~$
Ohja die warnung muss man übersehen.
Damit steht bei mir fest, dass int main() benutzt werden muss.
-
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.
Ersteres funktioniert nicht beliebig, weil C eine Teilmenge von C++ ist, aber nicht umgekehrt (sonst wären sie ja gleich). Aber bitteschön, wenn nicht selbst ein C-Programm hast zum ausprobieren, nimm halt dieses:
#include <stdio.h>
int main(void) {
printf("Hello World!\n");
return 0;
}
Läßt sich ohne weiteres sowohl als C als auch als C++ kompilieren.
Zum Thema void main(): Hab's ausprobiert, g++ gibt tatsächlich einen Fehler aus, gcc aber nur eine Warnung.
-
Also, C und C++ unterscheiden sich vom design her schon sehr stark imho. Bei C nimmt man zB eher weniger ein Objekt-orientiertes Design.
Es geht im Moment eher darum, was der Compiler schluckt. Daß die Verwendung von reinem C-Code in C++, also das, was manchmal C+ genannt wird - C mit Klassen eben - kein guter Stil ist, dürfte klar sein.
Um mal auf den Kernel zurückzukommen: Ich halte es für eine bessere Idee, alles in C zu halten, und darauf C++-Schnittstellen aufzusetzen. Das dürfte einfacher sein als umgekehrt. Und die Möglichkeit, C-Bibliotheken zu nutzen, bietet im Gegensatz zu C++ eigentlich jeder Compiler, so daß Kompatibilität sicher auch ein Argument sein könnte.
-
Naja C++ ist mein Fan, aber wir können es auch in C machen, obwohl ich in objektorientierend programmierung verliebt bin ^^
:oops:
-
Damit es nicht in Vergessenheit gerät:
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.
Das ist eine sehr gute Idee.
-
sehr gute idee :)
falls für die seite ansonsten noch irgendwas programmiertechnisches (php) gemacht werden muss sagt bescheid, hab aktuell nichts zu tun ;)
-
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.
Also ich bin da, sogar ziemlich oft. Jedoch wollte ich bisher nicht grossartig technisch eingreifen, da bis vor dem Serverumzug alles in Roshl's Hand gelegen hat - vor allem das System der Seite stammt ja auch von ihm. Ich hab dort aber auch selbst schon Hand angelegt um die verrueckten Ausgaben des Scripts zu korrigieren.
Melde dich bitte mal per Mail (alexander DOT panek AT brainsware DOT org) bei mir bezueglich Daten und SQL Dumps von Forum und Tutorials. Der Server steht euch natuerlich weiterhin kostenlos zur Verfuegung - mit allen Feinheiten, Schikanen und weiss der Kuckuck was alles gebraucht wird (SVN repos, Trac, MediaWiki, FTP, HTTP - auch mit Domain ohne weiteres moeglich, ... auf gut Englisch: features on demand).
Ad LOST: Ich bitte euch, geht die Sache strukturiert an. Fangt nicht mit einer Homepage an ohne auch nur einen bootfaehigen Kernel mit Memory Management zu haben; es zahlt sich einfach nicht aus.
LG,
Alex
-
alle sagen immer es soll strukturiert sein :?
dabei ist es eh strukturiert, nur kommt das meiste nicht ins forum, sondern ins Wiki und vieles davon aus dem IRC Channel :wink:
ich denke die website läuft dazu parallel ab, was mich nicht stören würde, solang da etwas selbsständig weitergeht