Re: [TCLCORE] TIP 716 ready for comments

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

Am 26.04.2025 um 00:12 schrieb Jan Nijtmans:
> Op vr 25 apr 2025 om 16:06 schreef Ashok Nadkarni <apn...@ya...>:
>>
>> And other posts on the same (DB2 drivers not supporting UTF-8) - SQLAllocHandle of the driver on SQL_HANDLE_ENV failed when connecting to IBM-DB2 database - MATLAB Answers - MATLAB Central and windows - DB2 service does not start - Stack Overflow
> 
> Those posts tell me something. First, compare the story with this Tcl ticket:
>      <https://core.tcl-lang.org/tcl/info/0b9332722a>
> Tcl had the same problem 5 years ago. It got the ACP value, prepended it
> with "cp" and then used it as an encoding name. There is no "cp65001"
> encoding, it should be handled as "utf-8".
> 
> My guess is that the IBM dll does the same thing. No surprise
> the initialisation fails. They really should fix this bug, it shouldn't
> be difficult. Is it already reported to them? The DB2 dll
> simply doesn't work in any utf-8 environment.
> 
> Does that make sense?
> 
>          Jan Nijtmans
> 
Dear Jan,
indeed, it might be the same issue related to the ticket, who knows.
The magic manifest key is a partial work-around for programs using the 8 
bit Windows API. It was introduced in Windows 10.
It only affects the ANSI/char/MCBS Windows API which is superseeded 
since 1993 by the wide Windows API.

What does this workaround do:
- switch some (not all) ANSI API functions from the local encoding 
(cp1252 in Western Europe) to use UTF-8 as char encoding
- switch the reporting of the native codepage
- as the manifest is in the exe, it applies to all loaded DLLs

Unfortunately, this breaks a lot of legacy DLLs. They are not fixed as 
the source code or maintainer is not available.
In addition, there is no reason to fix. The DLLs work.

The upper workaround is only useful (if for any case), if a small 
application with only WinAPI dependencies should be easily ported.

It is not useful for TCL as it breaks legacy DLLs.
There is no useful application, as TCL uses the wide Windows API.

Ashok gets a bit nerved, as this was changed without a TIP.
Here, I am not his opinion. The intention was clear and when reading 
from it, I was initialy also in favor: Unicode? Yes, we want it.
Now, we are wiser and we should revert this change.
Ashok goes the formal way by a TIP, what is noble.
IMHO, it could just be reverted as a not valid bugfix.

I really appreciate all your work.
But putting energy in here is IMHO lost and may better be investigated 
in the great three tickets by Christian ;-).

Thanks for all and take care,
Harald