Jump to content

Python 3.5 Runtime Redistributable backported to XP


FranceBB

Recommended Posts

Hi folks!

Python (multi-platform programming language) officially dropped its support for Windows XP. Python programs are slightly different compared to other programs, because they are not compiled when you download them: they are just scripts. When you click on them, they will look for Python "assemblies" in order to quickly compile the program during the runtime. (It's not 100% true, but that's an over-simplyfied explanation). So... since Python dropped its support for XP, this meant a big issue for Python programs 'cause the old "assemblies" can't compile 3.5 scripts; that's why Python 3.5 Runtime Redistributable - Windows XP is here for you.

Please note that this is an unofficial Runtime Redistributable package. Extract it to "C" and rename it "Python35". The core and its dependencies have been compiled to run in Windows XP, but I have been able to test with a single program 'cause I don't have any other programs written for Python 3.5.

You'll find the official Python website screen and the backported version below.

Link

35python.PNG

XP.PNG

Edited by FranceBB
Link to comment
Share on other sites


  • 2 years later...

Actually, it was working on my computer in 2015 and it still is now. It must be something about your configuration.

mfSqx2I.png

Anyway, years passed and nowadays Python 3.7.1 is out.

Programmes written using 3.7.1 capabilities won't be able to be compiled at runtime by Python 3.5 anyway, so even if you manage to get it up and running, it would be useless for programmes written after 2016. Someone should backport a newer version of Python. @someguy25 I noticed that you opened a topic already about newer version of Python, but as @Dibya said, there's no guarantee that it will be working. 

Quote

As i know MSFN is a magical place.

It's a magical place... to a certain extent. xD

 

Edited by FranceBB
Link to comment
Share on other sites

8 hours ago, someguy25 said:

This is cool :w00t:I installed it and....

this happened

Something is wrong here:dubbio:

I tried downloading & installing and got the same result.

It's hard to tell from the screen shots, but it looks like @FranceBB's installation contains eight folders in addition to the seven files that were created during installation. My guess is that some/all of those folders and their contents are also required, but I don't know where one would get them.

Edit: Got it working. Had to install Python 3.5.4 on a Win 7 system, then copy all the folders over, but it works now.

Edited by Mathwiz
Link to comment
Share on other sites

@Mathwiz I see... Perhaps I forgot to include something back then. It just baffled me that nobody noticed it for years...

@someguy25 I'm not really sure about what I did in 2015/2016, but I tried make a new installer and it found 3481 dependencies and I have now included them all.

 

New Installer (of the old 3.5 project): Link

EXE header size:               50688 / 37888 bytes
Install code:                  30540 / 202408 bytes
Install data:               24995897 / 116377752 bytes
CRC (0xE68CCFD0):                  4 / 4 bytes

Link to comment
Share on other sites

@VistaLover I mean the C python one by PolarNick for MinGW using MSYS2. It just works around kernel calls that are not implemented in XP like so:

--- a/PC/python.manifest

+++ b/PC/python.manifest

@@ -1,6 +1,6 @@

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

- <trustInfo>

+ <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

     <security>

       <requestedPrivileges>

         <requestedExecutionLevel level="asInvoker" uiAccess="false"/>

--- a/Modules/posixmodule.c

+++ b/Modules/posixmodule.c

@@ -1445,6 +1445,31 @@

     return TRUE;

 }

 

+/* Grab GetFinalPathNameByHandle dynamically from kernel32 */

+static int has_GetFinalPathNameByHandle = -1;

+static DWORD (CALLBACK *Py_GetFinalPathNameByHandleW)(HANDLE, LPWSTR, DWORD,

+ DWORD);

+static int

+check_GetFinalPathNameByHandle()

+{

+ HINSTANCE hKernel32;

+ DWORD (CALLBACK *Py_GetFinalPathNameByHandleA)(HANDLE, LPSTR, DWORD,

+ DWORD);

+

+ /* only recheck */

+ if (-1 == has_GetFinalPathNameByHandle)

+ {

+ hKernel32 = GetModuleHandleW(L"KERNEL32");

+ *(FARPROC*)&Py_GetFinalPathNameByHandleA = GetProcAddress(hKernel32,

+ "GetFinalPathNameByHandleA");

+ *(FARPROC*)&Py_GetFinalPathNameByHandleW = GetProcAddress(hKernel32,

+ "GetFinalPathNameByHandleW");

+ has_GetFinalPathNameByHandle = Py_GetFinalPathNameByHandleA &&

+ Py_GetFinalPathNameByHandleW;

+ }

+ return has_GetFinalPathNameByHandle;

+}

