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

[Jacek Caban]

On 09.02.2017 14:00, Alexandre Julliard wrote:
> 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.

I meant that only about session 0, which is reserved for services.

> 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.

I will send a new patch, thanks.

Thanks,
Jacek