Python 3.5 Runtime Redistributable backported to XP

[-SnooPY-]

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?

[jumper]

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

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

Edited October 26, 2019 by jumper

[-SnooPY-]

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

Edited October 28, 2019 by -SnooPY-

[-SnooPY-]

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.

Edited October 29, 2019 by -SnooPY-

[jumper]

Lots of ideas from searching:

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

Edited October 29, 2019 by jumper
fix url

[Usher]

2 hours ago, -SnooPY- said:

What else can be done in this case?

You have fixed problems with slashes, but you should always check all possible problems with paths and names, including spaces in names, UPPER- and lowercase letters. For example, some scripts expect only UPPERCASE drive letters.

Just guessing…

[-SnooPY-]

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.

Edited November 3, 2019 by -SnooPY-

[jumper]

Try an older version of libgio-2.0-0.dll. File version: 2.28.8.0 7/19/11 8:00 AM is XP-compatible.

[Mathwiz]

On 11/3/2019 at 4:57 PM, -SnooPY- said:

One-Core-API and ReactOS, on which it is based.

Due to concerns about potential copyright infringement issues, ReactOS is quite explicitly not based on One-Core API.

[jumper]

And no one said it was (certainly not SnooPY who stated the converse).

[-SnooPY-]

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.

Edited November 6, 2019 by -SnooPY-

[-SnooPY-]

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.

Edited November 20, 2019 by -SnooPY-

[dencorso]

1 hour ago, -SnooPY- said:

I'm sorry, maybe I'm not accurately expressed. My English is poor and I often use Google Translate. 

Avoid Google Translate and use DeepL, instead: the result will be much better understandable text. My 2¢ only, of course. 

[VistaLover]

@-SnooPY-: Python 2.7.17 has been recently released:

https://www.python.org/downloads/release/python-2717/

Quote

It is expected to be the penultimate release for Python 2.7.

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

[siria]

Machine translations:
Last year I did a bit testing, compared results for Google, Deepl, Yandex etc., but for me Google was the clear winner again. The completely unexpected, scary part was that some services translated completely different stuff as in the original, sometimes even inventing complete additional sentences out of nothing! There was also somewhere a quite long, hilarious reddit thread with such nonsense examples.