direkt auf Grafikbildschirmspeicher ...

Nobuo T

Nein. (Ausser so ein paar billigen NT-Kernel-Interrupts)

Die BIOS-Interrupts laufen teilwesie auch noch.
Ob die nicht allerdings vom OS emuliert werden kann ich nicht sagen

Snakey

Ja und wie macht man das, wenn man nicht die Auflösung 320x200 hat ??
Wie schaltet man in andere Bildschirmmodi, ohne BGI ?

Original erstellt von <DocJunioR>:**
Die BIOS-Interrupts laufen teilwesie auch noch.
Ob die nicht allerdings vom OS emuliert werden kann ich nicht sagen
**

BIOS Interrupts bringen eine Win32-Anwendung garantiert zum Abstuerzen.

Original erstellt von Snakey:**
Ja und wie macht man das, wenn man nicht die Auflösung 320x200 hat ??
Wie schaltet man in andere Bildschirmmodi, ohne BGI ?**

In einer 16Bit DOS-Anwendung, die in Windows laeuft, koennen BIOS Interrupts benutzt werden, um den Bildschirmmodus zu wechseln.
Interrupt 10h, ax=0013h wechselt z.B. in den Bildschirmmodus 320*200 bei 256 Farben.

Nitromaus

Mich würd auch mal interessieren wie dass dann bei 32-Bit geht. Müsste man sich da dann eigene Treiber schreiben, damit man auch interrupts benutzen darf, oder wie is des.

Würde es auch gehn mit 16-Bit DLLs die dann Funktionen haben die DOS-Interrupts aufrufen?

SideWinder

Die Treiber kannst schon schreiben, aber Win blockiert sie dir trotzdem ;). Using the windows application programming interface ;).

MfG SideWinder

DocJunioR

okay, dann bitte mal dieses hier durchführen:

debug testgr.com
-a
0CA2:0100 mov ax,0013
0CA2:0103 int 10
0CA2:0105 mov ax,0700
0CA2:0108 int 21
0CA2:010A mov ax,0003
0CA2:010D int 10
0CA2:010F mov ax,4c00
0CA2:0112 int 21
0CA2:0114
-rcx
0000
14
-w
14 Bytes written
-q
c:\>testgr.com

okay, das ist nicht perfekt, zeigt aber eindeutig, das Interrupts funktionieren.
zumindest mein W2K lässt sowas zu. NT fängt Interrupts ab und emuliert sie. Völlig ohne Interrupts wäre ein Computer nicht steuerbar.

cYa
DjR

[ Dieser Beitrag wurde am 13.11.2002 um 16:45 Uhr von DocJunioR editiert. ]

Snakey

Klar, W2k lässt das auch noch zu, W2k lässt auch noch Hardwareports - Zugriffe zu, nur bei XP ist Schluss damit !!

Nitromaus

was du da gemacht hast is aber ein 16-bit Code, und kein 32-Bit Code meines Wissens. Und bei 16-Bit ist es ja erlaubt

DocJunioR

@Snakey :
Der 2k-Kernel und der XP-Kernel sind fast identisch. Abgesehen davon beruhen beide auf windows NT. Dieses Windows ist mit einem HAL (Hardware - Abstraction - Layer) ausgestattet, welches sämtliche interrupts und sonstige Hardwareabfragen abfängt und an die Hardware mit eigenen Routinen neu schickt. XP ist nicht so viel anders als 2k.

@Nitro:
Dazu habe ich leider keine definitive Aussage. Ich persönlich glaube zwar nicht, dass das damit was zu tun hat, aber ich will mich nicht darauf versteifen.

Anonsten laß' ich mich bei jeder Aussage gerne vom Gegenteil überzeugen.

cYa
DjR

Nobuo T

