GDI separation patch

[Andreas Mohr]

On Sun, May 05, 2002 at 02:12:57PM +0200, Eric Pouech wrote:
> > BTW, does anyone have an idea how to get rid of the remaining LOCAL_xxx()
> > calls in gdiobj.c ?
> > We need those because we do
> >     GDI_HeapSel = instance | 7;
> > , so we directly use the GDI instance plus 7 as the heap selector
> > for GDI objects (thus we can't do a standard LocalInit, as this would
> > allocate a *new* selector for the new heap instead of using the implicit
> > GDI module one, and thus we need to pass the GDI_HeapSel to LOCAL_Alloc instead)
> I'd say: write a wrapper in gdi which
> 	1/ sets DS to the GDI_HeapSel value
> 	2/ calls LocalAlloc16 (for instance) (the call has to be a 16 bit
> call),
> 	   so you need the relay to be generated for this 16 bit call
> 	3/ restores old DS value (before 1)
> 
> this sounds hacky, but it was a standard way of using the LocalXXX on
> several
> 64k buckets at the same time
> 
> you may also create a new type of 32 => 16 relay stub, which sets DS to
> a
> passed value... (that'd be IMO the cleanest way...)
Thanks for the reply !

Hmm, I guess I don't even need to do that.
After all we're talking 32 bit code here.
What should prevent me from changing the 16bit stack frame
(CURRENT_DS -> CURRENT_STACK16->ds) to the correct selector
before and after the call ?
(LocalAlloc16 et al. pick up the local heap selector by consulting CURRENT_DS).

AFAICS there's nothing that stops me.

So I'll just create wrapper functions in gdiobj.c like GDI_LocalAlloc
that set CURRENT_DS to GDI_HeapSel, call func and restore CURRENT_DS.

This could be a problem if the local heap functions did some Win16 callback,
but even then: I don't see a problem if those imaginary callbacks were made
using the GDI heap sel stack frame DS (after all we are operating on
GDI local heap, so the Win16 DS should indicate that, I guess !).

-- 
Andreas Mohr                        Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604                http://home.arcor.de/andi.mohr/