X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	"Rod Pemberton" <dont_use_email AT xnothavet DOT cqm>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Is this a bug in crt1.c?
Date:	Fri, 11 Apr 2014 16:59:43 -0400
Organization:	Aioe.org NNTP Server
Lines:	63
Message-ID:	<op.xd569tns6zenlw@localhost>
References:	<op DOT xd4ntjft6zenlw AT localhost>
	<201404110126 DOT s3B1Q0R8020183 AT delorie DOT com> <op DOT xd44buvg6zenlw AT localhost>
	<83y4zctgrr DOT fsf AT gnu DOT org> <op DOT xd5etwkg6zenlw AT localhost>
	<83r454t3tc DOT fsf AT gnu DOT org>
NNTP-Posting-Host:	CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org
Mime-Version:	1.0
X-Complaints-To:	abuse AT aioe DOT org
User-Agent:	Opera Mail/12.16 (Linux)
X-Notice:	Filtered by postfilter v. 0.8.2
Bytes:	4083
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

On Fri, 11 Apr 2014 09:04:47 -0400, Eli Zaretskii <eliz AT gnu DOT org> wrote:
> From: "Rod Pemberton" <dont_use_email AT xnothavet DOT cqm>
>> Eli

>>> Therefore, env_selector is suitable to be the 1st arg of movedata.
>>
>> Sigh, that is exactly what I asked about.
>> This is also where you've lost me.
>
> And you have now lost me.  What exactly is the problem, in detail?
>

The enivronment segment is created by DOS and stored in the PSP as
a RM segment.  The code appeared to be retrieving and using that RM
segment directly as a PM selector.  Being confused about this, I said
that can't be the case since movedata() doesn't accept segments, unless
maybe it did actually accept segments, or maybe it is a bug ...  I
asked where is the conversion of the environment's RM segment within
the PSP is converted into a PM selector.  Half of that was answered
in a very roundabout, RTFM way, which I've done too many times to count,
and was irked by.  So, the half that was answered is the PSP segment
is converted to a selector by the DPMI client.  That's where the
hidden conversion takes place, but the DPMI host leaves that in ES.
I've overlooked this or ignored it since I don't generally need the
PSP for DPMI with assembly or C.  The other half, as to where and
how a PM selector gets into the PSP, now known to be left in ES, so it
could be used by movedata(), wasn't answered.  Obviously, now that I
know the DPMI creates the PM selector for the PSP, it's simply stored
within the PSP somewhere, probably in assembly code right after or near
the call to init DPMI.  I can probably locate that myself, now that I'm
aware that there was a "hidden," and "undocumented" conversion of the
environment's segment value in the PSP to a selector.  I searched for
0x2c before, but I don't recall finding anything that stored into it.
A search for 1686 or 1687 should find it, perhaps crt0.S.

So...  The answer is: no, it's not a coding mistake to use movedata()
since we secretly rewrote the DOS environment's RM segment in the PSP
with a PM selector using one provided to us by the DPMI client.  This
occurs in <file(s) to be found>.  Or, the answer is something very
similar to that.

At best, this is deceptive, secretive, unclear and not all that accurate:

   "The environment pointer in the client program's PSP is
  automatically converted to a selector during the mode switch."

That states that the PM selector for the environment is written
to the PSP by the DPMI host during it's mode switch.  Not true.
The DPMI host doesn't write to the PSP.  It leaves a value in ES.
Writing to the PSP may be part of the startup code's routine which
calls the mode switch, but it's clearly not part of the DPMI host's
mode switch.  That's obvious from the info on the page that the
quote came from.

Sigh, this all came up because I wanted to know if DJGPP placed any
limitations on the size of the passed environment since I couldn't
find anything regarding the size limit of a DOS environment string.

Now, I'm wondering how safe it is to mess with DOS' structures by
writing into them, changing values ...


Rod Pemberton

- Raw text -