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: from "Mark Habersack" at Jul 20, 96 03:05:42 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > 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