Protected mode interrupt problem

[Jukka Heinonen]

Mike McCormack wrote:
> Two 16bit programs launch, one after the other. Each program hooks INT 
> 0, however since our interrupt tables are global to all tasks, the 
> second task retrieves the interrupt vector that the first task set.
>
> The first task exits, and restores the original INT 0 vector.  When the 
> second task exits, tries to restore the INT 0 vector set by the first 
> task, which now has an invalid selector, so it crashes.
>
> After a bit of discussion and writing a test program, we discovered that 
> it appears that some interrupt vectors are task local, and some are 
> global.  The local ones appear to be stored in the TDB (task descriptor 
> block), in offsets 0x26 - 0x4a.
>
> The attached patch fixes this, though we're not sure that it is correct 
> for DOS programs.

Well, I don't know much about the relation between Win16 tasks and DOS.
If this is how interrupt vectors are handled under Win16 then I guess
the basic idea in the patch is correct.

However, I can't see why this would cause a crash because as far as
I know, int 0 vector is never called by Wine. It doesn't really matter
but I'm just curious... (Perhaps they handle int 0 as a call chain?)

Anyway, this patch fails to initialize the vectors so any attempt to
use them causes a crash. These vectors are not currently used by Wine
(except 0x3e) so this is not yet a problem but I would really like to
see this patch changed so that those vectors are properly initialized
(possibly lazily) at program startup and when new task is created
(are they copied from another task or reset to default values?).

And, I don't think TASK_GetCurrent() should be called from winedos
and I thought use of WINE_PACKED was unnecessary and deprecated.

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>