Thema: C im Real-Mode

[Strukain]

Hi there,
Also, nachdem ich nun seid 1,5 Wochen vergeblich versuche, einen C-Kernel im PM hinzubekommen (Immer Exception 13, was auch immer das sein soll, egal mit welchem Code oder welchem Tutorial), hab ich mir überlegt, doch lieber im RealMode zu bleiben und das A20 so zu lassen wie es ist. Natürlich will ich nicht auf den Comfort von C verzichten (ich weiß, ich bin zu bequem). Was muss ich tun, um einen C-Kernel in 16 Bit und im Real-Mode zu programmieren?  Ich nutze übrigens Linux und den mitgelieferten gcc-Compiler.
Kann mir jemand helfen?

[SSJ7Gohan]

Mit gcc geht das soweit ich weiß nicht, du müsstest einen 16Bit Compiler benutzen. Mit Turbo-C sollte es gehen.

Lass das A20 Gate einfach von GRUB aktivieren. Hast du den PIC remappt und eine gültige IDT aufgesetzt?

[Strukain]

So weit ich weiß, sind die TurboC-Programme aber sehr stark auf M$-DOS eingestellt. Mit den Segmenten und so. wie soll ich denn das abschalten?
An GRUB hab ich auch schon gedacht, aber ich krieg den nicht kompiliert, damit ich ihn in den Boot-Sector schreiben kann. Außerdem erfordert mein Dateisystem einen spezeillen Bootloader.

[SSJ7Gohan]

Hm, bei LOST ist ein Image von GRUB darbei. Das hat ausserdem noch VESA/VBE Erweiterungen.

[Strukain]

Na ja, aber GRUB kommt unter Garantie nicht mit LowFS klar, weil ich es erst vor ner Wochen entwickelt habe.

[Legend]

GRUB hat auch den Nachteil den Kernel im Protected Mode auch erst zu starten. Fuer den Real Mode muesste man diesen erstmal wieder verlassen.

[joachim_neu]

Cool, jemand benutzt LowFS.  
Turbo-C müsste eigendlich frei von jeglichen Bevorteilungen sein, außer den Libs, die du eh nicht verwenden darfst.

[Strukain]

Cool, jemand benutzt LowFS. Lachen

Was soll das heißen? Gibts das schon? Wenn ja, muss ich mich doch aus dem Fenster schmeißen.

Gibts eigentlich ne TurboC version für Linux? Ich glaube nicht. Und unter Windows arbeiten... Alle Tools und Nasm noch mal downloaden... Oder ich bleib bei Assembler.

[Jidder]

Strukain: joachim_neu hat euch ein FS unter dem Namen LowFS entwickelt.

Was soll das heißen? Gibts das schon? Wenn ja, muss ich mich doch aus dem Fenster schmeißen.

Bedeutet diese Reaktion, dass dein FS in LOST verwendet werden soll? Wenn es darum geht einen Patch für GRUB zu schreiben, damit es von LowFS booten kann, würde ich mich anbieten.

Turbo C sollte unter linux mit DOSEMU und/oder DOSBox ausführbar sein.

[Strukain]

Diese Reaktion bedeutet, dass jede Idee (bis auf eine, die ich hier natürlichnicht verraten werde) bereits geklaut wurde, und zwar BEVOR ich sie hatte. Ich weiß nicht wie die das immer schaffen. Hier war es zum Glück nur der Name...
Ich hab nicht vor, irgendeinen Patch zu schreiben, weil ich meinen eigenen Bootloader verwende, der im Gegensatz zu allem anderen prächtig funktioniert. Was bisher vom Kernel funktioniert: Textaugabe. Nicht mal die Eingabe eines einfachen Strings krieg ich hin. Das kann ja noch was werden...

[Another Stupid Coder]

Ich denke Joachim_neu hatte sogar ein Tutorial für sein LowFS, wenn ich mich recht entsinne.

[joachim_neu]

Rischtisch. Bitte, liebe Community, sagt einfach Joachim oder Joachim Neu zu mir, nicht immer mit Unterstrich, das is nur mein Nick.

[Legend]

So weit ich weiß, sind die TurboC-Programme aber sehr stark auf M$-DOS eingestellt. Mit den Segmenten und so. wie soll ich denn das abschalten?

Nun, was Segmente angeht, das ist ja grad der Hauptgrund warum du gcc wohl nicht benutzen kannst, und so etwas wie Turbo C (ich hab glaub ich noch irgendwo Microsoft C (nicht C++) 6.0 rumfliegen) musst.
(Hab das lange nicht gesehen, und grad auch keine Antwort dadrauf)

[Strukain]

Die Sache ist, dass, soweit ich nicht total fehlinformiert bin, Turbo C diese DOS-Segmente erstellt, damit die Programme größer als 64 KB werden können, was ja die COM-Dateien nicht sein dürfen, die EXEs aber schon. Darum wird (laut meinem uralten Büchlein, das ich noch nicht weggeschmissen habe ) immer eine DATA, eine CODE und eine STACK-Section gebildet, was natürlich beim Aufbau eines unabhängigen Kernels in meinen Augen sehr hinderlich ist. Auch beginnen solche Programme immer damit, die DATA-Section in DS zu laden, was der Compiler von TC sicher automatisch einbauen wird, weils DOS-Standard ist. Außerdem gibts da ja noch die von Borland so geliebten Standardbibliotheken und son Zeug.
Auch meine (zugegebenermaßen sehr alte) Version von QuickC wird da nicht anders sein.

[Jidder]

Hi,

COM-Dateien dürfen auch größer als 64 KB sein -> siehe command.com. Die müssen dann halt selbst sehen, wie sie mit ihren Segmenten zurecht kommen. (Da gibt es dann diese ganzen komischen Modelle wie TINY, SMALL, MEDIUM, COMPACT, LARGE und HUGE ...)

Ich habe mal vor ganz langer Zeit (2 Jahren) ein OS mit Turbo C und NASM gebastelt. Die Standardbibliotheken sind mir da nicht in die quere gekommen. Ich habe gerade mal in meinen PorkChicken Archives (TM) ^^ gestöbert und gesehen, dass ich die Assembler- und C-Dateien sowohl mit dem Linker von Turbo C als auch mit JLOC scheinbar erfolgreich gelinkt habe. Das Ding war allerdings immer kleiner als 64 KByte, also konnte ich auf keine Probleme wegen den Segmenten stoßen.

[__OS_coder]

Das ist nicht ganz richtig:
COM-dateien müssen in ein segment passen und dürfen
folglich nich größer als 64KB sein(Übrigens ist die command.com
bei mir nur 52KB groß und so weit ich weiß ist das weniger als 64KB
oder?!   ).
Diese Memory-Models(e.g. TINY, SMALL, MEDIUM, etc.)
haben nichts mit COM-dateien zutun. Diese Memory-Models
sind nur vorgefertigte Segmente für EXE-dateien.

e.g. ersetzt dieser Code:

.MODEL SMALL
.DATA
...
.CODE
...
END

folgenden:

DATA SEGMENT
...
DATA ENDS

CODE SEGMENT
ASSUME CS:CODE, DS:DATA
...
CODE ENDS

Man sieht hier sehr gut, dass diese Memory-Models nur
verkürzte Anweisungen sind.

[Legend]

Na ja, aber trotzdem könnte ich trotz COM Datei, wenn ich alles schön ordentliche programmiere, ein weiteres Segment dynamisch zur Laufzeit mir unter den Nagel reissen (oder nen Teil von einem halt), zumindestens wenn ich Assembler programmiere. Wenn ich C programmiere, muss der Compiler das können (auch mit dem Tiny Memory Modell, was der aber genau dann nicht kann, soweit ich weiss).

[__OS_coder]

Ja sicher lässt sich ein segment dynamisch erstellen, nur
die COM-Datei selber MUSS imma 64KB groß sein.
Die C/C++ Compiler benutzen soweit ich weiß nich
das COM-Format, sondern das EXE-Format. Und wenn
der Code die 64KB-Marke überschreitet macht der compiler
einfach noch ein Segment auf und sorgt dafür, dass die
entsprechenden Sprünge oder Funktionsaufrufe zu FAR
Calls bzw. FAR Jumps werden um das andere segment zu
erreichen.

[Strukain]

Warum labern wir jetzt hier über Segmentaufteilungen im DOS-Tiny-Speichermodell?
Der Punkt ist, dass es für Linux keinen 16Bit C-Compiler gibt, wahrscheinlich weil das OS 32 Bit ist. Und solange ich noch nicht herausgefunden habe, warum die Dinge aus Tutorials, die bei anderen immer prima funktionieren, bei mir nie funktionieren, muss ich bei Assembler bleiben.
Schön, dass das geklärt wäre. Es gibt nur ein Problem, wegen command.com:
Wie krige ich in Assembler sowas wie die ANSI-Function scanf hin? Würd ich gern im Kernel haben.
Aber das gehört wohl nicht hierher...

[__OS_coder]

tjaa... wie du das implementierst bleibt wohl dir überlassen...
Die einfachste Möglichkeit währe zum Beispiel.

Code: [Auswählen]


mov ax,0
int  0x16


Das wartet auf einen Tastendruck, und gibt in AL des gelesene
Zeichen zurück... Mit schleifen kannst du dann daraus sowas wie
ne gets() funktion machen. So kannst du allerdings nur strings
einlesen. Du müsstest dir auch noch ne Funktion coden die
in strings gespeicherte Zahlenwerte in Integer bzw. Floats umwandelt.
Dann hast du sowas wie scanf();

Ach und übrigens in C ist das auch nich viiiiel leichter, da du
dir auch ersmal n tastaturtreiber coden musst. Du kannst nich
einfach die Standard-Funktionen benutzen.