The trick to efficiently converting binary data to Base64 encoding (required for MIME-encoding attachments) is the fact that the string representation of Progress raw values is Base64-encoded plus a six-byte header. Raw values can be converted to strings by using the STRING function or by exporting the raw value to a file. Strings are automatically converted to raw when you import a raw variable, but unfortunately the built-in RAW function will not do this.
The six-byte header on the encoding of a raw field appears to consist of the characters 02 (zero two) plus the length of the data in hexadecimal (not counting the header).
In Base64 encoding, the upper and lower-case alphabets, the numerals and the symbols / and + (slash and plus) are used to create a 64-character set. To represent three 8-bit bytes requires four of the 6-bit Base64 characters. If the length of the input value is not a multiple of three, the output string has one or two = (equals) characters appended. A valid Base64 encoded string is thus always a multiple of four bytes long.
The two programs, to64.p and from64.p convert arbitrary files to and from Base64 encoding respectively. Because the RAW function doesn't work to convert a string into a raw value, from64.p must read the Base64 file, create a temporary file with the headers and the Base64 data, and then import the raw values from this temprorary file to re-create the originaly binary data. Since a raw *can* be converted to a string, the to64.p program doesn't need to mess around like this.