Hallo Matthias
Also da muß ich protestieren . HTML mit Basic zu vergleichen
ist vielleicht bei manchen älteren Interpretern zulässig ,
nicht mehr aber bei modernen Compilern .
Zutreffend ist , das man Schwierigkeiten hätte , einen
Compiler für eine bootfähige Sache zu finden .
Wie man Makros oder Unterprogramme schreibt und verwendet ,
ist aber eigentlich gleich , solange dieselbe Logik , derselbe
Programmablauf geschieht . Ich bin aber der Meinung , das
falls man sich mit Basic relativ gut auskennt und außerdem mit
Assembler kann , dann kommen ein paar Routinen für Basic-Style
in Frage . Damit könnte man dann auch leichter das Programm
portieren , was aber wegen der unterschiedlichen Maschinen
nicht unbedingt Sinn macht .
Du mußt bedenken , das Dir C anscheinend geläufig ist , und
das es Dir deswegen möglicherweise selbstverständlich
erscheint .
Du hast recht, der Vergleich Basic HTML war vielleicht etwas übertrieben da sich seit den Interpreter-Basic doch einiges geändert hat.
Denoch ist Basic viel zu sehr in das Betriebssystem integriert alsdass man damit eine Kernel erstellen könnte. Man müsste also wirklich ein „paar Rutinen“ schreiben, ich fürchte aber dass das bei einer so komplexen Sprache wie Basic ziemlich ausarten würde.
Naja , er könnte mit Debug einen Bootsektor schreiben , der
eine Meldung ausgibt . Damit hätte er ein erstes Hurra und
bräuchte nichts für aufwendige Werkzeuge bezahlen . Debug
nimmt Assemblerbefehle an , aber keine benannten Variablen
usw… aber man kann es schaffen , damit auf 512 Byte zu
kommen . Ich sagte nicht , das man Debug nehmen „muss“ ,
sondern , „man kann noch“ . Hierbei beziehe ich mich auf die
Programmgröße des Bootsektors .
Ich kenne mich mit debug nicht aus, aber für einen einfachen „Hello World“-Kernel sollte es reichen. Vorraussetzung dafür ist natürlich dass debug binäre Dateien erstellen kann die sich unter Realmode ausführen lassen.
Ich würde übrigens davon abraten einen eigenen Boosector zu schreiben, da dies aufgrund der 16bit Realmode-Umgebung (DOS, nur BIOS-Interrupts) relativ kompilziert und frustrierend sein kann. Anstatt dessen kann man genausogut einen bereits bestehenden Bootsector wie GRUB verwenden.
Für Werkzeuge bezahlen musst du sowieso nie - es gibt ja immer noch Open-Source:
NASM - Assembler, gut zum Programmieren von Bootsectoren geeigenet
GCC - C(++) Compiler, bei der Kernel-Programmierung in weit verbreitet da systemunabhängig (Windows: MinGW, Cygwin)
Alle Geräte benötigen einen Treiber, auch Graphikkarte (!) und
Festplatte. Die Programmierung der meisten Treiber ist nicht
allzu schwer, da man leicht Information und Technische
Spezifikationen findet.
Na da hast Du aber was schönes geträumt …
Höchstens für eine einzelne Grafikkarte gelingt vielleicht die
Programmierung , und das dauert trotzdem lange genug .
Ein einfacher Zugriff auf die Festplatte mittels IDE Protokoll
und auf das VGA mittels Bios wäre noch zu schaffen , meine
ich .
Auf das Problem mit Graphikkarten habe ich ja kurz darauf hingewiesen:
Die Graphikkartenhersteller nVidea und ATI veröffentlichen jedoch keinerlei
Infos über ihre Karten, man kann sie daher nur mithilfe der VGA oder
VESA-Standards ansprechen. Der VGA-Standard wird von allen Karten unterstützt,
bietet aber nur sehr gering Auflösungen (max 640*480*4), VESA hingegen erlaubt
es alle, auch unter Windows möglichen, Auflösungen einzustellen, wird
allerdings nicht von allen Herstellen unterstützt.
Der VGA-Standard ist übrigenz recht gut dokumentiert so dass man einen VGA-Treiber wirklich relativ einfach selbst schreiben kann:
http://www.italios.it/oslib/mode13h_nobios.zip
Der wesentlich neuere VESA-Standard hingegen kann nur sehr aufwendig direkt angesprochen werden, es ist daher sinnvoller auf das Video-BIOS zurückzugreifen.
Der große Nachteil der BIOS-Interrupts ist zum einen ihre Langsamkeit und zum anderen die Tatsache, dass sie unter ProtectedMode nur mithilfe eines V86-Taskes aufgerufen werden können. Da ein solcher Task nicht ganz einfach zu Programmieren ist und zumindest einen Taskmanager (und damit einen Speichermanager) benötigt, würde ich deshalb Vorschlagen den gewünschten Videomodus bereits während des Bootens zu setzen und dann direkt in einen Linearen Framebuffer zu schreiben.
Ein IDE-Treiber ist, wie schon gesagt, nicht alzu schwer, das größere Problem ist dabei das Dateissystem.
Ich verstehe übrigens das C nicht besonders und wenn ich was
schreibe , dann mit VB 5.0 ( zur Zeit ) und ich muss
feststellen , Vb ist schnell genug für vieles auf
Pentium100 Mhz und VB läßt sich Klasse mit ein bischen
Assemblercode gewaltig aufbessern .
Ich bezweifle ja garnicht, dass VB ausreichen schnell ist aber darum geht es ja auch garnicht. Das Problem ist vielmehr dass VB zusehr auf Windows zugeschnitten ist und daher zur Kernel-Programmierung nur mit allergroßten Aufwand verwendet werden kann.
Abgesehen davon ähneln sich die Highlevel-Sprachen. Es sollte daher nicht allzu schwer sein als Basic-Programmierer C(++) zu lernen, da das Prinzip gleich bleibt.
Grüße,
Daniel Raffler
