[PATCH] imm32: Automatically initialize COM on window activation.

[Nikolay Sivov]

On Tue, 29 Jan 2019 at 11:32, Dmitry Timoshkov <dmitry at baikal.ru> wrote:

> Nikolay Sivov <nsivov at 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.


So why is that important?


> > >> Why would it better to delay-load?
> > > Because loading ole32 is very expensive.
> > What's expensive about it?
>
> Mostly dependencies and initialization.


Be more specific please. Which dependency and what is slow about
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.


Thanks. I already explained why, not going to repeat myself. I’ll wait for
a second opinion on that one.


>
> --
> Dmitry.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190129/c2bcf51c/attachment.html>