+

 static BOOL

 get_target_path(HANDLE hdl, wchar_t **target_path)

 {

@@ -1453,7 +1479,7 @@

 

     /* We have a good handle to the target, use it to determine

        the target path name (then we'll call lstat on it). */

- buf_size = GetFinalPathNameByHandleW(hdl, 0, 0,

+ buf_size = Py_GetFinalPathNameByHandleW(hdl, 0, 0,

                                          VOLUME_NAME_DOS);

     if(!buf_size)

         return FALSE;

@@ -1464,7 +1490,7 @@

         return FALSE;

     }

 

- result_length = GetFinalPathNameByHandleW(hdl,

+ result_length = Py_GetFinalPathNameByHandleW(hdl,

                        buf, buf_size, VOLUME_NAME_DOS);

 

     if(!result_length) {

@@ -1497,6 +1523,12 @@

     wchar_t *target_path;

     const char *dot;

 

+ if(!check_GetFinalPathNameByHandle()) {

+ /* If the OS doesn't have GetFinalPathNameByHandle, don't

+ traverse reparse point. */

+ traverse = FALSE;

+ }

+

     hFile = CreateFileA(

         path,

         FILE_READ_ATTRIBUTES, /* desired access */

@@ -1587,6 +1619,12 @@

     wchar_t *target_path;

     const wchar_t *dot;

 

+ if(!check_GetFinalPathNameByHandle()) {

+ /* If the OS doesn't have GetFinalPathNameByHandle, don't

+ traverse reparse point. */

+ traverse = FALSE;

+ }

+

     hFile = CreateFileW(

         path,

         FILE_READ_ATTRIBUTES, /* desired access */

@@ -3824,6 +3862,13 @@

     if (path_wchar == NULL)

         return NULL;

 

+ if(!check_GetFinalPathNameByHandle()) {

+ /* If the OS doesn't have GetFinalPathNameByHandle, return a

+ NotImplementedError. */

+ return PyErr_Format(PyExc_NotImplementedError,

+ "GetFinalPathNameByHandle not available on this platform");

+ }

+

     hFile = CreateFileW(

         path_wchar,

         0, /* desired access */

@@ -3839,7 +3884,7 @@

 

     /* We have a good handle to the target, use it to determine the

        target path name. */

- buf_size = GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT);

+ buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT);

 

     if(!buf_size)

         return win32_error_object("GetFinalPathNameByHandle", path);

@@ -3848,7 +3893,7 @@

     if(!target_path)

         return PyErr_NoMemory();

 

- result_length = GetFinalPathNameByHandleW(hFile, target_path,

+ result_length = Py_GetFinalPathNameByHandleW(hFile, target_path,

                                               buf_size, VOLUME_NAME_DOS);

     if(!result_length)

         return win32_error_object("GetFinalPathNamyByHandle", path);

--- a/Python/pytime.c

+++ b/Python/pytime.c

@@ -463,7 +463,7 @@

     /* 11,644,473,600,000,000,000: number of nanoseconds between

        the 1st january 1601 and the 1st january 1970 (369 years + 89 leap

        days). */

- *tp = large.QuadPart * 100 - 11644473600000000000;

+ *tp = large.QuadPart * 100 - 11644473600000000000ULL;

     if (info) {

         DWORD timeAdjustment, timeIncrement;

         BOOL isTimeAdjustmentDisabled, ok;

@@ -557,6 +557,32 @@

     return pygettimeofday(t, info, 1);

 }

 

+/* GetTickCount64() is not available on XP. */

+ULONGLONG GetTickCount64_Alternative ()

+{

+ static ULONGLONG (CALLBACK *Py_GetTickCount64)() = (ULONGLONG (CALLBACK *)(void))-1;

+ static DWORD last_ticks = 0;

+ static DWORD n_overflow = 0;

+ DWORD ticks = 0;

+ HINSTANCE hKernel32;

+

+ if (Py_GetTickCount64 == (void*)-1)

+ {

+ hKernel32 = GetModuleHandleW(L"KERNEL32");

+ Py_GetTickCount64 = *(ULONGLONG (CALLBACK *)(void))(GetProcAddress(hKernel32,

+ "GetTickCount64"));

+ }

+ if (Py_GetTickCount64 != (void*) NULL)

+ {

+ return Py_GetTickCount64();

+ }

+

+ ticks = GetTickCount();

+ if (ticks < last_ticks)

+ n_overflow++;

+ last_ticks = ticks;

+ return ((ULONGLONG)n_overflow << 32LL) + (ULONGLONG)GetTickCount();

+}

 

 static int

 pymonotonic(_PyTime_t *tp, _Py_clock_info_t *info, int raise)

@@ -566,7 +592,7 @@

 

     assert(info == NULL || raise);

 

- result = GetTickCount64();

+ result = GetTickCount64_Alternative();

https://gist.github.com/PolarNick239/5168c2bbf2731171bc190a465cc4d052

By the way, it seems that the author of xompie has been working on a newer version of python (3.5.2): https://opensourcepack.blogspot.com/2016/10/python-352-on-xp.html?m=1

 

 

Edited by FranceBB
Link to comment
Share on other sites

On 11/19/2018 at 5:37 PM, someguy25 said:

This is cool :w00t:I installed it and....

this happened

Something is wrong here:dubbio:

img4.JPG

img6.JPG

Hey dude , I got a snake from jungle ported for you .

Take care of my pet python.

python xp

 

Edited by Dibya
Link to comment
Share on other sites

On 11/28/2018 at 8:19 AM, Dibya said:

Hey dude , I got a snake from jungle ported for you .

Take care of my pet python.

python xp

Greetings, Dibya!

Thank you very much for the work done! But there is one question:

Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:05:16) [MSC v.1915 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "socket.py", line 49, in <module>
ImportError: DLL load failed: The specified procedure could not be found.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified procedure could not be found.
>>>


It looks like it doesn’t find _socket.pyd. Any ideas how to fix this problem?

Link to comment
Share on other sites

12 minutes ago, -SnooPY- said:

Greetings, Dibya!

Thank you very much for the work done! But there is one question:

Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:05:16) [MSC v.1915 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "socket.py", line 49, in <module>
ImportError: DLL load failed: The specified procedure could not be found.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified procedure could not be found.
>>>


It looks like it doesn’t find _socket.pyd. Any ideas how to fix this problem?

I will check.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...