Programmierung ohne OS?
lima-city → Forum → Programmiersprachen → Sonstige Programmiersprachen
betriebssystem
boot
diskette
fehler
http
image
mache
menge
paar
programm
programmiersprache
programmierung
projekt
prozessor
schauen
speichern
tun
url
wahl
wissen
-
Soo, mal wieder ein paar Minuten frei, mal wieder ein wenig langeweile... Da habe ich mir überlegt, wie es wohl realisierbar wäre, ein (einfaches) Programm zu schreiben, was vollkommen unabhängig funktioniert (bzw. ausschließlich davon abhängig, dass nichts da ist (o: )
Nun habe ich mir eine VM eingerichtet - und stand vor der Wahl des Betriebssystems. Falsch: Ich will ja unabhängigkeit! Tja, aber die meisten Programmiersprachen sind ja von sowas abhängig...
Um das klar zu stellen: Ich will gar kein Riesen-Projekt, mit mega funktionsumfang - mir reicht ein einfaches Hello-World Programm, also ein Programm, was mir - wenn ich die VM hochfahre - schlicht "Hello World" ausgibt und wenn es hoch kommt noch eine Tastatureingabe ermöglicht.
Nun meine Fragen:
- Welche Programmiersprache nutze ich da wohl am besten?
- Womit fange ich am besten an? (Tutorials?)
- Worauf ist zu achten?
Wäre nett, den Sinn nicht weiter zu hinterfragen - es geht um "learning by doing"; Reiner Zeitfüller. (o: -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Was du vor hast, ist nichts desto trotz ein kleines Betriebssystem. Von daher solltest du erstmal festlegen, von welchem "Nichts" du abhängig sein willst
. Soll heißen: für 32bit oder 64bit-Prozessoren? für x86-32, x86-64, für Power-PC, für ARM, es gibt viele Zielplattformen, und gerade bei der Low-Level-Programmierung ist es wichtig, zu wissen, womit man sich einläßt. Es stehen dir nämlich unter keiner Programmiersprache dann irgendwelche API-Calls zur Verfügung, nicht mal ein simples Asugeben von Text!
Als eine gute Startseite hat sich erwiesen: http://www.osnews.com/resources
Scroll unter die Bücher runter, zum Abschnitt "How to Write Your Own OS". Das sollte helfen.
Edit: sehr oft wird für ein OS C verwendet, natürlich unter Zuhilfenahme von Assembler.
Ein Thread, ind em bereits auch über das diskutiert wurde: http://www.lima-city.de/thread/wit-welcher-programmiersprache-werden-betriebssysteme-programmiert
Beitrag zuletzt geändert: 5.10.2009 15:55:16 von burgi -
Nettes Ding. Du willst einen Kernel programmieren.
Die Waffen deiner Wahl werden gcc, nasm und ld sein. Du kannst natürlich nur C ohne irgendwelche Standardlibs benutzen, also kein printf, kein malloc, kein free. Du musst so ein Paar Basics wissen, z.B. wo liegt beim Booten der Bildschirmspeicher und wie schreibst du da rein. Das Eigentliche Kernstück wirst du in Assembly schreiben, dafür der nasm. Zusammenführen wirst du es mit ld.
Dafür gibt es einen Haufen Tutorials im Netz, suche am besten nach "kernel home brew" oder "Kernelbau" oder ähnlichem.
EDIT: Narf, zu spät.
Beitrag zuletzt geändert: 5.10.2009 16:00:05 von census -
burgi schrieb:
Dass es dennoch mächtig aufwändig wird, ist mir durchaus bewusst. Deshalb möchte ich es ja vorerst so klein und sympel wie möglich halten. ;)
Was du vor hast, ist nichts desto trotz ein kleines Betriebssystem. Von daher solltest du erstmal festlegen, von welchem "Nichts" du abhängig sein willst. Soll heißen: für 32bit oder 64bit-Prozessoren? für x86-32, x86-64, für Power-PC, für ARM, es gibt viele Zielplattformen, und gerade bei der Low-Level-Programmierung ist es wichtig, zu wissen, womit man sich einläßt. Es stehen dir nämlich unter keiner Programmiersprache dann irgendwelche API-Calls zur Verfügung, nicht mal ein simples Asugeben von Text!
Als eine gute Startseite hat sich erwiesen: http://www.osnews.com/resources
Scroll unter die Bücher runter, zum Abschnitt "How to Write Your Own OS". Das sollte helfen.
Edit: sehr oft wird für ein OS C verwendet, natürlich unter Zuhilfenahme von Assembler.
Ein Thread, ind em bereits auch über das diskutiert wurde: http://www.lima-city.de/thread/wit-welcher-programmiersprache-werden-betriebssysteme-programmiert
Hm, was die Prozessoren angeht, bin ich noch nicht so richtig fit. :) Werde ich mich mal schlau machen. Ich denke da wäre es fast am einfachsten sich für nen 10er nen alten 486er anzuschaffen - das sollte dann ja ein x86er sein, da ich bei der aktuellen Prozessor-Entwicklung nicht mehr so richtig durchblicke. ;) Ausserdem ist es da nicht so dramatisch, wenn durch spielerreien irgendwas kaputt geht.
Die Seite werde ich mir dann mal ansehen. Wenn ich deinen Edit richtig interpretiere, wäre also C die Sprache der Wahl?
census schrieb:
Das mit dem Bildschirmspeicher habe ich glaube ich noch ganz gut aus QBx drin, wo es dann auch oft darum ging, direkt in den Speicher zu schreiben. Allerdings bin ich mir da nicht ganz sicher, in wiefern das damals MS-Dos-Abhängig war. ;)
Nettes Ding. Du willst einen Kernel programmieren.
Die Waffen deiner Wahl werden gcc, nasm und ld sein. Du kannst natürlich nur C ohne irgendwelche Standardlibs benutzen, also kein printf, kein malloc, kein free. Du musst so ein Paar Basics wissen, z.B. wo liegt beim Booten der Bildschirmspeicher und wie schreibst du da rein. Das Eigentliche Kernstück wirst du in Assembly schreiben, dafür der nasm. Zusammenführen wirst du es mit ld.
Dafür gibt es einen Haufen Tutorials im Netz, suche am besten nach "kernel home brew" oder "Kernelbau" oder ähnlichem.
EDIT: Narf, zu spät.
Auch deine google-tips werde ich mir mal zugemüte ziehen. -
nerdinator schrieb:
Ich denke da wäre es fast am einfachsten sich für nen 10er nen alten 486er anzuschaffen - das sollte dann ja ein x86er sein, da ich bei der aktuellen Prozessor-Entwicklung nicht mehr so richtig durchblicke.
Wozu kaufen? Du hast ja eine VM, hast du gesagt. Mach das virtuell!
Allerdings bin ich mir da nicht ganz sicher, in wiefern das damals MS-Dos-Abhängig war. ;)
Wenn ich mich richtig erinnere, ging der Bildschrimspeicher im Textmodus unter DOS bei $B800 an
Wie gesagt: Die Vorgangsweise wird erstmal so sein, dass du herausfinden solltest, wo genau der Bootsector hingeschrieben werden muss. Wenn du den Kernel so klein hältst, dass er im Bootsector Platz hat, und du das wirklich nur aus Spaß an der Freude machst, brauchst du dich auf nicht wirklich mit Dateisystem etc. auseinandersetzen, da du dann nichts von der Festplatte oder einem anderen Medium nachladen mußt!
Eine andere Möglichkeit wäre (aber das entspricht nicht ganz deinen Vorgaben), den Soruce-Code eines bestehenden OS zu durchforsten und dort zu schauen, wie das gemacht wurde. Der Lerneffekt dabei ist aber mit Sicherheit geringer, als wenn du das slebst erarbeitest. -
burgi schrieb:
Hm, ich weiss halt nicht, inwiefern es da Fehler geben kann, was Speicher usw. angeht - eine VM ist ja prinzipiell für sowas ähnliches da, aber ich weiss halt nicht, in wiefern es da konflikte gibt, weil evtl. die VM den gleichen Arbeitsspeicher, den gleichen Prozessor oder irgendwas verwendet und ich da eventuell irgendeinen fatalen Fehler mache, welcher dann meinen ursprünglichen PC fatal beschädigt. Da dachte ich mir, dass ich mir doch lieber einen 486er zerhaue. Zumal ich mir nicht sicher bin, ob meine CPU ein x86er ist, oder was auch immer... Ich dachte, dass ich da einfach bei den einfachsten Anfängen beginne.
Wozu kaufen? Du hast ja eine VM, hast du gesagt. Mach das virtuell!
burgi schrieb:
Mag ja sein, dass ich das verwechsel - ich lese da dann oft in der Liste für PEEK/POKE nach, um mich zu vergewissern, dass ich auch das richtige mache. Damit konnte man nämlich schon damals ne Menge falsch machen - was mich wieder auf den weiter oben beschriebenen Punkt bringt ;)
Wenn ich mich richtig erinnere, ging der Bildschrimspeicher im Textmodus unter DOS bei $B800 an
burgi schrieb:
Naja, erstmal sollte es wirklich nur ein Programm werden, jenes halt eine Zeile ausgibt. Wie weit ich dann später damit komme und ob ich noch weiter mache, hängt von der vorhandenen Langeweile ab.;)
Wie gesagt: Die Vorgangsweise wird erstmal so sein, dass du herausfinden solltest, wo genau der Bootsector hingeschrieben werden muss. Wenn du den Kernel so klein hältst, dass er im Bootsector Platz hat, und du das wirklich nur aus Spaß an der Freude machst, brauchst du dich auf nicht wirklich mit Dateisystem etc. auseinandersetzen, da du dann nichts von der Festplatte oder einem anderen Medium nachladen mußt!
burgi schrieb:
Auch daran habe ich gedacht - nur ist in den meisten Fällen halt wesentlich mehr drin, als ich haben möchte, wobei ein Anfänger sicher schnell den Überblick verliert, was wo passiert. Deshalb werde ich mich wohl erstmal mit den "Basics" vertraut machen und dann nochmal schauen, ob es danach noch spaß macht. Man muss ja nicht gleich alles wollen. :)
Eine andere Möglichkeit wäre (aber das entspricht nicht ganz deinen Vorgaben), den Soruce-Code eines bestehenden OS zu durchforsten und dort zu schauen, wie das gemacht wurde. Der Lerneffekt dabei ist aber mit Sicherheit geringer, als wenn du das slebst erarbeitest. -
Eine VM hat auch immer einen virtuellen Prozzi, dass heißt du musst rausfinden, was deine VM simuliert. Meistens ist es aber x86.
Das mit dem PC kaputt machen geht viel eher mit dem 486 als mit nem aktuellen. Den 486 kannst du schnell mal zerhauen.
Es gibt halt n paar Sachen, die man beachten muss, allerdings wird das denke ich in jedem ordentlichen Tut drinstehn.
P.S. Ich hatte heute genau denselben Gedanken. Allerdings soll er bei mir simpel ein paar Inputs und Outputs per seriell bearbeiten.
Beitrag zuletzt geändert: 5.10.2009 17:27:11 von reimann -
nerdinator schrieb:
Hm, ich weiss halt nicht, inwiefern es da Fehler geben kann, was Speicher usw. angeht - eine VM ist ja prinzipiell für sowas ähnliches da, aber ich weiss halt nicht, in wiefern es da konflikte gibt, weil evtl. die VM den gleichen Arbeitsspeicher, den gleichen Prozessor oder irgendwas verwendet und ich da eventuell irgendeinen fatalen Fehler mache, welcher dann meinen ursprünglichen PC fatal beschädigt. Da dachte ich mir, dass ich mir doch lieber einen 486er zerhaue. Zumal ich mir nicht sicher bin, ob meine CPU ein x86er ist, oder was auch immer... Ich dachte, dass ich da einfach bei den einfachsten Anfängen beginne.
Jep, ein 486 fällt unter x86, da x ein Platzhalter ist
http://de.wikipedia.org/wiki/X86
Mit OS-Programmierung kannst du aus einer VM heraus nichts zerschießen, da die Virtualisierungs-Software genau das auch verhindern soll/muss. Wenn dir ein beispielsweise virtuelles Windows mit einem BlueScreen abstürzt, oder einem Ausnahmefehler 0-irgendwas (ich führe jetzt absichtlich nicht Linux an, damit's kein Gemecker gibt
), dann bleibt das Host-OS auch am Laufen, du schließt die VM, und startest diese neu. Von daher wäre es meiner Ansicht nach eine geeignete Test-Umgebung, ohne immer was auf einen anderen PC rüberschaufeln zu müssen, das Image auf die Platte bauen, neu starten, ...
Allerdings weiß ich nicht, ob oder was zu beachten ist, wenn man nicht auf echter Hardware arbeitet, sondern auf einer VM. Aber für deine Zwecke sollte das keine Unterschiede machen, da das normalerweise nur bei Hardware-beschleunigten Dingen (3D-Programme, Spiele, ...) ein Rolle spielen sollte, aber nicht beim Gebrauch von "Standard-Hardware". -
reimann schrieb:
@burgi:
In dem Fall würdes doch auch eine Diskette tun oder?
Wer vernwendet denn heute so was noch, wenn er's auf ein und dem selben Gerät erledigen kann
Aber du hast recht, eine Diskette würde reichen, rein vom technischen Gesichtspunkt betrachtet
(wenn das Projekt so klein bleibt, wie behauptet )
Beitrag zuletzt geändert: 5.10.2009 17:33:50 von burgi -
Wie schon gesagt: Ich bin auch ziemlich überzeugt davon, dass bei der VM nichts kaputt geht. Aber sicher bin ich mir halt nicht, ob es da nicht zu irgendeinem Bug kommt oder sonst was. Ich weiss, dass man sich früher ganz schnell den Prozessor durch falsche Operationen zerhauen konnte. (War unter Win95 glaube ich irgendwas von wegen logarithmus von 0 berechnen lassen...)
Wenn nun der 486er durchbrennt sind 10 Euro im Eimer - das stört nun nicht so echt. Wenn aber mein eigentlicher Pc drunter leidet wird das schon etwas schmerzhaft. Da gehe ich dann doch lieber kein Risiko ein.
Was die Diskette angeht: Ich habe kein Diskettenlaufwerk. Ich muss ja selbst schon schrauben, wenn ich eine CD einlegen will. ;)
Beitrag zuletzt geändert: 5.10.2009 17:41:17 von nerdinator -
Du wirst es nicht schaffen durch eine VM deinen Prozessor zu schrotten. Das einzige was zigtausendmal passieren wird, ist, dass die VM nicht bootet. Aber daran muss sich jeder Kernelprogrammierer gewöhnen. Als Anfänger würde ich die Finger davon lassen, den Bootloader gleich mitzuprogrammieren. Installier dir in die VM lieber ein schmales Linux mit Grub (z.B.), kompiliere und linke deinen Kernel, pack das Image ins /boot Verzeichnis und pass die Grub config an um ihn zu laden. Das erleichtert dir einiges.
-
census schrieb:
Das mit der VM ist reine Vorsicht. Ich meine, ich benutze VMWare 6.5 (Kommerziell vertrieben) und werde mir ganz sicher auch Mühe geben, dass da nichts dramatisch falsch gemacht wird, aber es gibt immer den "Menschlichen Faktor". Ein kleiner Bug in der Virtual Machine, welcher sich mit einem Fehler den ich mache deckt kann vielleicht alles kaputt machen. Auch auf dem anderen Rechner werde ich vorsichtig sein, vielleicht sogar echt über den Vorschlag mit den Disketten nachdenken. um wirklich jegliches Risiko zu minimieren. Auch wenn die Wahrscheinlichkeit an Unmöglichkeit grenzend gering ist ;)
Du wirst es nicht schaffen durch eine VM deinen Prozessor zu schrotten. Das einzige was zigtausendmal passieren wird, ist, dass die VM nicht bootet. Aber daran muss sich jeder Kernelprogrammierer gewöhnen. Als Anfänger würde ich die Finger davon lassen, den Bootloader gleich mitzuprogrammieren. Installier dir in die VM lieber ein schmales Linux mit Grub (z.B.), kompiliere und linke deinen Kernel, pack das Image ins /boot Verzeichnis und pass die Grub config an um ihn zu laden. Das erleichtert dir einiges.
Danke für den Hinweis, aber um Sachen wie den Bootloader geht es mir leider Hauptsächlich. Daran arbeite ich dann notfalls auch ein paar Monate länger. Wie schon gesagt: Das Projekt wird ein Projekt an dem ich arbeite, wenn ich wirklich überhaupt nichts besseres zu tun finde. :) Und ich werde vorweg eine ganze Menge lesen müssen. Die bisher gegebenen Tips waren denke ich so gut, dass man dieses Thema eigentlich schließen könnte, wenn da nicht noch ein "Tu dies, tu jenes"-Kochbuch kommt, was denke ich auch nicht so wirklich hilfreich wäre. Bisher ist mir denke ich ganz gut geholfen, bis es da weiter geht, können aber wohl Monate vergehen, weil da halt sehr viel Stoff einzuholen ist.
Dennoch wäre das Thema wohl besser offen - nur, falls noch irgendwer Ideen hat, oder Hinweise worauf zu achten wäre. Und Fragen tauchen sicher früher oder später auf ;) -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
