Mail Archives: djgpp/1999/01/16/20:25:22
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.
- Raw text -