Mail Archives: djgpp-workers/2003/04/30/08:28:21
> > + _farsetsel(_dos_ds);
>
> This modifies FS, right? And libc code uses GS?
No, it's actually GS because of include of farptrgs in the
non-modified part of the file the diff doesn't show.
> I just stumbled across a RMCB bug that only occurs under Win-XP;
> a packet-driver that uses the FS/GS registers (and assumes the
> callback saves them). But AFAICS, the gormcb.c code doesn't save
> and restore those registers. So the int 1B handler may also cause
> havoc.
A workaround would be to manually save and restore FS/GS if they
are modified. (I've always just written my own assembly wrappers
for callbacks). Fixing the wrappers will be a real pain.
> Another thing, the stack value set in wrapper_common[] sets
> ESP to 'malloced_stack + stack_length'. According to my doc's an
> i386 decrement ESP *after* a push (opposed to an 286). So the
> malloc() area is overwritten by 4 bytes. To make thing worse; the
> allocation is a multiple of 8 (ALIGN), so I guess some other area
> will choke. At least I got crashes and tracebacks in strange areas
> (end+0ff??).
I think you have some other problem - this code has worked fine before.
> Don't know if problem manifested itself due to the new malloc code
> or what. Sorry I don't have the details here now (I'm writing this
> in Pine on my ISP shell-account via Watt-32 telnet client).
The new malloc code isn't in the library yet.
- Raw text -