Thema: APIs aber nicht über Interrupts

[bitmaster]

Hallöchen popöchen,

ich habe gerade den OS-Loader von OS-64 soweit fertig, dass er von einer FS64 formatierten Partition (welche steht in einer Datei) die OS Dateien lädt (auch diese stehen in einer Datei). Alles wunderbar und gut. Er lädt die Treiber, Bibliotheken, den Kernel und die Shell. Aber bis jetzt laufen die APIs alle über Interrupts (Kernel APIs über int 30h und Shell APIs über int 31h). Aber das mag ich überhaupt nicht. Denn jedes Programm soll noch mal eigene APIs mitbringen können. Und dann wären 1. 256 minus 30h Interrupts ein bisschen wenig und 2. wer sagt dass ein Programm welchen Interrupt benutzt.

Ja ich weiß, dass ist blöd ausgedrückt, aber auf jeden Fall möchte ich keine Interrupts benutzen. Jetzt frage ich mich die ganze Zeit wie ich das sonst machen kann. Da die Bibliotheken zwar immer im Speicher sind (sobald geladen und falls nicht beendet, also für jeden Task ansprechbar) aber nicht immer an derselben Adresse (Code wird größer/kleiner etc.), kann ich nicht einfach an einer Adresse springen um eine Funktion auszuführen. Ich weiß nicht wie das bei Windows funktioniert, denn da springt man doch über call MessageBoxA (z.B.) an eine feste Adresse??

Könnt ihr mir ein paar Verfahren nennen und ggf. erklären? Darüber wäre ich sehr dankbar. Zur Belohnung gibt’s dann auch bald eine neue OS-64 Version.

thx

bitmaster

[kevin]

Was du machen willst, ist IPC. Dazu haben wir im Wiki einen wunderschönen leeren Artikel.

Als Ersatz mal einen kleinen unkommentierten Linkhaufen:
http://de.wikipedia.org/wiki/Interprozesskommunikation
http://lowlevel.brainsware.org/forum/index.php?topic=1787.0
http://lowlevel.brainsware.org/forum/index.php?topic=457.0

[bitmaster]

Hmm..

demnach sollten die Bibliotheken nicht ständig im RAM sein, sondern auch nur Taks sein, die ausgeführt werden, wenn der Scheduler das sagt (durch Messages der anderen Taks)?



Meint ihr, sollte NUR der KERNEL immer im RAM sein und sonst nichts? Also auch keine Treiber, Bibliotheken oder sonst was?

thx

[kevin]

Bist du sicher, daß du APIs meinst?

Wenn du einfach nur Shared Libraries/DLLs meinst, laufen die natürlich nicht als eigener Prozeß, sondern werden dynamisch dazugelinkt. Und dann ist es wirklich nur ein normaler Call.

[RedEagle]

Wie währe es, wenn sich diese Programme bei deinem kernel (oder irgend einem Modul) anmelden, und z.B. dem system ein array mit den Funktionsadressen, sowie dem namen des Programmes hinterlassen.

wenn jetzt ein Prozess die 5. Funktion von dem Programm "xyz" aufrufen wollen, brauchen sie dem System nur mitteilen
bsp.:

Code: [Auswählen]

void (*machwas)();
machwas = (void (*)()) SYSAPI_ProgrammFunktion("program.elf", PROGRAMXYZ_FNC_MACHWAS);

if(machwas == NULL) return -1; //Programm läuft nicht mehr oder sowas...

machwas();

[bluecode]

Prozess
Ein Prozess würde ich jetzt hier einfach mal als Adressraum + alle anderen Ressourcen (Dateihandles, IPC handles, ... Anmerkung: Die Ressourcen müssen nicht unbedingt im Kernel sein, zB kann ein Dateihandle auch in einem (V)FS-Server sein <-> Microkernel) + alle enthaltenen Threads bezeichnen. Ein Prozess ist nicht schedulbar.

Thread
Ein Thread ist die schedulbare Einheit und gehört zu einem Prozess.

static library
Diese Bibliothek wird zur Linkzeit, also beim Erstellen der ausführbaren Programmdatei komplett in die Programmdatei mit aufgenommen.

shared library
1. Diese Bibliothek muss zur Linkzeit dem Linker mitübergeben werden, damit keine unaufgelösten externen Symbole auftreten und der Linker in die ausführbare Programmdatei schreiben kann aus welcher shared-library welche Funktionen kommen. Beim Laden der Programmdatei werden diese shared-libraries dann in den Adressraum des Prozesses eingeblendet und anhand der vom Linker erzeugten Tabellen alle Funktionsaufrufe des ausführbaren Programms korrekt auf die Adressen in der shared-library abgebildet.
2. Man kann solche Bibliotheken auch wie es RedEagle beschrieben hat zur Laufzeit laden über sowas wie load_library("mylib.so") und dann Funktionsadressen über irgendeine API-Funktion auslesen, aber das ist nur für Plugins nützlich und ist für eine libc ziemlich umständlich.
Shared-libraries können natürlich nicht nur in den Adressraum eines Prozesses, sondern sind so konzipiert (zumindest elf und PE), dass sie in mehreren Adressräumen gleichzeitig existieren können. Das läuft natürlich komplett transparent für den Prozess ab.

Das für Bibliotheken keine flat binary ausreicht sollte glaub ich jetzt klar sein, oder?

Microkernel
Treiber sind eigenständige Prozesse.