@DocJunioR:
Was Du da erstellt hast ist eindeutig eine 16Bit DOS-Anwendung.
Das sieht man einmal an der Endung .com (schau mal nach, welche Dateibeschreibung Windows zu dieser Endung parat hat)
Und dann musst Du doch wohl zugeben, dass es ziemlich unrealistisch klingt, dass sich eine Windows-Anwendung durch DOS-Kommandos steuern lassen soll.

Hast Du schonmal versucht, das ganze via C++ und Inline Asm als 32Bit Konsolenanwendung zu compilieren? Also ich weiss ja nicht, was dabei auf deinem System passiert, aber meines hat sich einfach neu gestartet

BTW: Selbst Windows XP simuliert noch eine recht begraenzte DOS-Umgebung. Da DOS-Anwendungen normalerweise ueber Interrupts (int 21h, 31h usw.) gesteuert wreden, werden diese dort natuerlich auch simuliert. (Aber nur in 16Bit DOS-Anwendungen!)

So, damit hast Du eine definitive Aussage und Nitromaus hatte voellig recht. :p
Ich hoffe, dass jetzt ein fuer allemal klargeworden ist, dass in Windows-Anwendungen aller Art KEINE BIOS o. DOS Interrupts benutzt werden koennen

[ Dieser Beitrag wurde am 14.11.2002 um 18:50 Uhr von Nobuo T editiert. ]

Da brauch ich nicht nachzuschauen. Ich habe lange genug .com Dateien selber geschrieben und ich kenne noch das Buch PC-Intern 3.0 - immerhin kannte ich das mal fast auswendig!

.com-Dateien sind arg begrenzt. sie haben maximal 64kb - also ein Segment - Speicher, sind daher 16 bit-Anwendungen. Klar. Allerdings läuft auf der anderen Seite mein cmd im 32 Bit-Modus und emuliert die 16 Bit-Befehle.

Ich habe ja auch nie gesagt, dass Windows-Anwendungen Interrupts benutzen. Das haben sie afaik noch nichtmal bei Win 3.0 gemacht. mir geht's ja nur umd die Aussage, dass Windows keine Interrupts mehr zulässt, was ich ja mit meinem Prog widerlegt habe. Sie werden nur abgefangen und von Windowseigenen Prozeduren ersetzt. Leider klappt das nicht immer, da viele inzwischen veraltete Interrupts nicht unterstützt werden.

Was Deine Aussage angeht, so bin ich überzeugt, dass du recht hast. Allerdings ist das doch vom Prinzip her das Gleiche was ich meinte, oder?

Solaris'dUKe

kenne noch das Buch PC-Intern 3.0

Ja der Tischer war echt der Hammer. Schade nur dass spätere Ausgaben
den Anhang nur noch auf der CD hatten...

Sie werden nur abgefangen und von Windowseigenen Prozeduren ersetzt. Leider
klappt das nicht immer, da viele inzwischen veraltete Interrupts nicht unterstützt werden.

Ja.. oder werden einfach nur noch Simuliert (Rückgabewert stimmt nicht mit
der wirklichen Aktion überein). Das Progam kann also "angelogen" werden.
Da ich DOS vor Jahren aufgegeben habe weis ich gerade keine Beispiele, aber
der VESA könnte auch so einer sein...

Nobuo T

Original erstellt von <DocJunioR>:
Ich habe ja auch nie gesagt, dass Windows-Anwendungen Interrupts benutzen.

Naja, IMHO schon, dann war das wohl ungluecklich ausgedrueckt?

Original erstellt von Nitromaus:
**Sind interrupts in 32-Bit Windows Anwendungen denn überhaupt noch erlaubt
**
...

Original erstellt von <DocJunioR>:
Die BIOS-Interrupts laufen teilwesie auch noch.
Ob die nicht allerdings vom OS emuliert werden kann ich nicht sagen

So, wie die Texte auf Seite 1 angeordnet sind, verstehe ich hier Sinngemaess, dass Windows in 32Bit-Anwendungen BIOS-Interrupts o.ae. zulaesst, was schliesslich nicht der Fall ist.