On 2023-06-07 11:47, LIU Hao wrote:
在 2023/6/7 13:55, Steve Lhomme 写道:
1) `GetFileVersionInfoW` isn't mentioned anywhere. According to its
documentation [3] it should be imported from
`api-ms-win-core-version-l1-1-0.dll` but that DLL exports no such
function.
I think you mean api-ms-win-core-version-l1-1-1. This is how it's
exported in the WACK XML files and also what WindowsApp.lib uses (in
19041).
That was not a typo. Microsoft documentation says
Requirements
(... ...)
DLL Api-ms-win-core-version-l1-1-0.dll
As I said the WACK, WindowsApp.lib and the doc in [7] all agree on the
proper DLL name allowed. The table of the "visible" documentation is
just wrong.
If the policy is to follow the wrong doc, it's OK with me. At least with
this function, neither VLC nor its contribs use it.
The changes in api-ms-win-core-winrt-error-l1-1-1 are documented as
belonging there. For example, for RoClearError it doesn't show in the
webpage but it does show in the MarkDown file, in the "api_location"
element [9].
OK maybe we can take those Markdown references, but should we keep those
undocumented exports? (esp. those cryptographic ones.)
The undocumented ones, no.
Indeed. I made a tool (private as I'm not sure how legally safe it is)
to generate the .def files from the WACK XML files. I used it to find
which DLLs are needed to export some functions. However, it seems that
this export doesn't match any version of WindowsApp.lib (from 10240 to
22261). So it's correct to remove all these calls. In this case the
MarkDown doc is incorrect [10].
The question is probably whether we should remove those that have been
documented as 'removed'. I suspect so, because they should be called via
`GetProcAddress()`.
My understanding is that the API's are never removed from existing DLL.
Newer DLLs with different names may not contain them.
For example if you take CLSIDFromString [1] it moved from
api-ms-win-core-com-l1-1-1 to api-ms-win-core-com-l1-1-0. This is also
reflected in the WindowsApp.lib for 10240 and 16299. But if I look at my
system, the format DLL doesn't exist, only the latter. So an app
compiled for UWP before 16299 may not work properly in newer Windows
versions. Maybe the UWP package needs to list these dependencies and
MSVC add them.
In mingw-w64 it's defined in both and libwindowsapp.a and contains both.
Not sure which one it will be when linking...
BTW, since the online doc is now generated from the MarkDown files in
that sdk-api repo, would it make sense to put some tools in mingw-w64
to parse those files and extract some data. I have some Python code
that parses the frontmatter part of files to find various information.
For example we could verify that the headers match the minimum allowed
version for each API entry.
The issue about such a tool and recent patches is that the stdcall
suffixes have to be checked manually. (`HSTRING_UserFree64` etc. at this
moment does not have a correct suffix.)
For headers, I don't think it's possible to do a tool that changes the
headers accordingly. I don't have one. It can just tell you which API is
correct and which ones are not.
Things could get worse if Microsoft will remove more in the future.
'minimum allowed version' might not even make much sense if something
gets removed, and as a result there could have to be a 'maximum allowed
version'.
I'm not aware of API removal nor API that used to be allowed in UWP and
then removed. In the MS SDK it would just mean using different headers
and WindowsApp.lib for that new SDK. In our case we can handle it with
NTDDI_VERSION or _WIN32_WINNT in headers. In libwindowsapp.a it's
trickier. We would need a different one for each SDK target.
--
Best regards,
LIU Hao
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-com-l1-1-1dll
[2]
https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/winver/nf-winver-getfileversioninfow.md?plain=1#L42
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
