Date: Thu, 3 Jun 1999 09:46:25 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp-workers AT delorie DOT com Subject: Re: __dpmi_simulate_real_mode_procedure_retf_stack In-Reply-To: <9906030423.AA13313@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 2 Jun 1999, Charles Sandmann wrote: > > Won't that cause crashes and other trouble? The DPMI host will see > > the value of ECX and copy that many words onto the RM stack. Are we > > sure there will be enough stack space to push twice the amount of > > data? The DPMI spec seems to ensure only 30 words of stack provided > > by the DPMI host, and recommends to put non-zero values into the RM > > SS:SP beyond that. > > My point is that if anyone is actually using this feature, they > probably have coded it up so that it works... and it's silly for > us to request "bytes" when the spec specifies "words" and will > copy only an even number anyway. So, I say we fix the documentation > to match the current code. I don't see how the docs alone can be changed to fix this. The problem is that the code does copy the values to the PM stack as bytes (it uses "REP MOVSB"), but then it sticks the same number of bytes into ECX, where the DPMI function expects the number of words. This will cause some of the RM stack to use twice as large space, and to have garbage in some of it. So to fix this, we need to right-shift the argument before putting it in ECX. Then the docs could be left alone. Alternatively, we could change the docs to say "words" and change the code to use MOVSW instead of MOVSB when copying to the PM stack.