Lowlevel
Lowlevel => OS-Design => Thema gestartet von: eldrige am 31. January 2007, 16:46
-
Hallo Zusammen,
Zuerst einmal muss ich Euch für die grossartige Arbeit gratulieren. Vor etwa 5 Jahren konnte ich nur ein einziges Deutsches Tutorial zu diesem Thema finden, in der Zwischenzeit ist aber schon diese Seite entstanden wo man wirklich die letzte Informationen finden kann, die man brauchen könnte!
Nun zu meiner Frage. Ich weiss, dass sie einige hier (wenn nicht alle) etwas ergärn wird, aber ich muss es einfach mal versuchen: Gibt es wirklich keine alternativen zu Assembler und C/C++? Kann man ein OS nicht mit Basic programmieren? Ich denke schlussendlich ist es egal was man für eine Sprache nimmt, wichtig ist nur, dass man keine Windows/Linux Systemspezyfische API verwendet, sondern reine Prozessor befehle, die dann auf jedem Rechner ausgeführt werden können, oder?
PS: Oder besser gefragt, was kann man sonst für die OS Programmierung verwenden ausser ASM & C/C++?
Gruss und Danke im Voraus.
eldrige
-
Gibt es wirklich keine alternativen zu Assembler und C/C++?
Wer hat das den behauptet? Natürlich gibt es Alternativen.
Ich denke schlussendlich ist es egal was man für eine Sprache nimmt, wichtig ist nur, dass man keine Windows/Linux Systemspezyfische API verwendet, sondern reine Prozessor befehle, die dann auf jedem Rechner ausgeführt werden können, oder?
Genau.
Oder besser gefragt, was kann man sonst für die OS Programmierung verwenden ausser ASM & C/C++?
Hab schon öfters gelesen, das Pascal mindestens genauso gut für Kernel-Pragrammierung geeignet sein soll wie C.
-
Danke :)
und ausser Pascal, was kann man sonst noch verwenden?
Gruss
-
Du kannst dein OS in jeder Sprache programmieren, sogar in Java oder C#, wenn du die entsprechende Laufzeitumgebung hast. Allerdings wirst du Sachen wie direkte Speicher und Registerzugriffe benötigen, und dass ist in manchen Sprachen höchstens über Umwege erreichbar.
-
Verwendbar sollte eigentlich jede Sprache sein, für die es einen Compiler gibt, der Code für i386 erzeugt - die Frage ist nur immer, mit welchem Aufwand. Sehr hilfreich wäre es, wenn die Sprache Inline-Assembler unterstützt, denn ganz ohne geht es eben doch nicht.
Ich wüßte aber jetzt keinen hier, der eine andere Sprache als Assembler, C/C++ oder Pascal benutzt. Das dürften einfach die naheliegendsten Alternativen sein. Wenn du dich für was anderes entscheidest, mußt du dich auch bewußt sein, daß du ein Stück weit etwas machst, was noch kein anderer hier gemacht hat und wo du tendenziell eher alleinegelassen bist, wenn es Probleme gibt. (Andererseits, das sollte ich vielleicht auch nicht verschweigen, war das gerade der Grund, warum ich einen Kernel in Pascal angefangen habe: In C habe ich mich zu viel beim planlosen Kopieren von fremdem Code erwischt und in exotischere Sprachen muß man Beispielcode zumindest übersetzen, wobei man dann wenigstens ansatzweise ein Verständnis gewinnt ;))
-
Vielen Dank taljeth
Ich bin gestern zufällig auf eine andere Sprache gekommen (die Euch eventuelle bekannt ist). Es handelt sich um Weiterentwicklung von QBasic und die heist jetzt FreeBasic http://freebasic.de/ .
Die Sprache macht einen sehr netten Eindruck! Wird Compiliert, unterstützt InLine Assembler und und und.
Nun ich sehe langsam ein was Du meinst. Wenn man der 'Erste' ist, dann geht es sehr schwer, weil man keinen nach Erfahrung fragen kann. Für mich stellt sich jetzt die Frage, wo und was muss ich fragen, weil, die die mit FreeBasic programmieren, die machen bestimmt kein OS und die die OS programmieren, haben bestimmt mit FreeBasic nix zu tun!
Um aus dieser etwas schwirigen Lage heraus zu kommen, werde ich hier einfach mal folgendes Fragen:
Welche Sprachfunktionalitäten braucht man ausser InLine Assembler? Braucht man irgendwelche Interupts Funktionen (sind die Prozessorseitig gegeben oder habe ich das mit DOS verwechselt)?
Noch vielleicht eine kleine Frage: Wenn ich ein grafisches OS erstellen möchte, dann muss ich also grafische Prozessoranweisungen verwenden (es geht natürlich nicht mehr über WIN API, DirectX oder OpenGL). Nun welche Möglichkeiten hat man da? Ich stelle mir vor, dass Prozessor nur einen einzigen Befehl zur Verfügung stellt und zwar das Zeichnen eines Punktes. Die restliche Formen müsste man dann selber programmieren bzw. eigene OS Funktionen dafür schreiben, oder? Oder werden grafische Objekte gezeichnet indem man direkt in den Grafischen Speicher die Bits setzt?
Hmmm sorry falls es etwas zu viel auf einmal ist, aber es sind denke ich nur zwei Fragen. Danke schon mal im Voraus.
eldi
-
Moin
Grafische Prozessoranweisungen? was ist das?
dein prozessor stellt dir direckt keine befehle bereit mit denen du was zeichnen kannst (ala punkt x,y in farbe f). das must du schon selber mit der hardware und dem speicherbereich ausmachen, den die grafikkarte verwendet. (entsprechenden wert an die entsprechende Addresse schreiben)
Sprich deine Programiersprache muss direckte Speicheraddresierung unterstützen.
Wird ein Intterupt ausgelöst, unterrbricht der Prozessor dein Programm, lädt einen bestimmten speicherbereich, und springt dann an diese addresse, um die entsprechende Interruptservicerotine auszuführen. Was must du somit tun, den Funktionspointer an die entsprechende stelle im speicher hinterlegen. Und ggf dafür sorge tragen, das die Funktion auch die Anforderungen einer Intteruptservicerotine erfüllt. z.B. IRET anstelle von ret am ende, damit der prozessor weis, das der Interrupt zuende ist.
Also möglichkeit für Asm bzw Inlineassembler ist notwendig
Direkte speicheraddresierung
Erstellen Obj dateien, die hinterher passend verlinkt werden können.
@Korona Was soll das für ein OS sein, das erst mal eine Laufzeitumgebung benötigt? da ist doch die Laufzeitumgebung doch schon fast das OS selbst. zumindest bei java. bzw die laufzeitumgebung von sun selber braucht son wieder ein OS.
Bei java könnte ich mir vorstellen, nur den Syntax zu verwenden. ( laufzeitumgebung überbord werf ) den java BinaryCode dann in Mashinen code übersetzen und versuchen zum laufen zu bringen. Weiter wird das ansprechen von speicher nicht möglich sein, da der syntax das garnicht hergibt. sprich man muss dann sowas von ausen durch den linker machen. ( Statisches Classen element VideoBuffer[65536] wird an addresse 0xA0000 gelinkt) Inlineassembler?
Mir ist bekannt, das java auch im embeded bereich eingesetzt wird, es java prozessoren gibt (Java erweiterungen für arm cors). nur hat das weniger was mit dem java zu tun, das ihr kennt.
gruss
-
Noch vielleicht eine kleine Frage: Wenn ich ein grafisches OS erstellen möchte, dann muss ich also grafische Prozessoranweisungen verwenden (es geht natürlich nicht mehr über WIN API, DirectX oder OpenGL).
Ich sehe, du hast noch viel zu lernen. ;) Macht nichts, jeder fängt klein an. Aber mein Tip an dich wäre, Grafik für das nächste Jahr mal komplett zu vergessen. Es gibt viel anderes, was stehen sollte, bevor es überhaupt Sinn macht, sich damit zu beschäftigen. Wenn du mit deinem exotischen Compiler ein "Hello world" auf dem Bildschirm hast, hast du vermutlich schon ein ganzes Stück geleistet.
-
@Termite
Tut mir leid, dass ich mit mich LowLevel Programmierung zu wenig auskenne. Ich bin Profi-Programmierer, verwende aber in der letzten Jahren ausschliesslich DOTNET und VBA (MS Access, MS Excel) und dort sind die Funktionen und Klassen einfach wie eine BlackBox. Man weisst nicht was drin steckt und man interessiert sich auch nichtdafür. Hauptsache man kommt schnell zum Ziel und es funktioniert.
Jetzt wo ich mich mit LowLevel Programmierung befasse, sehe ich dass es ganz andere Welt ist und das mein Wissen über DOTNET & Co wenig nützt!
Ich kann also etwas Zeichnen (z.B. einen Punkt) indem ich direkt die Bits in der Videomemory setze. Gibt es dafür hier irgendwo ein kleines Tut, der das erklärt? Danke.
Im FreeBasic Forum habe ich bereits nachgefragt, ob die Sprache direkte Speicheradressierung unterstützt. Ich habe das gefühl, dass man sich darunter schwierig etwas vorstellen kann. Ist das einfache Pointeradresierung? Oder kann man diese Adressierung auch über Assembler machen (weil FreeBasic unterstützt ausch InLine Assembler, dann könnte ich es auf die Art und Weise machen).
@taljeth
Falls man mit FreeBasic auch zum eigenen OS kommen kann, dann denke ich wird es viel schneller sein, als mit C/C++ :) .
Haste die Homepage von FreeBasic angeschaut? Meinst Du man könnte damit wirklich ein OS coden?
Gruss
-
Hallo,
Ausgaben auf dem Bildschirm kannst du prinzipiell auf zwei Weisen machen:
(a) du programmierst die Register und schreibst in den Grafikspeicher
(b) du rufst passende Interrupt-Routinen vom BIOS (bzw. bei EGA/VGA vom Grafikbios) auf (ich glaub int 10h is das)
(a) heißt, eigenen Grafiktreiber programmieren und sich mit der Hardware auseinander setzen.
(b) heißt, sich auf VGA (oder VESA) beschränken und Geschwindigkeitseinbußen in Kauf nehmen.
Die Speicheradressierung ist auch so 'ne Sache, weil du ja im Real Mode und im Protected Mode die gesamte Speicherverwaltung komplett neumachen musst. Inwiefern Freebasic dafür geeignet ist, weiß ich nicht, aber du bist im Protected Mode auch bestimmten Beschränkungen unterworfen (keine privilegierten Befehle außerhalb des Kernels, verschiedene Speicherbereiche...). Wenn Inline-Assembler unterstützt wird (oder du sogar eine Assembler-Bibliothek einbinden kannst), sollte es aber prinzipiell möglich sein. Die Frage ist nur, wie weit du den Aufwand treiben möchtest - wenn es am Ende darauf hinauslaufen würde, 80% in Assembler schreiben zu müssen, würde ich nocheinmal darüber nachdenken.
Interrupts werden dir vom BIOS gegeben, solange du dich im Realmode befindest. Danach musst du alles selbst machen. DOS stellt dir aber auch Interrupts zur Verfügung (z.B. int 21h, der DOS-Funktionsverteiler), die du ohne DOS nicht nutzen kannst.
Aber bedenke eins: Für Assembler brauchst du keine Unterstützung, für C auch nicht. Aber du wirst wahrscheinlich nicht umhin kommen, für dein Freebasic eine Laufzeitbibliothek zu programmieren. Sonst funktioniert ja kein PRINT (weil kein Bildschirm vorhanden ist), kein DIM (weil ja die Speicherverwaltung für Variablen fehlt) usw... also die elementarsten Sachen fehlen.
Gruß,
Sebastian
-
Aber bedenke eins: Für Assembler brauchst du keine Unterstützung, für C auch nicht. Aber du wirst wahrscheinlich nicht umhin kommen, für dein Freebasic eine Laufzeitbibliothek zu programmieren. Sonst funktioniert ja kein PRINT (weil kein Bildschirm vorhanden ist), kein DIM (weil ja die Speicherverwaltung für Variablen fehlt) usw... also die elementarsten Sachen fehlen.
:-(
Danke trotzdem.
-
Ist der Compiler selbst in FreeBASIC geschrieben? Das wäre ein klares Zeichen, daß damit alles machbar ist.
-
Nabend
In c/c++ darf man auch nicht einfach so alles verwenden. sonst knalltz auch. Includs von bibliotheken gehen ja auch nicht, da di lib nicht portiert ist. new / delete, alloc malloc, realloc das gleiche.
Solang kein funktionen aufgerufen werden, oder Objecte verwendet werden die man nicht selber geschrieben hat sollte alles in ordnung sein. Nur Basic könnte so böse sein, Sachen wie Print einfach immer mit anbieten zu wollen, ohne vorher einen Include, import, use,... zu machen.
gruss
-
Könnte jemand von Euch schnell einen Blick auf FreeBasic Homepage werfen http://freebasic.de/index.php ? Danke.
Falls es gar nicht für ein OS geeignet ist, dann könnte ich mir viel Zeit sparen. Selber werde ich es erst zu spät merken, dass es vielleicht nicht geht.
Zu finden ist unter anderem auch folgendes:
- FreeBASIC (kurz FB) ist ein recht junges Projekt.
- Es ist ein Basic-Compiler, der auf Windows und Linux und auch DOS verwendbar ist.
- FreeBASIC ist kompatibel zur Syntax von Microsoft's QuickBASIC das gegen Ende der 80'er Jahre entwickelt wurde. Das ist auch der Grund, warum man Free- und QuickBASIC-Foren meist zusammen findet.
-Er ist für jedermann frei erhältlich, weil es ein Open-Source-Projekt ist. Das heißt Du kannst ihn kostenlos herunterladen und benutzen.
-Programme, die damit kompiliert werden, laufen ohne Zusätze wie Runtime-Interpreter.
-Und ob Du Deine Programme dann frei weitergibst, oder als Shareware oder gar als Nichtfreie Software anbietest, ist Deine freie Entscheidung.
Eine vollständige Liste findet man auf der Englischen Seite unter: http://www.freebasic.net/index.php/about?section=features
PS: Obwohl, ich habe dort schon Leute angetroffen, die damit ein OS proggen (siehe http://mao.freebasic.de/exorc/blog/index.php )
Von dem her würde ich auch meinen, dass damit alles möglich wäre.
Gruss
-
Hiho
Also ich habe mir den mal angeschaut und bin mir nicht ganz sicher. Wie ich gesehen habe, kann man den compiler sagen, dass man keine Standartbibliotheken haben will und dass er es auch nicht eigenständig linken soll.
dass DIM nicht gehen soll, wie es Svenska gesagt hat, kann ich mir nicht vorstellen. ein "DIM test as integer" ist im grunde genommen nichts anderes als "int test" in C/C++ und das funzt ja auch. Wo Svenska aber recht hat ist, dass man sowas wie Print nicht nutzen kann, da es an eine Standartbibliothek gebunden ist.
Wie ich gesehen habe, kann FB auch mit Pointern umgehen, also anders gesagt kann FB auch direkt mit Speicheradressen arbeiten. Von daher kann man schonmal etwas rumspielen. sollte etwas nicht möglich sein, hast du ja immernoch inline ASM und kannst zur not nen c/c++ modul noch backen, das du dort mit integrierst.
Ciao JensFZ
-
Vielen Dank JensFZ,
In der Zwischenzeit habe ich dort einiges betrefend FreeBasic erfahren. Man ist noch immer gespalten in der Meinung, ob man mit FreeBasic ein OS coden kann oder nicht, weil sehr viele Fake OS damit schon gecodet wurden.
Auch über Sinn und Zweck einer neuen OS Entwicklung wurde geschrieben (was hier auch sicher öfters der Fall sein wird). Meiner Meinung nach hängt die Effektivität eines OS grössten Teils davon welche Entwicklungstools man damit auch noch ausliefert. Das heisst wenn ich für ein neues OS nur in Assebmler coden kann, wird mich die Lust nach neuem OS schnell vergehen. Wenn aber jemand eine einfache Sprache (etwa BASIC o.ä.) zur Verfügung stellen würde, dann könnte ich mir vorstellen, dass ich eine oder andere Applikation, die ich bereits in Windows programmiert habe, auch dort portiere. Wenn von mehreren Milionen Programmierer nur jeder 10te so etwas macht, dann kann auch der 'kleinste' OS sehr schnell bekannt werden, weil es dafür einfach viele Applikationen gibt!
So, Frage ist nun, soll man ein OS coden, oder soll man besser zuerst eine einfache Sprache entwickeln, mit der man dann ein OS coden kann und folglich auch alle Applikationen für das OS? Was die Grafik zum Beispiel betrifft, da müsste man nur ein Befehl für das Zeichnen eines Punktes zur Verfügung stellen und schon konnte man mit der neuen Sprache alle mögliche Funktionen für das Zeichnen von Kreis, Rechteck usw. erstellen, folglich wäre ein Grafisches OS in wenigen Tagen fertig, oder?
Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist! Dass man noch immer C/C++ zur Verfügung hat nützt, wie wir es sehen, wenig, weil der grösste Teil von diesen Millionen-Programmierer machen doch die NICHT C/C++ Programmierer aus!
Gruss
-
Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist!
Jede Sprache verwendet nur Prozessorbefehle. Nur kannst du halt für ein OS im allgemeinen keine Bibliotheken benutzen - das ist ja genau das, was das OS selbst bereitstellen soll, das ist die Definition eines OS. Also ich bin recht froh, daß ich nicht einen Browser mit integriertem Treiber für meine Netzwerkkarte brauche.
Vielleicht willst du in Wirklichkeit gar kein OS schreiben, sondern nur eine Shell für DOS?
-
So, Frage ist nun, soll man ein OS coden, oder soll man besser zuerst eine einfache Sprache entwickeln, mit der man dann ein OS coden kann und folglich auch alle Applikationen für das OS? Was die Grafik zum Beispiel betrifft, da müsste man nur ein Befehl für das Zeichnen eines Punktes zur Verfügung stellen und schon konnte man mit der neuen Sprache alle mögliche Funktionen für das Zeichnen von Kreis, Rechteck usw. erstellen, folglich wäre ein Grafisches OS in wenigen Tagen fertig, oder?
man könnte die applikation sehr schnell auf andere gui systeme von anderen Betriebsytemen portieren, das ja. nur besonders schnell ist das leider nicht. für jden der ca 1Millon pukte muss man eine funktion aufrufen.
Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist! Dass man noch immer C/C++ zur Verfügung hat nützt, wie wir es sehen, wenig, weil der grösste Teil von diesen Millionen-Programmierer machen doch die NICHT C/C++ Programmierer aus!
ich versteh hir grad nur banhof.
Prozessor Befehle sind für mich ASM anweisungen wie MOV, ADD, INC, DEC, SUB MUL, CALL RET, JMP,.... oder verstehe ich dich da falsch? Somit ist der Assembler die Programiersprache die die Prozessorbefehle verwendet.
Wiso soll die programiersprache daran angelehnt sein? Eine API stellt neue Funktionen und "neune Befehle" zur verfügung, die der Entwickler verwenden kann, damit er nicht alles selber machen muss. das ich ja auch der grund wieso es Betriebsysteme gibt. Ein Betriebsystem ist eigentlich nichts anderes als eine sammlung von Funktionen, (manche mögen auch befehle dazu sagen) die gewisse wiederkehrende Aufgaben bereits implementiert haben, und somit die Software entwicklung beschleunigen und vereinfachen. (Datei verwaltung, Netzwerkschnitstellen, GUI, Prozesse, Resorcenverwaltung, Interprocesskomunikation,...)
In C/C++ kannst du die zusätzlich zur verfügung gestellten Funktionen verwenden, musst dies aber nicht, du kannst sie auch selber implementieren. Das ist aber in jeder Programiersprache so. In C/C++ passiert das durch Includes, in java durch imports,...
gruss
-
ich versteh hir grad nur banhof.
Prozessor Befehle sind für mich ASM anweisungen wie MOV, ADD, INC, DEC, SUB MUL, CALL RET, JMP,.... oder verstehe ich dich da falsch? Somit ist der Assembler die Programiersprache die die Prozessorbefehle verwendet.
Klar und genau das ist für die meisten aktuellen Programmierer das grösste Problem. Du kannst wahrscheinlich jedes Algorithmus in wenigen sekunden in ein Assembler Code umwandeln, ich (und Millionen andere) nicht. Was wir machen können ist das selbe aber in einer Sprache, die uns viel verständlicher aussieht, und die ist in der Regel ein BASIC Dialekt (sei es VB, VBA, VB.NET, FREEBASIC o.ä.).
Ich dachte eben, dass die FreeBasic sprache so etwas ermöglichen könnte, also dass man auf alle Prozessor Befehle zugreiffen kann, aber scheinbar werden beim Compiler noch andere Lib's gelinkt, die dann in eigenem OS nicht 'verstanden' werden (ja klar wenn es die gar nicht gibt). Also ein Basic mit dem man schon ein eigenes OS coden könne wäre sicher sehr interessant für die restliche Programmierer-Welt, die sich mit Assembler nur schwer befreunden können :)
Gruss
-
Mit nichten. ich kann zwar ASM, brauch dazu aber meist die docu dazu. viel zu viele befehle, alle HW abhänging, und überal gibts kleine aber gemeine stolpersteine. Big Endian, Litel Endian, ( arm kann beides ) RISC CISC Befehlssätze, .... Aber wozu hat man den die hochsprachen geschaffen? genau deswegen. Komplexe abläufe so einfach wie möglich beschreiben zu können. Es geht ja sogar mitlerweile noch viel weiter, Model Driven Development, OOP, Aber das sollte dir ja bekannt sein.
Was dein Problem ist, das dein compiler standart libs mit einbindet. Das die in deinem os vorhanden sein müssen stimmt nicht, sie werden ja dazugelinkt. es ist eher so, das die dafür notwendigen DLLs nicht vorhanden sind, bzw auf betriebsytem spezifische sachen zugegriffen wird. in etwa so wie wenn du eine .Net verteilst. Das .Net Framwork muss installiert sein, sonst gehts nicht.
Bei C/C++ kann man das halt ausschalten. In c ist es sogar so, das die sprache an sich nur ihren syntax kennt, und alles was darin geschrieben wird platform unabhängig ist. alle zusätzlichen Funktionen wie z.B. Printf, scannf, ... müssen alle erst über einen Include hinzugefügt werden. Bei c++ machen new und delate eine ausnahme. sie sind Sprachbestandteil, der eine Platformspezifische implementierung benötigt. Aber solang man sie nicht verwendet, braucht man sie auch nicht zu implementieren.
Aber jede sprache hat seine vor und nachteile, und somit seine bereiche in der IT wo sie punkten können. Fortran obwohl es schon sehr alt ist, findet im bereich ströhmungssimulation noch anwendung, und überal da, wo Mathematik im fordergrund steht.
gruss
-
So, Frage ist nun, soll man ein OS coden, oder soll man besser zuerst eine einfache Sprache entwickeln, mit der man dann ein OS coden kann und folglich auch alle Applikationen für das OS?
Du möchtest also eine Programmiersprache entwickeln, in der man ein OS programmieren kann? Das funktioniert nicht. Wenn dein OS auf verschiedenen Prozessoren/Architekturen laufen soll, benötigst du definitiv ein paar (wenige) absolut hardwareabhängige Teile. Der Rest, der darauf aufsetzt, kann durchaus allgemein sein.
Einfacher wäre es, ein OS zu schreiben (in irgendeiner Sprache), und dann eine Programmiersprache (bzw. die nötigen Tools) dorthin zu portieren. Beispielsweise einen Basic-Interpreter (evtl. sogar Freebasic). Dann kommst du eher dahin, wo du hin willst. Das ist aber ein sehr weiter Weg.
Was die Grafik zum Beispiel betrifft, da müsste man nur ein Befehl für das Zeichnen eines Punktes zur Verfügung stellen und schon konnte man mit der neuen Sprache alle mögliche Funktionen für das Zeichnen von Kreis, Rechteck usw. erstellen, folglich wäre ein Grafisches OS in wenigen Tagen fertig, oder?
Ja. Aber die Geschwindigkeit ist nicht berauschend. Außerdem hat eigentlich jede Grafikkarte mindestens beschleunigte Funktionen für Linien und Flächen. Wenn ich den Bildschirmhintergrund einfarbig gestalten will und dabei jeden Punkt einzeln setze, kann ich selbst bei 2 GHz noch dabei zuschauen.
Also: Ja, aber du willst es nicht tun. :)
Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist!
Jede Programmiersprache erzeugt im Endeffekt nur die Prozessorbefehle. Wenn du die Windows oder Linux API auf dein OS portierst (oder nur Teile davon), kannst du durchaus alles mögliche darauf aufsetzen.
Dass man noch immer C/C++ zur Verfügung hat nützt, wie wir es sehen, wenig, weil der grösste Teil von diesen Millionen-Programmierer machen doch die NICHT C/C++ Programmierer aus!
Wie ich. Allerdings programmieren genau diese Programmierer in den seltensten Fällen Betriebssysteme - sie programmieren anhand der verfügbaren API Anwendungen.
Wenn du Freebasic auf dein Betriebssystem portierst, und dazu natürlich auch die notwendigen Bibliotheken und Funktionen, kannst du Freebasic-Programme auf deinem OS ausführen. Du wirst damit aber nicht unbedingt ein ganzes Betriebssystem auf die Beine stellen können, weil viele Funktionen stark systemabhängig sind.
Unter Linux ist der Bildschirm ursprünglich als intelligentes serielles Terminal abgebildet, Windows bildet alles als "Fenster" nach, d.h. du musst die serielle Terminals erst einmal nachbilden, um dein Programm portieren zu können. Solch eine Bibliothek brauchst du unter jedem Betriebssystem und genau darauf beziehen sich Hochsprachen. Und eben dieser Begriff fällt unter "API".
Gruß,
Svenska
-
Hmmmmmmmm :x
Na gut, dann wird nix daraus.
PS: Unglaublich wie schwer das ist obwohl es im Prinzip eigentlich sehr einfach sein sollte (man denkt nur an Z80 Programmierung o.ä.)!
Oder man erfindet ein neues Computerkonzept wo man dann all diese Treiber nicht mehr braucht! Dann wäre wohl auch die OS Programmierung wahrscheinlich viel einfacher!
PPS: Was ist aus all diesen Homecomputer OS geworden (Spectrum, Atari, Comodore usw.). Die waren schon damals viel besser als Windows 95, ganz zu schweigen von Spielen! Was mir nicht klar ist, damals verschwanden all diese Home Computer wegen Personal Computer. Jetzt kommen die Spielconsolen, die im Grunde nichts anderes sind als die Home Computers :) Komisch wie sich die Wirtschaft entwickelt!
-
Oder man erfindet ein neues Computerkonzept wo man dann all diese Treiber nicht mehr braucht! Dann wäre wohl auch die OS Programmierung wahrscheinlich viel einfacher!
Wer Hardware benutzen will, braucht Treiber. Das ist keine Bösartigkeit der aktuellen Rechnerarchitekturen, sondern eine Konstante. Wenn du dich darauf beschränkst, ein paar Buchstaben auf den Bildschirm auszugeben, wird das auch noch nicht sonderlich komplex.
-
PS: Unglaublich wie schwer das ist obwohl es im Prinzip eigentlich sehr einfach sein sollte (man denkt nur an Z80 Programmierung o.ä.)!
Da war auch die Hardware recht einfach gestrickt. Man brauchte sich nicht mit Caches oder Pipelines rumärgern, es gab keine verschiedenen Modi. Und das BIOS wurde (CP/M) vom Betriebssystem gesponsert.
Wobei die meisten Systeme zusätzlich ein eigenes Betriebssystem hatten, welches die Hardware ausnutzen konnte.
Oder man erfindet ein neues Computerkonzept wo man dann all diese Treiber nicht mehr braucht! Dann wäre wohl auch die OS Programmierung wahrscheinlich viel einfacher!
Gab es ja ... das BIOS von CP/M stellte die Grundlagen von Treibern zur Verfügung, weitere gab es nicht. Und die ursprünglichen Systeme (z.B. CAOS auf dem KC85) brauchten keine Treiber, weil sie nur auf dieser entsprechenden Architektur liefen und somit die Hardware sich nicht änderte.
Allerdings gibt es dieses Konzept inzwischen nicht mehr - und darum muss es Treiber geben.
PPS: Was ist aus all diesen Homecomputer OS geworden (Spectrum, Atari, Comodore usw.). Die waren schon damals viel besser als Windows 95, ganz zu schweigen von Spielen!
Bekannte Hardware kann man ausnutzen. Inzwischen ist Hardware aber so komplex, dass niemand da mehr durchsieht. Darum verwischen die Treiber dann die Grenzen - niemand kann/darf heutzutage ungeschert an den Registern einer modernen Graka rumpfuschen, bei Hercules/CGA/... war das noch notwendig und sinnvoll.
Schau dir mal SymbOS (http://www.symbos.de) an, das könnte in die Richtung Homecomputer OS gehen (für Amstrad CPC, allerdings ist der Source nicht ganz freigegeben). Das finde ich durchaus ein beachtliches Stück Leistung für einen Z80.
Was mir nicht klar ist, damals verschwanden all diese Home Computer wegen Personal Computer. Jetzt kommen die Spielconsolen, die im Grunde nichts anderes sind als die Home Computers :) Komisch wie sich die Wirtschaft entwickelt!
Für PCs gibt/gab es mehr Software für jeden Zweck. Als Rechentechnik noch richtig Geld kostete, hatte man -ein- Gerät und das musste u.U. für alle reichen. Eine Spielekonsole konnte eben keine Textverarbeitung. Inzwischen sind die Preise gesunken und spezielle Geräte für Spiele sind preislich nicht mehr so angesiedelt, dass man sich entscheiden müsste.
Dafür trifft die o.g. Behauptung wieder zu, dass sich die Hardware-Architektur nicht großartig verändert (PSX bleibt PSX, wie SNES auch SNES bleibt) und damit u.U. besser ausgereizt werden kann. Da allerdings moderne Spielekonsolen auch nur verkleinerte, zusammengestopfte PCs sind, relativiert sich das.
@taljeth: Du schriebst, dass du einen Kernel in Pascal angefangen hast. Irgendwie kann ich mir das nicht zu richtig vorstellen, wie das funktioniert (ich kenne nur Delphi). Welche Software (Compiler) benutzt du dafür? Kannst du mir einen kleinen HelloWorld-Bootloader mal darin programmieren? Weil Pascal würde mich schon interessieren (ich mag kein C und hab die Pascal-Syntax nunmehr zwangsweise lernen müssen... Basic fällt ja aus).
Gruß,
Svenska (Sebastian)
-
@taljeth: Du schriebst, dass du einen Kernel in Pascal angefangen hast. Irgendwie kann ich mir das nicht zu richtig vorstellen, wie das funktioniert (ich kenne nur Delphi). Welche Software (Compiler) benutzt du dafür? Kannst du mir einen kleinen HelloWorld-Bootloader mal darin programmieren?
Bootloader? Ne, laß mal, dafür nimmt man Assembler... Ich benutze eigentlich immer GRUB. Für den Kernel habe ich FreePascal (http://www.freepascal.org) benutzt. Ich kann dir auch mal einen kleinen Beispielcode geben, wenn ich daheim bin.
-
Ich habe dazu einen neuen Thread eröffnet.
Gruß
-
Ich sage es mal so, ohne Assembler kann man kein OS schreiben (min. inline Assembler braucht man an paar stellen), da z.B. C zu blöd dafür ist Register auf den Stack zu pushen (oder geht das doch?). Aber mit Assembler brauchst du keine anderen Sprachen. Warum dann viele C/C++/Pascal/Delphi etc. benutzen? Weil es einfacher und schneller ist. Ich persönlich bin lowleveler und habe spass an der x86 (und x86-64) Architektur weshalb ich alles in Assembler Programmiere.
bitmaster
-
Thema verfehlt, sechs, setzen.
-
also, um nochmal auf freebasic zurückzukommen. Es gibt ein Betriebssystemprojekt, realisiert mit Freebasic: http://www.freebasic-portal.de/index.php?s=projekt&id=3
-
3. Zeile der Projektbeschreibung: Was man können muss, um bei dem Projekt mithelfen zu können.
Als (aktiver) Programmierer solltest du mindestens C im fortgeschrittenem Stadium können, Kenntnisse in x86-Assembler sind von Vorteil,
C und ASM Kentnisse bei einem Freebasic projekt ;)
-
Ohh, sorry, ich habe mich nur auf dieser Seite umgeschaut und das gelesen. Da dachte ich, dass es gehen würde! Tut mir leid! :oops:
-
Ändert nichts daran, daß es mit Freebasic tatsächlich geht. Zumindest ein von GRUB bootbares Hello World habe ich damit schon hinbekommen. Und da das Ding Inline-Assembler kann, ist damit eigentlich alles problematische erledigt.
-
[...]Und da das Ding Inline-Assembler kann, ist damit eigentlich alles problematische erledigt.
:-D
--------------
Man kann einige/viele(?) Microcontroller in BASIC programmieren (z.B. BASCOM-Basic für AVRs).
Theoretisch währe es, wenn man GRUB verwendet möglich, Die BASIC-Variante müsste halt nur entsprechende lowlevel-befehle besitzen (wie IN und OUT). Wenn man einen BASIC-Interpreter mit GRUB lädt, könnte man sogar auf ein Kompilieren des Codes verzichten :evil: