Frage zu Bios Interrupt Funktion

Hallo ich habe ein Tutorial zur Programmierung auf BIOS ebene gefunden.

So kann man ja z.b. unter Windows Text ausgeben.

mov ah, 9               
    mov dx, OFFSET enterstr 
    int 21h

Unter Linux kann ich ja z.b. so Text ausgeben

movl $4, %eax

	movl $1, %ebx

	movl $HelloWorldString, %ecx

	movl $12, %edx

	int $0x80

Müsste das dann nicht eigentlich auch mit mov ah,9h möglich sein unter Linux Text auszugeben weil mov ah,9h ja eine Funktion ausm Bios ist oder Täusche ich mich da ?

bios schrieb:

So kann man ja z.b. unter Windows Text ausgeben.
mov ah, 9               
    mov dx, OFFSET enterstr 
    int 21h

nein, das is für DOS!

Die Belegung der Interupts und Funktionsnummern hat hier nichts mit dem BIOS zu tun - das haben die Programmierer von M$ und Linux nach eigenen ermessen festgelgt.

Aber man kann doch auf die Bios Funktionen zugreiffen oder nicht ?
Wie kann ich z.b. eine Text Ausgabe machen die auf Windows und Linux funktioniert ?

Das stand in dem Tutorial:

Da wir uns in diesem Tutorial auf der BIOS Ebene bewegen, werden wir auch gleich die Funktionen nutzen die der Computerhersteller bereits ab Werk zur Verfügung stellt. Konkret gesagt, wir verwenden den BIOS Tastatur Handler Interrupt 16h. Dieser liefert uns eine Taste aus dem Tastaturpuffer. INT 16h eignet sich hervorragend dazu die erweiterten Tastaturtasten, wie die Cursortasten oder Bild ↑ und Bild ↓ Tasten zu lesen. Jede dieser erweiterten Tasten erzeugen einen 8-Bit Scan Code der auf allen IBM-kompatiblen Computern gleich ist.

Das Tutorial:

http://www.codeplanet.eu/tutorials/assembler/9-bios-level-programmierung.html?start=1

Demnach müsste man ja auf Windows sowie auf Linux über
mov ah, 10h
int 16h

Text einlesen können.

Laut Ralf Browns Interrupt list ist das ja auch eine Bios Funktion:
http://www.ctyme.com/intr/rb-1771.htm

Oder liege ich wieder falsch und es würde so nicht funktionieren ?
Weil mein Bios ändert sich ja nicht das is ja Jacke wie Hose ob ich jetzt Linux oder Windows installiert habe ...

Nobuo T

Schon richtig, das BIOS bleibt gleich. Allerdings hast du von einem Betriebssystem, das im Protected Mode arbeitet (fast alle modernen PC-Betriebssysteme) idR. keinen Zugriff mehr auf die BIOS-Funktionen.
Wenn man bedenkt, dass die meisten BIOS-Funktionen nur als grundlegende I/O-Funktionen im Real Mode geschrieben sind und damit die Treiber der Betriebssysteme wahrscheinlich ganz schoen durcheinander bringen wuerden, ist das auch sinnvoll so.

Es gibt folglich momentan meines Wissens keine Moeglichkeit, auf Assembler-Ebene Programme zu schreiben, die ohne spezielle externe Libs, Meta-Kommando- oder Precompiler-Magie in z.B. Windows wie Linux lauffaehig sind.

Aber wieso kann ich so mit TASM diese Funktion aufrufen ?

Das muss doch eine Bios Funktion sein Erhard Henkes verwendet diese Funktion ja auch in einem Kernel dann kann es doch mit DOS nicht zu tun haben oder versteh ich da was falsch ?

http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

mov ah, 0Eh
int 10h

.MODEL Small    
.STACK 100h     
.DATA           

.CODE  

Start:   

	mov  ax,@data   
        mov  ds,ax

	mov al , "a"

	mov ah, 0Eh
	int 10h	

	mov  ah,4Ch
   	 int  21h       

END  Start

Nobuo T

TASM ist nur ein Assembler. Mit dem rufst du gar nichts auf, der uebersetzt nur deinen Code.

Der x86 kennt 256 verschiedene Interrupts. Wie das grob Funktioniert, verraet dir Wikipedia: http://de.wikipedia.org/wiki/Interrupt

2 Dinge sind dabei hervorzuheben: 1. kann jedem der 256 Interrupts ein anderer Handler zugeordnet werden und 2. lassen sich die Handler zur Laufzeit veraendern (entsprechende Kernel-Rechte vorausgesetzt).

Die Handler fuer die wichtigsten BIOS-Funktionen sind ueber die Interrupts 10h, 13h, 15h und 16h erreichbar. DOS richtet seine Syscalls dagegen bei Interrupt 21h ein, arbeitet aber im Gegensatz zu Windows oder Linux mit dem BIOS so weit zusammen, dass die oben genannten BIOS-Funktionen zudem weiterhin funktionieren.
Linux und Windows bieten zwar auch Syscalls ueber Interrupts an (Linux: 80h und Windows 2Eh), aber bei diesen Systemen sind wie gesagt keine BIOS-Funktionen mehr verfuegbar.
Windows hatte bis Vista eine integrierte VM, die automatisch DOS-Programme auf einem simulierten DOS-Rechner ausgefuehrt hat. Nativ kannst du aber auch in Windows weder mit int 21h, noch mit BIOS-Funktionen irgend etwas (ausser einem Programmabsturz) erreichen.

Um genauer zu sehen, welcher Interrupt im RealMode oder in DOS welche Funktionen anbietet, kannst du dir eine Interrupt Liste wie zB. die von Ralf Brown reinziehen.

Nobuo T schrieb:

Schon richtig, das BIOS bleibt gleich. Allerdings hast du von einem Betriebssystem, das im Protected Mode arbeitet (fast alle modernen PC-Betriebssysteme) idR. keinen Zugriff mehr auf die BIOS-Funktionen.
Wenn man bedenkt, dass die meisten BIOS-Funktionen nur als grundlegende I/O-Funktionen im Real Mode geschrieben sind und damit die Treiber der Betriebssysteme wahrscheinlich ganz schoen durcheinander bringen wuerden, ist das auch sinnvoll so.

Das steht übrigens auch so in dem Artikel.

Der Real Mode wird von neuen Prozessoren im Sinne der Abwärtskompatibilität unterstützt. Das heißt jeder moderne x86-Prozessor startet im Real Mode und wird später manuell vom Betriebssystem in den Protected Mode geschalten. Unter allen modernen Windows Betriebssystemen erledigt das der NT Loader (Abkürzung: ntldr) in der Startphase. Erst danach kann auf die vollständigen 32-Bit des Speichers zugegriffen werden. Nachdem der NT Loader einige Page Tables generiert hat um einen 16 MB großen Speicher mit aktiven Paging betreiben zu können, aktiviert er das Paging und Windows kann normal geladen werden.

Bei den in diesem Tutorial vorgestellten Quellcodes handelt es sich um 16-Bit Applikationen. Da nur im Real Mode ein direkter Zugriff auf die Hardware möglich ist, neue Windows Betriebssysteme der NT-Serie den Prozessor jedoch beim Start in den Protected Mode schalten und das System vollständig abschirmen, ist es ggf. erforderlich die erstellten Programme beim Start separat im DOS-Modus auszuführen. Sie können diese aber auch unter Windows NT laufen lassen. Zu diesem Zweck stellen Windows Betriebssysteme eine virtuelle DOS Maschine, auch WOW genannt, zur Verfügung. Diese läuft unter dem Namen ntvdm.exe im Taskmanager. Dabei handelt es sich um ein Win16 Subsystem das es 16-Bit Anwendungen ermöglicht so ausgeführt zu werden als ob diese direkt in einer normalen DOS Umgebung laufen würden.

NTVDM nutzt dazu einen speziellen Modus der x86-Prozessoren namens Virtual-8086 Mode. Der Modus erlaubt es Anwendungen, die für den Real Mode konzipiert wurden, in einer kontrollierten Umgebung zu laufen. Ihr Programm wird also von der virtuellen Maschine emuliert während Windows NT allein darüber entscheidet wie und ob das Programm auf die Hardware zugreifen darf. Da die Programme unter einer Multitasking Umgebung laufen, können die 16-Bit Anwendungen Windows NT auch nicht zum Absturz bringen. Windows NT verhindert in jedem Fall das NTVDM Instruktionen ausführt die direkt den Speicher oder die Hardware manipulieren können!

Neben der Bedingung das unsere Programme im Real Mode laufen müssen, gibt es noch einige weitere Punkte zu berücksichtigen um mit Assemblersprache auf der BIOS Ebene programmieren zu können. So benötigen wir einen entsprechenden Assemblierer und 16-Bit Linker. In diesem Tutorial greifen wir auf den Microsoft Macro Assembler 6.x zurück. Microsoft bietet den MASM 6.x nicht mehr als Retail Produkt an. Bei Bedarf lässt sich dieser jedoch separat beim Support bestellen. Sie müssen sich darum jedoch nicht kümmern. Der MASM 6.x ist samt Update Patch und 16-Bit Linker im Anhang dieses Tutorials enthalten.

http://www.codeplanet.eu/tutorials/assembler/9-bios-level-programmierung.html

Man muss nur lesen können...

merano

Anzumerken wäre noch das die DOS-Shell bis Windows-XP noch einige
BIOS kompatible Schnittstellen bot. Auch der Zugriff auf Register
der Grafikkarte waren ohne grosse Einschränkungen möglich.

Leider haben sich seit VISTA einige Dinge verschlechtert ...

nachtfeuer

Auf dem Level, auf dem der Threadersteller hier fragt, hätte es gereicht, darauf hinzuweisen, dass ein Programm wie DosBox auf Linux und Windows läuft, und ganz gut dafür geeignet ist, RealMode Programme/Programmierung auszutesten, z.B. dieses hier:

--
  B013CD1033C0BFB001B9007DF3ABBAC803EE42FEC980/~~~~~~~~\      The Bitripper
FB3C730580C304EB0880FF3C730380C7048AC3EE8AC7/'          `\~~~\
EE32C0EEE2E3B1C88106AC01E9628006AC01628116AE`\           /'   )
  011936A1AE0133D2BB4001F7F38BF2FE8C707DE2DDBE`~~/   \~~'    / Coders do it
   F102BFB17EB162BA3E018A9CC0FE8A44FF03D88A4401/`     )      `\  bit by bit
  03D88A84400103D8C1EB02881D46474A75E246464747/       /        )
 E2D9BEB27EBFB201B97E3E5157F3A55E6800A007BF02(_______/        /
          7D59F3A51E07B401CD16748CB80300CD10C3c4urself`.____/'
--

(von Seite: http://thestarman.pcministry.com/asm/fire/Fire.html )
(...hat übrigens gut zur Weltmeisterschaft gepasst...;)

Und man sollte vielleicht noch wissen, dass Bios-Programme auf 16Bit Basis laufen, und das der 32bit ProtectedMode aus dem 16Bit RealMode heraus gestartet wird. Der Code auf der Seite http://www.henkessoft.de/OS_Dev/OS_Dev1.htm dreht sich um Betriebssystemprogrammierung. Auf welchem Betriebsystem man den Code für sein EIGENES Betriebssystem schreibt, ist relativ egal, man muss nur zusehen, dass der Maschinencode bytegenau auf dem Bootmedium landet.