Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WTF is this ?

Sep
134
1
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: 202
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 ?
 
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: 162
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:
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.
 
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: 166
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: 154
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.
 
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
 
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".
 
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
 
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.
 
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 :-)
 
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 :-) :-) :-)
 
Back
Top