-SnooPY-

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.

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.

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.

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.

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.

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.

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.

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).

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?

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.

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.

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.

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!

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.

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.

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

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.

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= ============================================================

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).

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!

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!

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?

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

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. 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.

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.