Xref: news2.mv.net comp.os.msdos.djgpp:1658 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Q: DPMI Date: Tue, 05 Mar 1996 12:23:46 CST Organization: Rice University, Houston, Texas Lines: 28 Message-ID: <313c86b2.sandmann@clio.rice.edu> References: Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > [1] When try to allocate a real mode callback and pass the address of a real > mode call structure to DPMI function 0x0303, does it copy structure's > contents to some internal buffer or does it use the original one (the one I > passed)? If so, do I need to lock it? Since the contents at that point are undefined, it does not copy anything. You are just passing it an address of a structure to be used when the RMCB happens. Yes, you should lock it. Since the structure location itself would be re-used (overwriting the previous values) if another RMCB happened while you inside the first, you shouldn't re-enable interrupts unless you know all the fine print in the DPMI spec and have made your routine do the copies and made it reentrant. > [2] It is said in the FAQ that changing the PM int vector automatically changes > the appropriate RM vector. Why and how? This is only for hardware interrupts (which can happen in either mode). It is done by the DPMI provider. This is done to make sure your PM HW interrupt handler gets called, even if the HW interrupt happens in RM (like in the middle of DOS or a disk I/O). Thus the need for locking. > So can someone help me or show a `live' example of setting a mouse event > handler with int 33/AH=0C? Or maybe a RM hw interrupt handler? Please? A somewhat flawed example is available in ftp.neosoft.com:pub/users/s/sandmann in torture.zip - it hooks HW interrupts, the mouse, and then page faults like crazy. I know it has bugs, and it's terrible code, but it's better than nothing as an example.