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.

--
Dmitry.