Eryk Sun added the comment: > We'd have to statically link python##.dll.
I was talking about the partially static build that you used for wininst-14.0-amd64.exe in rc3, in which vcruntime is linked statically but ucrt is linked dynamically (actually to the api-ms-win-crt-* API sets). But is there a bad assumption there? I was only thinking about installing to systems with Python 3.5+, on which ucrtbase.dll is guaranteed to be in System32, but this installer should work for older systems that don't have the universal CRT update, right? > However, it may break other loads if python##.dll calls it or > makes assumptions about the search path I don't understand. It would be pretty broken if python##.dll depends on the current directory. All SetDllDirectory does is swap in the target directory in place of the current directory in the DLL search path. I made the suggestion because it's cleaner to surgically change only what the system loader sees, rather than changing the current directory, which affects everything. The LoadLibrary docs recommend using SetDllDirectory instead of changing the current directory. Using AddDllDirectory would be better, but that's only available on updated Vista/7 systems (KB2533623). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26071> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
