LockResource16 in ole32.dll

[Alexandre Julliard]

"Ge van Geldorp" <ge at gse.nl> writes:

> Just to be sure: if I understand you correctly you suggest doing the
> LockResource16 in LoadAcceleratorsA/W, then GlobalAlloc a new block of
> memory, copy the table to the new block and return the global memory
> handle as the HACCEL. Then in IsAccelerator use GlobalLock to get at the
> contents. Please correct me if I'm wrong.
>
> Doesn't that still violate DLL separation? Ole32.dll "knows" that a
> HACCEL is actually a HGLOBAL and even "knows" how the accelerator table
> is stored internally. IMHO that stuff should only be known to user32.
> Put another way: if you run the proposed ole32 IsAccelerator code on MS
> Windows it would fail. Using CopyAcceleratorTable (a user32 function)
> fixes this, knowledge of the internal structure is limited to user32.

Yes, that sounds like the right way. Dmitry is right that the
accelerator support needs to be fixed to not allocate 16-bit memory,
but as far as ole32 is concerned it shouldn't matter, because ole32
has no business knowing what's behind an accelerator handle.

-- 
Alexandre Julliard
julliard at winehq.com