Built-in applications are launched by a special service similar to DOS's normal exec service which allows the ROM-based applications to execute in place. The ROM space contains in a fixed location a map for the entire ROM space. Each application has an entry which details the location and length of the applications code and data and the bank of system memory from which it may execute if a ROM app, or the EXM's file path if a RAM app.
When the appropriate triggering event occurs (when the application key is pressed in the HP palmtop), the System Manager reads the map entry for the values specific to the application. First, the System Manager must allocate memory for the applications data. It first requests the memory from DOS using conventional DOS services. If that fails and if 1-2-3 is resident, a request is made to 1-2-3 to shrink by the appropriate amount. If that also fails to provide enough memory, suspended applications are terminated until enough memory is released.
Once sufficient RAM is claimed, the application's initialized data is copied either from ROM or the executable file into the block of system memory just allocated for that application. Memory to be used as uninitialized data is zeroed.
For a ROM application, the area of ROM containing the application code is then mapped into the appropriate bank of system memory. For a RAM application, the situation is more complex. All RAM applications execute starting at the same code address--the lowest memory address available to the System Manager. This is right after the static RAM; static RAM is set by the user for special TSR's or other fixed-memory uses in the System Manager. A DOS box also needs to be loaded at this address. If there is nothing else open, the System Manager is free to use that low space to load the RAM app's code. If another application's data segment occupies the lowest S.M. memory, the System Manager must move that data segment out of the way. If another RAM app occupies that memory, its code segment is discarded (if needed later, that RAM app's code segment is reloaded from disk). Finally, if a DOS box occupies that memory, a portion of the DOS box large enough to accommodate the RAM app's code is moved to a higher memory block. The rest of the DOS app stays in low memory. Since the System Manager saves and restores the interrupt table when switching to and from DOS, the System Manager can guarantee no interrupts trapped by the DOS program will enter the now missing portion of the program.
The System Manager then initializes the CPU registers to the appropriate initial values and transfers control via a far call to the applications initial entry point. The initial state of the machine will differ slightly from that expected following a DOS load, as detailed below: