Mail Archives: djgpp-workers/1998/07/22/15:46:55
> In general, if you do manage to hook the DOS interrupt, you don't need to
> worry about DOS non-reentrancy, since you see the call *ahead* of DOS.
> This means that when your RMCB is called, DOS is not yet busy, and you
> can do anything you want befoire chaining to DOS.
I think you should use the FSEXT stuff with PM far calls to fill/empty/
buffer the I/O - but I'm not designing it, and would only work for
V2.02+ to V2.02+ images... Kind of cooperative multitasking ;-P
> Hooking Int 21h, if possible, is a very attractive solution, since it
> will work for all programs, not only DJGPP ones, and doesn't require them
> to be recompiled.
> > > If you think about using the usual DJGPP RMCBs, then I think they
> > > *must* be locked, or CWSDPMI will abort your program. Charles, am I
> > > right here?
> >
> > Sorry, I fail to catch the idea, what do you think we must lock and
> > why?
>
> Charles once told me that CWSDPMI imposes a limitation on RMCBs, for
> safety reasons, and the upshot is that you must lock every code and data
> that is called by an RMCB. But I'm not sure I got it right, so I will
> wait for Charles to give the definitive answer.
If a RMCB comes into CWSDPMI ... you are never sure what state DOS is in.
A mouse call back may have interrupted DOS - and if you need to page fault
you would re-enter DOS, which can destroy your hard disk.
So, if you used the RMCB you would have to lock the buffers that you take
bytes out of and the code, but this would be fairly small and localized.
BTW - with my travel schedule it may sometimes take up to a week before I
can reply to these things...
- Raw text -