Re: [PATCH 1/2] user32: Allow creating windows using null driver for invisible winstations.
Jacek Caban jacek@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@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.
On 08.02.2017 11:02, Alexandre Julliard wrote:
Jacek Caban jacek@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@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.
Thanks, Jacek
Jacek Caban jacek@codeweavers.com writes:
On 08.02.2017 11:02, Alexandre Julliard wrote:
Jacek Caban jacek@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@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.
On 09.02.2017 14:00, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
On 08.02.2017 11:02, Alexandre Julliard wrote:
Jacek Caban jacek@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@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
-
Alexandre Julliard -
Jacek Caban