[PATCH 1/2] user32: Allow creating windows using null driver for invisible winstations.

[Alexandre Julliard]

Jacek Caban <jacek at codeweavers.com> writes:

> On 08.02.2017 11:02, Alexandre Julliard wrote:
>> Jacek Caban <jacek at codeweavers.com> writes:
>>
>>> The main motivation is Office 2016 installer, which creates a
>>> non-HWND_MESSAGE window in its service (although it seems to be for
>>> message only purposes). It is supported on Windows.
>>>
>>> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
>> Hacking only CreateWindow means the driver will get calls for windows
>> that it hasn't created, that's ugly. Also the window station can change
>> dynamically, so we need better mechanisms to handle that sort of thing.
>> Ideally the driver would also have support for it, so that you could do
>> things like having separate window stations for separate X displays
>> within the same session.
>
> The problem of services is somewhat different than that. I used
> winstation to determine that situation in user32, but the real problem
> is that we don't support sessions. Services should run in a separated
> session (they do in on Windows since Vista). Processes can't interact
> with windows from other sessions, so if a driver in other process gets
> calls for windows that a service created, that's because we don't
> enforce that yet. Thus I think we eventually want services (and any
> session 0 process) to use null driver.
>
> That said, in my opinion, a fix for separated X displays is mostly
> separated issue. What would ideally be done for services is support for
> multiple sessions, including limiting windows interaction to single
> session. Given that so far I don't know any real world needing proper
> sessions support, I was hoping we could have a simpler solution.

I don't see why other sessions couldn't also have user interaction,
especially in a future multi-user architecture.

But I see that I misread your patch, you are actually relying on the
driver failing to load on the service winstation, so that would be
acceptable for now. I think the nulldrv_CreateWindow shuffling should be
done the other way around though (the null case being the default and
the no driver case set explicitly), to make it clearer what's happening.

-- 
Alexandre Julliard
julliard at winehq.org