1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Take Command 10.0 build 61 uploaded

Discussion in 'Support' started by rconn, Mar 20, 2009.

  1. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    (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?
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    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
     
  5. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,179
    Likes Received:
    11
    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:


    file

    the same

     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    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. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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
     
  8. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,179
    Likes Received:
    11
    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:



    accented

    0x0F.

     
  9. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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
     
  10. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,179
    Likes Received:
    11
    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:


    for

    thus

    code

     

Share This Page