Python 3.7.1 for Windows XP

[Dibya]

14 hours ago, dencorso said:

@FranceBB & @Dibya: The yodeling obvious, if it hasn't yet dawned on you both, is that both your day-to-day XP systems are too modified to serve as test platforms, and that, by contrast, the virtual machines you both are using as alternative test platforms are not realistic enough to display the issues people are finding... With all due respect, haven't you realized that by yourselves, by now?

My exams are going on . I will install a raw XP on my laptop for testing.

Any beta tester will be highly appreciated

[404notfound]

Eh, I'm using XP with unofficial "SP4" updates(OS reinstall from POSReady 2009).

https://anonfile.com/RbQ7w4qfb4/Python37_zip
I've repackaged and twiddled with python 3.7 a bit, using a few suggestions from other thread.
Cleanup folder structure a bit, separate misc files from the pyc(fixes pip failure), added tkinteri+tcl, include get-pip.py,

One slightly curious thing is this.
https://www.virustotal.com/en/file/40ef233105b36ea12b600235ad96905820053246bcb003f22eb33ca180ef28c1/analysis/1544275319/
https://www.virustotal.com/en/file/a29e6eef3a1ee7a9606b5092d3ca61e7f1675a67798e9514bcfad7b46b9fbad6/analysis/1544275691/
I'm thinking maybe false positives.

Edited January 12, 2019 by 404notfound

[Dibya]

It is ultra false positive.

[FranceBB]

Definitely false positive; we would never release a virus. (Not like this, not to this community).

[Dibya]

6 minutes ago, FranceBB said:

Definitely false positive; we would never release a virus. (Not like this, not to this community).

Come on man I hate virus devlopers personally.

I need to pay money to eset due to them.

 

[FranceBB]

4 hours ago, Dibya said:

Come on man I hate virus devlopers personally.

I need to pay money to eset due to them.

 

I hate viruses too. In an ideal world, antivirus softwares wouldn't exist and we wouldn't waste resources.

Unfortunately, there are thieves on the high street and there are thieves on the web.  

On the top of that, instead of living in in harmony all together, different countries have different views on different things and they often disagree and these views lead to international conflicts, which is why there are terrorists spread all over the world and intelligence agencies like NSA and MI6 that actually make viruses to spy enemies and to protect their citizens and there are criminals that make viruses to steal credit cards and so on.

Will we ever agree and live in harmony in the whole world? Probably not as it's a utopia, but in all this darkness there's a little shining ray, 'cause here in MSFN there are people from different countries and we all respect each other and try to help each other, which makes me think that maybe, just maybe, one day, human beings will refrain from being greedy and will cooperate (but I'll probably be long gone into dust before this happens).

(end of off-topic).

[Thomas S.]

@404notfound, @Dibya and @FranceBB

Hello all. Nice work, but...

If a project requires a development environment, this must also fully run.
If Python 3.7 under XP is required as a development environment for HTTPSProxy under XP, Python 3.7 must be fully installable and supported.
It is unacceptable that already the development environment must be sought together until it runs without error.
The Python modules need to be updated regularly, there are enough tests therefor. I would like to supply SW to my user, that is not develloped on a possibly faulty development environment...

Sorry, but so your project is not suitable for a development of HTTPSProxy (at this time) i think.

[TuMaGoNx]

Cpython 3.5 and up use VS2015/2017 (which not run on XP,) to build C-ext thus porting just cpython is half of story. Different approach would be Pypy (pure python), last time I check (py 3.5) still use VS2008 (not that it matter much anyway) and run fine on XP.

Then there is msys2's python3 (mingw64) if you want to go separate way from the official.

[Dibya]

On 4/7/2019 at 6:30 AM, TuMaGoNx said:

Cpython 3.5 and up use VS2015/2017 (which not run on XP,) to build C-ext thus porting just cpython is half of story. Different approach would be Pypy (pure python), last time I check (py 3.5) still use VS2008 (not that it matter much anyway) and run fine on XP.

Then there is msys2's python3 (mingw64) if you want to go separate way from the official.

MinGw has severe performance issues .

 

[Dibya]

Source code : https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz

Some one can help me to fix UpdateProcThreadAttribute  , InitializeProcThreadAttributeList , DeleteProcThreadAttributeList

These calls are located in _winapi.c

 

[TuMaGoNx]

Dibya as I said you will solve only half of the problem, python without its abundant c-ext (though some may work put of the box) libraries is not that good.
with PyPy you only need patch the core which for current version is trivial

[ops]

[Zorba the Geek]

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.

 

 

                                                                              

Edited December 26, 2019 by Zorba the Geek

[ops]

Also, I do not know how to paste text from the clipboard into the window.