"Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
> 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 IsAccel
"Ge van Geldorp" <[EMAIL PROTECTED]> 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 IsAcce
> From: Dmitry Timoshkov
>
> "Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
>
> > Another idea just popped up: the basic problem we're having is
> > translating the handle passed in to a table containing the
> > accelerator entries. How about using CopyAcceleratorTableA/W
> > to do that? This functio
"Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
> Another idea just popped up: the basic problem we're having is
> translating the handle passed in to a table containing the accelerator
> entries. How about using CopyAcceleratorTableA/W to do that? This
> function is designed to do that job and is loc
> From: Dmitry Timoshkov
>
> Then it's better to fix LoadAcceleratorsA/W to use a proper allocator
> and use the same aproach in both Wine and ReactOS.
>
> But in that case you have to write a test case which works at least
> on NT/2000 and Wine.
Another idea just popped up: the basic problem we
"Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
> > That will not work. 32-bit LockResource can't be used on a
> > memory block allocated by GlobalAlloc16, as I explained before.
>
> No, not in Wine. But Wine will still use LockResource16, so there's no
> problem. I can assure you that the memory blo
> From: Dmitry Timoshkov [mailto:[EMAIL PROTECTED]
>
> "Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
>
> > Would the attached patch be an acceptable solution?
> > Basically it does a GetProcAddress on LockResource16
> > and uses it if found (Wine case). If it's not found,
> > it uses LockResource().
"Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
> Would the attached patch be an acceptable solution? Basically it does a
> GetProcAddress on LockResource16 and uses it if found (Wine case). If it's
> not found, it uses LockResource().
That will not work. 32-bit LockResource can't be used on a memory
> From: Dmitry Timoshkov
>
> "Casper Hornstrup" <[EMAIL PROTECTED]> wrote:
>
> > I would like to have the call to the Win16 API LockResource16 removed
> > from ole32.dll. I guess there is a reason for it being LockResource16
> > and not LockResource. What is the reason?
>
> Because LoadAccelerato
> -Oprindelig meddelelse-
> Fra: Dmitry Timoshkov [mailto:[EMAIL PROTECTED]
> Sendt: 6. december 2003 14:00
> Til: Casper Hornstrup
> Cc: [EMAIL PROTECTED]
> Emne: Re: LockResource16 in ole32.dll
>
>
> "Casper Hornstrup" <[EMAIL PROTECTED]>
"Casper Hornstrup" <[EMAIL PROTECTED]> wrote:
> I would like to have the call to the Win16 API LockResource16
> removed from ole32.dll. I guess there is a reason for it being
> LockResource16 and not LockResource. What is the reason?
Because LoadAcceleratorsA/W returns a value allocated by Global
11 matches
Mail list logo