monolithischer Kernel
Treiber sind im Kernel enthalten.

Syscalls bzw. Kernel API
Syscalls sind die Funktionen, die nicht zum Prozess selbst gehören, aber die ein Thread direkt aufrufen kann. Dies wird über Interrupts, callgates, die 'syscall' oder 'sysenter' Instruktion erreicht. Da ein Thread somit nur direkten Kontakt (d.h. ohne den Adressraum zu wechseln) mit dem Kernel haben kann ist es zugleich die Kernel API.

IPC
Die Kernel API eines Microkernels muss nun mindestens einen Mechanismus zur Kommunikation mit anderen Prozessen (IPC) bereitstellen, damit du auch Funktionen in anderen Prozessen (also zB eines Treibers) nutzen kannst. Wie solche Mechanismen aussehen könnten steht in dem wikipedia-link von taljeth (wobei die englische Seite einiges mehr bietet, en: IPC). In einem monolithischen Kernel ist IPC erstmal eigentlich kein wirklich großes Thema (wird aber von den bekannten Kernels bereitgestellt), da der Kernel ja die komplette Betriebssystemfunktionalität enthält.

Anmerkungen: Microkernel bzw. monolithischer Kernel sind nur zwei Extreme (wenn man mal den Nanokernel außen vor lässt). Alles zwischendrin ist natürlich auch denkbar.

Das ist meine Sicht der Dinge. Logische Fehler sind selbst zu klären.
Ich hoffe es hilft.

[bitmaster]

Hmm...

Das verstehe ich nicht ganz. Dann müsste der Quellcode der API-Funktionen ja offen sein und es sich dabei lediglich um Makros handeln, die dann z.B. beim assemblieren in die Datei assembliert werden. Das müsst ihr mir noch mal erklären.

[kevin]

[ ] Du hast verstanden, was ein Linker macht

[bluecode]

Von welchen API Funktionen redest du denn gerade, bitmaster?

[bitmaster]

Also:

Ich habe einen Kernel, der Funktionen hat. Z.B. sucht eine Funktion freien virt. Speicher und weißt ihm den angegebenen phys. RAM zu. Diese Funktionen stellt der Kernel bis jetzt über den int 30h bereit. Die Shell nutzt diese Funktion für den phys. Speicher B8000h. Damit hat die Shell jetzt virt. Speicher, auf dem sie zugreift über bis jetzt Unterfunktion wie z.B. WriteMsg und WriteChar. Aber ich möchte, dass auch andere Tasks diese Funktionen WriteMsg und WriteChar nutzen können (z.B. die Datei HalloWelt.prg). Aber dazu dürfen die Funktionen ja nicht lediglich nur Unterprogramme der Shell sein. Denn die HalloWelt.prg muss ja irgendwie die Funktionen aufrufen können. Und das verstehe ich nicht, wie ich das machen soll. Da der Kernel ja allen Tasks zur verfügung steht, kann ich einfach ein Interrupt nutzen (was ich aber auch nicht toll finde). Aber wenn die HalloWelt.prg ausgeführt wird, ist der Speicher der Shell nicht mehr vorhanden, wegen dem cr3 wechsel.

thx

[bluecode]

IPC...

[stultus]

IPC, oder die Variante die auch Windows verwendet. Binary enthält Liste "Die Funktionen brauch ich", OS setzt im RAM beim Programmstart dann Adressen ein. Funktionsaufruf über Pointer.

Zur weiteren Information zu Ansatz 2 kannst ja mal nach dll/PE und Import und Export-Tabellen suchen.

[bitmaster]

IPC...

Ja wie denn, wie denn?

[stultus]

und IPC läuft meistens über feste bekannte Syscalls im Kernel, die halt Speicherbereiche entgegennehmen und anderen Prozessen irgendwie bekannt machen (bestimmte funktion aufrufen -> RPC, einfach an adresse X nen Buffer mit Nachrichten hinterlegen -> Polling...). Nötige Syscalls: Prozess finden (Name -> ID oder sowas), Nachrichtenübermittlung selbst, ggf. IPC-Handler-Routine setzen.

[bitmaster]

Und was ist, wenn ich ein Programm habe, dass eine hallo.dll benutzt und mir ein Programm aus dem Internet lade, welches zufälligerwise auch eine hallo.dll benutzt? Woher weiß jetzt dass Programm dass es 2 hallo.dll gibt? Oder unterscheidet der nicht beim Namen sondern bei etwas anderem.

Sonst müsste ja jeden Programm andere DLL Namen haben. Aber woher weiß ich als Programmierer ob ein anderes Programm den DLL-Namen schon nutzt?

[bluecode]

IPC hat überhaupt nichts mit Bibliotheken zu tun (und umgekehrt). Und unterschieden wird beim Linken woher die DLL kommt, ob von dem Verzeichnis des Programms oder aus dem Verzeichnis für die ganzen (globalen) Windows DLLs.

[bitmaster]

Ja dann, ja dann...


thx

[kevin]

Entscheide dich doch bitte endlich mal, wovon du reden willst. Von Syscalls, von DLLs, von Kommunikation zwischen unterschiedlichen Prozessen, oder was ganz anderes? Du springst hier ständig zwischen verschiedenen Themen hin und her.

[bitmaster]

Wie jetzt?

[bluecode]

Jo, ich war in diesem Thread auch nach jedem deiner Posts verwirrt und wusste nicht wovon du nun redest.