Re: How to request additions to w32api?

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5110960986095219458==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="ptt5xoDEbANzOxKZrk7CHMHQN8uMBJ1Qy"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ptt5xoDEbANzOxKZrk7CHMHQN8uMBJ1Qy
Content-Type: multipart/mixed; boundary="zj46iU1hGa9NnPVWLElgIl7mgpbbq92WO";
 protected-headers="v1"
From: Keith Marshall <[email protected]>
To: [email protected]
Message-ID: <d5eb45cc-cb65-a408-5823-7854cdd4290a-JlWs9+JhQMeJPt80KsDg5Q@public.gmane.org>
Subject: Re: [MinGW-Users] How to request additions to w32api?
References: <838s7viy6k.fsf-mXXj517/[email protected]>
In-Reply-To: <838s7viy6k.fsf-mXXj517/[email protected]>

--zj46iU1hGa9NnPVWLElgIl7mgpbbq92WO
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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=3Dcontact.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.

--=20
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


--zj46iU1hGa9NnPVWLElgIl7mgpbbq92WO--

--ptt5xoDEbANzOxKZrk7CHMHQN8uMBJ1Qy
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEwZ7AGBVH3lDh1I9TwK02xjR+Wj8FAmAlHagFAwAAAAAACgkQwK02xjR+Wj+V
jw//RQmQdayta49a+45y5mW7SVc9nkwxhHRgpCYPJnyRg552QKWgNMFgPc4rbL1JZxENK1eumTij
3zRGlXUEELTjVE5ZIGB6DyfTscU769hVUnQa8uvuEozfdpMjNyqBqH13lQ2P6vBQYoNXIp+RtATM
CK2ULapPLuKkyeJCcSYJr5g+rSfohU/j3FkRoaEWN9LhEZ3PTuWW1ma+pfd0YiixltFTF8UWcT7K
lEYtJKd8yuiQK5lFUWsu2hZk4ZjwFBJFXG+B62PuL3LZEtWG/Qfjnh360skKgqsgEQ4Ih0Nn+yHT
cda/2WV1WfPMSv2zI7HVJu4pRW1yCQw/DM8k70NBwm2g2D4wVL9LBDTjjYYmO+W5MeyoJXddinnD
+OMEzkFf1kyb9BLwn7zRlTxo0t8W1WXc5rcayxWqbkSAmDQptq4jhCfBoPXUAk6SVB1TNbNJKk+j
Ege/Nle4yZxEk2YW9Dzr2j4e2bb24icokDAvd9wLGaY0cz94+Svy6itU/4VoeSjSN86iPZ6Jbd6L
Tfn6SJRwuftcm3BhEoNytmPCn4/NxHedyn5DBJTpeumO95cp3uaroN53rnJM3BpHqCS0TYInYVTX
1T6Hp4PXhFLcBD2RnUkwQD10vlXZL6ic9yFM89p994u1EwDNgexJvGNnvel25Yrr1bJWhmfE/a+8
Ffk=
=8Jk4
-----END PGP SIGNATURE-----

--ptt5xoDEbANzOxKZrk7CHMHQN8uMBJ1Qy--


--===============5110960986095219458==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWluR1ctVXNl
cnMgbWFpbGluZyBsaXN0Ck1pbkdXLVVzZXJzQGxpc3RzLm9zZG4ubWUKClRoaXMgbGlzdCBvYnNl
cnZlcyB0aGUgUG9zdGluZyBFdGlxdWV0dGUsIGFzIGRlc2NyaWJlZCBhdCBodHRwczovL21pbmd3
Lm9zZG4uaW8vaW5kZXguaHRtbD9wYWdlPW1haWxpbmcuaHRtbCNsaXN0LWV0aXF1ZXR0ZS4KV2Ug
YXNrIHRoYXQgeW91IGJlIHBvbGl0ZSBhbmQgZG8gdGhlIHNhbWUuICBEaXNyZWdhcmQgZm9yIHRo
ZSBsaXN0IGV0aXF1ZXR0ZSBtYXkgY2F1c2UgeW91ciBhY2NvdW50IHRvIGJlIG1vZGVyYXRlZC4K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCllvdSBtYXkg
Y2hhbmdlIHlvdXIgTWluR1cgQWNjb3VudCBPcHRpb25zIG9yIHVuc3Vic2NyaWJlIGF0OgpodHRw
czovL2xpc3RzLm9zZG4ubWUvbWFpbG1hbi9saXN0aW5mby9taW5ndy11c2VycwpBbHNvOiBtYWls
dG86bWluZ3ctdXNlcnMtcmVxdWVzdEBsaXN0cy5vc2RuLm1lP3N1YmplY3Q9dW5zdWJzY3JpYmU=

--===============5110960986095219458==--