Am 09.06.2017 um 19:56 schrieb Kenneth:

> (A little side note: I can actually open the help file--in its entirety-- in
> Windoze Wordpad. The contents are meaningless of course, mostly symbols. But It
> doesn't open likewise in POV-Ray-- just one little 'word.' I thought POV was
> robust enough to open and display just about any 'programming language.' But
> then again, I'm somewhat naive about 'compiled' languages ('somewhat'?? That's
> an understatement!!) ;-)

The help file is a binary file.

Most "compiled" stuff is binary files.

A binary file may contain arbitrary sequences of arbitrary bytes, from 0
to 255 (hexadecimal 00 to FF).

Most notably, a binary file may contain byte value 0 (hexadecimal 00)
anywhere in the file.


The vast majority of programming languages is based on plain ASCII text
files.

A canonical ASCII text file may contain only bytes that represent
_printable_ ASCII characters (32 to 126 = hexadecimal 20 to 7E), as well
as a few select control characters (horizontal tabulator, line feed,
carriage return, end of file = 9, 10, 13, 26 = hexadecimal 09, 0A, 0D, 1A).

Most notably, an ASCII text file must _never_ contain byte value 0
(hexadecimal 00) _anywhere_ in the file.


When a program handles text, it needs to keep track of where the text
ends. One obvious way to do this is to store the length in a separate
numerical data field, but this has the drawback of potentially wasting a
lot of memory if you're working with lots of small yet occasionally
large pieces of text: Unless you want to restrict yourself to at most
255 characters per piece of text, you need to set aside at least 2 extra
bytes per piece of text for that length data field; and if your text
pieces may potentially exceed 65535 characters, you'll need 4 extra
bytes for the length data field.

A more compact scheme is to not store the length of the text, but rather
mark its end with a special pseudo-character; this only requires 1 extra
byte per piece of text (presuming the text uses byte encoding such as
ASCII, or byte-based variable-length encoding such as UTF8). Commonly,
the byte value hex 00 is used as this end-of-string marker, in which
case this scheme is referred to as "null-terminated strings".

Virtually all text editors can cope with files containing arbitrary
characters from the range 1 to 255 (hexadecimal 01 to FF), at least to
some degree; but text editors that happen to use null-terminated strings
to store the lines of text may screw up on any files containing the byte
value hex 00.


The text editor module in POV-Ray for Windows presumably suffers from
this null-terminated-string ailment, while the Windows Wordpad
apparently does not. Whether it is because Wordpad does not use
null-terminated strings, or because it immediately replaces any hex 00
byte value with a placeholder upon loading, I can't tell.

Post a reply to this message