Lowlevel
Lowlevel => OS-Design => Thema gestartet von: Kevin_ am 15. February 2005, 22:07
-
Weiß jemand wie die "großen" Betriebssystem ihr API gemacht haben? Über Interupts? Wenn ja dann wären das doch viel zu wenige oder? Wenn ihr bei euren OS schon ne API habt: Wie habt ihr sie realisiert?
-
Ne... das sind nicht zu wenige...
Schau es gibt ja 256 Interrupts... (Ich weiß man kann nicht alle davon verwenden -> BIOS belegt auch ein paar :roll:) Wenn du es bei deinem Betriebssystem so wie in Dos machst kannst du mit AH einen Parameter an den Interrupt übergeben.
Beispiel:
Interrupt 21 unter Dos:
AH Funktion
----------------------------------------------------
00 Program termination
01 Keyboard input
02 Display output
...
E2 Directory functions
...
F9-FF OEM functions
AH ist 1 byte groß... also 256 mögliche Parameter => 256*256 = 65 536 mögliche API-Funktionen (nicht ganz ;-))
Das sollte bei weitem reichen denke ich...
WM_HOPETHISHELPS
fasmat
PS.: Fals ich mit meinen Überlegungen falsch liege, wird bestimmt jemand so freundlich sein und mich korrigieren. :-)
-
Ich weiss es nicht, aber ich vermute, dass Windows eine Art Messagequeue bastelt, in der dann eingetragen wird "Anwendung xy hat Funktion yz in Datei xz aufgerufen" und der Kernel irgendwann diese Schleife durchgeht und die API-Funktionen aufruft... könnte ich mir so vorstellen. So ähnlich wuerde ich es sicherlich machen :)
Svenska
-
ich werde es auch mit nem int machen, und man kann es sogar so machen, dass man ganz eax als funktionsnummer benutzt, was dann wohl bei weitem reichen wird ;-)
-
Nehmen wir an, man hat 150 für die API freie Interrupts und EAX ist die Funkionsnummer: 150 * 2^32 = 644245094400 Funktionen, welchem OS reicht das nicht? ;)
-
Nehmen wir an wir haben einen 64Bit Prozi dann sind es 2.767.011.611.056.432.742.400 Funktionen oder in Worten:
2 Trilliarden, 767 Trillionen, 11 Billiarden, 611 Billionen, 65 Milliarden, 432 Millionen, 742 Tausend, 4 Hundert
Das wäre dann wohl noch ausreichender^^
-
Mann, Mann, Mann... und ich hab mir verkniffen so eine Rechnung zu posten... ](*,)
-
man kann noch ganz anderes Zeug berechnen *g* aber das wäre zuviel des guten
-
Aber bei 32 und 64 bit muss man sich dann was einfallen lassen, damit die Kompatiblität erhalten bleibt ;)
-
Aber bei 32 und 64 bit muss man sich dann was einfallen lassen, damit die Kompatiblität erhalten bleibt ;)
warum? was muss man sich einfallen lassen?
-
Na wenn man jetzt z.B. einen Interrupt mit 70 000 Funktionen proggt, wie soll man die dann mit einem 16 bit Prozessor, wo man doch nur 65 536 ansprechen kann, verwenden?
Ok, das Beispiel is vieleicht ein bisschen unwahrscheinlich ;)
-
wenn ich im realmode bin, ist es unwahrscheinlich das is soviele intfunktionen selbst proggen werde
im PM schon eher, und PM hat eigentlich fast zwangsläufig 32bit(286 zählt nicht) also muss man da eigentlich nicht drauf achten, nur bei 64Bit dann wieder
-
wenn ich im realmode bin, ist es unwahrscheinlich das is soviele intfunktionen selbst proggen werde
im PM schon eher, und PM hat eigentlich fast zwangsläufig 32bit(286 zählt nicht) also muss man da eigentlich nicht drauf achten, nur bei 64Bit dann wieder
hm... also wer eine api baut, die über 2^32 funktionen hat, der hat was erreicht, aber ich denke der wird so schlau sein, dass dann nicht mit einer funktionsnummer zu machen, weil er sonst ewig weit abfragen muss, sondern eher mit einem MSG-System.
-
wer schlau ist fragt überhauptnicht ab sondern macht ne calltable ;)
call [eax] eax verweist auf eine tabelle in der die adressen für die jeweiligen funktionen stehen, nix mit prüfen oder so.
Im Prinzip arbeit so ein C-Switch.
-
auch nicht schlecht, aber dann braucht man wieder so ne tabelle... man könnte es auch in bereiche aufteilen, dann könnte ein treiber als ersatz gewisse teile übernehmen, wenn neue hardware rauskommt... z.B.
bereiche:
1 = Grafik
2 = Drives
3 = USB
4 = Sound
und dann gibt man einen aufruf etwa so an:
sendapiquery bereich/nummer
dann hat man mehr aufteilung und kann auslagern.
-
Ein gigantischer vorteil bei den Tabellen ist, dass du je nach Prozessortyp andere Routinen eintragen kannst. Oder je nach Grafikkarte. Alles sowas.
Am Anfang stehen in der Tabelle nur Standardfunktionen die immer gehen sollten. Dann Erkennungscode für z.B. Graka, dann können betreffende Funktionen umgeändert werden, so das beschleunigte Funktionen verwendet werden.
-
Unter Windows wir ja eh so eine Art Calltabelle für die API gemacht.
Man kriegt das Handle einer Library mit dem Befehl LoadLibrary.
Als Parameter wird der Dateiname der Bibliothek angegeben.
Dann bekommst du das Handle zurück.