I started trying out the new binary buffer support. @BPEEK and @BPOKE I see that the length of the value written or read is constrained to be 1, 2, 4, or 8 bytes. Why not 3, 5, 6, and 7? Suppose I want to read a 24-bit quantity. I can do it by reading 32 bits and ANDing it with 0xffffff, but it would be much more convenient to be able just specify 3 bytes. Writing a 24-bit quantity requires two or three writes. It ought to (IMO) require just one. Please consider this for the next version. (For completeness (which I know you probably don't want to bother with, Rex), I would also allow 0 bytes, and the result would always be 0.) (I would have preferred a number of BITS rather than bytes.) @BREAD and @BWRITE There's an offset argument indicating the offset from the current position of the file to be read or written to/from the binary buffer. It would seem that there ought to be another argument to mean from the beginning, current position, or end of the file, like in the @FILEREAD function. Trying to read from any file position not specifyable as an offset from the current position (such as, say, 2 bytes before the EOF) requires a separate @FILESEEK. Alternatively, if one is willing to do the @FILESEEK before a @BREAD or @BWRITE, we could eliminate the offset argument from those calls completely. (I kind of wish I had seen the alpha and early beta versions -- this comment would have been better timed then.) I'm trying to be constructive here. What was implemented is a GREAT improvement. I will use this feature extensively.