Date:	Sat, 08 Sep 2001 09:57:23 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	djgpp AT delorie DOT com
Message-Id:	<3405-Sat08Sep2001095723+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	leif AT dtcs DOT de
In-reply-to:	<3B9993B7.7673E4B7@dtcs.de> (message from Leif Leonhardy on Sat,
	08 Sep 2001 05:42:47 +0200)
Subject:	Re: __dpmi_simulate_real_mode_procedure_retf[stack](): Links to bug fixes? FAQ?
References:	<3B9993B7 DOT 7673E4B7 AT dtcs DOT de>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: Leif Leonhardy <leif AT dtcs DOT de>
> Newsgroups: comp.os.msdos.djgpp
> Date: Sat, 08 Sep 2001 05:42:47 +0200
> 
> PROBLEM: passing arguments to real mode procedures via the (which?!)
>          stack
> 	 I tried BOTH __dpmi_simulate_real_mode_procedure_retf_stack()
> 	 AND __dpmi_simulate_real_mode_procedure_retf() setting up
> 	 the stack (regs.x.ss, regs.x.sp) by myself - with exactly
> 	 the same results.
> 
> Few minutes ago ;-) I was happy to find a patch for d0301_s.S (from
> about a year ago), not immediately realizing that this patch wouldn't
> solve my problem because the function without the extra stack parame-
> ters behaves exactly (?) the same :-(

Sorry, I don't understand this.  d0301_s.S, as shipped with DJGPP
v2.03 indeed has a bug (all older versions also had a bug, albeit a
different and more grave one).  But what do you mean by the last
sentence above?  What does ``without the extra stack parameters''
mean?

Anyway, I append below the fixed source of d0301_s.S.  I think it
should solve your problem, although it's a bit hard to know, what with
all the text you wrote without showing a single code line or
explaining what exactly doesn't work ;-) (It's possible that the patch
you saw was for an earlier version of the function, i.e. for e a
different bug.)

> [Btw: The fixed bug (s.a.) in the ..._stack() version is so obvious
>  even to me that I only wondered that it is (still) there

It's still there because no new versions of DJGPP were released since
the bug was discovered.  The patches are published precisely for that
reason: so people who cannot wait for the next official release could
patch their libraries and go on with their coding.

Finally, your ``which stack?'' question seems to indicate that you are
unsure how to pass the data on stack to these functions.  Assuming you
use __dpmi_simulate_real_mode_procedure_retf_stack (which is what you
_should_ use), the data is taken from the last argument of the
function; see the function's documentation in the library reference.

If this still doesn't help, please post the fragment of your code
which invokes __dpmi_simulate_real_mode_procedure_retf_stack to call
the ASPI manager.

Here's the fixed version of d0301_s.S:

/* Copyright (C) 1999 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 1995 DJ Delorie, see COPYING.DJ for details */
#define USE_EBX
#define USE_ESI
#define USE_EDI
#include "dpmidefs.h"

	.text

	FUNC(___dpmi_simulate_real_mode_procedure_retf_stack)
	ENTER

	pushl	%es

	movl	ARG2, %ecx
	testl	%ecx, %ecx
	jz	L_do_call

	/* Set up %esi, %edi to copy data to the PM stack. */
	subl	%ecx, %esp
	subl	%ecx, %esp
	movl	%esp, %edi
	movl	ARG3, %esi

	/* Copy the data. */
	cld
	rep
	movsw

	/* Reload %ecx with the number of words to transfer to RM stack. */
	movl	ARG2, %ecx

L_do_call:
	movw	___djgpp_ds_alias, %es
	xorl	%ebx, %ebx
	movl	ARG1, %edi
	DPMI(0x0301)

	xorl	%eax, %eax

#define RESTORE_ESP	addl ARG2, %esp ; addl ARG2, %esp  /* comma confuses LEAVEP macro. */
	LEAVEP(RESTORE_ESP ; popl %es)

- Raw text -