Take Command 10.0 build 61 uploaded

rconn

Administrator
Staff member
May 14, 2008
10,580
97
#1
I've uploaded build 61 of Take Command / TCC 10.0 to the web and ftp sites.

(61) Fixed a (Windows) bug with repeated ^Breaks sometimes terminating TCMD.EXE
(61) Fixed a bug with the Find dialog in Take Command displaying a blank message box if the expression was not found
(61) Fixed a problem with combining the Shift and Caps Lock keys
(61) TYPE - fixed a bug with displaying Unicode files with the /X option

Those of you who've experienced problems in the past with ^Break, please try build 61 and let me know how it works for you.
 
#2
(61) TYPE - fixed a bug with displaying Unicode files with the /X option

It shows all the text now but it doesn't show the BOM. Thus the file offsets of each character are off by two. IMHO, the hex should be an accurate reflection of what's in the file.

I didn't check ... with an ascii file, do the hex representations of of some translated bytes still disagree with the bytes actually in the file?
 

rconn

Administrator
Staff member
May 14, 2008
10,580
97
#3
(61) TYPE - fixed a bug with displaying Unicode files with the /X option

It shows all the text now but it doesn't show the BOM. Thus the file offsets of each character are off by two. IMHO, the hex should be an accurate reflection of what's in the file.
WAD - typing the file without /X (or doing ANYTHING with the file other than LIST /X) doesn't show the BOM either. (And in many cases there won't be one anyway.)

Reiterating - TYPE is not intended to (and will never) display binary contents of files.
 
#4
On Fri, 20 Mar 2009 08:41:14 -0500, rconn <> wrote:

|Reiterating - TYPE is not intended to (and will never) display binary contents of files.

But it does (now) show the correct byte values for all characters in a file
comtaining 0x00 - 0xFF and (except for a few control characters) show the same
glyphs as LIST /X. That's all good.
--
- Vince
 

samintz

Scott Mintz
May 20, 2008
1,289
11
Solon, OH, USA
#5
I noticed that the TYPE /X output has the glyphs in its output from the
original IBM PC BIOS for characters 0x00 - 0x20 and 0x7e - 0xff.
In my HEXDUMP.BTM script, I couldn't figure out how to do that. The
printable characters from 0x20 - 0x7F come through, but the upper
characters (0x80-FF) come through as question marks or as various accented
letters.

Is there a way to force the output to use the OEM character set?

-Scott

vefatica <> wrote on 03/20/2009 11:06:49 AM:


> On Fri, 20 Mar 2009 08:41:14 -0500, rconn <> wrote:
>
> |Reiterating - TYPE is not intended to (and will never) display
> binary contents of files.
>
> But it does (now) show the correct byte values for all characters in a
file

> comtaining 0x00 - 0xFF and (except for a few control characters) show
the same

> glyphs as LIST /X. That's all good.
> --
> - Vince
>
>
>
>
 
#6
On Fri, 20 Mar 2009 12:32:12 -0500, samintz <> wrote:

|I noticed that the TYPE /X output has the glyphs in its output from the
|original IBM PC BIOS for characters 0x00 - 0x20 and 0x7e - 0xff.
|In my HEXDUMP.BTM script, I couldn't figure out how to do that. The
|printable characters from 0x20 - 0x7F come through, but the upper
|characters (0x80-FF) come through as question marks or as various accented
|letters.
|
|Is there a way to force the output to use the OEM character set?

I get '.' for 0x05 - 0x09, and <space> (or nothing at all) for 0x0C - 0x0F.

Do you see otherwise?
--
- Vince
 
#7
vefatica wrote:
| On Fri, 20 Mar 2009 12:32:12 -0500, samintz <> wrote:
|
|| I noticed that the TYPE /X output has the glyphs in its output from
|| the original IBM PC BIOS for characters 0x00 - 0x20 and 0x7e - 0xff.
|| In my HEXDUMP.BTM script, I couldn't figure out how to do that. The
|| printable characters from 0x20 - 0x7F come through, but the upper
|| characters (0x80-FF) come through as question marks or as various
|| accented letters.
||
|| Is there a way to force the output to use the OEM character set?
|
| I get '.' for 0x05 - 0x09, and <space> (or nothing at all) for 0x0C -
| 0x0F.
|
| Do you see otherwise?

