Some suggestions from another legacy Windows software backports dev

[the-r3dacted]

I was looking at the readme, and saw this

At runtime, check whether a possibly unsupported Windows API function exists on the current system and use an alternative if it does not.

In nearly every case, the newer functions unnecessarily complicate things, and I think having the code to switch between new function and old function is just worse than only using the old function. There may be some cases where you get better performance with a newer function, but Python isn't very performant anyways, and from my understanding, nothing touched here in the patch actually impacts performance in any meaningful amount.

For Python 3.9+, include the file api-ms-win-core-path-l1-1-0.dll in the distribution. This file was obtained from https://github.com/adang1345/api-ms-win-core-path and is necessary for Python to run on older Windows versions.

In the past I just used original Python because I only ever needed the portable version, or to run a packaged application, and I would just manually do this myself. I never used this, because if you're building it yourself and repackaging it, you should fix the root cause (requiring this dll) instead of packaging a workaround. Unless this is actually required for core functionality and a massive effort to undo/replace (I highly doubt), or compiler hell makes it very hard or impossible to do (Usually only pre-Vista).

I did some research and it first started on 3.9.0a3 (3.9.0a4 is the first to not run), and I pretty quickly found this. python/cpython@6a65eba Which literally goes back to the first point. Why do they do both? I'd just remove the mentions of pathcch and replace the PathCchCombineEx and PathCchCanonicalizeEx code with their older counterparts.

I actually missed the above commit at first because I filtered out commits that affected earlier than 3.8, but this also was something fixed on 3.8 and earlier, although in a different way python/cpython@ad4a20b

[adang1345]

Thanks for you suggestions. However, there are good reasons for the current technique. There are features in newer versions of Windows that are desirable.

• CopyFile2() for Windows 8+ improves file copying performance.
• GetActiveProcessorCount() for Windows 7+ gives a more accurate value for os.cpu_count() than the GetSystemInfo() alternative for Windows Vista.
• GetSystemTimePreciseAsFileTime() for Windows 8+ allows for high-resolution timers in the Python time module.

As for api-ms-win-core-path-l1-1-0.dll, getting rid of it would be difficult because usage of the functions defined in this DLL has increased over time. Python 3.9 only used it a little bit, so back then, it would have been easy to patch the source code to avoid this DLL, but newer versions use <pathcch.h> functions more extensively. For example, Python 3.11 included a re-write of the the Python Launcher py.exe that uses <pathcch.h> functions in multiple places. To avoid patching the Python source code too much and to account for future changes that may use these functions more, I think it makes more sense to include api-ms-win-core-path-l1-1-0.dll in the distribution.

[the-r3dacted]

As for api-ms-win-core-path-l1-1-0.dll, getting rid of it would be difficult because usage of the functions defined in this DLL has increased over time. Python 3.9 only used it a little bit, so back then, it would have been easy to patch the source code to avoid this DLL, but newer versions use <pathcch.h> functions more extensively. For example, Python 3.11 included a re-write of the the Python Launcher py.exe that uses <pathcch.h> functions in multiple places. To avoid patching the Python source code too much and to account for future changes that may use these functions more, I think it makes more sense to include api-ms-win-core-path-l1-1-0.dll in the distribution.

Ok, that's fair. Sounds like it would be hell when this is the easiest way to do it.

GetSystemTimePreciseAsFileTime() for Windows 8+ allows for high-resolution timers in the Python time module.

I don't see the point of needing such a precise time, and I think you can replicate the behavior with QueryPerformanceCounter, but that sounds like a lot of work. I guess this makes sense, but I'd have just not used it at all if it were my fork.

GetActiveProcessorCount() for Windows 7+ gives a more accurate value for os.cpu_count() than the GetSystemInfo() alternative for Windows Vista.

I did discuss this in the past, and it seems to not actually be true (Screenshots from here Eclipse-Community/r3dfox-old#273 (comment))

Although this was about using GetThreadGroupAffinity instead of GetSystemInfo, so this may not apply here idk.

CopyFile2() for Windows 8+ improves file copying performance.

This is something I'd like to see tested, but not something I'd feel confident about testing myself. I had to revert a change meant for performance in r3dfox that involved a function like this that broke under Vista. I kinda just have a bunch of distrust of Microsoft when they say a newer function is "better" I just don't believe them.