Please also add %Z format test in swprintf test (to show that it uses ANSI_STRING).
I added a case that uses `%Z` in `test_swprintf`.
Please also check the function behavior with ucrtbase - current implementation will fail there. Its behavior probably changes based on \_CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS or \_CRT_INTERNAL_PRINTF_LEGACY_MSVCRT_COMPATIBILITY flag.
I did some experiments on an `ucrt`-based toolchain: https://godbolt.org/z/sYxzWbM3x Without any legacy flag, `%Z` is always treated as wide. With `_CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS`, `%Z` is treated as narrow by wide functions and wide by narrow functions. `_CRT_INTERNAL_PRINTF_LEGACY_MSVCRT_COMPATIBILITY` has no effect. My previous research was done on clang/MinGW, and they probably did something weird there.
Please also add tests to ucrtbase.
I added tests to `test_printf_legacy_wide` to demonstrate the behavior. I checked and confirmed that it worked on Windows 11 25H2.
This is not portable, please define ANSI_STRING/UNICODE_STRING structures separately and use pointers to them here.
As I mentioned in the comment above, are you referring to the object literals or the structure definitions themselves? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10460#note_134651