I am not yet up to the latest build, but would like to remind you that what
you see in a TCC window is different from what shows in a TCC tab of a TCMD
window, thus you should include that information in your post...
--
Steve
 

samintz

Scott Mintz
May 20, 2008
1,289
11
Solon, OH, USA
#8
Yes, I see the same thing. I wasn't as concerned about the glyphs below
0x20. I do get differing results if I change the code page however.

For example, in my test file, I have 256 byte values ranging from 0 to
255. I think it is the same 00ff.bin that has been used in the TYPE /X
thread.

Using my HEXDUMP.BTM file, I get the following bytes output for the last
16 bytes of the file:
000000F0: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF d¤•¢“o”öo—£–y_˜

The "string" portion of the output does not contain the bytes F0 - FF. But
instead contains these bytes for codepage 437:
64 A4 95 A2 93 6F 94 F6 6F 97 A3 96 81 79 5F 98

But has the expected F0-FF for codepage 1252 although it does not display
the glyphs as expected.

And to further confuse things, if I change the codepage to 1252, run my
hexdump utility, then change the codepage back to 437, the glyphs change
on the display and display correctly.

-Scott


vefatica <> wrote on 03/20/2009 02:35:00 PM:


> On Fri, 20 Mar 2009 12:32:12 -0500, samintz <> wrote:
>
> |I noticed that the TYPE /X output has the glyphs in its output from the

> |original IBM PC BIOS for characters 0x00 - 0x20 and 0x7e - 0xff.
> |In my HEXDUMP.BTM script, I couldn't figure out how to do that. The
> |printable characters from 0x20 - 0x7F come through, but the upper
> |characters (0x80-FF) come through as question marks or as various
accented

> |letters.
> |
> |Is there a way to force the output to use the OEM character set?
>
> I get '.' for 0x05 - 0x09, and <space> (or nothing at all) for 0x0C -
0x0F.

>
> Do you see otherwise?
> --
> - Vince
>
>
>
>
 
#9
samintz wrote:
...
| And to further confuse things, if I change the codepage to 1252, run
| my hexdump utility, then change the codepage back to 437, the glyphs
| change
| on the display and display correctly.

Wow! If this is consistent, all one needs to do is to put those CHCP
commands into TCSTART.BTM. BTW, I long ago wrote a hex dump program in
Standard C89 (compiled with MSC6, so it needs SFNs), which uses period for
0x00...0x1F and 0x80...0xFF (control and non-ASCII characters), and is thus
not subject to this problem (when compiled for the target platform, the code
works unchanged on VAX and Unix, hence the character set limitation).
--
Steve
 

samintz

Scott Mintz
May 20, 2008
1,289
11
Solon, OH, USA
#10
Steve,

This line in my hexdump.btm creates the output string:
set a=%[a]%@if[0x%w lt 0x20,.,%@if[0x%w == 0x20,%@char[1],%@char[0x%w]]]

You will notice that I use a trick here that was suggested by Jonathan
Gilbert where I replace spaces with @char[1]. Then later I replace all
@char[1]'s with spaces before ECHOing the line. Since the line is built
up one character at a time, it is necessary to sometimes append a space.
Adding spaces to the end of a variable is not easily done in TCC.

At any rate, the above conditional can easily be changed to check if %w is
less than 0x20 or greater than 0x7F and output periods. Currently, it
only checks for less than 0x20. And doing that certainly avoids the whole
codepage issue.

-Scott


Steve F$BaC(Bi$BaO(B <> wrote on 03/20/2009 05:20:37 PM:


> samintz wrote:
> ...
> | And to further confuse things, if I change the codepage to 1252, run
> | my hexdump utility, then change the codepage back to 437, the glyphs
> | change
> | on the display and display correctly.
>
> Wow! If this is consistent, all one needs to do is to put those CHCP
> commands into TCSTART.BTM. BTW, I long ago wrote a hex dump program in
> Standard C89 (compiled with MSC6, so it needs SFNs), which uses period
for

> 0x00...0x1F and 0x80...0xFF (control and non-ASCII characters), and is
thus

> not subject to this problem (when compiled for the target platform, the
code

> works unchanged on VAX and Unix, hence the character set limitation).
> --
> Steve
>
>
>
>