Thema: Laden eines C-Kernels

[Svenska]

Naja, COM würde ich eher als subset der flat binary bezeichnen... gibt halt noch ein paar Unterschiede (die Einsprungadresse ist festgelegt auf 0x100 [ja ich weiß, Segment ist egal] und die Größe des Gesamtsystems ist auf 64K beschränkt).

Daher überrascht mich das doch etwas, dass man das dann nicht einstellen kann. Was solls. Für den Anfang sollte COM jedenfalls reichen.

Und was C mit dem PM zu tun hat, erschließt sich mir nicht. Wenn du jetzt wenigstens gesagt hättest, Treiberprogrammierung in C++ macht sich leichter, gut, Geschmackssache, aber der war...naja.

[kevin]

So meinte ich das auch: COMs sind flache Binaries, auch wenn nicht alle flachen Binaries COMs sind. Aber eine echte Einschränkung ist das ja für den Anfang nicht. Und später braucht man sowieso ein ordentliches Binärformat, da macht dann auch eine flache Binary ohne diese Einschränkungen keinen Spaß mehr...

[Programm Noob]

was für anständige Binärformat gibtes denn, die mit der Segmentierung klar kommen? ELF scheidet ja aus zwei gründen aus, ersten nur für 32 und 64 Bit geeignet und es kommt laut erik mit segmentierung nicht klar.

[kevin]

Ich hab mich damit nicht näher beschäftigt, aber ich schätze, .exe wird wohl tun, wenn DOS das verwendet hat.

[Svenska]

Das Executable-Format muss eigentlich keine Segmentierung unterstützen, solange man die einzelnen Bestandteile des Programms (also die Sektionen) unter der Maximalsegmentgröße hält, also im RM unter 64K. Dann braucht man nur die Sektionen als Segmente behandeln und gut ist.

EXE gibt es in verschiedenen Geschmäckern, von denen nicht alle geeignet sind:

MZ (DOS-16bit)
LE (Win16-VxD und OS/2)
LX (OS/2) [ungeeignet, LX=Linear eXecutable]
NE (Win16)
PE (DOS-32bit/Win32) [nur 32-Bit]

Nach hier ist OBJ sogar standardisiert. (Asche auf mein Haupt, ich dachte, das wäre ein Borland-exklusiv-Format.)

Außerdem gibt es das a.out-Format, welches die frühen Unixe verwendeten; der Nachfolger COFF ist fast eine PE-EXE.

Gruß,
Svenska

[erik.vikinger]

Hallo,


das MZ-EXE-Format von DOS sollte auch für größere RM-Programme (die für Code und Daten jeweils mehrere Segmente benötigen) sehr gut tauglich sein. Der Code zum relozieren dürfte IMHO recht wenig sein aber ich schau mir da gerne noch mal die Spec an (falls ich die noch mal finde).
Ich hab mal einen Boot-Sector für FAT12/16/32 entwickelt der eine EXE aus dem Stammverzeichnis lädt (bis max 512kB, beliebig fragmentiert) und dann aus dem Header den Einsprungspunkt ermittelt und eben anspringt. Das ganze hat in die gut 400Bytes gepasst und es fehlte nur der Code zum relozieren (der hätte aber auch nicht mehr rein gepasst, den von der EXE gewünschten Stack habe ich ebenfalls ignoriert). Ich denke es wäre möglich den Code zum relozieren in die EXE selber zu packen, man müsste nur ein kleines Assemblermodul dafür bauen und dessen Einsprungspunkt beim Linken angeben, dieser Code muss dann die EXE-Datei im Speicher durchgehen und an den gewünschten Stellen modifizieren und als letztes dann den Einsprungspunkt der crt0.asm anspringen (dieser Sprung darf sogar von der Relozierung abhängen). Das Problem ist das diese EXE dann auch im Speicher fest liegt also eventuell nur noch recht wenig Speicher, von den 640kB, für weitere User-Mode-Programme übrig bleibt.

was für anständige Binärformat gibtes denn, die mit der Segmentierung klar kommen?

Wenn Dir das MZ-EXE-Format von DOS nicht gefällt bleibt noch das NE-EXE-Format von Windows 2/3 übrig aber das bietet IMHO nur wenig bis gar keine Vorteile was die Speicheraufteilung angeht.

ELF scheidet ja aus zwei gründen aus, ersten nur für 32 und 64 Bit geeignet und es kommt laut erik mit segmentierung nicht klar.

Ich kann nicht mit Sicherheit behaupten das ELF absolut nicht mit Segmentierung zurecht kommt aber es dürfte wohl ziemlich aufwendig sein die Segmentierung in ELF hinein zu prügeln, ein eigenes Format mit passenden Loader macht IMHO signifikant weniger Arbeit. Einen eigenen Linker bräuchte man eh da keiner der Linker die ELF können ein ELF mit Segmentierung erzeugen kann.

Das Executable-Format muss eigentlich keine Segmentierung unterstützen, solange man die einzelnen Bestandteile des Programms (also die Sektionen) unter der Maximalsegmentgröße hält, also im RM unter 64K. Dann braucht man nur die Sektionen als Segmente behandeln und gut ist.

Also ganz so optimistisch sehe ich das nicht, man benötigt auch Relozierungen bei denen nur die Segmentnummer (oder Selector im PM) eines bestimmten anderen Segmentes irgendwo eingetragen wird. Genau solche Dinge fehlen bei ELF & Co.


Grüße
Erik