Re: [TCLCORE] TIP 716 ready for comments

[Harald O. <har...@el...>]

Am 25.04.2025 um 09:37 schrieb Jan Nijtmans:
> Op di 15 apr 2025 om 21:02 schreef apnmbx-public--- via Tcl-Core
> <tcl...@li...>:
>> The rules are (as per TIP 716):
>>
>> Use the Unicode Windows API as Tcl/Tk already do. Then these issues do not arise.
>> If you have to use ANSI API’s, use Windows encoding settings, not Tcl encoding settings.
> 
> So, let's establish that TIP #716 changes the rules!
> 
> I did some investigation which extensions will be broken by TIP #716.
> But - first -
> let's remember the rules how they were in  Tcl 8.x.
> 
> 1) Use the Unicode Windows API as Tcl/Tk already do. Then these issues
> do not arise:
>         Tcl_WinUtfToTChar(str, strlen(str), &ds);
>         _wfopen((WCHAR *)Tcl_DStringValue(ds), L"r")
> 
> 2) If you have to use ANSI API’s, use the following:
>         Tcl_DStringInit(&ds);
>         Tcl_DStringToExtenal(NULL, str, -1, &ds);
>         fopen(Tcl_DStringValue(ds), "r")
> 
> 3) If you only care about ASCII characters, just do:
>         fopen(str, "r")
> 
> In Tcl 9.0.0/9.0.3, all 3 rules start working correctly with UTF-8
> (except when using
> the GDI API but there is no known extension using that). Whatever
> choice is made, 1), 2) or 3), all work fine with Tcl 9.0.0/9.0.1.  If
> TIP #716 is
> accepted, 2) and 3) won't work correctly with characters outside ASCII any more.
> Which extensions will suffer from that? I found the following:
> 
>      blt/src/bltWinImage.c (line 1194)
>      expect/exp_main_sub.c (line 813)
>      pikchr/pikchr.c (line 8136)
>      tkimg/sgi/sgi.c (line 1512)
>      VecTcl/WavReader/generic/wavreader.c (line 88)
> 
> So, as long as BLT images, pikchr, sgi or waveform filenames
> use ASCII characters only, nothing to worry about. When running
> in Tcl 9.0.0 or 9.0.1, nothing to worry about either. But with
> TIP #716, the rules change, and 2) or 3) can no longer handle
> characters outside ASCII.
> 
> Hope this helps,
>          Jan Nijtmans
Dear Jan,
thanks for the action. I will test later or next week.
The example given by Ashok was a driver to the IBM data base which was 
loaded as a dll into TCL. This 3rd party driver did not work any more 
due to the manifest change.
There is nothing TCL related here. The only issue is, that any load DLL 
is influenced by the manifest.
This is only fixable by removing the UTF-8 manifest.
There is no problem with this, as TCL does not rely on it.
And no compatible extion should rely on it.
It is a work around, not a feature.

Thanks for all,
Harald