[Python 3.5 Runtime Redistributable backported to XP]

16 hours ago, FranceBB said:

Python 2.x and 3.x are two very different languages not compatible with one another.

In other words, I'm not really sure it will compile at all if I target 3.x

If I'm not mistaken, Python is only used to create the configuration, but a crucial part of *.dll and *.pyd code written in C. Unfortunately, at the moment I can not run MSVC 2013 on XP to check it out. I was able to compile some of the simpler libraries, such as the OpenSSL, using MinGW 4.92, but I have not yet mastered PyQt. That is why I am asking for help here from the more experienced and intelligent people.

 

[Python 3.5 Runtime Redistributable backported to XP]

I'm sorry to pester again with silly questions, but what about PyQt5 for XP? I recently came across an interesting project called PyQt5-xp. It looks promising and includes officially unsupported PyQt 5.11.3 and PyQt-sip 4.19.13, but unfortunately compiled for Python 2.7 only. If someone is willing and free time to compile these libraries also for Python 3.7, that would be wonderful.

[Python 3.5 Runtime Redistributable backported to XP]

10 hours ago, VistaLover said:

So, whenever it's out, v2.7.18 will be the EoL/EoS Python 2.7 release...

Yes, this is very sad news. But thanks to this thread and amazing people who write here, I think we will always have a chance, that Python 3.7 will be functional under XP.

JFYI, FontForge has a newer version, based on Python 3.7.4. All the problems that I have mentioned above are also relevant to it. For my experiments I choose not the latest version, based on Python 2.7.16 , because it is little easier to adapt under XP.

[Python 3.5 Runtime Redistributable backported to XP]

On 11/4/2019 at 6:54 AM, jumper said:

Try an older version of libgio-2.0-0.dll.

I downloaded the glib and gettext_runtime here, then corrected a few more simple dependencies, and now it finally works perfectly! Thank you very much.

UPDATE: Using a version glib 2.38 from here makes it possible to run Fontforge both console and GUI.

[Python 3.5 Runtime Redistributable backported to XP]

On 11/5/2019 at 4:05 AM, Mathwiz said:

ReactOS is quite explicitly not based on One-Core API.

I'm sorry, maybe I'm not accurately expressed. My English is poor and I often use Google Translate. I seriously thought about compiling One-Core-API from the sources and that you have quoted, I read on the project page - https://github.com/Skulltrail192/One-Core-Api/blob/master/README Of course, I mean that One-Core-API is based on ReactOS and GetIpForwardTable2 function currently missing in both projects.

[Python 3.5 Runtime Redistributable backported to XP]

On 10/29/2019 at 10:13 PM, jumper said:

Traceback "ImportError: DLL load failed: The specified procedure could not be found."

By trial and error method I have found that GetIpForwardTable2 function from IPHLPAPI.DLL is still missing in  One-Core-API and ReactOS, on which it is based. Your ImportPatcher, as usual, did not disappoint - a sincere thank you for it. However, I could not find a working implementation of this function, and even more so to build a new DLL from the sources.

[Python 3.5 Runtime Redistributable backported to XP]

I continue my experiments with the module fontforge.pyd. As said before, the problem is solved only partially and DLL loading bug is still there.

But now Dependency Walker does not indicate anything specific,

Loaded "c:\program files\fontforgebuilds\lib\python2.7\site-packages\fontforge\FONTFORGE.PYD" at address 0x6BDC0000.  Successfully hooked module.
Loaded "c:\program files\fontforgebuilds\bin\LIBFONTFORGE-3.DLL" at address 0x6A240000.  Successfully hooked module.
Loaded "c:\program files\fontforgebuilds\bin\LIBGUTILS-3.DLL" at address 0x65C40000.  Successfully hooked module.
Loaded "c:\program files\fontforgebuilds\bin\LIBGUNICODE-5.DLL" at address 0x00F90000.  Successfully hooked module.
Loaded "c:\windows\system32\WS2_32.DLL" at address 0x71A90000.  Successfully hooked module.
Loaded "c:\windows\system32\WS2HELP.DLL" at address 0x71A80000.  Successfully hooked module.
Unloaded "c:\program files\fontforgebuilds\lib\python2.7\site-packages\fontforge\FONTFORGE.PYD" at address 0x6BDC0000.
Unloaded "c:\program files\fontforgebuilds\bin\LIBFONTFORGE-3.DLL" at address 0x6A240000.
Unloaded "c:\program files\fontforgebuilds\bin\LIBGUTILS-3.DLL" at address 0x65C40000.
Unloaded "c:\program files\fontforgebuilds\bin\LIBGUNICODE-5.DLL" at address 0x00F90000.
Unloaded "c:\windows\system32\WS2_32.DLL" at address 0x71A90000.
Unloaded "c:\windows\system32\WS2HELP.DLL" at address 0x71A80000.

