WAD ANSI still misbehaves with build 35

[vefatica]

 

[rconn]

Not reproducible here. What's the timestamp on your ansi32.dll?

 

[vefatica]

It's not in use by TCC, but its times are

g:\tc22> filetimes ANSI32.dll
Created:  2018-01-17 19:10:35
Accessed: 2018-01-17 21:41:30
Modified: 2018-01-17 19:10:35

 

[vefatica]

I have "ANSI=Yes" and it misbehaves (without ANSI32.DLL loaded). If I start TCC with no inifile (/ii) I still get colors, ANSI32.DLL is loaded, and it doesn't misbehave.

 

[vefatica]

I have "ANSI=Yes" and it misbehaves (without ANSI32.DLL loaded). If I start TCC with no inifile (/ii) I still get colors, ANSI32.DLL is loaded, and it doesn't misbehave.

Isn't that odd? I'm not using TCMD. When I use no inifile, how's ANSI32.DLL getting into TCC? If I use an inifile with "ANSI=No", then I really get no ANSI.

 

[rconn]

TCC will not load ansi32.dll, ever. You have something else in your system doing that.

 

[vefatica]

TCC will not load ansi32.dll, ever. You have something else in your system doing that.

You're right. With no inifile, I get AutoRun and AutoRun does it. I could never understand "Yes" being the default for AutoRun. That file is very likely to have CMD-specific stuff in it (like DOSKEY macros). The help seems to suggest that "No" is the default.

AutoRun : If enabled ...

 

[rconn]

You do realize that you cannot print an escape when you're using ANSI output, don't you? Unless you send the ANSI sequence to print control characters, it will just get swallowed.

 

[vefatica]

You do realize that you cannot print an escape when you're using ANSI output, don't you? Unless you send the ANSI sequence to print control characters, it will just get swallowed.

I'm not sure what you're saying. I have had "ANSI=Yes" in every version of 4NT/TCC since ANSI support began. "ECHO ^e" shows the left-pointing arrow in every version I have (back to v8) except v22.

 

[vefatica]

When I said it was OK with ANSI32.DLL (no inifile, injected in AutoRun) that was my own build of ANSI32.DLL. When I set "ANSI=No" in [4NT] and "ANSI=Yes" in [TakeCommand] (and use the JP version of ANSI32.DLL), it's even worse than pictured above. Here's an example of a new TCMD22 with those settings; after typing the command, I pressed "Enter" three times.

 

[rconn]

Ah, I think I understand what you're doing & seeing now that I changed my font to an old one that displays the DOS control characters.

TCC and ANSI are doing everything correctly; your expectations are wrong.

In addition to all of the <ESC>[... and <ESC>]... sequences, ANSI x3.64 includes dozens of other two character escape sequences, such as:

<ESC>M (reverse index)
<ESC>c (reset)
<ESC>^ (privacy message)
etc.

When you do an:

echo ^e

You're sending:

<ESC><CR><LF>

The ANSI driver (correctly!) interprets this to mean "show the following control character as a graphical character". So what you're seeing is the <CR> being converted to its graphical representation.

So the question is -- do you have a pressing need to print invisible escape characters? If so, I will need to disable that feature in the ANSI driver (risking the wrath of whatever users out there actually want to use it).

 

[rconn]

I'm not sure what you're saying. I have had "ANSI=Yes" in every version of 4NT/TCC since ANSI support began. "ECHO ^e" shows the left-pointing arrow in every version I have (back to v8) except v22.

It only "worked" because prior versions of TCC didn't implement the full x3.64 set.

 

[vefatica]

The ANSI driver (correctly!) interprets this to mean "show the following control character as a graphical character". So what you're seeing is the <CR> being converted to its graphical representation.

So "ECHO ^e^e" should mean show me the graphical representation of character 0x1B? That doesn't work either and also leaves a peculiar after-effect.

 

[vefatica]

<ESC>M (reverse index)
<ESC>c (reset)
<ESC>^ (privacy message)

Are those and the others you mentioned documented in the help?

 

[rconn]

So "ECHO ^e^e" should mean show me the graphical representation of character 0x1B? That doesn't work either and also leaves a peculiar after-effect.
View attachment 1856

Definitely not -- you're telling the ANSI driver that you always want an escape to be displayed as a graphical character, not interpreted as an escape sequence.

You still haven't explained why you need to print the graphical representation of an escape character when you're using ANSI. If you have a compelling reason, then I will consider gutting the ANSI driver and removing most of the new escape sequences to allow it.

 

