China DOS Union

-------------------------------------------------------------------------------- -------------------------------------------------------------------------
NCTU-CIS BBS 'programming' board Digest Area

■■■ DOS extender, DPMI ■■■
-------------------------------------------- Compiled by: william@cis_nctu -----
-------------------------------------------------------------------------

Posted By: william (C++/ASM/Win Master) on board 'programming'
Date: Thu Jul 29 12:48:39 1993
Title: What is a DOS Extender?

> What is a DOS Extender?
> Lately I've seen this term in some magazines, but I don't know what it is.

Ordinary MS-DOS runs under the real mode of the Intel 8086 family, so it is subject to the 640KB limit.

UNIX, OS/2, and Windows, on the other hand, run under the protected mode of the Intel i286 family, or even under the Virtual 8086 mode of the i386, and can provide more than 640KB, even virtual memory capability.

But the machine code for protected mode and real mode is not quite the same, especially the addressing mode, so programs formerly built on MS DOS could not run under protected mode.

In order to let old real mode programs be ported to protected mode at the least possible cost, so they could enjoy its advantages, some extremely clever and highly skilled people put a layer of interface between the two (that is, the DOS extender), so that all system calls used by the old applications (real mode) (BIOS, DOS 21h...) are instead taken over by the DOS extender (protected mode real mode). Thus, a program using a DOS extender is equivalent to a dual-mode program: normally it runs in protected mode, and once it encounters a service that requires real mode (for example, the current common BIOS routines for disk I/O and screen I/O are still written in real mode, unless it is PS/2's ABIOS, which is shared by both real mode and protected mode), the DOS extender switches back to real mode by itself.

The details are hard to explain in a few words; please refer to "Extending DOS, 2nd edition", or a series of books published by Flag by Mr. Hou Jun-Jie.
==============================================================================

Sender: Hentai@cis_nctu (), board: programming
Subject: Re: Junior asking a protected mode expert..... experts please help
Posted at: NCTU CIS BBS (Aug 22 20:43:21 1994)
Forwarded from: cis_nctu

==>: pcjames.bbs@bbs.ee.nthu. (Danny) on board 'programming'
> After reading some of your posts, let me ask: do you enter protected mode directly?

Mine switches directly into protected mode, then opens a V86 mode and RUNs in it...

> But it isn't easy to rely completely on your own ability. There is a huge amount of prep work first, and besides I don't understand
> TSS, IDT, so I have even less hope of switching into Protected Mode by myself
> I have a copy of 80386 SYSTEM SOFTWARE WRITER'S GUIDE at hand, but it emphasizes concepts
> and the examples are really too simple

If you don't know that stuff, then it's a bit difficult...
Although that System Software Writer's Guide is indeed a bit too brief, the things in it are all very important. When I first started writing this stuff I often went back and flipped through it!

Also, you can refer to the 80x86 Programmer's Refrence manual. The system-programming material in it isn't as detailed as the System Software book, but for beginners there are quite a few things explained in a bit more detail!

> I really hope seniors can give me some suggestions and programs you've written. Thanks in advance

NCTUCCCA:/PC/demos/programming/source/dos32v24.zip

This is a Protected Mode program. It first checks whether there is a DPMI server; if there is, it uses DPMI to enter PM, and if not, it enters by itself...

> If you can also teach me TSS and IDT, I would be even more grateful

IDT is similar to the interrupt vector table starting at 0:0 in real mode,
in protected mode when there's an interrupt or exception, this is the table that's used!
TSS contains some basic information for Tasks. Basically, if the program doesn't involve multitasking or privilege-level changes,
this can be omitted...

-------------------------------------------------------------------------------- NCTU's Hentai
=============================================================================

Sender: BigLin.bbs@csie.nctu (Daxiong), board: programming
Subject: A small question about protected mode
Posted at: NCTU CS Phoenix City Information Station (Tue Oct 25 03:09:22 1994)

You can use a C function pointer to turn the pointer you got into Func ...
Later when calling XMS, just call Func....

If you want to read books on Protected MODE, I know of two:l:
1. 80386 Technical Manual (Chuan Hwa)
2. 80386 Microprocessor Manual (Tung Hwa) (I saw it in the library









































































































: Hentai@cis_nctu () on board 'programming'
> Do you find dos extender amazing??
> You can get dos32v and play with it!! This is a simple dos extender
> and it even comes with source, which can let you understand the protected mode features of the 386 CPU even better!!
> I learned quite a lot from this thing during winter break!!

Ha! I've also looked at the source code for Dos32V12, as well as pmode386 and protect,
and I even wrote a Dos Extender myself (though it can only enter protected
mode from real mode), but I think none of these Dos Extenders is as godlike as DOS/4GW. Do you know why?
Because entering protected mode requires reprogramming the 8259, freeing INT 0 through INT 31
for use when the CPU raises protection exceptions. Then the original interrupt routines are forced to move to other interrupt vectors.
You can see that ordinary Dos Extenders change IRQ 0-7 from the original INT 8h-fh to INT
32-39; but I tried directly writing "int 10h" in assembly while under DOS/4GW protected mode,
and it still correctly called the graphic card BIOS routine. But isn't this interrupt one of the vectors reserved for CPU
exceptions? How can it still behave just like in real mode? That's
what makes it feel so godlike to me.

===============================================================================

Sender: alexfish.bbs@bbs.nchu (Alex Yu), board: programming
Posted at: NCHU Tianshu Information Network (Sat May 7 14:38:05 1994)

> That's what makes it feel so godlike to me.

It's not that DOS4GW is godlike and can let interrupts overlap; this is what a DPMI server is supposed to do in the first place.
The method isn't very hard. Just set the IDT size a bit smaller,
enough to cover all CPU exceptions.
Then whenever an int occurs, or a program uses the int instruction to call an exception,
it will definitely cause an exception, allowing the RING 0 system to completely control interrupt dispatch.

The DPMI specification explicitly states that the DPMI server/host has the duty to map interrupts in protected mode
back to real mode when there is no protected mode ISR to handle them,
so that the real-mode ISR can handle them. Therefore,
QDPMI is an incomplete DPMI server implementation.

Besides DOS4GW, Borland's RTM also has similar capabilities, and also maps hardware interrupts into protected mode,
letting the protected-mode ISR handle the hardware interrupt first.

Also, under Windows all interrupts must first pass through the virtual programmable interrupt
controller device and the protected mode isr before it is the DOS box real mode ISR's turn.
According to M$ documents, the handling efficiency of real mode isr for hardware interrupts under Windows is only 7% of that outside Windows.
The efficiency ranking is:

1. real mode ISRs outside Windows
2. Windows VxDs
3. Windows bi-modal ISRs (ISRs callable by ring 0)
4. Windows or protected mode ISRs
5. ISRs in DOS box
===============================================================================

Sender: cmp@cis_nctu (), board: programming
Posted at: NCTU CIS BBS (May 9 19:08:10 1994)

==>: alexfish.bbs@bbs.nchu (Alex Yu) on board 'programming'
> It's not that DOS4GW is godlike and can let interrupts overlap; this is what a DPMI server is supposed to do in the first place.
> The method isn't very hard. Just set the IDT size a bit smaller,
> enough to cover all CPU exceptions.
> Then whenever an int occurs, or a program uses the int instruction to call an exception,
> it will definitely cause an exception, allowing the RING 0 system to completely control interrupt dispatch.

After causing the exception, what should be done next? And how does this exception handler know the int number?

I see that other Dos Extenders, when handling calls to original real-mode interrupts, set up
a special interrupt routine for it, such as AH= real-mode int number, then call this interrupt routine, and then this
routine switches into V86 mode to run the original real-mode interrupt.... Also, you say to reduce the IDT size,
but the minimum still can't be smaller than 32*8 Bytes, right! (that is, int 0-31) And I was doing int 16
while in protected mode! I don't think that could be under CPU exception handler control, right! (because int
16 is Math Error exception!)

===============================================================================

Sender: alexfish.bbs@bbs.nchu (Alex Yu), board: programming
Posted at: NCHU Tianshu Information Network (Tue May 10 10:10:40 1994)

> After causing the exception, what should be done next? And how does this exception handler know the int number?

The Exception error code will indicate it.
Under Windows or OS/2, use sidt to look at IDTR, and you'll know how small the IDT is.

> I see that other Dos Extenders, when handling calls to original real-mode interrupts, set up
> a special interrupt routine for it, such as AH= real-mode int number, then call this interrupt routine, and then this
> routine switches into V86 mode to run the original real-mode interrupt.... Also, you say to reduce the IDT size,
> but the minimum still can't be smaller than 32*8 Bytes, right! (that is, int 0-31) And I was doing int 16
> while in protected mode! I don't think that could be under CPU exception handler control, right! (because int
> 16 is Math Error exception! )

