Betriebssysteme programmieren ?!?

wenn man zum beispiel etwas professioneller mit linux arbeitet, kommt man oft nicht drum herum, den kernel neu zu kompilieren (beispiel aus der praxis: unser linux-server konnte standartmässig diverse firewall/router dinger nicht. da mussten wir den kernel neu kompilieren). im prinzip wird dieser dann kompiliert wie ein normales programm, dann installiert und die bude neu hochgefahren. so entstehen auch neue versionen.
das selbe läuft auch mit kompilern ab. man kompiliert einen neuen kompiler mit einem älteren. im prinzip müsste der älteste in assembler geschrieben worden sein =)
mit dem macos x, da ham se zum beispiel einfach BSD und NeXTStep genommen, dranrumgeschrieben, dass es mit nem Mac klar kommt, und fertig. mit der zeit halt ein um ein feature mehr eingebaut.

das mit dem hardware emulieren, da bin ich etwas am zweifeln...

 

n debugger-programm oder so watt wie'n ¿assembler-programm? durchgejagt...
...die Voraussetzung für die ganze Angelegenheit (programme und Assembler) gibt doch erst das Betriebssystem oder?
und jetzt:
... wie wird denn dann ein Betriebssystem samt Kernel (wenn notig???) überhaupt geschriebn????
Müsste doch dann auf unterster Ebene geschehen das Ganze oder????

Wenn mich mal jemand diesbezüglisch ein wenig aufklären könnte... dat wär suppa!

Gracias schonma im Vorraus für alle eure Bemühungen!

 

programmieren erfolgt wie folg:
1. möglichkeit: kompilieren
du schreibst ein programm in einer hochsprache, wie c/c++, pascal etc.
darin stehen in für menschen einfach verständliche anweisungen, was der komputer machen soll. das ganze gibst du dann an einen KOMPILER. der übersetzt dein programm in maschienen-sprache (assembler). ein LINKER verknüpft dann noch alles richtig, damit es auf dem entsprechenden system auch läuft.
das betriebssystem läd dann dein programm in den speicher und arbeitet es befehl für befehl durch. der maschienen-code den der kompiler erzeugt hat geht quasi direkt zum prozessor.
2. möglichkeit: interpretieren
du schreibst ein programm in einer hochsprache wie prolog, lisp, zT basic. ein interpreter geht dann jeden befehl durch (wärend das programm läuft) und übersetzt es in für den komputer verständliche befehle. manchmal wird der interpreter mit dem programm zu einem grossen programm geschnürt, bei dies Basic zeug ist das oft so.

deine programme laufen aber nicht ohne weiteres. für viele dinge muss dein programm auf system-befehle zugreifen, die in LIBRARIES, also bibliotheken zusammen gefasst sind. entweder packt die der linker direkt mit in dein programm, oder das betriebsystem lenkt das bei der laufzeit dynamisch hin.

betriebssystem programmieren:
funktioniert im grunde genommen genau so. sieh es so: das betriebssystem ist quasi wie ein programm, das beim booten automatisch gestartet wird und alles weitere dannach regelt.

übrigens: ein debugger ist ein programm um "bugs", also fehler in einem programm zu finden. das kann entweder auf "source-code" ebene geschehen, also du kannst direkt verfolgen, wie deine in zB c++ geschriebenen befehle ausgeführt werden, oder auf assembler-ebene.
ein disassembler nimmt ein fertiges programm und schreibt es dir in einer für menschen etwas einfacheren schreibweise der maschienen sprache deutlich.

ich hoffe ich konnte dir etwas helfen =)

 

aber wie kann man denn nun ein betriebssytem programmieren?
Man kann das doch nicht in einer Hochsprache machen,denn diese basiert ja auf dem Betriebssystem,oder?
Das ganze muss doch irgendwo einen Anfang haben!?

 

Heutzutage wird die Hardware des zu Erstellenden Betriebssystems Emuliert.
(fast so wie Virtual PC)

Sagen wir mal OSX für G5!

Man Emuliert also die G5 Hardware unter
einem G4 System. Darauf erstellt man
dann (Heute meist in C) das Betriebssystem. Da der G5 auch G4 Code verträgt läuft das OSX sowieso. Nur eben nicht Ideal.

Wenn das OS dann Irgendwann auf der Emulierten Hardware (langsam) läuft wartet man auf die Entwickler G5 u.
Testet es dann Real. Auf dem G5 wird das
OS dann Buggefixt u.s.w. bis es den Beta
Status ereicht. u.s.w....

Früher sagte man sich: OS am besten in
Assembler! Doch was nützt die schnelligkeit wenn die Fehlerbeseitigung sowie die Übersichtlichkeit für Programmierer sozusagen nicht da ist.

Nebenbei gibt es viele Betriebssysteme
für alle mögliche Hardware welche
von Maschinensprache bis Basic erstellt
worden sind. (Suchmaschine benutzen)

Letzten Endes ist aber ein OS nur dann
eines wenn die Anwender dieses auch Akzeptieren. So war es mit DOS bis Windows aber auch mit MACOS u.s.w.

Auch Handys bis DVD/Video Player haben ein Betriebssystem....

MFG

 

Wie ist es denn wenn man von einer Windows-Version eines Programms eine Mac-Version erstellt? Müsste dann doch ganz einfach sein: Kompiler od. Interpreter anschmeissen und die Sache ist gegessen, oder? Warum dauert es denn oft so lang bis von einem Programm Versionen für verschiedene Betriebssysteme da sind?

 

der haken sind die libraries und die system architektur. du brauchst zum beispielt komplett andere befehle um einfach nur ein fenster aufzumachen. da fängts erst an. komplizierter wird es dann erst richtig bei dingen wie Event-Erfassung (maus-klicks etc) und Netzwerk sachen.

wenn man sein programm sauber hält, ist der aufwand wesentlich geringer, aber das lässt sich insbesondere bei grösseren projekten kaum noch realisieren.

aber programme zum beispielt die nur die GLUT library benutzen (OpenGL utility library) laufen nach einfachen kompilieren auch sofort unter anderen betriebssystem. Es gibt schon diverse bemühungen, einheitliche libraries zu schaffen, so dass die programme einfach nur neu kompiliert werden müsse (zB auch das portable game librarie oder so)

 

warum das so kompliziert ist?
beispiel spiele: die sind normalerweise sehr sehr nah an der hardware programmiert, sprich der code ist abgestimmt auf grafikchips und cpu. damit hast du dann schon ein problem, wenn du eine komplett andere architektur hast (pc/mac) und selbst bei gleicher architektur ist es dann wie oben schon gesagt eine frage der libraries und wie das betriebssystem mit der hardware kommuniziert (win/linux).
leider ist das eben nicht nur eine frage des neukompilierens.

greetings

holger