On 10/02/2021 18:18, Eli Zaretskii wrote: > What is the procedure for requesting updates to the MinGW w32api > package (header files and import libraries)? The appropriate way would be to file a "feature request" ticket, as you did for your "libgccjit" request. (If you need a reminder of the filing procedure, please refer to: https://mingw.osdn.io/index.html?page=contact.html#feature-request ) > I bumped into a few APIs introduced by Windows 10 which are not > covered by the import libraries (so the only way to use them is to > link against the DLL itself). Which, of course, is a perfectly acceptable procedure, when you have the appropriate version of the DLL to hand, but that still leaves you with the task of furnishing appropriate definitions and prototypes. > Is it enough to mention their names in the ticket, or should I submit > some additional information, like an actual patch to the relevant > .def file(s)? A patch, (with accompanying ChangeLog entry), is the most effective way to achieve a quick turn-around, and attaching that to a ticket is the most effective way to provide it. > (It is not clear to me whether the *.def files are maintained by hand > or are produced by some tool.) The initial .def file, for any given import library, is likely to have been generated byt the "pexports" tool -- that's certainly what I use, when I have access to the DLL. Depending on the extent of subsequent additions, they may simply be added manually, or, for more extensive changes, by (selective) "diffing" against the output from "pexports", when run on a more recent version of the DLL. > And what about the header files and the prototypes there, and also > definitions of struct's and constants that those newer APIs require? > Is it acceptable to use in our headers the definitions from MSDN? Yes, that (or docs.microsoft.com, as it is now known) is the preferred source of documentation for any proposed addition, and header file updates should be included in any proposed patches; exposure of any additional API declarations should also be guarded, on the basis of the _WIN32_WINNT version with which they have been introduced. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20210211/65e78e4e/attachment.sig>
Fork