Figure 2-1To begin the discussion of supporting guest application environments, the first questions one might ask are: What is the application? and, What is the application environment?
For applications written in High Level Languages, the application is usually considered to be restricted to the code written in that language. The environment which supports the compiled version of that code usually consists of two parts. The first part is provided by the run time library that accompanies the compiler and consists of a set of subroutines that perform functions ranging from string comparison to file access. The second part is provided by the operating system that supports the application and consists of system service routines that range from memory management to I/O support for files.
It is usually possible to divide the runtime library routines into two sets of routines. The first set is very language specific and can be included as part of the application. The second set is system specific and can be included as part of the operating system. This separation of the library routines makes it possible to consider two places to define the dividing line between the application and the application environment.
The first dividing line lies within the runtime library. The environment emulator can consist of a set of subroutines that replace the system specific subroutines in the library with equivalent subroutines that provide the same function. These replacement subroutines would interface with the native KeyTECH environment (objects and capabilities) to provide the required function.
The second dividing line lies between the runtime library and the operating system. In this case, the entire runtime library is left unchanged and is considered part of the application. Only the specific system services are emulated, using the native KeyTECH functions.
There are merits in providing emulation at either of the two dividing lines. For the remainder of this document, we will call the dividing line within the runtime library the Application Interface and the dividing line at the boundary between the runtime library and the operating system the System Interface.
Some languages have library routines that are not documented since they are used totally within the runtime library. When these routines interface with the operating system, it is often easier to emulate the system function than to determine the specifications of the library routine. For this and other reasons, emulation often involves a "hybrid" approach of both the Application and System interfaces.
The runtime library for most high level languages is usually well documented, and many of the routines deal only with language specific support. Routines that deal with system support, such as Open File or Allocate Memory, are the only routines that need to be replaced. The replacement routines usually involve a small amount of code that runs as part of the application. The replacement routines use KeyTECH functions to supply the facilities normally supplied by the application's native environment.
However, because the semantics of the KeyTECH functions may differ in subtle ways from those of the native environment, there may be small incompatibilities between the real and emulated environments. These incompatibilities show up when the runtime library or the application has special knowledge about how the native environment works and exploits this knowledge to alter the behavior of the system functions in ways not possible when using the documented interfaces.
Figure 2-1
If the application interface approach is acceptable, the substitute run time library routines replace routines with the same name in the application run time library. This replacement can take place when the application is bound to the library prior to execution.
When the application is known to depend heavily on the internal behavior of the native system, or when the semantics of the real environment differ significantly from those of KeyTECH, it becomes necessary to use the run time library unaltered and to emulate the system interfaces directly.
These system interfaces are not always as well documented as the library routines that invoke them since they are not usually used by application programmers. However, the interfaces usually involve a transition from non-privileged to privileged state. This provides an easily identified place to intercept the system function and provide a replacement.
Figure 2-2
Occasionally, the actual code of the native system may need to be consulted to determine the exact behavior of the system function. Once this behavior is understood, it must be replicated or replaced by equivalent function using KeyTECH primitives. The replacement is similar to a transformation of one set of semantic rules into another and often involves more code than providing similar function at the application interface.
Once the system interface has been provided, it is usually easy for the emulated environment to support the subtle dependencies on the native environment because the behavior of the native environment is more closely replicated.
Many runtime routines that support High Level Languages depend on detailed behavior of the native system which dictates an approach that emulates the System Interface. However, most of the data access methods are actually part of the application runtime library.
In such a "hybrid" case, a guest environment consists of both a System Interface emulator and a set of routines that replace runtime library routines that are part of the Application Interface. This approach allows the accurate emulation of the native system behavior but shortcuts much of the work, because many areas of the native system whose behavior does not show through to the application are replaced by much simpler runtime routines.
Figure 2-3
The KeyRMVS product, which emulates the MVS application environment, is an example of the hybrid approach.
In MVS, the system interface includes operations on files such as OPEN and CLOSE, while the data transfer operations of GET and PUT are done by application called runtime routines, which themselves use lower level system routines to do the actual I/O.
KeyRMVS emulates the System Interface of OPEN and CLOSE because there is no other place to intercept these functions. However, once a file is opened, it is possible to intercept GET and PUT before the system interface of EXCP (actual disk I/O) is reached.