Of course it can, because the privilege levels are different. A RING 3 program cannot directly call
RING 0 interrupts and exceptions.
===============================================================================

Sender: alexfish.bbs@bbs.nchu (Alex Yu), board: programming
Posted at: NCHU Tianshu Information Network (Wed May 11 04:49:06 1994)

□ Quoting the post by: cmp.bbs@bbs.cis.nctu () □
>> Of course it can, because the privilege levels are different. A RING 3 program cannot directly call
>> RING 0 interrupts and exceptions.
> Sorry, I wasn't clear. I want to directly implement, in RING 0, a DOS/4GW-like arbitrary feature
> that lets people call original real-mode interrupts. (Don't tell me to use DPMI.)

I still have to say, DPMI has this kind of function, and the method is very simple:

Set every protected mode interrupt vector (the DPMI specification requires a DPMI server
to provide all 256 interrupts for use by DPMI clients; if it doesn't comply then it isn't compatible with the DPMI
specification) to your own handler, and this handler contains only a single int 3.

Note that the location of each handler must be different, so at most 256 opcode 0cch are needed (if all 256
interrupts are to be mapped back to real mode). Then intercept exception 3 as well (it would be best to point interrupt 3
to the same handler too), and then from this handler inspect the place that was interrupted,
so as to determine the original interrupt number
(because the interrupt number can be determined from return offset - int 3 array start offset
), then use DPMI to simulate the interrupt, convert all the registers that need to be mapped,
and then it's ok.

Back when I played with IDT moving in real mode, this was also how interrupt mapping was maintained, except that there was no need to switch modes then.
If you're not entering protected mode through DPMI, then it's even......simpler, right? Prepare a virtual 8086 machine,
and whenever you need to use a DPMI call real mode interrupt there, switch into that virtual machine, then return,
OK.

===============================================================================

Sender: cmp@cis_nctu (), board: programming
Subject: Re: Do DOS extenders like DOS4GW allocate XMS?
Posted at: NCTU CIS BBS (May 10 21:23:28 1994)
Forwarded from: cis_nctu

> Note that the location of each handler must be different, so at most 256 opcode 0cch are needed (if all 256
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> interrupts are to be mapped back to real mode). Then intercept exception 3 as well (it would be best to point interrupt 3
> to the same handler too), and then from this handler inspect the place that was interrupted,
> so as to determine the original interrupt number (because the interrupt number can be determined from return offset - int 3 array start offset
^^^^^^^^^^^^^^^^^^^^^^^
> ), then use DPMI to simulate the interrupt, convert all the registers that need to be mapped,
> and then it's ok.

This trick for determining the int number is indeed brilliant! I'd never thought of it before. Now that you've explained it like this,
the doubt in my mind is finally cleared up! (I've also thought of another method that doesn't use DPMI.) Many thanks for the reminder,
I'm going to go rewrite my Dos Extender right now and see!

===============================================================================

Sender: s8153119@summer.nchu (Alex Yu), board: programming
Posted at: NCTU CS News Server (Sun May 15 12:04:17 1994)

In article , Kevin wrote:
>> No, the main reason is an error in the interface to Watcom C/C++ in Tnyplay2.zip.
>> A friend of mine made a few modifications and has already made tnyplay2 work normally.
>> Its biggest mistake is that the size of the parameters on the stack is wrong; all the interface parameters for Watcom C/C++
> What parts need to be modified?

The parts commented out with Remark are from the original program:

;proc MODPlayModule Modfile:dword,Rate:word,Port:word,IRQ:byte,DRQ:byte
proc MODPlayModule Modfile:dword,Rate:dword,Port:dword,IRQ:dword,DRQ:dword

mov edi, ; Load parameters from stack
mov eax,
mov edx,
mov ecx,
mov ,dx ; save SB configuration parameters
mov ,cl
mov ecx,
mov ,cl
mov ,ax
; mov ax,
; mov dx,
; mov cl,
; mov ch,
; mov ,dx ; save SB configuration parameters
; mov ,cl
; mov ,ch
; mov ,ax

======================================================================
= I'm Alex Yu. I am Yu Meng-Xue. To contact me, try: =
= E-mail: s8153119@summer.nchu.edu.tw, s48153119@vax9k.nchu.edu.tw =
======================================================================
= Forgive me for response so late, for I pack all my e-mails & news =
= home and followup/reply them offline. =
= Please forgive my ultra-slow reply speed, because I use uqwk to pack news & e-mail and take them home to reply. =
======================================================================
===============================================================================

Sender: saturn@cis_nctu (SEGA fan), board: programming
Posted at: NCTU CIS BBS (May 7 18:14:10 1994)

May I ask Mr. cmp:
How do you intercept a certain INT under the DOS Extender DOS/4GW?
I've recently been writing a program that needs to intercept INT 9, but I just can't get it to work....

My program is roughly as follows:

.386P
.MODEL FLAT, C
.DATA
public Key
Key DB ?
.CODE
Newint9 PROC PUBLIC USES....
LOCAL OLDINT9:DWORD

mov AX, 3509h
int 21h
mov WORD PTR OLDINT9, BX ; don't know whether the return value is
mov AX, ES ; ES:BX or ES:EBX
mov WORD PTR OLDINT9+2, AX ;
jmp next
;====================================
NewINT:
.
.
.
iret
;====================================
next:
mov EDX, NewINT ;================
push CS ; don't know whether it should point to
pop DS ; DS:DX or DS:EDX
mov AX, 2509h ;
int 21h

mov EAX, OLDINT9 ;return the address of old int9
Newint9 ENDP
END

I hope Mr. cmp can answer this for me, or if any other expert knows, please help too

Thanks:)

