Thanks for contribution. Before I can get into the real review (it will take some time on my side), I have two questions:

• would it be possible to split this in two PRs (MinGW and 3.12)? I feel that the MinGW part could be much easier to review, much less controversial, and bring value immediately
• re compatibility with 3.12, how is the proposed solution supposed to help with loading the Python 3.12 DLL from memory (in other words, to work with bundle_files <= 1)?

ok, thanks for the suggestions.. i will split the PR

I left a few comments. General thought: I am willing to merge this PR as it is (if we are able to make all the tests pass, currently working on that). However, please be advised that MinGW is not a test target of this project and I personally do not intend to actively support it. Therefore, there is a chance that every single future commit could break this compatibility.

No worries, MSYS2 will maintain this package :)

No worries, MSYS2 will maintain this package :)

That's good to hear. But then, would you like to add one (or more) MinGW test target in the Actions workflow?

Thank you again for this PR!

Thank you too!

Also to add a little note for when 3.13+ needs support.

In windows due to how LoadLibraryA/W loads DLLs with the TLS information that initialization of the python core when bundle_files <= 1 is not possible. The resulting files must be the exe with the python core dll as a separate file from the exe in order for it to be initialized properly. That is unless the dll gets packed into the win32 resource section and just prior to it calling any python C api functions for it to write the dll to the disk. But even then that can break the built in C extensions when the exe does not directly import the core dll in it's IMPORT_ADDRESS_TABLE.

What this means for py2exe:

• When 3.13+ on python is requested, py2exe must provide both the core dll with the exe. I am sorry that it is currently not possible to single file it for 3.13+.
  • In 3.13+ a bit of required C code inside of import.c in the cpython source code for which _memimporter.c uses was removed so adding them would require build our own custom import.c that contains only the removed functions updated to the call the 3.13+ stable ABI.