Reverse Engineering:

Reverse engineering is a development method that uses information about an existing entity to produce a new entity that has some of the same properties of the existing entity. For example, ARDI has reverse-engineered the Motorola 68LC040 CPU and has also reverse-engineered 1,200 Macintosh Classic Operating System routines. In other words, by using information about the 68LC040 CPU and about the Macintosh Classic Operating System ARDI has produced software that performs enough of the same functions of the CPU and the Operating System to run hundreds of Macintosh programs.

Clean-Room Reverse-Engineering

Reverse-engineered software is said to be Clean-Room Reverse-Engineered if its creators avoid directly examining the software that is emulated. This can be done by using published specifications and test programs. Using clean-room reverse-engineering prevents the developers from including pieces of the software to be emulated in the emulated software. It does not prevent the developers from infringing on patents or infringing on look-and-feel copyrights.

Clean-Room Reverse-Engineering can be a labor intensive methodology. Any behavior that either isn't documented or that is incorrectly documented can cause the developers to write, run and analyze complex tests to determine the true behavior of the system being emulated. Although Apple's Classic Macintosh Operating System is fairly well documented by Apple in the Inside Macintosh series of books, each error and omission has either resulted in an incompatibility in ARDI's software or the expenditure of engineering time searching for better documentation or spent creating new, often esoteric, tests.

Dirty-Room/Clean-Room Reverse-Engineering

Directly examining the thing to be emulated is Dirty-Room Reverse-Engineering. For example, looking at the individual instructions that make up a computer program, even if only to determine specifications that aren't publicly available, is an example of dirty-room reverse engineering.

Dirty-room reverse engineering done by the same engineers who create emulation software runs the risk of deliberate or accidental copyright violations by incorporating portions of the software to be emulated in the emulator. To avoid this risk, dirty-room reverse engineering can be done in conjunction with clean-room reverse engineering by using two physically and electronically isolated teams where one team does dirty-room engineering and the other does clean-room engineering.

In Strictly Clean-Room Reverse Engineering, when it is determined that the specification that the clean-room engineers are working from is insufficient to produce the degree of compatibility desired, the only recourse is to search for additional documentation or to write additional tests. In Dirty-Room/Clean-Room Reverse Engineering, the clean-room engineers write a description of the portion of the specification that needs elaboration or clarification. The dirty-room engineers then use that request to create additional functional specifications. These functional specifications should not reveal the way in which the emulated software was written since such revelations would defeat the purpose of having separate clean-room and dirty-room engineers. One way to prevent such contamination is to disallow direct communication between the clean-room and dirty-room engineers. Instead, all communication between the two teams is passed through an intermediary who enforces protocol. Specifically the intermediary insures that only functional specifications are passed from the dirty-room to the clean-room. Any implementation details coming from the dirty-room are intercepted and prevented from ever being seen by the clean-room.

For complex products, the number of man-hours needed to create an emulation using dirty-room/clean-room reverse engineering may be less than the number of man-hours needed to create an emulation using only clean-room-reverse engineering. This will be so when it is considerably easier for dirty-room engineers to determine hidden specifications, than it is for clean-room engineers to determine the same hidden specifications through the construction and analysis of tests.

Strictly Clean-Room Reverse-Engineering

Strictly Clean-Room Reverse-Engineering is when only a clean-room team is used (i.e. without the use of a dirty-room team). To date, ARDI has used strictly clean-room reverse engineering in constructing its software, even though doing so has been less efficient than using dirty-room/clean-room reverse engineering. The benefit to ARDI of using strictly clean-room techniques is that ARDI has avoided the overhead of having separate dirty-room engineers and an intermediary. The significant drawback has been that ARDI's lower operating system layers are not sufficiently compatible to allow Apple's upper operating system layers to work with them. Such compatibility should be easy to provide using dirty-room/clean-room reverse engineering.

Executor Internals Paper

A paper detailing Executor's internals is available in the following formats. All work described in the paper was done using strictly clean-room techniques with respect to Apple's software.

• Web Page
• PostScript (for printing)
• Rich Text
• Microsoft Word