WritePrivateProfileString - is unpredictable

Question

We are using a tool that uses internally the simple Win-Api call WritePrivateProfileString.

I\'m aware of the define flag UNICODE to map either to

Answer 1

1. Always use WritePrivateProfileStringW version.

    [DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true,
    EntryPoint = "WritePrivateProfileStringW")]
    [return: MarshalAs(UnmanagedType.Bool)]
    public static extern bool WritePrivateProfileString(string lpAppName, string lpKeyName, string lpString, string lpFileName);
   

2. When the INI files does not exist, create it with Unicode file marker (first two bytes FF FE). By this way all strings are stored as Unicode. To create a blank ini file you can use this:

    File.WriteAllText(ini_file_path, "; Your comment\r\n", Encoding.Unicode);
   

A blank/comment line at the beginning is recommended. Write at least "\r\n".

Answer 2

I found the root cause:
https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows

In April 2018 with insider build 17035 (nominal build 17134) for Windows 10, a "Beta: Use Unicode UTF-8 for worldwide language support" checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling "narrow" functions, including fopen and SetWindowTextA, with UTF-8 strings. In May 2019 Microsoft added the ability for a program to set the code page to UTF-8 itself, and started recommending that all software do this and use UTF-8 exclusively.

This setting was activated on some systems and it was responsible for changing my expected ANSI code to UNICODE in the INI-file.

Yes, I understand that we have to go in the UNICODE direction in the future. But now also Microsoft is pushing us to this direction, which is not bad, but I was not aware of this setting or strategy before.

@IInspectable: yes you are right 0xA7 is not ASCII but ANSI (or ASCII-8, Extended ASCII) I had mixed it up, thank you.