A few days ago, a (imho) very impressive writeup on a peculiartiy of the Windows platform and how it handles Unicode/ANSI-Codepage backwards compatibility and conversion was published at
https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/ - the gist is that, if one is unlucky enough to pass Unicode into routines that expect non-Unicode string data, implicit conversion to the current OS codepage will happen - and if the stars align just right (i.e., the string having been passed in was massaged carefully by an attacker), a lot of bad things, up to arbitrary code execution, can follow.
Now as far as I can tell, you can (hopefully) avoid the pitfalls mentioned in the article if you are VERY careful to avoid all the ANSI-specific implementations in Windows, and stick to the wide-character-variants of the affected APIs.
Alternatively, you can reconfigure your Windows OS to use only Unicode encoded in UTF-8 as its internal string encoding/representation, but that will probably break legacy applications in obscure places.
Mitigating against this seems to be non-trivial (or maybe downright impossible?) for anything that uses Windows' C runtime/API in what could be construed as a "portable" fashion (i. e., defining main() instead of the Windows-specific wmain() is enough to incur the problem).
I was wondering what software authors implementing their programs in FPC and Lazarus could do to avoid being bitten by these hidden mines in the Windows API. Do you have any thoughts or advice on the matter?