[rconn]

Are those and the others you mentioned documented in the help?

They're standard ANSI x3.64.

 

[vefatica]

I don't know what "reset" means, but <ESC>c doesn't seem to work very well. Here's a before/after pressing Enter.

 

[vefatica]

I also don't know about "privacy message", but these either lead to the continuation prompt, corruption similar to that mentioned above, or an unusable console.

 

[vefatica]

Re: ECHO ^e^e

Definitely not -- you're telling the ANSI driver that you always want an escape to be displayed as a graphical character, not interpreted as an escape sequence.

So why isn't it displayed? And why does it have a bad after-effect?

 

[rconn]

Re: ECHO ^e^e

So why isn't it displayed? And why does it have a bad after-effect?

It is displayed in your screen shot.

 

[rconn]

I also don't know about "privacy message", but these either lead to the continuation prompt, corruption similar to that mentioned above, or an unusable console.
View attachment 1858

Everything above is WAD.

Rule of thumb - do not use an escape sequence when you have ANSI turned on unless you know what it's going to do! (In this case, you'd need to turn off escape character processing in TCC before you could use ^. And when you do, you won't be able to use the console until you send the appropriate escape sequence to clear it.)

Check the ANSI x3.64 documentation for details on specific escape sequences - I'm not going to disable ANSI just because you don't know what it's going to do ...

Since you haven't come up with a reason why you want to do this, I'm going to assume that you don't have any need for it.

 

[rconn]

I don't know what "reset" means, but <ESC>c doesn't seem to work very well. Here's a before/after pressing Enter.
View attachment 1857

WAD.

 

[rconn]

And please stop using ECHO for your examples -- that's the cause of most of your problems.

An "echo ^e" doesn't echo an escape, it echoes an escape + CR + LF. An "echo ^ec" doesn't echo an escape + 'c', it echoes an escape + 'c' + CR + LF. The trailing CR / LF are being interpreted as part of the escape sequence and that's why you're getting unexpected results.

 

[vefatica]

Does all this have anything to do with Windows 10 having VT100 emulation? I'd like to hear from someone who appraciates these changes. Have you seen https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences

The only thing I'd like to see again is the ability to set the scrolling region, so, for example, the first or last line of a console can be used as a "banner". Is that possible with TCC and Windows 10?

 

[rconn]

Does all this have anything to do with Windows 10 having VT100 emulation? I'd like to hear from someone who appraciates these changes. Have you seen https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences

Yes, and I've had dozens of requests to support all the VT100 sequences when not using the Windows 10 console ANSI.

The only thing I'd like to see again is the ability to set the scrolling region, so, for example, the first or last line of a console can be used as a "banner". Is that possible with TCC and Windows 10?

I don't know what you mean by "see again". You can set top & bottom margins with DECSTBM (ESC[#;#r), but that was never supported in TCC before v22.

 

[vefatica]

I don't know what you mean by "see again".

Again, as in since I used Coherent and Linux in the 1990s.

 

[rconn]

Again, as in since I used Coherent and Linux in the 1990s.

That is/was a VT100 feature; it didn't have anything to do with Coherent / Unix / Linux.

But you can't have DECSTBM if you also want me to remove all the 2-character escape sequences; they're intertwined.

 

[vefatica]

That is/was a VT100 feature; it didn't have anything to do with Coherent / Unix / Linux.

But you can't have DECSTBM if you also want me to remove all the 2-character escape sequences; they're intertwined.

They emulated VT100.

I'm not likely to have Windows 10 any time soon. If I ever get it and the feature exists, I'll try it just to see it work and probably not use it thereafter.

I have no pressing need to echo control characters. I wish I could remember what I was doing when I discovered the changed behavior.

 

[rconn]

The DECSTBM feature is supported in TCMD or TCC v22 running any version of Windows.

 

[vefatica]

The DECSTBM feature is supported in TCMD or TCC v22 running any version of Windows.

And it works! ... well, it sort of works. If, in my 52-line console, I

echo ^e[1;40r

and do DIR, it scrolls at line 40, leaving what's below fixed, just as I'd expect. But external apps use the whole window and that's likely to leave you stuck with the new prompt on the bottom row, and all further output using only that one row. If the internal ANSI will always have that problem, it hardly seems worth implementing DECSTBM.

So I figure it's a TCC-only sort of kludge. Does it work any better (or at all) if Windows 10 is handling the ANSI?