-------------------------------------------------------------------------------- Very bored today.
Tomorrow is Mother's Day, but I didn't go back to see Mom,
I'm really an unfilial son..........
【SEGA fan】
===============================================================================

Sender: cmp@cis_nctu (), board: programming
Subject: Re: Do DOS extenders like DOS4GW allocate XMS?
Posted at: NCTU CIS BBS (May 9 19:22:54 1994)
Forwarded from: cis_nctu

Brother Saturn: If you've already entered protected mode, then using DOS's interrupt vector setting function is useless!
Just look at the returned register length and addressing mode and you'll know (DS:DX ==> seg:offset addressing mode; no matter how you
address with it, it can only address within 1 Mega, but protected-mode program code has already been thrown beyond 1 Mega!)
To solve this, if you are using Watcom C/C++, you might try _dos_setvect() and
_dos_getvect()! I've been using them like this up to now,
and there have been no problems.
(This also includes setting vectors this way for ISRs written in assembly)

┌──────────────────────────────────┐
│　　Seeing your girlfriend snatched away: getting jealous is not very cool; drinking soy sauce is very cool, but you can't drink it.　　│
│ （Want to see me drink it?）　　　 │
└──────────────────────────────────┘
===============================================================================

Sender: alexfish.bbs@bbs.nchu (Alex Yu), board: programming
Posted at: NCHU Tianshu Information Network (Tue May 10 10:16:09 1994)

