[issue23606] ctypes.util.find_library("c") no longer makes sense

Alex Gaynor added the comment: Yeah, this got me (happy to explain what I was trying to do in more detail, if it'd be helpful), took me longer to understand why my tests passed on {26,27,33,34} but failed on 35 since the public "what's changed" docs page is where I went to. Ultimately I

[issue23606] ctypes.util.find_library("c") no longer makes sense

Steve Dower added the comment: Noted. Did this bite you somehow? Is there something else that should be added/changed? -- ___ Python tracker ___

[issue23606] ctypes.util.find_library("c") no longer makes sense

Alex Gaynor added the comment: An FYI for the future, it would have been very helpful if this had been documented in the whats-changed file for 3.5. -- nosy: +alex ___ Python tracker

[issue23606] ctypes.util.find_library("c") no longer makes sense

Eryk Sun added the comment: I occasionally come across code snippets on Stack Overflow, and projects such as win-unicode-console (IIRC), that use ctypes to work with C stdio FILE streams (sometimes for dubious reasons, such as a DLL API that uses FILE streams). Maybe the _ctypes extension

[issue23606] ctypes.util.find_library("c") no longer makes sense

Steve Dower added the comment: That's a bit too much of a tangent for me to note in-place in the docs, but it'd be good content for a "Best practices" section (I seem to recall we had one somewhere, that basically started with "avoid ctypes if possible"...) Given we've heard no feedback about

[issue23606] ctypes.util.find_library("c") no longer makes sense

Roundup Robot added the comment: New changeset f9dc71b566fb by Steve Dower in branch '3.5': Issue #23606: Adds note to ctypes documentation regarding cdll.msvcrt. https://hg.python.org/cpython/rev/f9dc71b566fb New changeset 6d84fe4d8cb0 by Steve Dower in branch 'default': Issue #23606: Adds

[issue23606] ctypes.util.find_library("c") no longer makes sense

Eryk Sun added the comment: If the examples continue to use printf, then msvcrt.dll is the best option. The universal CRT exports a single Swiss-Army-knife function, __stdio_common_vfprintf, which requires 5 parameters, including a va_list for the variadic argument list. That's not

[issue23606] ctypes.util.find_library("c") no longer makes sense

Steve Dower added the comment: The msvcrt module? I don't think so. -- ___ Python tracker ___ ___

[issue23606] ctypes.util.find_library("c") no longer makes sense

Antoine Pitrou added the comment: > Strictly there's nothing incorrect about the docs, and `cdll.msvcrt` is no > more incorrect than it has been since Python 2.4 or so (whenever we stopped > using VC6). It will find the DLL and you can call the functions, but it isn't > the same DLL as the

[issue23606] ctypes.util.find_library("c") no longer makes sense

Antoine Pitrou added the comment: Does it mean `cdll.msvcrt` is not the standard way to access the C symbols anymore? Could you update the docs to reflect the current guidelines? (https://docs.python.org/3/library/ctypes.html) -- nosy: +pitrou ___

[issue23606] ctypes.util.find_library("c") no longer makes sense

Steve Dower added the comment: Strictly there's nothing incorrect about the docs, and `cdll.msvcrt` is no more incorrect than it has been since Python 2.4 or so (whenever we stopped using VC6). It will find the DLL and you can call the functions, but it isn't the same DLL as the exports in

[issue23606] ctypes.util.find_library("c") no longer makes sense

eryksun added the comment: > some code that uses it will need updating (due to API changes > since VC9/VC10) For example, I discovered that the stdio exports don't include printf, etc. Using __stdio_common_vfprintf to implement printf relies on calling __acrt_iob_func to get stdout and (in

[issue23606] ctypes.util.find_library(c) no longer makes sense

Steve Dower added the comment: I've been ignoring this because I wasn't assigned... Here's the options. If we make it load ucrtbase.dll directly (which does still have named exports, and also uses the API schema on Windows 10): * some code that uses it will need updating (due to API changes

[issue23606] ctypes.util.find_library(c) no longer makes sense

Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23606 ___ ___ Python-bugs-list

[issue23606] ctypes.util.find_library(c) no longer makes sense

Steve Dower added the comment: Pretty much, except the entry point DLL version won't increment unless there's a breaking change to the API. So you have to know where it's from, but (AIUI) the l1-0-0 file will always be available. At some point it may turn into a wrapper rather than a

[issue23606] ctypes.util.find_library(c) no longer makes sense

eryksun added the comment: Say I need to use ctypes to call _wsopen_s to open a file without write sharing. If I read you correctly, you're saying I'll need to know it's exported by api-ms-win-crt-stdio-l1-1-0.dll? Does the 'l1-1-0' suffix reflect a version number that will be incremented

[issue23606] ctypes.util.find_library(c) no longer makes sense

Roundup Robot added the comment: New changeset fabbe6093567 by Steve Dower in branch 'default': Issue #23606: Temporarily suppress test for CRT name. https://hg.python.org/cpython/rev/fabbe6093567 -- ___ Python tracker rep...@bugs.python.org

[issue23606] ctypes.util.find_library(c) no longer makes sense

Roundup Robot added the comment: New changeset 86c9ef950288 by Steve Dower in branch 'default': Issue #23606: Disable ctypes.util.find_library(c) on Windows so tests are skipped while we figure out how best to approach the CRT change https://hg.python.org/cpython/rev/86c9ef950288 --

[issue23606] ctypes.util.find_library(c) no longer makes sense

Steve Dower added the comment: That change should get the buildbots passing again, as it will now skip those tests. The appcrt%d return value was blatantly incorrect anyway. -- ___ Python tracker rep...@bugs.python.org

[issue23606] ctypes.util.find_library(c) no longer makes sense

Steve Dower added the comment: Good question, I'm not sure. Right now, the api-* DLLs use forwarding rather than apisetschema, but that could change. Since they support back to XP though, I suspect it probably won't the api-* DLLs will stay as they are with ucrtbase exporting ordinals rather

[issue23606] ctypes.util.find_library(c) no longer makes sense

eryksun added the comment: Will manual forwarding eventually be replaced by the loader's ApiSetMap (in the process PEB), i.e. will ucrtbase join ntdll, sechost, kernelbase, and kernel32 in apisetschema.dll? In this case will the CRT API sets only exist in winsxs, i.e. will they no longer be

[issue23606] ctypes.util.find_library(c) no longer makes sense

eryksun added the comment: The api-ms-win-crt-* DLLs forward their exports to ucrtbase.dll, which currently uses named exports. When is it planned to remove the named exports? crt = CDLL('ucrtbase') filesystem = CDLL('api-ms-win-crt-filesystem-l1-1-0') math =

[issue23606] ctypes.util.find_library(c) no longer makes sense

Steve Dower added the comment: AIUI, by the time Windows 10 or Visual Studio 2015 releases (since it's now a Windows component, it's technically on a different schedule, even though the main developer is still working against Visual Studio's schedule) and probably sooner (VS 2015 RC is most

[issue23606] ctypes.util.find_library(c) no longer makes sense

Steve Dower added the comment: That was my original thought, but it's going to lose all of its named exports and effectively become useless for this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23606

[issue23606] ctypes.util.find_library(c) no longer makes sense

New submission from Steve Dower: With the changes to the CRT on Windows, it no longer makes any sense to call find_library(c) or (m) as there is no single C Runtime DLL. The new structure has a grouped and layered approach that is better for versioning, so we now link to

[issue23606] ctypes.util.find_library(c) no longer makes sense

eryksun added the comment: Shouldn't find_library(c) return ucrtbase.dll or ucrtbased.dll (debug)? Introducing the Universal CRT http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx -- nosy: +eryksun ___ Python