WTF is this ?

[Peter Murschall]

After Installation I started TCC 17 build 71, but it shows me the same croud things as build 57, see the Screenshot. It remembered me at old gone times of confusional font settings and so on.
What can I do ?

Mit freundlichsten Grüßen

Peter

 

[Charles Dye]

I'm curious what you have in your TCSTART.BTM file....

 

[Peter Murschall]

I'm curious what you have in your TCSTART.BTM file....

Ahemm...:
::* TCSTART.BTM
::ASCII:Ž™šá„”:
::ANSI :ÄÖÜßäöü§:
if %_pipe != 0 .or. %_transient != 0 quit
IF %_PIPE != 0 Quit
IF %_TRANSIENT != 0 Quit
IF %_SHELLS != 0 QUIT
IFF %_CMDPROC != 4NT THEN%+IF %_IDE != 0 Quit%+ENDIFF
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::* Echo On
:: * Echo Hier ist :%0: mit !%_CMDPROC! in %@INC[%_SHELL]. Instanz
Echo %@NAME[%0], Proz:%_CMDPROC, Vers:%_4Ver, Instanz: %@INC[%_SHELL]./ %@INC[%_SHELLS].
Echo `%_PIPE`=%_PIPE , `%_TRANSIENT`=%_TRANSIENT , `%_BDEBUGGER`=%_BDEBUGGER ,`%_IDE`=%_IDE ,`%_SHELL`=%_SHELL,`%_SHELLS`=%_SHELLS
::* Echo It's me:%0: mit :%_CMDPROC: in %@INC[%_SHELLS]. Instanz
::* , in %@REPEAT[#,72]
Log %@NAME[%0]-Start *%_CMDPROC%* Ver:%_4Ver, Umgebung:(%_DOS) Shell#%_SHELL#,`%_SHELLS`=(%_SHELLS),`%_PIPE`:!%_PIPE!,`%_TRANSIENT`: -%_TRANSIENT-,`%_IDE`=# %_IDE#,ComSPEC:"%COMSPEC"
:-----------------------------------------------------------------------------------------------
::* Echo _SHELL:^t "%_SHELL" ^t Instanz
::* one for each command processor.
::* _SHELL will return 0 for a primary shell,
::* or 1 (or higher) for a shell started by another 4NT or TC process (either directly or via a pipe).
::* Echo _SHELLS:^t "%_SHELLS" ^t liefert den gleichen Wert wie _SHELL aus den vorherigen Versionen.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Set DebugMe=Y
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
IF %_PIPE != 0 Quit
IF %_TRANSIENT != 0 Quit
IF %_SHELLS != 0 QUIT
IFF %_CMDPROC != 4NT THEN%+IF %_IDE != 0 Quit%+ENDIFF
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
IFF %DebugMe EQ Y THEN
Pause Debugme ist gleich "%DebugMe"
::* BDEBUGGER D:\JPSoft\Common\JPStart.BTM
IF %_4Ver LE 8 BDEBUGGER
IF %_4Ver GE 9 IDE D:\JPSoft\Common\JPStart.BTM
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::* ELSE
::* D:\JPSoft\Common\JPStart.BTM
ELSEIFF
D:\JPSoft\Common\JPStart.BTM
ENDIFF

Does it helps ? ;-)

 

[rconn]

It looks like you're not using the same font and/or code page in v17. (Note: TCMD and TCC each have their own fonts; if they don't match you'll get odd results.)

Are you using a Unicode or raster font?

 

[Peter Murschall]

I'm using raster font, 8x12, because this is my preferred font in console. I never changed anything in the Codepage (since Windows 2000!).

In deed, there are differences !
TCC16: echo %@FONT[0] ?8
TCC17: echo %@FONT[0] ?4
Can I do anything else ?

 

[vefatica]

I'm using raster font, 8x12, because this is my preferred font in console. I never changed anything in the Codepage (since Windows 2000!).

In deed, there are differences !
TCC16: echo %@FONT[0] ?8
TCC17: echo %@FONT[0] ?4
Can I do anything else ?

Here, Win7/32 they both give "Terminal".

But that may be unrelated to your original problem. Peter, can you add a codepage check to your elaborate display of system status ... maybe a simple CHCP command? It certainly looks (in your first post) like two different codepages are being used.

 

[Peter Murschall]

Here, Win7/32 they both give "Terminal".

But that may be unrelated to your original problem. Peter, can you add a codepage check to your elaborate display of system status ... maybe a simple CHCP command? It certainly looks (in your first post) like two different codepages are being used.

