From:	Sengan DOT Short AT durham DOT ac DOT uk
Message-Id:	<27927.9607201420@ws-ai5.dur.ac.uk>
Subject:	Re: XMS entry point
To:	grendel AT ananke DOT amu DOT edu DOT pl (Mark Habersack)
Date:	Sat, 20 Jul 1996 15:20:16 +0100 (BST)
Cc:	djgpp AT delorie DOT com
In-Reply-To:	<Pine.NEB.3.93.960720145510.4266A-100000@ananke.amu.edu.pl> from "Mark Habersack" at Jul 20, 96 03:05:42 pm
Mime-Version:	1.0

> I am writing a set of routines to detect and provide info on various
> memory-management services. Among all the others there's one to cope with XMS.
> One of the stages in getting XMS info is to collect the real-mode entry-point
> address for the XMS services. And here's where problems begin. I succesfuly
> retrieve this entry point using 0x4310 int 2F call but when I try to call the
> procedure it hangs the machine. Of course I'm not calling the proc directly
> but by means of __dpmi_simulate_proc_retf (I don't remember the name right
> know - they all too long ;-)))) - but it doesn't work. I was unable to check
> what's going on, even with GDB - it hangs also. As far as I could check, the
> es:bx pointer returned by 0x4310 2F call is OK. Where lies the problem? Is it
> allowed to call the XMS services from 32-bit proggy? I have checked that it is
> not a problem of DPMI server - all of them crash without a blink. 
> The only sensible message I got from the system comes from EMM386 - it says
> about exception in the software (it doesn't say which one) and that the system
> has been halted. So it seems that the crash happens AFTER processing the call
> by DPMI server. 

Well, I expect you are conflicting with the DPMI server: the DPMI server uses
XMS if it is available (possibly through EMM if necessary). So if you change
stuff in a way the dpmi server does not expect, you must expect trouble.

Also, it might help to know with what parameters you are calling the
procedure with.

Sengan

- Raw text -