[Date Prev][Date Next][Subject Prev][Subject Next][Date Index][Subject Index]

Handling of 00h bytes by XyWrite



In XyWrite 3 FILES, NUL (00h) bytes play no intended long term role in a file maintained by Xywrite.
That is shown by the fact that, in XyWrite 3, every time a file is loaded from disk into an editing
buffer, all NUL bytes are stripped out of the data stream and are discarded (they are stripped out
only when a file is loaded, but they are not stripped out, if present, when a file is saved). There
are conditions in which XyWrite (3.57, at least) will insert a NUL byte into a file, for example a
PFUNC xx command that is executed with the "insert key mode" being "overstrike"
rather than "insert" will insert a superfluous NUL right after the inserted xx primitive
(which will remain there after one deletes the primitive). XyWrite is quite good at
"hiding" these NUL bytes. For example, if I represent a NUL byte by the '!' character,
XyWrite will present the string 'HEL!!!LO' as 'HELLO' on screen, and a user would be hard pressed to
demonstrated that the NUL bytes are "there." And !

Since there are two "free" bytes in the "0FFh triggered" 3 byte sequence
"escape sequences" that XyWrite supports, there are about 65000 (65536, minus a few) that
could be used for possible encodings for the 3 byte escape sequences. XyWrite 3 uses only
256+351=607 (351 for the primitives like BC or CR or XC, 256 for 3 byte alternate encodings of 1
byte characters) of those 65000 possible encodings. XyWrite 4 would have a few more primitives, but
not a lot more. They are, somewhat conspicuously encoded so that no 3 byte encoding will contain a
NUL byte (as has to be the case, because if it weren't, loading such a file for editing would delete
the NULs and corrupt the 3 byte sequence.

So my specific question is, can anybody assure me that XyWrite 4 continues with these same policies
(i.e., stripping NULs when files are loaded for editing, and avoiding NULs in ANY 3 byte encoding
the XyWrite generates. I am especially interested in that question as pertains to XyWrite 4's new
0FEh triggered encodings which are intended to support the encoding of more that the 256 characters
that appear in a normal code page, and which didn't exist is XyWrite 3. I looked at the 0FEh
encodings more than 20 years ago, when XyWrite 4 came out, and my (weak) recollection is that
XyWrite 4 did NOT take steps to avoid the use of NUL bytes in the 0FEh triggered escape sequences.
IF that recollection is correct, it seems that XyWrite 4 must have changed some of the policies that
were present in XyWrite 3 (i.e., it would no longer be permissible to simply discard all NUL bytes
on file read-in). That is the issue that I would really like to understand.

Results of testing XyWrite 4 to see if it deletes NUL bytes (inserted by editing the file with DEBUG
or another hex editor) would be useful, as would any information on how the 0FEh escape sequences in
XyWrite 4 are actually encoded.

A guess a second question, which is only a matter of curiosity, would be "do the extra
encodings" offered by 0FEh triggered escape sequences actually get used, in practice. I get the
feeling that that mechanism (kludgy as it was) isn't really used, but instead, the problem has been
solved more by allowing users to switch (256 byte) "Code Pages" very easily. Is that
impression correct, and if not, can anyone explain how the 0FEh triggered stuff
"integrates" with the "switch Code Pages at will" capability. (I suppose that
one possibility is that XyWrite 4 still strips out NULs on buffer load, the way that XyWrite 3 does,
except that when XY4 finds a NUL, it checks to see if it is part of a 0FEh triggered sequence, and
preserves NULs in that case only.)


Wally Bass