On Mon, 9 Dec 2024, Pali Rohár wrote:
I see that in mingw-w64-crt/lib32/ are lot of def files which are
basically same as def files in mingw-w64-crt/lib-common/, just lib32
variants have @STDCALL suffixes. They have same set of functions (just
sometimes there are arch-specific available only for I386 or similar).
I was thinking if it would be possible to merge them and have just one
def file for both I386 and non-I386 variants.
For example there is mingw-w64-crt/lib32/kernel32.def and
mingw-w64-crt/lib-common/kernel32.def.in and if it would be possible to
merge them into one file.
What about having one def file kernel32.def.in where would be also
@STDCALL suffixes and when building non-I386 variant, the build process
will filter that file over sed 's/@[0-9]*$//' and then process by cpp
preprocessor? (Or first process by cpp and then by sed)
This could decrease the need to have more def files for the same library
(e.g. kernel32) and also maintenance of different variants of def files.
Yes, I've thought about this already back when we started merging def
files into lib-common. But then I initially thought about using the
preprocessor, something like API(func, 8) which either appends @8 or not.
But as you noticed, pasting @ with other symbols with cpp is
problematic...
Your suggestion of using some form of sed expression could achieve the
same, and would also avoid needing to rewrite things from what gendef or
other tools output - so that makes it much easier to accept.
For the vast majority of APIs outside of the core of complicated ones
(CRTs, kernel32 and similar), the set of symbols exported is indeed
identical across all architectures - i386 is usually not different from
the other ones, apart for the stdcall suffix. (Although some DLLs have
symbols that only are available e.g. in the 64 bit versions, but this is
not common and the distinction usually doesn't matter much either.)
For the currently merged ones (arm32, arm64 and x86_64), the fact that
they are merged is usually zero cost, as the files would be identical
anyway. But if start using stdcall based ones as main input, we'd have the
extra overhead, that if we want to add a def file for a new library, we'd
first need to find an i386 version of the DLL and dump that.
(Consider if i386 support in Windows gets phased out at some point? I
guess that never will happen, but perhaps there'll be no more new APIs in
i386 form?)
Today, if contributors who update def files are thorough and consistent,
they update both the lib32 and lib-common versions at the same time, so
the burden of finding an i386 version of the DLLs already is present, this
doesn't make any difference. But if they don't have such a version, they
can also just update the lib-common version and let lib32 lag behind.
So my opinion on your suggestion is "maybe" - it's of course not ideal
that there is this level of duplication, but as most of those files don't
have a lot of manual fixups/tweaks like the core def files, I'm not sure
if the burden of having lib32 + lib-common is very big, compared with the
extra build process complication, and for updating everything via the
@stdcall suffix form.
If you'd have a working PoC patch for it, it would be easier to judge the
tradeoff. I'm also interested in hearing Biswapriyo's opinion, as they
probably are the ones who do most the work in updating them these days -
would this ease the burden noticably, or would the amount of work mostly
be the same?
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
