From: Harold Roman Newsgroups: comp.os.msdos.djgpp Subject: Re: UNchain_protected_mode_interrupt_vector? Date: Sat, 16 Jan 1999 20:21:19 -0500 Organization: GigaNet Inc. Lines: 34 Message-ID: <36A13B0F.AE565984@giganet.com> References: NNTP-Posting-Host: pepsi.giganet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (X11; U; HP-UX B.10.20 9000/780) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Thanks for the comments. > AFAICS it is allocated in the same way as the wrapper allocated > by _go32_dpmi_allocate_iret_wrapper, so the > _go32_dpmi_free_iret_wrapper function should be able to free it > -- but I didn't check whether or not this is a good idea. I tried to call _go32_dpmi_free_iret_wrapper() with the seginfo for my-handler-function. This burst into flames with some sort of abort. I suspect that the seginfo arguement to "chain" isn't getting modified to point to the wrapper in the same way that it would in a call to "allocate_iret_wrapper". I didn't look into it any further. > When your program, or parts of libc, call malloc (in libc) it > needs to get the memory from the DPMI server. Even if you only > allocate 100 bytes, it will get the memory in chunks of 64K. > It will satisfy further requests from that block until it > is all used up, and then it will go back to the DPMI server and > ask for another 64K chunk. Well, that clear things up! Thanks. -------------------------------- Here's my solution, it seems to work for me: I create a "stub" interrupt handler and "chain" it to the desired interrupt. Then when I want to register a real handler, it gets put onto a linked list. When I want to deregister one of my real handlers, it gets removed from the linked list. The stub handler is never deregistered. The stub's only job, when called, is to look at it's linked list of registered handlers and call all of them.