X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" 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: References: <201404110126 DOT s3B1Q0R8020183 AT delorie DOT com> <83y4zctgrr DOT fsf AT gnu DOT org> <83r454t3tc DOT fsf AT gnu DOT org> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 wrote: > From: "Rod Pemberton" >> 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 . 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