On Mon, 26 May 2025, LIU Hao wrote:
Yeah, I agree. That was also the original reason for why we started merging
them originally; we had lib32, lib64 and libarm32, and wanted to add
libarm64. (Also, at the time I didn't have the real OS yet to even dump the
DLLs, so it would have been a copy of libarm32 anyway.)
A lot of the differences we have stem from the fact that lib32, lib64 and
libarm32, before starting unification, had been dumped from quite different
windows versions.
The idea about generating DEFs from DLLs is doubleplusungood
It has some drawbacks, yes.
But it also allows calling functions that aren't exposed in the official
SDKs. We rely on this for ucrtbase.dll and
api-ms-win-crt-private-l1-1-0.dll.
and is exactly the reason why we have unwanted symbols, like
`DllRegisterServer`, `DllCanUnloadNow`, `DllGetClassObject`, and some
which I removed a few days ago in
9c1dcbf0c6a990cabbad0d915110c601f1d32184, and some more which Jacek
removed in 99d13399bf5fa6e19c3c445b62fff751f3dbf997.
Yes, those are problematic and should indeed be excluded.
There has been numerous other cleanups for other unwanted things among the
def files, stemming from dumping them from def files - see e.g.
8cd2f47a240f721feeefe199c759f9069e491077,
f379f49cb4a2ac255728280b7f2a56cb754b917d,
11154847e17c3232ba0eba22d9aba196b2bcc006,
363d07f9c498e1a641d3cde45d64af1551c0189c,
a6027b9e1649fd498af88808cd99d3e38a739f34.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