so I once again appeal to you for any intelligent advice. What else can be done in this case? Thanks a lot.

[Python 3.5 Runtime Redistributable backported to XP]

On 27.10.2019 at 1:33 AM, jumper said:

The result is correct because the forward slash is a mistake: "When specifying a path, be sure to use backslashes (\), not forward slashes (/)."

It's amazing what you attentive, @jumper ! I did not even notice, since both types of slashes and "mixed" paths are valid for Python. Now I was able to partially solve the problem by correcting ntpath.py file, it contained a strange condition:

if sys.platform == "win32" and "MSYSTEM" in os.environ:
    sep = '/'
    altsep = '\\'
else:
    sep = '\\'
    altsep = '/'

determining the dependence of the environment variable that was missing. Apparently, because of that it did not properly convert forward slashes to backslashes. I tried to contact the developer of FontForge, but he assured me that it was XP problem, although I have seen a similar description of the problem for newer Windows (7 & 8.1).

[Python 3.5 Runtime Redistributable backported to XP]

Thank you, @jumper for your valuable reminder, at the second attempt I found a reference in MSDN. However, in my case, this registry key has absolutely no effect regardless of whether the setting is 0 or 1 or does not exist at all. But I mean, that above mentioned wrapper for LoadLibraryExA, in my opinion, is not working properly and always return a NULL, if LOAD_WITH_ALTERED_SEARCH_PATH flag is present.

    const DWORD load_library_search_flags = (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR |
                                             LOAD_LIBRARY_SEARCH_APPLICATION_DIR |
                                             LOAD_LIBRARY_SEARCH_USER_DIRS |
                                             LOAD_LIBRARY_SEARCH_SYSTEM32 |
                                             LOAD_LIBRARY_SEARCH_DEFAULT_DIRS);
    const DWORD unsupported_flags = (LOAD_IGNORE_CODE_AUTHZ_LEVEL |
                                     LOAD_LIBRARY_AS_IMAGE_RESOURCE |
                                     LOAD_LIBRARY_REQUIRE_SIGNED_TARGET);

    if (!(flags & load_library_search_flags)) flags |= default_search_flags;

    if( flags & unsupported_flags)
        FIXME("unsupported flag(s) used (flags: 0x%08x)\n", flags);

    if (flags & load_library_search_flags)
        load_path = get_dll_load_path_search_flags( libname->Buffer, flags );
    else
        load_path = MODULE_get_dll_load_path( flags & LOAD_WITH_ALTERED_SEARCH_PATH ? libname->Buffer : NULL, -1 );
    if (!load_path) return 0;

Or is this behavior normal?

[Python 3.5 Runtime Redistributable backported to XP]

Somebody tried to run under XP FontForge - free font editor (via One-Core-API project, of course)? I am interested in Python fontforge.pyd module, but it fails with the following error:

Python 2.7.16 (default, Mar  7 2019, 06:52:08)  [GCC 7.4.0 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import fontforge
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified procedure could not be found.
>>>

Dependency Walker log:

LoadLibraryExA("c:\program files\fontforgebuilds\lib\python2.7\site-packages/fontforge.pyd",
0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: The specified procedure could not be found (127).

I read in MSDN about LoadLibraryExA function and decided that an error is likely due to unsupported in XP LOAD_WITH_ALTERED_SEARCH_PATH flag.
I also looked into One-Core-API project sources, but unfortunately did not understand how function LoadLibraryExA should work if LOAD_WITH_ALTERED_SEARCH_PATH flag is nevertheless set.

I suppose that we need some kind of workaround to this case - https://github.com/Skulltrail192/One-Core-Api/blob/93711e91694b6c1e7643d0092ed88f1e21f0cd94/dll/wrappers/base/kernel32_wrapper/module.c  ( line 360 ). I would like to hear your opinion on this issue. Thanks a lot.

[List of unsupported feature by/for Windows XP]

On 9/29/2019 at 9:04 PM, UCyborg said:

It's not related to visual styles as it looks OK in Windows 7 with classic theme and also doesn't look correct with XP's default Luna theme.

I think the reason is that SysListView32 contains editable cell ( "Name"). There are many examples to change the background color of the cells for a simple ListView, but I could not find a working example to change the background color of the editable cells. I even want to write a small wrapper, but I still could not figure out what different ComCtl32.dll in Windows XP and Windows 7/8/10 (both have version 6.0). If someone here has the re-engineering skills and can help determine which functions are missing or otherwise implemented in XP, I would be very grateful for your help.

[List of unsupported feature by/for Windows XP]

I am sorry for possible offtopic, but somebody can explain how to use the Common Controls 6.0 and, respectively, Visual Styles in Windows XP? For example, in uTorrent 3.5.5 under XP standard ListView control is as follows:

I suspect that there is a bug here. The active element should be sky blue, and the remaining elements of the alternate white / gray or white only, if this setting is disabled.

[Python 3.5 Runtime Redistributable backported to XP]

4 hours ago, Reino said:

As said before, my FFmpeg binaries are compiled with MbedTLS. You can FFprobe opens the https-url just fine.

I don't have Facebook myself, so I can't check on a livestream atm.

I also can’t check any livestreams now. Perhaps, the results will be slightly different.  So far we can only state that any "non-DASH" streams work fine in all cases.

Thank you for your experiments, they were very useful. It became completely clear that the problem was most likely not in FFmpeg, not in OpenSSL, and not in mbedTLS. Good luck!

[Python 3.5 Runtime Redistributable backported to XP]

5 hours ago, Reino said:

I'm not familiar with Streamlink, but I can't find anything on that website about OpenSSL being a requirement for FFmpeg to open https-urls. Do my binaries (with MbedTLS) not work?

You are absolutely right, this is clearly not mentioned anywhere. I want to emphasize what I think the problem is the lack of OpenSSL support. Of course, I could be wrong. Yesterday I tried to watch the live broadcast from Facebook: https://www.facebook.com/snookernews2u/videos/418828755653697 And got a 404 error.
Today the situation is different. Now it’s not a live broadcast and stream coding "on the fly" through FFMpeg just doesn’t happen:

[cli] [info] Found matching facebook plugin for URL https://www.facebook.com/snookernews2u/videos/418828755653697/
[plugin.facebook] [error] Skipped DASH manifest with SegmentBase streams
[cli] [info] Available streams: sd (worst, best)
[cli] [info] Opening stream: sd (http)

Nevertheless, everything works fine, because FFMpeg is not used at all.

 

[Python 3.5 Runtime Redistributable backported to XP]

Sorry to interfere, but what about the Streamlink project? It also does not work officially under XP, but I managed to build and run it. The problem is that FFMpeg with OpenSSL support is required for normal operation. I know that @Reino regularly builds FFMPeg for XP and even tried the FFMpeg buildscript that @Reino created. But unfortunately, all executable files are compiled by default without OpenSSL support and I don’t know how to enable this option when compiling from a script. Would you recommend something? Thanks a lot.

[How to install One-Core-API?]

1 hour ago, jumper said:

If it shares an address or is followed by another API within a few bytes, it is a stub (not fully implemented).

I may be wrong, but it seems to me that everything is OK. Thanks a lot for the hint.

[How to install One-Core-API?]

Has anyone tested the SHCreateItemFromParsingName function? I have a suspicion that it is not implemented or is working with errors. I tried to analyze the sources on GitHub and found at least three different versions:
https://github.com/Skulltrail192/One-Core-Api/blob/master/dll/wrappers/base/shell32_wrapper/shellitem.c  - the function looks quite normal (line 566);

https://github.com/Skulltrail192/One-Core-Api/blob/master/dll/wrappers/base/shell32_wrapper_new/shellitem.c  - the function is commented out (line 566);

https://github.com/Skulltrail192/One-Core-Api/blob/master/dll/wrappers/dependencies/shellnew/unimplemented.c  - the function is "empty" (line 66).

Is there a way to check which version was used for the final build of shell32.dll? Thanks a lot.

[ImportPatcher.41 - Find and fix dependency problems]

Can anyone clarify the situation with [Export forward replacements]? Please advise what can be done to make this section disappear? Thanks a lot.

I try to patch Revo Uninstaller and get the following log:

============================================================

[Patches needed]
...
ntext.dll=Forwards  
KERNELXP.dll=Forwards  
...
RevoUninPro.exe=No problems found.
[Export forward replacements]
ntdll.ExpInterlockedPopEntrySListEnd=
ntdll.ExpInterlockedPopEntrySListFault=
ntdll.ExpInterlockedPopEntrySListResume=
ntdll.NtAddDriverEntry=
ntdll.NtApphelpCacheControl=
ntdll.NtDeleteDriverEntry=
ntdll.NtEnumerateDriverEntries=
ntdll.NtGetTickCount=
ntdll.NtModifyDriverEntry=
ntdll.NtQueryDriverEntryOrder=
ntdll.NtSetDriverEntryOrder=
ntdll.NtUnloadKey2=
ntdll.NtWaitForMultipleObjects32=
ntdll.NtWow64CsrAllocateCaptureBuffer=
ntdll.NtWow64CsrAllocateMessagePointer=
ntdll.NtWow64CsrCaptureMessageBuffer=
ntdll.NtWow64CsrCaptureMessageString=
ntdll.NtWow64CsrClientCallServer=
ntdll.NtWow64CsrClientConnectToServer=
ntdll.NtWow64CsrFreeCaptureBuffer=
ntdll.NtWow64CsrGetProcessId=
ntdll.NtWow64CsrIdentifyAlertableThread=
ntdll.NtWow64CsrNewThread=
ntdll.NtWow64CsrSetPriorityClass=
ntdll.NtWow64DebuggerCall=
ntdll.NtWow64GetNativeSystemInformation=
ntdll.NtWow64QueryInformationProcess64=
ntdll.NtWow64QueryVirtualMemory64=
ntdll.NtWow64ReadVirtualMemory64=
ntdll.RtlAcquirePrivilege=
ntdll.RtlAddVectoredContinueHandler=
ntdll.RtlAllocateActivationContextStack=
ntdll.RtlCopyMappedMemory=
ntdll.RtlFormatMessageEx=
ntdll.RtlFreeActivationContextStack=
ntdll.RtlGetCriticalSectionRecursionCount=
ntdll.RtlIsCriticalSectionLocked=
ntdll.RtlMultipleAllocateHeap=
ntdll.RtlMultipleFreeHeap=
ntdll.RtlReleasePrivilege=
ntdll.RtlRemoveVectoredContinueHandler=
ntdll.RtlSetUnhandledExceptionFilter=
ntdll.ZwAddDriverEntry=
ntdll.ZwApphelpCacheControl=
ntdll.ZwDeleteDriverEntry=
ntdll.ZwEnumerateDriverEntries=
ntdll.ZwGetCurrentProcessorNumber=
ntdll.ZwLoadKeyEx=
ntdll.ZwModifyDriverEntry=
ntdll.ZwQueryDriverEntryOrder=
ntdll.ZwQueryOpenSubKeysEx=
ntdll.ZwSetDriverEntryOrder=
ntdll.ZwUnloadKey2=
ntdll.ZwWaitForMultipleObjects32=
advapi32.AddMandatoryAce=
ntext.RtlAddVectoredContinueHandler=
kernel32.BaseCheckRunApp=
kernel32.BasepCheckBadapp=
kernel32.EnumSystemFirmwareTables=
fileextd.GetFileInformationByHandleEx=
kernel32.GetSystemFileCacheSize=
kernel32.GetSystemFirmwareTable=
kernel32.IsNLSDefinedString=
shlwapi.PathIsValidCharA=
shlwapi.PathIsValidCharW=
advapi32.RegCopyTreeW=
advapi32.RegDeleteKeyExA=
advapi32.RegDeleteKeyExW=
advapi32.RegDeleteTreeA=
advapi32.RegDeleteTreeW=
advapi32.RegGetValueA=
advapi32.RegGetValueW=
advapi32.RegLoadMUIStringA=
advapi32.RegLoadMUIStringW=
ntext.RtlRemoveVectoredContinueHandler=
fileextd.SetFileInformationByHandle=

============================================================

[How to install One-Core-API?]

You probably mean these files, but I can’t download any of them.

UPDATE 1: On the second attempt, I managed to find the full archive here.

UPDATE 2: A more detailed analysis of the above files revealed that these are different versions. In particular, kernel32.dll is much larger, does not depend on ntext.dll and psapi.dll, and does not contain, for example, the GetUserDefaultLocaleName function. On the third attempt, I hope I found what I was looking for (and this is really part of the One-Core-API).

[How to install One-Core-API?]

I'm not sure what I am asking here correctly, but there is a project on our forum that uses a modified version of kernel32.dll from Windows XP (kernelxp.dll). Now I needed other DLLs (shellxp.dll, userxp.dll, ...), but unfortunately I did not find them in the One Core API. Tell me, please, where can I find them? I do not want to permanently install the entire package and replace system files with it. Please advise what can be done. Thank you very much!

[Python 3.5 Runtime Redistributable backported to XP]

20 hours ago, heinoganda said:

The users who use Python version 3.5 or higher need a build with VS2015! 

Yesterday I built a (working?) version of the _openssl.pyd extension for Python 3.7.1 using MinGW 4.9.2 (I will be very grateful for any feedback) :

https://www13.zippyshare.com/v/olH5qzDq/file.html

I was forced to use pre-built binaries, LIBS and INCLUDES from the official Python distribution and the previously mentioned project Curl for Windows by Viktor Szakats.

Now you just need to install cryptography 2.6.1, and then replace the files libcrypto-1_1.dll and libssl-1_1.dll in the directory with Python.exe and the _openssl.cp37-win32.pyd file in Lib\site-packages\cryptography\hazmat\bindings

Your version of Cryptography 2.6.1 and the version of OpenSSL 1.1.1b from @Mathwiz also work great for Python 3.4, but I don’t have the opportunity to use Win7+ and VS2015+ to build a version compatible with Python 3.7.1. Thank you all and good luck!

[Python 3.5 Runtime Redistributable backported to XP]

7 hours ago, Mathwiz said:

I just looked with Dependency Walker and it seems like your version of libcrypto-1_1.dll does not have a dependency on bcrypt.dll.

You can also check OpenSSL 1.1.1b MinGW build from the Curl for Windows project. The only thing left is to build the latest Cryptography using these DLLs. Does anyone know how to build * .pyd files?

[Python 3.5 Runtime Redistributable backported to XP]

5 hours ago, Mathwiz said:

So I suspect those are typically built on Win 7, 8.1, or 10, and the builders are unaware they need to override the definition of WIN32_WINNT to 0x0501 when compiling if they want to retain XP compatibility.

Exactly! And the problem with Cryptography in Python is just a consequence of this "inaccuracy".

[Python 3.5 Runtime Redistributable backported to XP]

23 hours ago, Mathwiz said:

Are you saying that, if you have Win 7 (and therefore bcrypt.dll), the latest Cryptography modules are compatible with Python 3.4?

I apologize for not being clear. Personally, I only have Win XP, but as far as I understood, @heinoganda successfully tested the latest Cryptography up to 2.6.1 under Win 7 with Python 3.4. In theory, in newer versions of Python (3.5, 3.6 and 3.7) there should also be no problems under Win 7. I just meant that.

23 hours ago, Mathwiz said:

Have you tried to compile OpenSSL on Win XP with, say, MSVC?

IMHO, we already have OpenSSL with XP support in the form of libcrypto-1_1.dll and libssl-1_1.dll files. Unfortunately, I still can not figure out how to build *. pyd files for Python. Cryptohraphy package is not well documented for this case.

[Python 3.5 Runtime Redistributable backported to XP]

On 3/6/2019 at 6:33 PM, Mathwiz said:

But TLS continues to evolve, so to avoid eventual obsolescence we'd like to get ProxHTTPSProxyMII working with newer Cryptography versions.

This required a newer version of Python, so we've got Python 3.7.1 working on XP; [...]

Cryptography performance does not depend on the version of Python. The only problem is that the new cryptography package (v2.5 - v2.6.1) includes incompatible pre-built binaries (_openssl-cp37-win32.pyd, etc ...), which for some reason is not possible to rebuild with XP support.

Although @hotnuma already pointed to the source code: https://github.com/openssl/openssl/blob/master/crypto/rand/rand_win.c
We are interested in lines from 20 to 40. It is enough not to link bcrypt.lib and the compatibility problem will disappear.