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