WTF is this ?

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
 

Attachments

  • TC17murks.PNG
    TC17murks.PNG
    179.2 KB · Views: 141
Last edited:
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 ? ;-)



 
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 ?
 
May 20, 2008
12,173
133
Syracuse, NY, USA
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.
 
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":
 

Attachments

  • TC17Desaster.PNG
    TC17Desaster.PNG
    144.5 KB · Views: 102

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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.
 
Last edited:

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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.
 

Attachments

  • test.zip
    337 bytes · Views: 105
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..
 

Attachments

  • TC17Desaster2.PNG
    TC17Desaster2.PNG
    203.6 KB · Views: 98

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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.
 
May 20, 2008
12,173
133
Syracuse, NY, USA
Interesting! But tell me ... what is this character? According to Charmap, my font (Andale Mono) can't produce it.

upload_2015-2-4_17-28-13.png
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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".
 
May 20, 2008
12,173
133
Syracuse, NY, USA
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).
upload_2015-2-4_20-32-50.png

That's how it looks when I view "Andale Mono" in charmap.
upload_2015-2-4_20-34-55.png
 
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 :-)