The masqueraded files begins with a footer. It is accessible by reading the last 4 bytes of the file which are the size of the footer (excluding these four bytes). The footer then occupies the bytes immediately before this length record. The last byte of the footer is the fifth byte before the end of the file.
This footer says that the file is masqueraded and where the platform specific content of the file are located in the masqueraded file. Also there is a magic number that says which platform the file is for. The format of the footer is platform specific but the beginning of the footer has always the same meaning and for most platforms there is only a list of fixed size containing the lengths of the platform specific binary contents. These contents are stored starting from the beginning of the file and without any paddings. If the platform imposes some alignment restrictions for the structures in these contents, these alignment restrictions must be satisfied relative to the beginning of the content chunk, not the beginning of the whole file. The file must not contain anything else than the contents and the footer in order to be valid.
The mandatory portion of the footer has 12 bytes. The first 4 bytes contain a magic number, which identifies the platform for which the file is valid. The remaining 8 bytes contain the name of the library. If the name is shorter than 8 characters, it is padded with zero bytes. A library name cannot be longer than 8 characters. This name is used to identify the library in the memory.
After this mandatory portion comes the platform specific data and the length of the footer located at the very end of the file. The platform specific data has fixed length for a particular platform and typically contains the list of sizes of various platform specific chunks in the file.
The reason behind this strange layout of the file is that the content of the file can be more easily tailored to enhance the direct interoperability with the platform specific tools.
For example a .rtl file under GNU/Linux is composed of two datablocks. The first datablock is the shared library (.so file) and the second one is the static library (.a file). The shared library portion is the one placed at the beginning of the file. In it there is a section record named "OSHS.supp.info" which covers the static version of the library and the footer. The result is a file that behaves like a normal GNU/Linux shared object so it can be directly used for linking. The footer here says in the first four bytes that the platform is Linux on a 32 bit machine, the next eight bytes are the name of the library, then comes four zero bytes (no program portion of the library), four bytes with the length of the shared library portion and finally four bytes stating the length of the static library in the file.
There also is a portion of the directory tree which is made invisible to the OSHS software. This portion of the directory tree contains the platform specific binaries extracted from the masqueraded files. Also some control files are stored there; these control files are used to control the synchronization between the OSHS filesystem visible from OSHS software and this special directory tree.
The binaries are manipulated using the COMPILE and LINK utilities. These utilities are pseudoexecutables, which are accessed by passing @:/compile and @:/link to the execution server respectively. The COMPILE utility is used to compile the source code and the LINK is used to link the resulting relocatable modules to produce a binary or a library. These utility extract the platform specific portions from the input files to a temporary workspace located in the special internal OSHS tree so the platform specific binutils can pick up the data in the format they like. After the platform's binutils complete their duties the LIBTOOL picks up the results and assembles their content to the output files.
Program binaries are manipulated similarly. The emulated execution server extracts the platform specific content of the binary and executes the file with this platform specific portion rather than the executable specified by the user.
The library memory from the OSHS librarian subsystem is emulated by a subdirectory of the internal OSHS directory. The execution server places there platform specific dynamic portions of the libraries when it obtains a request to load a library into memory. When it is requested to unload the library from memory, it deletes the respective platform specific portion from the memory. The name of the file with that platform specific portion is derived from the name of the library (this is not the same as the name of the file with the library; the name of the library is stored in the file).