On 1/29/19 10:52 AM, Dmitry Timoshkov wrote:
Nikolay Sivov nsivov@codeweavers.com wrote:
--- a/dlls/imm32/Makefile.in +++ b/dlls/imm32/Makefile.in @@ -1,6 +1,6 @@ MODULE = imm32.dll IMPORTLIB = imm32 -IMPORTS = user32 gdi32 advapi32 +IMPORTS = user32 gdi32 advapi32 ole32
According to dumpbin output imm32 in Windows doesn't import ole32 directly, most likely it loads it manually only when really needed. So, it would probably be better to either use delay loading, or also load it manually, and make sure that ole32 is never loaded for languages that don't need IME.
I doesn't depend on the language, it will work as long as IME is not disabled for thread/process.
As far as I can see from the tests IME messages are optional, and that means that IME is completely disabled in some Windows configurations. For instance I don't get IME messages in 2 of 3 my Windows machines.
That's hardly relevant, if it's disabled patch will skip initialization.
Why would it better to delay-load?
Because loading ole32 is very expensive.
What's expensive about it?
It will be called practically always for GUI applications.
Adding a convincing test case would be also helpful.
I don't think so, it's clearly internal behavior. If you're really interested there is a test at https://bugs.winehq.org/show_bug.cgi?id=42695, that works regardless of your input language, and doesn't work if application disables IME for itself.