Re: LockResource16 in ole32.dll

2004-01-24 Thread Dmitry Timoshkov
"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

Re: LockResource16 in ole32.dll

2004-01-24 Thread Alexandre Julliard
"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

RE: LockResource16 in ole32.dll

2004-01-24 Thread Ge van Geldorp
> 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

Re: LockResource16 in ole32.dll

2004-01-24 Thread 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 > function is designed to do that job and is loc

RE: LockResource16 in ole32.dll

2004-01-23 Thread Ge van Geldorp
> 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

Re: LockResource16 in ole32.dll

2004-01-23 Thread Dmitry Timoshkov
"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

RE: LockResource16 in ole32.dll

2004-01-23 Thread Ge van Geldorp
> 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().

Re: LockResource16 in ole32.dll

2004-01-23 Thread Dmitry Timoshkov
"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

Re: LockResource16 in ole32.dll

2004-01-23 Thread Ge van Geldorp
> 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

Re: LockResource16 in ole32.dll

2003-12-06 Thread Casper Hornstrup
> -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]>

Re: LockResource16 in ole32.dll

2003-12-06 Thread 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 LoadAcceleratorsA/W returns a value allocated by Global