Bug 1535704 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Here are some notes on this:

* We need to get our act together with libxul dependencies. We're wasting startup time loading `user32`, `gdi32` and friends in sandboxed processes with win32k lockdown. Plus they're causing problems like the ones in this bug.

* The function involved in all of this is `combase!IsGetProcessWindowStationPresent`, which calls [`ApiSetQueryApiSetPresence`](https://docs.microsoft.com/en-us/windows/desktop/sysinfo/apisetqueryapisetpresence) to determine whether it can invoke `user32`.

* The parameter passed to `ApiSetQueryApiSetPresence` is a `UNICODE_STRING` containing "ext-ms-win-ntuser-windowstation-l1-1-0"

* I don't know how hard it is to fix our XUL dependencies. Trivially delayloading `gdi32` and `user32` is insufficient due to being loaded transitively. Maybe we can clean this up and add enough assertions such that nobody can add a breaking entry to `OS_LIBS` without being backed out.

* [This](https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/mozglue/build/WindowsDllBlocklist.cpp#802) explicit `user32` load should go away if we're locked down. If we need DLL blocking via `CreateRemoteThread` to ride the trains to make this happen (it is currently only on Nightly), then so be it.

* Short-term it might be easiest to just take care of the `ApiSetQueryApiSetPresence` issue when locked down.
Here are some notes on this:

* We need to get our act together with `xul.dll` dependencies. We're wasting startup time loading `user32`, `gdi32` and friends in sandboxed processes with win32k lockdown. Plus they're causing problems like the ones in this bug.

* The function involved in all of this is `combase!IsGetProcessWindowStationPresent`, which calls [`ApiSetQueryApiSetPresence`](https://docs.microsoft.com/en-us/windows/desktop/sysinfo/apisetqueryapisetpresence) to determine whether it can invoke `user32`.

* The parameter passed to `ApiSetQueryApiSetPresence` is a `UNICODE_STRING` containing "ext-ms-win-ntuser-windowstation-l1-1-0"

* I don't know how hard it is to fix our XUL dependencies. Trivially delayloading `gdi32` and `user32` is insufficient due to being loaded transitively. Maybe we can clean this up and add enough assertions such that nobody can add a breaking entry to `OS_LIBS` without being backed out.

* [This](https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/mozglue/build/WindowsDllBlocklist.cpp#802) explicit `user32` load should go away if we're locked down. If we need DLL blocking via `CreateRemoteThread` to ride the trains to make this happen (it is currently only on Nightly), then so be it.

* Short-term it might be easiest to just take care of the `ApiSetQueryApiSetPresence` issue when locked down.

Back to Bug 1535704 Comment 8