warum werden betriebssysteme in c geschrieben?

warum werden betriebssysteme in c geschrieben, und nicht etwa in c++?
Ich meine, alt genug, dass einige OSs in c++ geschrieben werden könnten, wärs ja. Und es ist schneller als c und hat oop!

this-*gt*that

Hat wohl viele Gründe: vorhandenes Wissen, Altcode, Schnörkellosigkeit von C usw.

n000b schrieb:

warum werden betriebssysteme in c geschrieben, und nicht etwa in c++?

Wo fängt bei Dir ein "Betriebssystem" an ?

Ja, aber wären die Systeme nicht schneller? Es wurde doch ein Teil des Mac OS X Kernels schon in c++ geschrieben nicht?

rüdiger

Die ganzen UNIX-Systeme und Derivate werden in C geschrieben. Aber das hat historische Gründe. C wurde ja dafür entworfen, um den UNIX Kernel portabel programmieren zu können.

Aber zB Windows und Mac OS X sollen auch C++ im Kernel enthalten. BeOS/Haiku sind komplett in C++ etc.

borg

gibt doch auch schon in java geschriebene betriebssysteme: http://www.jnode.org/

warum auch nicht? die befehlssätze der prozessoren nimmt doch ständig zu, ich könnte mir durchaus vorstellen das es in zukunft prozessoren gibt die java bytecode interpretieren können.

edit: gibts sogar schon, http://de.wikipedia.org/wiki/PicoJava

Artchi

Wenn man schaut, wann die meisten OSe ursrpünglich entwickelt wurden, dann sieht man, das es damals praktisch "nur" C gab, was sich wirklich optimal für so ein OS lohnte. Als z.B. Linux begonnen wurde, gabs ja praktisch C++ nur bei AT&T und war noch in den Kinderschuhen. UNIX ist noch älter, da gabs kein C++. OK, ich kenne auch OSe die in Assembler entwickelt wurden, die auch Multitasking, GUI usw. haben. Aber das war auch begründet, zu der damaligen Zeit.

Ich denke, wenn man heute ein OS von Grund auf neu entwickeln würde, würde jemand, der C++-Knowhow hat, auch C++ und nicht C benutzen.

Captain Obvious

ist man bei beos eigtl. auf einen compiler festgelegt?

rüdiger

Beiträge die nur dazu dienen einen Flamewar aus diesem Thread zu machen, werde ich konsequent löschen. Falls ihr einen Bedarf für so einen Flamewar habt, eröffnet bitte einen eigenen Thread. Danke für das Verständnis.

Ihr freundlicher Moderator

Aprollo

rüdiger schrieb:

BeOS/Haiku sind komplett in C++ etc.

Noch nie ins Repository von Haiku gesehen, hab greade hier ne cpu.c angeguckt, selbst in cpp-dateien sehen man mehr C o_O

ronny

haiku war nie komplett c++

es basiert u.a. auf den newos kern, der einiges an c enthält

Ich verstehe. Und Systeme wie Windows Vista werden jetzt nicht komplett in C++ geschrieben, weil man den vorherigen Kernel auch noch verwendet um Zeit zu sparen usw.

Gut, dann weiß ich, falls ich mal ein Betriebssystem entwickeln sollte, dass ich es in meiner Lieblingssprache (c++ ^^) schreiben kann.

ronny

beos ist komplett c++, jedoch ohne exceptions im kern

er grund ist, das die c++ eh lib von gcc nicht ring0-save ist und zu komplex zum nachbauen

ich hab auch schon mal n kleines hello world c++ os gebastelt

borg schrieb:

edit: gibts sogar schon

gibts schon lange, auch im iphone is einer drin

borg schrieb:

gibt doch auch schon in java geschriebene betriebssysteme: http://www.jnode.org/

warum auch nicht? die befehlssätze der prozessoren nimmt doch ständig zu, ich könnte mir durchaus vorstellen das es in zukunft prozessoren gibt die java bytecode interpretieren können.

edit: gibts sogar schon, http://de.wikipedia.org/wiki/PicoJava

Wobei ich schon glaube, dass die Menschheit sowas nicht braucht (Prozessoren, die Java-Bytecode verstehen). Das führt die Idee des Bytecode ad absurdum. Natürlich sehe ich ein, dass der Computer beim Booten am Anfang etwas braucht, was er ohne Schnickschnack einfach ausführen kann, aber zu diesem Zweck könnte man die wichtigsten Teile (auch wenn sie in Java geschrieben sind) zu native code compilieren. Oder das BIOS startet einen extrem kleinen Microkernel, der kaum was anderes macht als die VM zu starten.

Optimizer schrieb:

Wobei ich schon glaube, dass die Menschheit sowas nicht braucht (Prozessoren, die Java-Bytecode verstehen).

Das ist sehr praktisch, denn Bytecode-Programme sind ziemlich schlank.
Glaubst du auch, daß die Menschheit keine CISC-Prozessoren braucht?

Der Bytecode muss intern wieder in Micro-Ops zerlegt werden (weil auch ein CISC-Prozessor einen RISC-Kern hat) und das Endergebnis kann eigentlich nicht kürzer sein für das gleiche Programm. Man packt einfach, was der JIT-compiler normal macht, in die Hardware, aber was daran besser sein soll, erschließt sich mir nicht.

Sinnvoller würd ich da schon finden, wenn man den Prozessoren spezielle Befehle angedeihen ließe, die z.B. Garbage Collection beschleunigen.

Badestrand

Optimizer schrieb:

Wobei ich schon glaube, dass die Menschheit sowas nicht braucht (Prozessoren, die Java-Bytecode verstehen).

Irgendwie ist das ja schon eine interessante Sache... Wenn ich mich richtig erinnere, war das holen der Instruktionen aus dem Speicher einer der Flaschenhälse beim Ausführen eines "konventionellen" Programms. Liegt ja irgendwo auch nahe, höhere Befehle zu verwenden, v.a. weil die Technik ja schon weit fortgeschritten ist, wird ja mal Zeit für eine neue Version der Prozessortechnik

Schade fände ich nur, wenn man sich eben auf eine Programmiersprache festlegen würde, aber das ist ja eine andere Sache

Badestrand schrieb:

Schade fände ich nur, wenn man sich eben auf eine Programmiersprache festlegen würde, aber das ist ja eine andere Sache

bytecode für eine Java-VM muss nicht unbedingt mit einem Java-compiler erzeugt werden.

Badestrand

is ja nicht so... schrieb:

bytecode für eine Java-VM muss nicht unbedingt mit einem Java-compiler erzeugt werden.

Nunja, er wird aber wohl relativ Java-spezifisch sein (schätze ich ). Man kann doch auch aus unverschlüsseltem Bytecode den Quelltext fast vollständig wieder herstellen oder nicht?