manx

Maybe we need to go to inline asm, after all, at least for active architectures. I would suggest also considering to change to intrinsics instead of inline asm. Intrinsics for SSE and AVX on amd64 (or NEON on arm64) are widely supported and compatible between all major compilers, while inline asm requires compiler-specific syntax. We'd keep the files for 32 bit archs unchanged, I presume. Changing all the x86 32bit asm implementations is very likely not worth the effort, totally agreed.

is the combined workflow missing something? As far as I can see, only to old, now removed, noyasm workflow did not successfully build. See https://github.com/madebr/mpg123/actions/runs/12609590335 vs https://github.com/madebr/mpg123/actions/runs/12609590334 . This is because Microsoft removed 32bit ARM support in the latest SDK, and only the combined workflow accounts for that by explicitly selecting an older SDK for 32bit ARM. See https://github.com/madebr/mpg123/blob/b7db2283aa045699c53a788575...

They are converted back to wchar_t and passed to e.g. _wfopen. See for example INT123_compat_fopen in src/compat/compat.c. Even though the perfect solution would be to always keep filenames in wchar_t on Windows, this is way too much hassle for an originally POSIX-focused project like mpg123. mpg123 tries to keep everything in char in UTF8 internally. Windows support and conversion handling is not perfect and has known bugs. I am generally pushing for moving towards better Windows support (MinGW...

patch attached

[MPG123_LINK_DLL] I guess we should put a platform check into mpg123.h to default to a client build on Windows? Setting __declspec(dllimport) unconditionally on Windows would break clients that statically link libmpg123. But apparently it works without? "Modern" (last decades I think, I can did up details if wanted) MSVC toolchains do work without __declspec(dllimport) in client code when calling functions from a linked import library of a DLL, albeit (IIRC) at a small pointer indirection cost for...

I think the "demanding to use the _-variants" is Microsoft specific, I am not aware of any situation where the POSIX names do not exist while the _-variants do exist. I really do not know if "_WIN32 implies _-variants" holds true in all situations, so defaulting to the POSIX names by default is probably a more conservative approach. Assuming all Windows C libraries are implementing _-variants sounds somewhat fragile to me. On the other hand, with the current state there is a risk of missing some...

Looks like I missing switching to #if defined(MPG123_COMPAT_MSVCRT_IO) in INT123_compat_close. Can you do that as well?

Yeah, works for me.