@zooba I found some more cases that I was working around by explicitly linking the kernel32 lib (which shouldn't be done).

It's the three done in here and the newos.get_blocking/os.set_blocking on windows.
That one is also weird because it looks likeGetNamedPipeHandleStateW is unavailable butSetNamedPipeHandleState is available 😕

That one is also weird because it looks likeGetNamedPipeHandleStateW is unavailable butSetNamedPipeHandleState is available

IIUC, the game API functions are basically decided by what is requested, so I guess someone needed to set the state but not read it (which seems reasonable - you'd normally set the state to what you need rather than what's "best").

If they're needed by other internal functions, we might just need to get the Get one directly from the DLL (which is fine as long as wesafely handle the case where we can't get it). If you prefer to just omit the entire function then that's fine by me.

If they're needed by other internal functions, we might just need to get the Get one directly from the DLL (which is fine as long as we safely handle the case where we can't get it). If you prefer to just omit the entire function then that's fine by me.

Would be fine with me as long as I know which dll to retrieve it from. In my original xbox change (https://github.com/python/cpython/pull/102256/files#diff-27e9033ac552bd8208213a2d5a0a294312e3918cd81c4da822ab32c382e392c4) we did the same forPathCchSkipRoot andPathCchCombineEx by retrieving it fromapi-ms-win-core-path-l1-1-0.dll.

_winapi.NeedCurrentDirectoryForExePath: I have absolutely no clue whether this should be True or False.

I thinkTRUE is probably better. I'm thinking of cases where you might launch a script that runs a few processes, and is expecting to find tools in the script directory (probably CWD, likely not the "application" directory where python.exe is). But because it only affects the stdlib it probably only matters forshutil.which, so low impact in any case.

Would be fine with me as long as I know which dll to retrieve it from

Docs say kernel32.dll. The path APIs are a bit special, as I don't think they were ever in kernel32 to begin with (they were advapi32 or shell32, IIRC), but really core stuff has always been accessible from kernel32.

It might also be in an API set, but that shouldn't matter. This API isn't going to change at any rate we care about, and if the dynamic load is limited to the non-desktop partitions than devs have a much better chance of being able to manage breakage than regular users on desktop.

Skipping NEWS because it's an internal module and won't affect normal releases.