Hello Eugene,

I have some issue, and not sure how to fix that.

In R20 echoes the bytes are 437/850. If Windows OEM is 866 --> those messages turn into Cyrillic garbage. No CHRS is fine — I have XLATIMPORT CP437 in the group. The broken ones are the ones that do say IBMPC.

Tried to use 'XLATCHARSETALIAS CP850 IBMPC' globally, but it does nothing here. On the unicode build 'CHRS: IBMPC 2' never looks at the alias table.
The recoder decides it itself: UTF-8 session --> Windows OEM page (GetOEMCP(), that gives 866 in this case). Aliases are only used if the recoder fails and it falls back to the old .chs files. IBMPC always "succeeds", so the alias is never reached.

Ctrl-J to CP437/CP850 works per message.

Could XLATCHARSETALIAS (or a groupable XLATIBMPC) be honoured in GRecoder::canonical() before GetOEMCP()?

GROUP R20
MEMBER R20*
XLATIMPORT CP437
XLATEXPORT CP850
XLATCHARSETALIAS CP850 IBMPC
ENDGROUP

Right now the alias line is ignored.

Mvh,
Alex.

---
* Origin: Rabarber > Skellefteå > Västerbotten > Sverige (2:203/910)

Hello Alexey,

On 05 Sep 26 12:03, you wrote to Eugene Subbotin:

In R20 echoes the bytes are 437/850. If Windows OEM is 866 --> those messages turn into Cyrillic garbage. No CHRS is fine — I have
XLATIMPORT CP437 in the group. The broken ones are the ones that do
say IBMPC.

Those messages wouldn't originate from a Winpoint system would they?

