Nikolay Sivov nsivov@codeweavers.com wrote:
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.
This means that under Windows ole32 is probably not always get loaded, and that basically means that your patch is wrong.
Why would it better to delay-load?
Because loading ole32 is very expensive.
What's expensive about it?
Mostly dependencies and initialization.
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.
The tests don't work this way, especially if you change how low level functionality works. Adding an ole32 dependency to the user32 subsystem needs very convincing arguments.