Title: Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only
Type: behavior Stage: resolved
Components: Interpreter Core, Windows Versions: Python 3.6
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, paul.moore, r.david.murray, smernst, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-04-27 12:17 by smernst, last changed 2017-04-27 21:01 by steve.dower. This issue is now closed.

Messages (6)
msg292430 - (view) Author: Sebastian Ernst (smernst) Date: 2017-04-27 12:17
I am investigating a bug in Wine:

The Python 3.6(.1) interpreter fails to start on Wine because of an unimplemented function in Wine: "api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx". 

While the missing function is clearly a problem in Wine, the fact that PathCchCombineEx is called in the first place is somewhat odd. The call was added to Python 3.6 on 09 Sep 2016 by Steve Dower of Microsoft:
Logically, Python 3.5.x and prior do not require this call and work flawlessly under Wine. 

Digging deeper into this, I found that PathCchCombineEx was introduced in Windows 8:

However, the following page states, that the current version of Python (3.6) should support Windows Vista and 7:

I am seeking clarification on why PathCchCombineEx is called during the Python interpreter startup although Wine pretends to be Windows 7 and although Python should support Windows Vista & 7. My thinking is that this call might also happen on an actual Windows 7 system under some circumstances and break Python there as well, which would make it a bug in Python.
msg292471 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-04-27 18:34
PathCchCombineEx isn't an import dependency. It's used dynamically via LoadLibraryW and GetProcAddress, with a fallback to PathCombineW. Does Wine maybe have a stub for this function that returns E_NOTIMPL (not implemented)?
msg292474 - (view) Author: Sebastian Ernst (smernst) Date: 2017-04-27 19:35
Relaying this on behalf of Gijs Vermeulen from Wine: "In my patch I tried returning E_NOTIMPL and I got the error: Fatal Python error: buffer overflow in getpathp.c's join()"
msg292478 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-04-27 20:21
I didn't mean that there's support to fall back on PathCombineW if PathCchCombineEx returns E_NOTIMPL. I was just guessing at what the stub in Wine might be doing. I took a look at the source. It seems the Wine stub function for unimplemented functions is __wine_spec_unimplemented_stub in dlls/winecrt0/stub.c, which calls RaiseException. 

I think this issue should be closed as 3rd party since I don't see anything wrong with Steve's code, but I'll leave it open for Steve to make that decision.
msg292481 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-04-27 20:51
Indeed, it sounds like wine is claiming to be Windows 7 but then implementing (as not implemented) later-than-windows-7 apis.  That definitely sounds like a bug in wine.
msg292483 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-04-27 21:01
The approach I used is the correct way to use the function if it's available. If Wine is not supporting this function, it should return NULL from GetProcAddress, not a stub. If the function exists, any error it returns is fatal.

We need the better function for Win10 in order to support paths longer than 260 characters. PathcombineW fails on long paths.
Date User Action Args
2017-04-27 21:01:32steve.dowersetstatus: open -> closed
resolution: third party
stage: resolved
2017-04-27 21:01:16steve.dowersetmessages: + msg292483
2017-04-27 20:51:06r.david.murraysetnosy: + r.david.murray
messages: + msg292481
2017-04-27 20:21:39eryksunsetmessages: + msg292478
2017-04-27 19:35:21smernstsetmessages: + msg292474
2017-04-27 18:34:45eryksunsetnosy: + eryksun
messages: + msg292471
2017-04-27 12:17:59smernstcreate