I have been trying to make "FTSC member" Tim Schattkowski understand that using "IBMPC" as the "default character set" in WinPoint is a bad idea. He insist that "IBMPC" is better because "every system" understands that... :-(


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20260904
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Michiel!

05 Sep 26 13:31, you wrote to Alexey Matrosov:

In R20 echoes the bytes are 437/850. If Windows OEM is 866 --> those
messages turn into Cyrillic garbage. No CHRS is fine — I have XLATIMPORT
CP437 in the group. The broken ones are the ones that do say IBMPC.

Those messages wouldn't originate from a Winpoint system would they?

I have been trying to make "FTSC member" Tim Schattkowski understand that using "IBMPC" as the "default character set" in WinPoint is a bad idea.
He insist that "IBMPC" is better because "every system" understands that... :-(

Shouldn't it just be ignored, falling back to the default charset? There's no such charset as "IBMPC".

P.S. Yesterday I finally encountered a CHRS line that broke AmberEdit's recoding. It was "CHRS: +7 FIDO 2"

Yegor
--- AmberEdit/linux 0.7
* Origin: to err is human, but to really f.. things up you need AI (2:382/736)

Hello Yegor,

On 05 Sep 26 14:08, you wrote to me:

Shouldn't it just be ignored, falling back to the default charset?
There's no such charset as "IBMPC".

The FTSC documents it as "obsolete", "must not be used when creating new messages" (FTS-5003.001, par 5)

P.S. Yesterday I finally encountered a CHRS line that broke
AmberEdit's recoding. It was "CHRS: +7 FIDO 2"

From FTS-5003.001:

The character set "+7_FIDO" is sometimes used as an identifier for
CP866. This use is deprecated, and "CP866" is recommended instead.
Implementations should treat "+7_FIDO" as a synonym for "CP866".

It gets even worse when the "_" is replaced by a space....


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20260904
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Michiel,

Saturday September 05 2026 13:31, you wrote to me:

In R20 echoes the bytes are 437/850. If Windows OEM is 866 -->
those messages turn into Cyrillic garbage. No CHRS is fine — I
have XLATIMPORT CP437 in the group. The broken ones are the ones
that do say IBMPC.

Those messages wouldn't originate from a Winpoint system would they?

No, in case of R20 those messages came from some good but old software like TCL and so.

I have been trying to make "FTSC member" Tim Schattkowski understand
that using "IBMPC" as the "default character set" in WinPoint is a bad idea. He insist that "IBMPC" is better because "every system"
understands that... :-(

Yep, I would say IBMPC is not the best choice for the "modernish" software ;)

Mvh,
Alex.

---
* Origin: Rabarber > Skellefteå > Västerbotten > Sverige (2:203/910)

Hello Alexey!

Saturday September 05 2026 12:03, you wrote to me:

I have some issue, and not sure how to fix that.

In R20 echoes the bytes are 437/850. If Windows OEM is 866 --> those messages turn into Cyrillic garbage. No CHRS is fine — I have
XLATIMPORT CP437 in the group. The broken ones are the ones that do
say IBMPC.

Tried to use 'XLATCHARSETALIAS CP850 IBMPC' globally, but it does
nothing here. On the unicode build 'CHRS: IBMPC 2' never looks at the alias table. The recoder decides it itself: UTF-8 session --> Windows
OEM page (GetOEMCP(), that gives 866 in this case). Aliases are only
used if the recoder fails and it falls back to the old .chs files.
IBMPC always "succeeds", so the alias is never reached.

Could XLATCHARSETALIAS (or a groupable XLATIBMPC) be honoured in GRecoder::canonical() before GetOEMCP()?

GROUP R20
MEMBER R20*
XLATIMPORT CP437
XLATEXPORT CP850
XLATCHARSETALIAS CP850 IBMPC
ENDGROUP

Right now the alias line is ignored.

Added in a new snapshot: https://github.com/evs38/golded-plus/releases/tag/golded-plus-1.1.5-20260905

I still have a hard time understanding what to do with this IBMPC. So, I've left it all up to the user to determine. In theory, it should be CP437 in the Z1, CP850 in Eastern Europe, and CP866 in Russia, Ukraine, and Belarus. Overall, it's a very unfortunate character set that means absolutely nothing.


Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260905 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene,

Saturday September 05 2026 22:06, you wrote to me:

Added in a new snapshot: https://github.com/evs38/golded-plus/releases/tag/golded-plus-1.1.5-20 260905

I still have a hard time understanding what to do with this IBMPC. So, I've left it all up to the user to determine. In theory, it should be CP437 in the Z1, CP850 in Eastern Europe, and CP866 in Russia,
Ukraine, and Belarus. Overall, it's a very unfortunate character set
that means absolutely nothing.

Yes, that is like this in my understanding as well, so IBMPC has to be CP437 in the US, and CP850 for Sweden/Finland. So, I do export to CP850 in R20 group, and guessing CP437 for messages without CHRS, just in case of some old software creating such a message.

So, XLATCHARSETALIAS works well now! But I'm experiencing another unexpected side effect with build 20260905: every time I start Golded, it enters my netmail area instead of showing an arealist :) That netmail area is the first one in the list.

Mvh,
Alex.

---
* Origin: Rabarber > Skellefteå > Västerbotten > Sverige (2:203/910)

Hello Alexey!

Saturday September 05 2026 21:35, you wrote to me:

So, XLATCHARSETALIAS works well now! But I'm experiencing another unexpected side effect with build 20260905: every time I start Golded,
it enters my netmail area instead of showing an arealist :) That
netmail area is the first one in the list.

I've reuploaded the latest release with this small fix https://github.com/evs38/golded-plus/releases/tag/golded-plus-1.1.5-20260905

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260905 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene,

Sunday September 06 2026 01:08, you wrote to me:

So, XLATCHARSETALIAS works well now! But I'm experiencing another
unexpected side effect with build 20260905: every time I start
Golded, it enters my netmail area instead of showing an arealist
:) That netmail area is the first one in the list.

I've reuploaded the latest release with this small fix https://github.com/evs38/golded-plus/releases/tag/golded-plus-1.1.5-20 260905

It works correctly!

Sju sjösjuka sjömän sköttes av sju sköna sjuksköterskor :)

Mvh,
Alex.

---
* Origin: Rabarber > Skellefteå > Västerbotten > Sverige (2:203/910)