On Mon, 26 Jun 2023, Steve Lhomme wrote:
They have moved there in 16299 [1]. Some functions were removed but
they are still allowed by the WACK.
Some function were never in windowsapp.lib:
* RtlAddFunctionTable
* RtlDeleteFunctionTable
* RtlInstallFunctionTableCallback
* RtlVirtualUnwind
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-rtlsupport-l1-2-0dll
---
Just because these things are really hairy and messy to get right, I would
like to split this change into two:
- Move existing functions from l1-2-0 into l1-1-0. This should have no
visible effect on whether linking works or not, it just ends up linking
against a different apiset name. (As l1-1-0 is a lower number than l1-2-0,
I would naively expect that l1-1-10 exists whenever l1-2-0 exists.)
- Remove functions which shouldn't be there. This potentially has a
significant impact on how linking behaves. How long these entries have
been in place also affects the potential impact.
For the deleted 4 functions, the first three,
* RtlAddFunctionTable
* RtlDeleteFunctionTable
* RtlInstallFunctionTableCallback
all were added in this commit:
commit 9cd1a0be3aa94d275c4cd3137db0850b9b4b449d
Author: Steve Lhomme <[email protected]>
Date: Thu Jun 1 15:34:54 2023 +0200
crt: add new found API entries api-ms-win-*.def
So these were in place just for 1-2 months. Probably not a big deal. The
last one though, RtlVirtualUnwind, was added over 3 years ago:
commit ae2750626c2eb29dbc200f46831922de6e6972eb
Author: Steve Lhomme <[email protected]>
AuthorDate: Fri Apr 10 15:33:11 2020 +0200
Commit: Liu Hao <[email protected]>
CommitDate: Sun Apr 12 13:50:25 2020 +0800
crt: add new found API entries api-ms-win-*.def
So that will possibly have a bigger impact on things.
However I don't understand how you come to the conclusion that these
functions should be removed. If I inspect windowsapp.lib in WinSDK
10.0.22621.0, I do find it still:
kits/10/lib/10.0.22621.0/um/x64$ llvm-nm windowsapp.lib | grep -B1 RtlVirtual
api-ms-win-core-rtlsupport-l1-1-0.dll:
00000000 T RtlVirtualUnwind
00000000 T __imp_RtlVirtualUnwind
The same goes if I look at WACK, looking at kits/10/App Certification
Kit/SupportedAPIs-x64.xml (in the same WinSDK version):
$ grep RtlVirtualUnwind SupportedAPIs-x64.xml
<API Name="RtlVirtualUnwind"
ModuleName="api-ms-win-core-rtlsupport-l1-1-0.dll"/>
<API Name="RtlVirtualUnwind"
ModuleName="api-ms-win-core-rtlsupport-l1-2-0.dll"/>
<API Name="RtlVirtualUnwind"
ModuleName="api-ms-win-core-rtlsupport-l1-2-1.dll"/>
<API Name="RtlVirtualUnwind"
ModuleName="api-ms-win-core-rtlsupport-l1-2-2.dll"/>
<API Name="RtlVirtualUnwind" ModuleName="kernel32.dll"/>
<API Name="RtlVirtualUnwind" ModuleName="kernel32.dll"/>
<API Name="RtlVirtualUnwind" ModuleName="ntdll.dll"/>
<API Name="RtlVirtualUnwind"
ModuleName="api-ms-win-core-rtlsupport-l1-2-0.dll"/>
So this function is definitely still supported, and accepted in l1-1-0,
l-1-2-0, l1-2-1 and l1-2-2.
What I believe has happened here is that you looked at the x86 version of
windowsapp.lib, which lacks these symbols since it uses a different
unwinding mechanism.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
