cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/01/14:21:50

From: DavMac AT iname DOT com (Davin McCall)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP - real mode procedures.
Date: Tue, 01 Jun 1999 05:52:40 GMT
Organization: Monash Uni
Lines: 32
Distribution: world
Message-ID: <3753714e.1113378@newsserver.cc.monash.edu.au>
References: <37533A3A DOT B6A84588 AT hitech DOT net DOT au>
NNTP-Posting-Host: damcc5.halls.monash.edu.au
X-Trace: towncrier.cc.monash.edu.au 928216328 25736 130.194.198.138 (1 Jun 1999 05:52:08 GMT)
X-Complaints-To: abuse AT monash DOT edu DOT au
NNTP-Posting-Date: 1 Jun 1999 05:52:08 GMT
X-Newsreader: Forte Free Agent 1.1/32.230
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

I didn't give the code a major going over or anything, but did see one
or two things I thought could cause a problem:

>pop bx
>mov ax, 10
>add ax, bx
>iret

This will pop half the return address. The stack parameters are pushed
*before* the return address. You need something like "mov bx, word ptr
[sp+4]" (and is that even valid? You might need to setup BP)

>I then call the function
>__dpmi_simulate_real_mode_procedure_retf_stack(&r, 4, &stack);

I suspect the 4 should be 1, or possibly 2. The DPMI spec is rather
unclear. Unfortunately "word" on intel machines is sometimes used to
refer to a 16-bit quantity. The technically correct value would, I
suppose, be 1.

>It did this even when I ran a smaller procedure that was this
>mov ax, 13
>retf

Weird. Are you sure you weren't using the "iret" version of the dpmi
call by mistake?

Davin.

__________________________________________________________
       *** davmac - sharkin'!! davmac AT iname DOT com ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019