RTEJava

(beta version)

Copyright © 2003-2006 Mark K. Davis. All rights reserved.

Backward-compatibility details

Why does the original utility have this flaw?

The encoding/decoding algorithm used by the original utility makes it impossible to decode a .rte file correctly unless the user has a key file that is identical byte-for-byte to the key file used for encoding.

The Windows, Mac, and *nix platforms use different byte sequences to indicate a line return in a text file.

In some cases where the key file used is a text file (for example, a Wavefront .obj file), the key file used for encoding has a different line return sequence than the key file used for decoding. The original utility will fail to decode the .rte file in such a case.

What is the name of the "original .rte utility"?

The author of that other utility has requested that I refrain from using his name and trademark (that is, the name of his utility).

How important is this flaw?

There are probably a small number of key files that will be problematic. However, the severity of this flaw is related to the popularity of the key files used, not the number of such key files.

One example is the Victoria geometry file blMilWom.obj, as distributed on DAZ3D's "Victoria 2" CD-ROM. The Windows version uses Unix-style (LF) line returns, but the Macintosh version uses Mac-style (CR) line returns. This is the reason that a Mac user cannot decode the Netherworks-Viomar V3 Hybrid character using the original utility in Virtual PC, with the Mac version of blMilWom.obj as the key file.

Another example discovered by Renderosity member MarianneR is the DAZ3D HouseMouse.obj geometry file. The Windows version uses single-spaced DOS/Windows-style (CRLF) line returns, but the Macintosh version uses double-spaced Mac-style (CR CR) line returns.

RTEJava has been designed to handle the different line return sequences. For example, RTEJava can decode the Netherworks-Viomar V3 Hybrid character no matter which version of blMilWom.obj is used.

How does RTEJava compensate for the flaw in the original utility?

RTEJava and the original utility use the same encoding algorithm, but RTEJava uses an improved decoding algorithm that automatically converts the line return sequences used by a text key file, if such conversion is needed.

Here is a description of the new decoding algorithm used by RTEJava:

When the user chooses a key file, the name, length, and CRC are compared to the expected key file name, length and CRC, which are stored in the .rte file header.
  • If all the data matches the expected data, the key is used as-is to decode the .rte file.
  • If the name does not match (but both the length and CRC are correct), the user is allowed to decode, but is warned that the name was unexpected.
  • If the name matches, but either the length or CRC (or both) do not match the expected data, RTEJava attempts to create a "virtual" key file in memory whose data matches the expected data. If RTEJava can create the correct "virtual" key file, the .rte file is decoded using the "virtual" key file. This method does not change the original key file on the user's disk.
    For Java programmers only: No copy of the key file is made either on disk or in memory. The objects that compute the CRC implement java.util.zip.CheckSum, so the update() method can be passed a different line return sequence than the one read from the key file. Likewise, during decoding, a different line return sequence can be inserted into the byte stream as needed.
  • If none of the above work, RTEJava informs the user that the chosen key file cannot be used to decode the .rte file.

Why did you choose this solution?

One alternative was to release a "decode-only" application to allow Mac and *nix users access to existing .rte files. However, any attempt to encode a new .rte file using the original utility in a virtual environment (Virtual PC, VMWare, etc.) could still lead to files that Windows users could not decode with the original utility. There was no compelling reason to deny content creators who work on a Mac or *nix computer from encoding their work on their chosen platform.

A second alternative was to create a new file format, similar to but not identical with the original file format. Either a different version number could be stored internally in .rte files created by RTEJava (so that the original utility would refuse to open those files), or a different extension (.rtj) could be used. This alternative would have been too drastic, as one of the goals of RTEJava was to extend the functionality of the original utility to non-Windows platforms, rather than to replace the original utility.

A third alternative was to "standardize" all key files to match the Windows version by virtualizing the key when encoding a new .rte file. This turns out to be impossible! The table below shows that there is no "standard" line return sequence for some common Poser files on either the Windows or Mac platforms!

                                       line return style
										
        file name          length       Win        Mac 
        ---------          ------     -------    -------

        blMilWom_V3.obj   8617333      Win?        Win

        blMilWom.obj      3150215      Unix        Mac 

        P4NudeWoman.obj   1717405      Mac         Mac 

        blFairy.obj       3491774      Unix        Unix 

        HouseMouse.obj    2130538      Win         Mac (double-spaced) 
For example, blFairy.obj uses Unix-style line returns on both the Win and Mac platforms, while P4NudeWoman.obj uses Mac-style line returns on both platforms.

The solution chosen by the developer is to not change the original .rte format at all, and to allow non-Windows users the opportunity to create encoded .rte files, with a warning at the time that the encoded file is created that these new .rte files may not be compatible with version 1.00 of the original utility.

Is there a way to avoid the effects of this flaw?

Yes. Use RTEJava for all your encoding and decoding, as it was designed to be cross-platform.

But I really, really, REALLY want to use "the original utility"!

The flaw is built into the original utility, but just follow this rule:

If you are encoding using a text key file, use the "Windows" version of that key file.

Be careful to understand what this rule means! Do not convert all your text files to use DOS/Windows style line returns, as many Windows text key files use Unix (or even Mac!) line returns, as shown in the table above. Try to obtain a copy of the exact key file that a Windows user would have installed on her/his computer!

NOTE: There is no need to follow this rule for binary data key files. For example, a JPG image is not a text file, and should not differ across platforms.

For example, a Mac user who runs Virtual PC and uses Poser 4 could install the Windows version of Poser (and any other content) to a shared folder on the Mac's hard drive, then use the files in the shared Windows Runtime folder as key files for encoding.

Likewise, a Linux user on a dual-boot Windows/Linux box could install Poser under Windows, then boot into Linux and mount the Windows partition to access the Windows Runtime as key files for encoding.

Copyright © 2003-2006 Mark K. Davis. All rights reserved.

Hosted by www.Geocities.ws

1