[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
RE: Binary vs. text
- Subject: RE: Binary vs. text
- From: "Sacks, Avram" Avram.Sacks@xxxxxxxx
- Date: Fri, 13 Jul 2007 13:39:16 -0500
Hi,
Carl wrote:
>The mischief arises because
>when XyWrite displays a file, it strips out all occurrences of
>Ascii-0 and truncates the file contents after the first occurrence
>of Ascii-26, discarding the balance of the file. If you SAve this
>defective and incomplete version of the file to disk, all of the
>stripped-out and truncated information is permanently LOST, and the
>file is thus irretrievably corrupted.
I am surmising that this would then explain why, when my colleague saved her dict.spl file, instead
of aborting it, it was no longer useful, even though the visible characters on her screen were
identical to the visible characters on my screen for that file.
--
Avi
Avram L. Sacks
Social Security Law Analyst
847-267-7110
Avram.Sacks@xxxxxxxx
http://hr.cch.com/unemployment-insurance/CCH
Business Compliance
2700 Lake Cook Road
Riverwoods, IL 60015
-----Original Message-----
From: owner-xywrite@xxxxxxxx [mailto:owner-xywrite@xxxxxxxx] On Behalf Of Carl Distefano
Sent: Thursday, July 12, 2007 10:44 PM
To: xywrite@xxxxxxxx
Subject: Re: Binary vs. text
Reply to note from Harry Binswanger Thu, 12 Jul
2007 22:10:34 -0400
Harry:
> None of this means that there aren't crucial differences *at
> some lesser level of abstraction* between text files and
> executable files. So my original question amounts to: at what
> level of abstraction? E.g., does the DICT.SPL file have fixed-
> length fields or records?
No. The "difference" is not in the binary file per se (a byte is a
byte, you're right), but in XyWrite -- specifically, in XyWrite's
use of certain low- and high-level Ascii characters, called "control
characters", in order to format and display text on the screen,
display MoDed text and certain special characters (e.g., XPL
functions), mark the end-of-file, etc. Xy uses several control
characters -- Ascii 0, 26, 27, 174, 175, 253, 254 and 255 spring to
mind -- but the two that work the most mischief vis-þ-vis binary
files are Ascii 0 and 26. These occur plentifully in binary files
but MUST BE ABSENT, save for a single terminating Ascii-26 at
End_of_File, from any XyWrite file if the file is to maintain its
integrity once displayed in XyWrite. The mischief arises because
when XyWrite displays a file, it strips out all occurrences of
Ascii-0 and truncates the file contents after the first occurrence
of Ascii-26, discarding the balance of the file. If you SAve this
defective and incomplete version of the file to disk, all of the
stripped-out and truncated information is permanently LOST, and the
file is thus irretrievably corrupted.
XyWrite's use of control characters is sparing, but the few
characters that are reserved for special purposes are sacrosanct,
and cannot be expected to do double duty as displayable, printable
characters. At the heart of the problem is the "use-mention"
distinction, on which I will leave it to you and the other
professional philosophers on the list to expound. But if you really
want to understand how XyWrite employs control characters, you've
got to consult the definitive monograph on the subject, Robert's
CTRLCHAR.TXT, which is available at the XyWWWeb site.
--
Carl Distefano
cld@xxxxxxxx