Unfortunately, this is not the case, vefatica, see "snippshot":

 

[Charles Dye]

If you change the console font to Lucida Console and re-run your TCStart script, does it look better?

Edit: Never mind. It's not a font issue.

 

[Charles Dye]

Okay, I see it now. When a .BTM file contains OEM text (not Unicode), characters 0x80 - 0xff are interpreted as if they were Unicode -- not OEM characters. This seems only to happen in a .BTM; if you rename the file to end in .CMD or .BAT, high-order characters are interpreted according to the console code page.

 

[Charles Dye]

Here's a ditzy little batch file which demonstrates the issue. I've zipped it so uploading and downloading won't affect its OEM-ness.

 

[Peter Murschall]

Okay, I see it now. When a .BTM file contains OEM text (not Unicode), characters 0x80 - 0xff are interpreted as if they were Unicode -- not OEM characters. This seems only to happen in a .BTM; if you rename the file to end in .CMD or .BAT, high-order characters are interpreted according to the console code page.

Ahemmm .....really ? see snippshot ;-)
Btw: As You can see, TCCs are installed (and started !) in the same OS/Environment/Path/Drive etc..
So it could not be, that I'm using other Codepages/Fonts etc..

 

[Charles Dye]

Btw: As You can see, TCCs are installed (and started !) in the same OS/Environment/Path/Drive etc..
So it could not be, that I'm using other Codepages/Fonts etc..

Exactly. I was able to reproduce your issue. It has to do with the way TCC v17 reads characters from an 8-bit file loaded into memory, as a .BTM is by default. High-order characters are just zero-extended to 16 bits, not translated according to the current code page as they should be -- and were, in older versions.

I think that if you edit the batch file which displays all that stuff ( D:\JPSoft\Common\JPStart.BTM? ) and add a line LOADBTM OFF at the start, you'll find that the characters are interpreted correctly. Alternatively, you could load that batch file in a text editor and then re-save it as UTF-16; that should also work around the issue.

 

[vefatica]

Interesting! But tell me ... what is this character? According to Charmap, my font (Andale Mono) can't produce it.

 

[Charles Dye]

0xB2 is a graphics character in code page 850 and code page 437. It should translate to Unicode U+2593, "dark shade". TCC is instead making it Unicode U+00B2, "superscript 2".

 

[vefatica]

0xB2 is a graphics character in code page 850 and code page 437. It should translate to Unicode U+2593, "dark shade". TCC is instead making it Unicode U+00B2, "superscript 2".

It's not like any "dark shade" I've seen. Look at it carefully. It has bumps on the left, indents on the right, and it's not flat on top. I'm accustomed to that character being perfectly rectangular, like this (Lucida Console).

That's how it looks when I view "Andale Mono" in charmap.

 

[vefatica]

Do you suppose that's what happens when Windows sizes it?

 

[Charles Dye]

Do you suppose that's what happens when Windows sizes it?

Don't know. It might be caused by ClearType, which I suspect was never really intended for (a) console windows or (b) graphics characters.

 

[vefatica]

Don't know. It might be caused by ClearType, which I suspect was never really intended for (a) console windows or (b) graphics characters.

Maybe.

 

[Peter Murschall]

Exactly. I was able to reproduce your issue. It has to do with the way TCC v17 reads characters from an 8-bit file loaded into memory, as a .BTM is by default. High-order characters are just zero-extended to 16 bits, not translated according to the current code page as they should be -- and were, in older versions.

I think that if you edit the batch file which displays all that stuff ( D:\JPSoft\Common\JPStart.BTM? ) and add a line LOADBTM OFF at the start, you'll find that the characters are interpreted correctly. Alternatively, you could load that batch file in a text editor and then re-save it as UTF-16; that should also work around the issue.

Many thanks, Charles, LOADBTM OFF will do the Job :-)

 

[Charles Dye]

Many thanks, Charles, LOADBTM OFF will do the Job :-)

It's a workaround, but I think this issue qualifies as an incompatibility if not an outright bug.

 

[rconn]

Fixed in build 74 (Microsoft RTL bug).

 

[Charles Dye]

Fixed in build 75. (Sorry for the slow feedback.)

 

[Peter Murschall]

Fixed in build 75. (Sorry for the slow feedback.)

Great Job, Guys ! Build 75 works well as expected,
now I'm going to test the rest :-) :-) :-)