DEC MICA

The original goal for MICA was that all applications would have full and interchangeable access to both the VMS and ULTRIX interfaces, and that a user could choose to log in to an ULTRIX or VMS environment, and run any MICA application from either environment.[6] However, it proved to be impossible to provide both full ULTRIX and full VMS compatibility to the same application at the same time, and Digital scrapped this plan in favour of having a separate Unix operating system based on OSF/1 (this was variously referred to as PRISM ULTRIX or OZIX).[7] As a result, MICA would have served as a portable implementation of a VMS-like operating system, with compatible implementations of DCL, RMS, Files-11, VAXclusters, and the VAX/VMS RTLs and system services. Proposals were made for reinstating Unix compatibility in MICA on a per-application basis so that a MICA application could be compiled and linked against the VMS interfaces, or the ULTRIX interfaces, but not both simultaneously.[8]

Due to scheduling concerns, the first PRISM systems would have been delivered with restricted subsets of the full MICA operating system. This included systems such as Cheyenne and Glacier which were dedicated to running specific applications, and where direct interaction with the operating system by customers would be limited.[9]

MICA was to be written almost entirely in a high-level programming language named PILLAR. PILLAR evolved from EPascal (the VAXELN-specific dialect of Pascal) via an interim language called the Systems Implementation Language (SIL).[10][11] PILLAR would have been backported to VAX/VMS, allowing applications to be developed that could be compiled for both VAX/VMS and MICA. A common set of high-level runtime libraries named ARUS (Application Runtime Utility Services) would have further facilitated portability between MICA, OSF/1, VAX/VMS and ULTRIX.[12] As part of the PRISM project, a common optimizing compiler backend named GEM was developed (this survived and became the compiler backend for the Alpha and Itanium ports of VMS, as well as Tru64).[13][14]

In addition to PILLAR, Mica provided first-class support for ANSI C in order to support Unix applications.[10] An assembler named SPASM (Simplified PRISM Assembler) was intended for the small amount of assembly code needed for the operating system, and would not have been made generally available in order to dissuade customers from developing non-portable software. Similarly, an implementation of BLISS was developed for internal use only, in order to allow pre-existing VAX/VMS applications to be ported to MICA. MICA would have featured ports or rewrites of many VAX/VMS layered products, including Rdb, VAXset, DECwindows, and most of the compilers available for VAX/VMS.[15]

When PRISM and MICA were cancelled, Dave Cutler left Digital for Microsoft, where he was put in charge of the development of what became known as Windows NT. Cutler's architecture for NT was heavily inspired by many aspects of MICA.[2][16][17] In addition to the implementation of multiple operating system APIs on top of a common kernel (Win32, OS/2 and POSIX in NT's case) MICA and NT shared the separation of the kernel from the executive,[6] the use of an Object Manager as the abstraction for interfacing with operating system data structures,[18] and support for multithreading and symmetric multiprocessing.[4]

After the cancellation of PRISM, Digital began a project to produce a faster VAX implementation which could run VMS and provide comparable performance to its DECstation line of Unix systems.[5] When these attempts failed, the design group concluded that VMS itself could be ported to a PRISM-like architecture. This led to the DEC Alpha architecture, and the Alpha port of VMS.[19]