Date: Thu, 7 Jun 2001 17:52:24 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Alex Oleynikov <alex AT compuweigh DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: DJGPP on PTS-DOS run problem
In-Reply-To: <004001c0ef5c$b77df990$1400a8c0@alex2000>
Message-ID: <Pine.SUN.3.91.1010607174442.1521J-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


On Thu, 7 Jun 2001, Alex Oleynikov wrote:

> Looks like you were right here - this little program didn't go through...
> I've attached the crash dump of the test program you wrote (NAMETEST.EXE)

Thanks.  The program didn't actually crash: it aborted itself.  That's 
what the assert macro does when its argument doesn't evaluate to 1 (i.e. 
the condition it tests is FALSE).

It would be nice to understand what happens on PTS-DOS that makes 
`access' fail.  If you could spare some time to look into this, here's 
what I'd suggest:

  - download v2/djlsr203.zip from SimTel.NET
  - extract the file src/libc/posix/unistd/access.c from djlsr203.zip
  - insert the contents of access.c into the source of the test program
  - compile the test program
  - run it under a debugger, such as GDB, step into the `access' 
    function, and see what line fails there
  - if the failure comes from another library function, which is called 
    by `access'', extract the source of that function from djlsr203, 
    insert it into your test program, and repeat the procedure, now 
    stepping inside that failing function

Eventually you will come to a low-level function which calls __dpmi_int, 
to use some DOS service, and fails.  You don't need to go any further: 
just post here where did that happen, and what error code did that DOS 
function return in the __dpmi_regs structure accepted by __dpmi_int.

Thanks in advance.