DOS4GW provides 32-bit int 21h services, including file read/write and get/set interrupt vector.
There is a MOD player source code for Watcom C/C++ (filename 'tnyplay2.zip'; originally
I got it from wuarchive, but I just looked in ftp.edu.tw /PC/wuarchive/games/programming
and the watcom directory below it and didn't see any trace of it there) in which the IRQ handler is set similarly to

mov ax,250fh
mov edx,offset irq_handler
int 21h

===============================================================================

Sender: cmp@cis_nctu (), board: programming
Posted at: NCTU CIS BBS (May 9 20:01:26 1994)

Speaking of how I captured DOOM's graphics and "discovered" that it was using 320x200x256c 4 pages mode,
I have to start from capturing the graphics of Pinball. At that time, as soon as I saw Pinball's smooth screen scrolling
and its resolution higher than 320x200, I concluded that the program was using mode X for display.

So I wrote a screenshot program specifically for capturing mode X under DOS, and it was indeed quite successful. Later,
while playing DOOM, I suddenly had the idea of using this screenshot program on DOOM, and it actually worked! Besides discovering
that DOOM uses 4-page display, I also found that in the full 256K bytes of memory I captured,
besides the 64K bytes of graphics currently being displayed on the screen, there were two other 64KB images. One of them
was the previous frame that had already been displayed, and the other was the next frame that was about to be shown on the screen
(because it had not been fully rendered yet); and from this image I learned that DOOM's render method is
to render the walls first, then render the floor and ceiling, and to render from far to near....。

┌──────────────────────────────────┐
│　　Seeing your girlfriend snatched away: getting jealous is not very cool; drinking soy sauce is very cool, but you can't drink it.　　│
│ （Want to see me drink it?）　　　 │
└──────────────────────────────────┘
===============================================================================