VR for Legacy Apps

Today Virtual Reality fails to fool many people; it is for fun and illumination. Keykos has a version of VR suitable to fool compilers, editors, display managers and many other useful programs from legacy systems. Few legacy programs have the imagination to look about for things that do not concern them. Those that do see a few nearly empty directories and no Internet service. A C compiler will find the tree of header files where it expects them.

The illusion goes both ways; the system appears conventional to the imported legacy application, while the application shows up as a native cap oriented citizen.

The insight illustrated here is that one can experiment with functionality normally restricted to kernel hackers without endangering other users of the platform you inhabit. You do not impact their security or integrity. This unleashes the power of conventional hardware which was hitherto too dangerous to allow.

Dual Citizenship of Unix Files

The Unix file concept as an array of bytes closely matches the Keykos concept of a segment with the same bytes which are mapped into memory in Keykos just as with Unix mmap or earlier as in Multics. Such information collections exist comfortably with dual citizenship: Linux and Keykos.

No Root Node

We parted ways with Unix when it came to the directory structure. Keykos has objects which, a bit like Unix, map ASCII strings to capabilities, including caps to other directories, but Keykos has no global root, except perhaps a local simulacrum to fool some Unix program that thinks it is god. There are also objects that each own a directory and that understand the Unix pathname conventions with slashes, “/” but not “..”. Native cap programs pass capabilities, not pathnames, between themselves.

After several months of this development, it was seldom more than an afternoon’s job to adapt one of the many useful Unix utilities. This seldom required recompilation. The 370 Keykos stole applications and utilities from IBM’s CMS world, without access to the sources. (Most of those had been taken by IBM, unmodified, from other even more conventional IBM systems. You might say that this IBM pattern inspired us.)

Domain Keeper

The Keykos feature that is central to this pretense is the domain keeper which gets control when a domain, executing a Unix app, encounters a system call or other action which would invoke the Unix kernel. The domain keeper finds itself in control with just the authority, via capabilities, to do what the Unix kernel would do for (or to) this program. The keeper has no other authority. Each domain has its own keeper with the authority to do kernel like things to that one domain. Domains that obey code written for other platforms have a domain keeper with modified behavior. In each case the result is a foreign program masquerading as a native, with its original functionality available via capabilities.

The domain keeper is in the integrity reliance set of the domain it keeps; it is in no other domain’s reliance set except as the other’s security relied on the correct function of keeper’s client. This is in drastic contrast to the Unix situation. A domain that executed legacy code seldom holds any capabilities unless some attempt has been made to teach it some cap tricks. There were very few such hybrids.

I recommend the general strategy of creating a native creator of native objects for each of the many useful legacy apps and tools. The created objects would originate fully adapted to the cap environment. They need not all come from the same legacy OS. With technology such as QEMU they need not even agree on the same ISA. The capability environment becomes a cosmopolitan neighborhood — many emigrants. They all speak cap language, some with an accent.