Hi,
could you please give me any hints related to this patch?
The way how imm32 is loaded or not is quite strange in it. It's generally matching native behavior but I'm not sure if it's needed here. I also don't see a nice way of testing it inside wine test suite.
Thank you, Piotr
Piotr Caban piotr.caban@gmail.com writes:
Hi,
could you please give me any hints related to this patch?
The way how imm32 is loaded or not is quite strange in it. It's generally matching native behavior but I'm not sure if it's needed here. I also don't see a nice way of testing it inside wine test suite.
In which case does it make a difference to load it this way?
But the real bad part is passing a function pointer through the magic DWORD. There has to be a better way.
On 11/10/14 12:02, Alexandre Julliard wrote:
Piotr Caban piotr.caban@gmail.com writes:
Hi,
could you please give me any hints related to this patch?
The way how imm32 is loaded or not is quite strange in it. It's generally matching native behavior but I'm not sure if it's needed here. I also don't see a nice way of testing it inside wine test suite.
In which case does it make a difference to load it this way?
It makes it possible to load and unload imm32.dll. On the other hand it leaves user32 dll in broken state, that leads to crashes while calling some user32 functions on windows (tested on Windows 7 and XP).
But the real bad part is passing a function pointer through the magic DWORD. There has to be a better way.
Do you think that adding additional export to wine's imm32 is acceptable?
Thanks, Piotr
Piotr Caban piotr.caban@gmail.com writes:
On 11/10/14 12:02, Alexandre Julliard wrote:
In which case does it make a difference to load it this way?
It makes it possible to load and unload imm32.dll. On the other hand it leaves user32 dll in broken state, that leads to crashes while calling some user32 functions on windows (tested on Windows 7 and XP).
Yes, but is there really an app that depends on being able to unload imm32?
But the real bad part is passing a function pointer through the magic DWORD. There has to be a better way.
Do you think that adding additional export to wine's imm32 is acceptable?
It's not great, but it's less offensive, if there's no other way.
On 11/10/14 12:27, Alexandre Julliard wrote:
Piotr Caban piotr.caban@gmail.com writes:
On 11/10/14 12:02, Alexandre Julliard wrote:
In which case does it make a difference to load it this way?
It makes it possible to load and unload imm32.dll. On the other hand it leaves user32 dll in broken state, that leads to crashes while calling some user32 functions on windows (tested on Windows 7 and XP).
Yes, but is there really an app that depends on being able to unload imm32?
No.
But the real bad part is passing a function pointer through the magic DWORD. There has to be a better way.
Do you think that adding additional export to wine's imm32 is acceptable?
It's not great, but it's less offensive, if there's no other way.
I was trying to find how native does it. It works completely different on windows. There's an undocumented window message sent on every keyboard layout change. I guess native passes some internal structures there. Because we don't have such notifications I didn't want to implement similar (but not compatible) mechanism.