[azchohfi]

On Windows, poll() in compat/poll/poll.c waits with MsgWaitForMultipleObjects() and pumps
window messages with PeekMessage(), TranslateMessage() and DispatchMessage(). These are the
only functions git.exe imports from user32.dll, so every Git process loads user32, and with it
gdi32, gdi32full, win32u and imm32, even though most commands never call poll().

This loads the four functions with the existing lazyload.h helpers the first time poll() runs.
If user32 cannot be loaded, the process cannot have a message queue to pump, so it waits with
WaitForMultipleObjects().

git.exe then maps 17 images for git --version instead of 23. On a Windows 11 desktop, built
from v2.55.0.windows.5 with and without the change, 100 interleaved runs each:

	before	after	saved
git --version	15.5 ms	13.2 ms	2.2 ms [2.0, 2.4]
git rev-parse --git-dir	17.5 ms	15.2 ms	2.3 ms [2.0, 2.4]
git status --short	48.5 ms	46.2 ms	2.0 ms [1.7, 2.2]
git log -1 --oneline	20.4 ms	18.0 ms	2.3 ms [2.0, 2.5]

t0061-run-command, t5400-send-pack and t5601-clone pass with the change, on the release and
on main.

The same code is in upstream Git, so I can send it to the mailing list too if you prefer it to go
upstream first.

I used GitHub Copilot to help investigate and prepare this change. I have reviewed and tested it.

[rimrul]

If user32 cannot be loaded, the process cannot have a message queue to pump, so it waits with
WaitForMultipleObjects()

Could you elaborate on where we'd expect to need that fallback?

[azchohfi]

Mostly sandboxes that start processes with Win32k system calls disabled (PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON). user32.dll can't initialize in those, so today's git.exe doesn't even start there (it fails with 0xC0000142 before main() runs). With this change, git --version and git rev-parse work in that setup.

If such a process gets to poll(), loading user32 fails and it falls back to a plain wait on the handles. There's no message queue to pump in that case anyway.

I haven't been able to hit that path, though, because anything that reaches poll() also starts sh.exe, which fails the same way. If you'd rather not keep code that isn't exercised, I can drop the fallback and have poll() return an error instead.

[rimrul]

Mostly sandboxes that start processes with Win32k system calls disabled (PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON). user32.dll can't initialize in those, so today's git.exe doesn't even start there (it fails with 0xC0000142 before main() runs). With this change, git --version and git rev-parse work in that setup.

Ah, sandboxes are the puzzle piece I didn't think about hard enough. I even looked up if nano server had no user32.dll, but sandboxes make sense.

I haven't been able to hit that path, though, because anything that reaches poll() also starts sh.exe, which fails the same way. If you'd rather not keep code that isn't exercised, I can drop the fallback and have poll() return an error instead.

That fallback might become reasonably reachable in combination with msys2/MSYS2-packages#6785 and git-for-windows/MINGW-packages#230.

It might make sense to mention in the commit message that this fallback is intended for sandboxed environments with PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON.

[azchohfi]

Thanks, I've added that to the commit message.

I also found a way to reach the fallback without a shell: parallel checkout waits for its checkout--worker children with poll(). In a process started with Win32k disabled, git -c checkout.workers=8 -c checkout.thresholdForParallelism=0 switch <branch> worked 10 times out of 10 with this change, and the checked-out files were correct. And you're right about msys2/MSYS2-packages#6785: with bash built against that readline, a post-checkout hook also runs through sh.exe in the same sandbox, while with the current bash it doesn't start.