AntonyD asked my twice for a response in this thread. I have looked into it now and here is my response.
I was able to confirm that the behavior changed in TC 9.51rc4. I think because of this change:
By default, TC uses ANSI for storing wincmd.ini. Values are stored wincmd.ini as ANSI or when necessary as UTF-8 with BOM. But the Windows beta option to set the system's codepage to 65001, causes a problem. Values in the wincmd.ini (ANSI format) may have been stored as UTF-8 without BOM. I assume the change in TC 9.51rc4 is that TC tries to read the value as UTF-8 with ANSI as fallback. That way it wouldn't matter if the user for example temporarily enabled the Windows beta option and later in time disabled it.
The problem with this is that valid ANSI can be valid UTF-8 at the same time. TC could take the wrong value, as is the case presented in this thread. Perhaps a solution to this is to make a change when storing the value. After TC stores the value to wincmd.ini, it could retrieve the value the way it would when loading the value (attempting to interpret it as UTF-8), and check if the retrieved value differs from the value that was supposed to be stored. If so, TC could store the value with BOM instead.
I was able to confirm that the behavior changed in TC 9.51rc4. I think because of this change:
This is my interpretation:04.03.20 Fixed: New option in regional settings "Beta: Use Unicode UTF-8 for worldwide language support": Read both UTF-8 and ANSI values from wincmd.ini (32/64)
By default, TC uses ANSI for storing wincmd.ini. Values are stored wincmd.ini as ANSI or when necessary as UTF-8 with BOM. But the Windows beta option to set the system's codepage to 65001, causes a problem. Values in the wincmd.ini (ANSI format) may have been stored as UTF-8 without BOM. I assume the change in TC 9.51rc4 is that TC tries to read the value as UTF-8 with ANSI as fallback. That way it wouldn't matter if the user for example temporarily enabled the Windows beta option and later in time disabled it.
The problem with this is that valid ANSI can be valid UTF-8 at the same time. TC could take the wrong value, as is the case presented in this thread. Perhaps a solution to this is to make a change when storing the value. After TC stores the value to wincmd.ini, it could retrieve the value the way it would when loading the value (attempting to interpret it as UTF-8), and check if the retrieved value differs from the value that was supposed to be stored. If so, TC could store the value with BOM instead.
Statistics: Posted by white — 2025-05-24, 14:05 UTC
