Zorba the Geek

The big drawback of this project is that the Xompie modules do not include all the export functions of the NT6 versions that they are meant to complement. If you examine kernelxp.def, for instance , you will see 292 out of 1416 export functions in the NT6 version of kernel32.dll have not been included. Invariably, anyone who wants to backport a Vista+ application to XP will find that Xompie does not provide all the missing imports that they require. For instance, if you want to backport Python 3.7 GetFinalPathNameByHandleW is provided by Xompie, but InitializeProcThreadAttributeList, UpdateProcThreadAttribute, and DeleteProcThreadAttributeList are not. This requires the user to copy and paste code from the Wine project into the kernelxp source, and compile it. If they are not programmers it is inevitable that they will fail. I am not a programmer, so when I tried compiling the unaltered kernelxp.c using mingw-w64 as an experiment, I received baffling error messages which I have posted as an issue at the Xompie github repository. I should point out that the kernelxp source does provide a very useful suggestion for the gcc command with options that must have worked for TuMaGoNx.

I cannot understand why people are having so much trouble backporting Python 3.7 to XP because it seems straightforward to me. Dependency Walker shows the following missing NT6 functions in XP required by Python 3.7 NT6 export functions missing in XP's kernel32.dll GetTickCount64 GetFinalPathNameByHandleW InitializeProcThreadAttributeList UpdateProcThreadAttribute DeleteProcThreadAttributeList NT6 export functions missing in XP's ws2_32.dll inet_pton inet_ntop These Winsock APIs are imported by _socket.pyd, a module which is loaded only when a network operation is performed by Python. On my system WNetRestoreConnectionA is missing from mpr.dll (Multiple Provider Router DLL) which is a dependency of shlwapi.dll (Shell Light-weight Utility Library). I am not sure if this important for the functioning of Python. The simple solution would be dll redirection using a fake kernel32.dll and ws2_32.dll that includes code snippets from the Wine project to supply the missing NT6 export functions while forwarding all the other API calls to the real kernel32.dll and ws2_32.dll of XP using a line of code like this: #pragma comment(linker, "/export:AddRefActCtxWorker=kernel32.AddRefActCtxWorker") The header of Python.exe would have to be edited so that the MajorOperatingSystemVersion and MajorSubsystemVersion is changed from 006 to 005. The import directory of Python.exe would then need to edited so that kernel32.dll is replaced with the name of the fake kernel32.dll located in the same directory of Python.exe. Another approach to intercepting API calls by the fake dlls would be a manifest file in the same directory as Python.exe. I suspect that Dibya is doing something more clever than this but when I tried to download his Python 3.7.1 project I received a 403 forbidden notice. He never provides source code so no-one can really grasp what it is he is trying to do. 404notfound has provided a link to his backported Python 3.7 project that appears to use the kernelxp.dll from the Reactos project with the description ".Kernel32 API BASE COMPATIBILITY LAYER" Usinf CFF Explorer I note that he has changed the MajorSubSystemVersion in the optional header to 005 and kernel32.dll in the import directory has been changed to kernelxp.dll. Opening his Python.exe in Dependency Walker reveals that kernelxp.dll supplies 1476 export functions, including those from the NT6 kernel32.dll, and many others have been forwarded to advapi32.dll, ntext.dll, shlwapi.dll, user32.dll, version.dll, normaliz.dll, kernelex.dll, and fileext.dll. The last three libraries are not Windows system files and they are not present in the Python project. Only one export function is forwarded to kernel32.dll which is GetTickCount. All the kernelxp.dll export functions are coloured grey because they are not in use which is weird. One of the dependencies of kernelxp.dll is ntext.dll which is the Reactos NT Layer DLL Compatibility Layer. This supplies all the export functions of ntdll.dll including 326 export functions from the NT6 ntdll.dll not available in XP, while the others are forwarded to XP's ntdll.dll. Once again all the export functions are grey suggesting they are not in use. The inclusion of ntext.dll is pointless in this context because Python.exe does not import functions from the NT6 version of ntdll.dll not available in XP. Opening his _socket.pyd in CFF Explorer I note that the import table contains entries for ws2_xx.dll and KERNEL3x.dll, the latter of which is not present in his project. ws2_xx.dll has no description, so I do not know if it originates from Reactos. Opening _socket.pyd in Dependecy Walker shows empty parent import and export panes which is weird because it's description shows that it should be an original Python module. One of it's dependencies is ws2_xx.dll which supplies the missing inet_pton and inet_ntop functions, while all the others are forwarded to XP's ws2_32.dll. Again all these export functions are coloured grey I suspect that the reason why get-pip.py does not work is because _socket.pyd has been mucked about with. TuMaGoNx is right in stating that backporting PyPy would be less challenging. pypy3.exe only requires the export function GetTickCount64 from the NT6 version of kernel32.dll and this could be replaced with the XP GetTickCount when recompiling Python. There are still the two missing functions in XP's ws2_32.dll imported by libpypy3-c.dll to deal with. He is wrong to state that C extensions are not an issue with PyPy because C extensions can be compiled for PyPy just as they can be for the standard Python distribution.

A reddit user has posted his custom Python 3.5 binaries intended for Windows XP. The download can be found at https://drive.google.com/open?id=0BwiHllHhj79zaF9faEVsQUsxNDQ As he has not provided an installer I have written this little reg file to provide some of the registry settings one would expect with an official msi installer. It includes associating file types with Python, installation of wheels by double clicking .whl files, the Python path, and the install path. It has been written for an installation at C:\Python35 and needs to be edited if you want to install Python elsewhere. ideally you would use a batch file with the reg command because then you include variables like %SYSTEMROOT% in paths. I have installed this version of Python on my XP machine, and so far everything has gone swimmingly. I ran get-pip.py and the latest versions of pip, wheels, and setup tools were installed with no errors. I have also installed requests2 as a Python wheel and that went OK too. I have been experimenting with this Python as a means to download videos, and despite only succeeding in downloading one video using urllib and requests I have concluded that it is a useful addition to my toolbox and shall keep it on my hard drive According to the developer "zipimport and many 3rd party c extensions don't work on Windows XP now" Requires Microsoft Visual C++ 2015 Redistributable Python 3.5.reg