News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

DPMI trials/tribulations

Started by redskull, February 14, 2006, 08:56:36 PM

Previous topic - Next topic

redskull

Mostly for fun, i've been experimenting around with the DPMI, but every corner i turn seems to be a brick wall....  All i can find on the internet/forum is just different formats of the specification, which are not very clear.  I tried putting the example asm program from the specification, just for shits and giggles, but the program never returns from the FAR CALL.
In a nutshell, i have a 16-bit assembly program that I was trying to put into protected mode by using DPMI, that's running in a virtual-86 process under windows 2000..am I at least pointed in the right direction?

alan
Strange women, lying in ponds, distributing swords, is no basis for a system of government

sinsi

From what I remember, the program has to initialise, change to protected mode, do its thing, change back to real mode, cleanup.
Remember that interrupts are handled differently (I think not at all? not sure).

DPMI for me means Windows 3.1  :bdg

have a look at unreal mode (4 gig 32-bit access for DOS!) for a 386+, or if you really want DPMI have a look for Ralf Brown's Interrupt List...
Especially the DPMI Multiplex interrupt (2F) and the protected mode INT 31 stuff...

Cheers,
John
Light travels faster than sound, that's why some people seem bright until you hear them.

Gustav

> From what I remember, the program has to initialise, change to protected mode, do its thing, change back to
> real mode, cleanup.
> DPMI for me means Windows 3.1

no.

a sample which just displays 'A' in protected mode:



; simple 16-bit dpmi client in MASM

        .286
        .MODEL SMALL, stdcall
        .386

.data
       
dErr1 db "no dpmi host",13,10,'$'
dErr2 db "no dos memory",13,10,'$'

        .CODE

;--- main runs in protected mode

main    proc c
mov ah,2
        mov dl,'A'
        int 21h
        ret
main    endp

; init code: put app in protected mode

start:
mov ax, dgroup
        mov ds, ax
        mov     ax, sp
        shr     ax, 4
        mov     bx, ss
        add     ax, bx
        mov     bx, es
        sub     ax, bx
        inc     ax
        mov     bx, ax
        mov     ah, 4Ah ;free dos mem
        int     21h

        mov     ax, 1687h   ;DPMI host active?
        int     2fh
        and     ax,ax
        jnz     error1
        push es
        push di
        mov bp,sp
                            ;alloc memory for dpmi host
        mov     ah,48h
        mov     bx,si
        int     21h
        jc      error2
        mov     es,ax
        mov ax,0        ;16bit client
        call    dword ptr [bp]  ;initial switch to protected mode

call main
       
        mov ah,4ch
        int 21h

error1:
mov dx, offset dErr1
mov ah,9
        int 21h
        mov ah,4ch
        int 21h

error2:
mov dx, offset dErr2
mov ah,9
        int 21h
        mov ah,4ch
        int 21h

        END start



redskull

mov ax, DGROUP

is that the same as

mov ax, SEG dERR1

Is there any particular reason you used DGROUP?  My general (and often misguided) understanding was that DGROUP allowed you to group seperate segments together, but was usually not big enough....please school me?

thanks again
alan
Strange women, lying in ponds, distributing swords, is no basis for a system of government

MichaelW

DGROUP is the segment group that includes the _DATA, _BSS, CONST, and, assuming the default NEARSTACK,  STACK segments. It is automatically defined when you use the MODEL directive, and it represents the near data area, normally accessible through DS or SS. For a 16-bit app DGROUP is limited to 64KB, and for most apps this is more than sufficient, considering that you can include additional far data segments and/or allocate memory from the OS.

http://webster.cs.ucr.edu/Page_TechDocs/MASMDoc/ProgrammersGuide/Chap_02.htm

eschew obfuscation

Gustav

an addition to Michael's post:

the usual 64 kb limit of DGROUP comes from the linker. It's not a true restriction for a 16-bit dpmi client, which could handle 4 GB segments as well (if it is running on a 80386+). However, in a windows dos box, the dpmi host also includes a "dos extender" (which allows to directly call int 21h with pointers involved), and these extenders will ignore the HIWORD of any offsets for 16bit clients.