


	CHAPTER 7:   HP 95LX System Manager Operation\and Programmer's Guide

===== OVERVIEW =====
 
The System Manager is a layer of control and services that resides between the
operating system (MS-DOS) and the built-in applications on the HP 95LX. In
addition to the built-in applications, the System Manager supports external
applications that conform to the programming conventions discussed in this
chapter. External applications that run under the System Manager will be
called "System-Manager-compliant" applications to differentiate them from
programs that run directly under MS-DOS.

A PC version of the System Manager is also used by the Connectivity Pack so
that System Manager compliant applications can, usually with no or only minor
changes, also run as a component of the Connectivity Pack. 

The System Manager provides two	basic functions:

	* Application control (includes launching and task swapping).

	* Common services for basic user-interface constructs, file I/O,
	  memory management, and system requests.

This chapter provides general information for developing
System-Manager-compliant applications. The information ranges from the general
principals of System-Manager operation to a template for a
System-Manager-compliant application written in C. See chapter 8 for
descriptions of the services available to System-Manager-compliant
applications.

===== SYSTEM MANAGER OPERATION =====

The System Manager reads all keyboard input so that when an application's hot
key is pressed, the System Manager can start that application. When no other
applications are active, the System Manager displays the owner-information
screen (which can be thought of as the default application).

SYSTEM MANAGER EXECUTION
------------------------

The System Manager is the default shell. That is, it is the program that is
started by MS-DOS at boot time and it always remains resident in memory. The
System Manager does NOT process AUTOEXEC.BAT on startup. 

If desired, the shell can be changed to the standard MS-DOS command processor.
This is done by creating a config.sys file containing the command
"SHELL=COMMAND /P" and rebooting. If this is done, the system will boot
directly into MS-DOS, the System Manager will not be running, and the built-in
applications will not be available. The /P parameter causes COMMAND to be a
permanent shell and also causes COMMAND to process any AUTOEXEC.BAT file.

After booting directly into DOS, the System Manager can be invoked by the
command $SYSMGR. There is no way to exit the System Manager, however you can
spawn a DOS shell using the Filer's System command or by running COMMAND.COM
from the Filer.

TASK MANAGEMENT
---------------

First, consider the case where an application is being selected and no
applications are currently active (i.e., the owner-information screen is
showing).

When the System Manager starts an application, it loads the application into
memory, sets up the segment registers, and transfers control to the
application's entry point. For built-in applications (that run from ROM), the
load step involves allocating enough system RAM for the application's data and
copying the initialized data from ROM to RAM. For loading external
applications, the System Manager must also allocate system RAM for the
application's code. In this case, both the code and initialized data are read
from disk into memory.

Once started, an application enters an event loop where it calls the System
Manager m_event or m_nevent function to get the next key stroke or other
event. Once started, an application will be called open until it calls the
System Manager m_fini function, which is normally when the user quits the
application. An open application will be called active if it has control and
inactive if another application has control.

Now, consider the case where an application is being selected but a different
application is currently active. In this case, the System Manager not only
needs to load and launch the new application, but also needs to deactivate the
previous application.

When switching to a new application, the System Manager sends a deactivate
event to the current application, which changes its status from active to
inactive, and then starts the new one. If there is insufficient memory to load
the new application, the System Manager displays a low memory close down
screen and gives the user the chance to terminate one of the open
applications. Once there is sufficent memory, the new application is loaded
and launched, while the data for the previously open applications remain in
memory.

Special handling of the code space is required for external applications. Only
one external application's code is kept in memory at any one time, so if the
new application is an external application and another external application is
open, this code space (after possible expansion) is reused for the code of the
new external application.

*************
* NOTE !!!! *
*************
Whenever there is an external application open, the external
application code space is NOT reduced in size because there must always be
enough code space to restart any of the open (but inactive) external
applications.
*************
* NOTE !!!! *
*************

MEMORY MANAGEMENT
-----------------

The System Manager is responsible for efficiently managing memory for
System-Manager-compliant applications. 

For example, to prevent memory fragmentation, an inactive application's data
space may be moved in memory as other applications are launched and exited.
This means that applications should not save the DS value in memory unless
the application is prepared to modify the DS value in case its data segment has
been moved. 

As another example, the code space is overlaid for all external applications.
This means that the code for an inactive external application will not be in
memory if any other external application has been subsequently activated. This
implies that variable data should not be stored in the code segment. 

TSRs, INTERRUPT VECTORS, AND THE SYSTEM MANAGER
-----------------------------------------------

TSRs are DOS programs that terminate but stay resident in memory. There are
two ways that DOS can be accessed on the HP 95LX. One way is to change 
the DOS shell from $SYSMGR to COMMAND as mentioned above. The other way 
is to run a DOS command	from the Filer or from the DOS command line 
accessed via the Filer's System	function. Thus, there are two environments
in which to run TSRs.

Running TSRs from the Filer has two drawbacks. One is memory fragmentation due
to the hole left by COMMAND's data when the TSR terminates. This memory may or
may not be usable by the System Manager. A more important drawback is that the
System Manager may not be able to run an external application, after a TSR has
been installed from the Filer. This is because the System Manager needs to
expand a memory block in order to load the external application's code and the
TSR may block this expansion. 

Consequently, we generally recommend that TSRs be run BEFORE starting the
System Manager. The TSRs can be started from an AUTOEXEC.BAT file which, if
terminated with the $SYSMGR command, will start the System Manager. This
technique permanently ties up memory for COMMAND's data; but, since this is
below the System Manager, it does not cause memory fragmentation.

TSR's usually make use of some interrupt vectors. The System Manager takes
over some interrupt vectors without "chaining" onto the previous owner. This
means that a TSR that is loaded first may not get control when it expects to
if the System Manager has taken the TSR's interrupt. Thus, it is necessary
to know which interrupts are used by the System Manager. 

The interrupts taken by the System Manager are:

   Int 05h  Print screen.
   Int 06h  HP 95LX specific BIOS service used to signal entering and
            leaving sleep modes.
   Int 0Ch  COM1 serial port interrupts.
   Int 1Bh  Ctrl-Break interrupt. The System Manager saves the original
            value and restores it before accessing DOS from the Filer.
   Int 4Ah  User alarm. Called by BIOS when real-time clock alarm goes off.
   Int 60h  Used for calls to System Manager services.
   Int 61h  Used by the System Manager to load its DS register.

In addition, the System Manager chains into Int 1Ch, the user timer tick
interrupt.

Finally, INT 62H is used by the HP 95LX's Calculator application. 

===== EXTERNAL APPLICATION SUPPORT =====

The System Manager supports adding external applications via entries in an
APNAME.LST file. External applications can reside either on the C: drive
or on a plug-in card. External applications have the file name extension EXM
that distinguishes them from DOS applications that typically have the EXE
extension.

The creation of EXM files is discussed in "Building Applications" below.

The total number of external applications, including those on the C: drive and
the plug-in card, is limited to eight. 

THE APNAME.LST FILE
-------------------

Each record in APNAME.LST contains registration information on one external
application. The format of each record is:

	FILESPEC, HOTKEY, NAME(carriage return)

where

	FILESPEC is the complete drive, path, and file name of the executable
	file for the application. Note that the FILESPEC must not be longer
	than 28 characters.

	HOTKEY is the four hex digits of the scan/ASCII code for the
	application's hotkey. Refer to the Int 09h section in chapter 5 for a
	table of scan/ASCII codes. Char modified keys cannot be used for hot
	keys.

	NAME is the application name that will be displayed in the System
	Manager low memory close out screen. NAME can be up to 12
	characters long.

APPLICATIONS ON THE C: DRIVE
----------------------------

At startup, the System Manager checks for the presence of the file
C:\_DAT\APNAME.LST. If the file exists, the applications listed in it are
added to the System Manager task table as external applications.

This provides the opportunity to register applications that reside on the
C: drive. All entries in C:\_DAT\APNAME.LST should start with C:.

APPLICATIONS ON A PLUG-IN CARD
------------------------------

The System Manager contains support for automatic registration of external
applications that reside on a plug-in card. The general situation is that
when a card is inserted, the System Manager checks for the presence of the 
file A:\APNAME.LST. If the file is found, its entries are added to the System
Manager task table as (possibly additional) external applications. 
Likewise, when the card is removed, the entries are
removed from the task table. However, there are special situations that can
occur if a plug-in card application is "missing" due to its card being 
removed	while while the application was open.

Suppose a card containing an open external application is removed. In this
case, the System Manager will not remove the card's applications from the task
table and will refuse to register any applications from other cards that 
might be inserted. 

Should reloading the missing application's code become necessary, 
an error condition exists since the code cannot be found.
Reloading would be necessary, for example, if a second
external application residing on the C: drive is run and then the missing
application's hot key is pressed. 

A distinctive beep is issued to signify various "missing application" 
conditions as follows:

	* When any card is inserted. If this card is the missing application's
	  card, then that application is again available for use. If this is a
	  different card, then the beep is a warning that there is an open
	  application from a previous card and that any applications that might
	  be on this card have not been registered.

	* When the hot key for a missing application is pressed. 

	* When other applications are exited causing the missing application to
	  become the current application. In this case, the missing application
	  will be skipped, allowing the next application on the stack to be
	  restarted. In addition, the missing application will be hidden on the
	  active task list so that it will be skipped in the future.

	* When the application is selected from the low-memory close down menu.
	  In this case, the application will remain on the menu, but it cannot
	  be closed down until its card is plugged in again.


===== ACCESS TO SERVICES =====

ACCESSING SERVICES FROM THE C PROGRAMMING LANGUAGE
--------------------------------------------------

C-language applications access services by calling the functions as listed in
chapter 8.

Each source file containing services calls must include the header
file INTERFAC.H which contains macro definitions for each service. The
macro expands the call to be a call to a common System Service request
function. In addition, the macro adds a service number to the argument list
and casts near pointers to far pointers as appropriate.

For example, the m_disp call in the source

	#include "interfac.h"

	int row,col,style,ostyle;
	char *str;
	...
	m_disp(x,y,str,strlen(str),style,ostyle); 


expands to

	c_service(F_M_DISP,x,y,(void far *)str,strlen(str),style,ostyle);

where

	F_M_DISP is the function code for m_disp and is defined in INTERFAC.H.

The function c_service() is provided in the object module csvc.obj and
converts the call into a software interrupt that transfers control to the
System Manager dispatch table.

ACCESSING SERVICES FROM ASSEMBLER
---------------------------------

Assembler programs access the services by pushing any required arguments on
the stack and then using the SMCALL macro to "call" the service. The required
arguments can be found in chapter 8.

For example, usage of m_disp might appear as:

	include interfac.mac
	...
	push   dx         ; ostyle (not actually used)
	push   dx         ; style
	push   cx         ; string length
	push   ds         ; string segment
	push   si         ; string offset
	push   ax         ; column
	push   bx         ; row

	SMCALL F_M_DISP   ; display the string

	add    sp,14      ; remove arguments from stack


There are three things to note in this example:

	* The arguments	are pushed in left to right order as is done by the C
	  compiler.

	* Pointers are passed as far pointers. See INTERFAC.H for argument
	  specifics where, in general, pointers are cast as far pointers.

	* The function numbers such as F_M_DISP and the SMCALL macro can be
	  found in INTERFAC.MAC.


===== APPLICATION CONSIDERATIONS =====

RAM VERSUS XIP EXECUTION
------------------------

RAM execution refers to having the application code load into RAM at run time.
XIP (eXecute In Place) refers to having the application code run directly from
ROM. All the built-in applications are XIP while external applications can be
either strictly RAM or a combination of RAM and XIP.

The System Manager does not directly support external XIP applications. That
is, the System Manager loads both the code and data for EXM files into RAM.
However, an EXM program can in turn use the XIP services provided in Int 63h
to launch an XIP program. In this senario, the EXM program acts as a loader
for the XIP portion of the program. 

Since the XIP loader is a small amount of code, an application done as XIP
will require less RAM for execution than if it was done as RAM-executable.
However, the card containing an XIP application must not be removed while that
application is active. Doing so will force a system warm start.

APPLICATION INITIALIZATION AND TERMINATION
------------------------------------------

All System Manager applications must call the System Manager functions
m_init() and m_fini() on startup and termination, respectively.

*************
* NOTE !!!! *
*************
m_fini() never returns and hence plays a role analogous to the DOS terminate
process function.
*************
* NOTE !!!! *
*************

EVENT HANDLING
--------------

The System Manager implements non-preemptive multitasking for
System-Manager-compliant applications. Hence, compliant applications are event
driven and must make timely calls to the m_event() or m_nevent() function
to receive keyboard input and other events.

Ths System Manager reports key strokes for normal keys, but reports a
deactivate event when another application's hot key is pressed. In response to
a deactivate event, the application is expected to do any necessary
housekeeping to prepare for suspension and then request the next event. The
next event, which will be an activate event, will not be returned until this
application is activated again. Activation can occur for several reasons; for
example, the application's hot key is pressed, all subsequently activated
applications are quit, or the application has been selected for termination
from the low memory close out menu.

In response to an activate event, the application must redraw its screen. For
RAM efficiency, it is recommended that applications have a means of
redisplaying the screen from primary data, rather than by saving a copy of
display memory.

The System Manager may also return a termination event at any time. The
application is required to respond to this as if the user issued a quit
command, with any user-interface variations needed to make clear what is
happening. For example, if an editor is being terminated and its buffer has
been modified, the user should be prompted to save the file.

If possible, when an application terminates, it should save its state
information in a file. When it is subsequently relaunched, it can inspect the
file and reconstruct its state prior to termination. 

The example at the end of this chapter shows the code for a typical event loop.

INTERRUPTIBLE PROCESSES
-----------------------

An "interruptible process" within a program is one which the user can 
interrupt by pressing a key. An example of an interruptible process is
function plotting in the built-in calculator application.

During an interruptible process, the program must periodically check
the keyboard to see if the user has requested interruption. The
HP 95LX BIOS uses keyboard checks as an occasion to go into light sleep.
This is done as a power saving feature and is only done when running on
batteries. In many cases keyboard checks are only done when a program is
otherwise idle. In these cases going into light sleep does not affect
performance and is an effective way to conserve batteries. However, during
an interruptible process, going to light sleep can substantially slow down 
the process.

The BIOS provides a service (Int 15h, function 4Eh) which controls whether
light sleep will be entered during a key test. This function should be
used to disable going to light sleep during an interruptible process and
then to reenable going to light sleep after the process is complete. Care
must be taken to be sure and reenable light sleep for power conservation
reasons.  The code fragment below shows an interruptible process which
can be terminated by the ESC key or by Cntl-Break. Included are routines 
which disable and enable going to light sleep during a key press.


/*-----------------------------------------------------------------------*/

   m_lock();    /* disable task swapping and thus ensure that we
                   cannot exit without getting a chance to reenable
                   light sleep */
   disable_light_sleep();
   while (1) {
      /* one iteration of interruptible process goes here */
      ...
      /* check for key */
      m_nevent(&appevent);
      if (appevent.kind == E_BREAK)
         break;
      if (appevent.kind == E_KEY) {
         m_event(&appevent);
         if (appevent.data == ESCkey)
            break;
         else
            m_beep();
         }
      }
   enable_light_sleep();
   m_unlock();	/* reenable task swapping */

/*-----------------------------------------------------------------------*/

void disable_light_sleep(void)
{
_asm {
        mov     ax,4e00h
        int     15h
     }
}

/*-----------------------------------------------------------------------*/

void enable_light_sleep(void)
{
_asm {
        mov     ax,4e01h
        int     15h
     }
}

/*-----------------------------------------------------------------------*/


USING STANDARD C LIBRARY FUNCTIONS
----------------------------------
Our general recommendation is: If the System Manager provides a given
service, that service should be used instead of using a C-library function.
This ensures compatability and reduces the application's code size.

SOME SPECIFIC POINTS TO NOTE ARE:

	* Keyboard input must be obtained only by the use of the System
	  Manager m_event() or m_nevent() functions.

	* Dynamic memory allocations must be done only by the use of the System
	  Manager m_alloc() or m_alloc_large() functions, or by using DOS
	  services directly. Standard C library memory management functions
	  should not be used.

	* Elementary C Library routines such as strlen() and atoi() can be used.

	* System Manager file I/O uses a FILE structure that is not compatible
	  with the FILE structure defined in Microsoft C's STDIO.H. Use care
	  with including STDIO.H and, in particular, don't include both
	  FILEIO.H and STDIO.H in the same module.

	* The standard C library startup code is not used with
	  System-Manager-compliant applications. This may affect the use of
	  some types of C Library functions.


USING DOS AND BIOS SERVICES DIRECTLY
------------------------------------

Our general recommendation is: If the System Manager provides a given service,
it should be used instead of going directly to a DOS or BIOS function. This
insures compatibility and also reduces the application's code size. In
particular, keyboard input must be obtained only by the use of the System
Manager m_event() or m_nevent() functions.


MEMORY MODEL CONVENTIONS
------------------------

External System-Manager-compliant applications must be small model
programs.

Specifically,

	* Less than 64 KB of code.

	* Less than 64 KB of preallocated data including the stack.

If larger code is required, the program MUST be made Execute-In-Place (XIP).

Additional data space, up to available memory, can be dynamically allocated
using the System Manager m_alloc() or m_alloc_large() functions.

DATA POINTER CONSIDERATIONS
---------------------------

As mentioned previously, the System Manager may move an application's data
space under certain circumstances and in particular when an application is
inactive. If only DS relative NEAR pointers are used, then this is not a
problem since the System Manager will set up DS properly prior to activating
the application. If FAR data pointers are used, then the application needs to
fix these pointers each time the System Manager moves its data segment.

STARTUP CONSIDERATIONS
----------------------

The special C-language program-startup situations for System-Manager-compliant
applications are:

	* Applications must link with a special version of the C-language
	  startup code, CRT0.OBJ. This version is needed because the System
	  Manager launch mechanism has already performed the tasks performed by
	  the normal C-language startup code.

	* The command-line and environment variables, argc, argv, and envp, are
	  NOT available.


COMPILING AND LINKING CONVENTIONS
---------------------------------

Three rules must be followed when compiling and linking
System-Manager-compliant applications:

	* Applications must be compiled with the /Gs option to eliminate stack
	  checking.

	* There must be at least 256 bytes of application stack space available
	  for System Manager use whenever a System Manager service is called.

	* Applications must link with the System Manager services interface
	  module, CSVC.OBJ. This module contains the c_service function that
	  performs the software interrupt to transfer control to the System
	  Manager services jump table.

===== BUILDING APPLICATIONS =====

DEVELOPMENT TOOLS
-----------------

COMPILERS, ASSEMBLERS, AND LINKERS

We recommend that System-Manager-compliant applications be built using
Microsoft's C 5.1 (or later version) compiler or the Microsoft 5.1 (or later
version) assembler. The recommended linker is the Microsoft linker which is
compatible with your compiler and assembler. The output from these tools
is an EXE file.

EXE to EXM UTILITY

A utility program, E2M, is provided to convert the EXE file produced 
by the linker to an EXM program that can be loaded by the System Manager. 
See the	example below.

CHECKOUT USING TKERNEL

TKERNEL is a DOS TSR version of the System Manager that runs on a standard PC.
While there are limitations, extensive development can be done on many
applications using TKERNEL. When applicable, TKERNEL provides the fastest
checkout and debugging environment for System Manager compliant applications. 

TKERNEL takes over Int 60h and processes System-Manager-function calls in a
manner very similar to that on an actual HP 95LX. The HP 95LX 
screen will be simulated by a 40 character by 16-line region in the center 
of the PC screen.

Some special aspects of using TKERNEL are:

	* When using TKERNEL, your application runs as a standard DOS
	  application and a standard debugger can usually be used. 

	* Task switching and other interactions among applications cannot be
	  tested because only one task runs at a time under TKERNEL.

	* Since the HP 95LX's MENU key is not on a PC keyboard, some other key
	  must be used. It is suggested that your application respond to both
	  the F11 key (scan/ASCII code = 0x8500) and the MENU key in the same
	  way.  This enables the F11 key to be used as the MENU key under
	  TKERNEL.  To enable this to work on PC's which don't have an F11 key,
	  TKERNEL converts Alt-F10 to the F11 key code so either F11 or Alt-F10
	  can be used as the MENU key.

GRAPHICS CHECKOUT USING TSRGRAPH

In a manner analogous to TKERNEL, TSRGRAPH.COM is a DOS TSR which provides
access to the HP 95LX's graphics routines on a PC. TSRGRAPH can be installed
either before or after TKERNEL.  Successive executions of TSRGRAPH switch
between installing it and deinstalling it.

EXAMPLE

SIMPLE SYSTEM MANAGER PROGRAM

The following listing is a template for a System-Manager-compliant application.

/*
 * SMHELLO.C - Small example of a System Manager compliant program.
*/

#define	 TRUE	1
#define	 FALSE	0

#include "..\headers\interfac.h"
#include "..\headers\event.h"

/* function prototypes */

void app_init(void);
void app_term(void);
void app_awake(void);
void app_sleep(void);
void app_break(void);
int app_key(void);
void app_display(char *msg);

/* global variables */
EVENT appevent;

/*-----------------------------------------------------------------------*/
void main(void)
{
   int done = FALSE;

   m_init();		/* init call to system manager */
   app_init();		/* application initialization */

                	/* event loop */
   do {
      m_event(&appevent);           /* get next event */
      switch (appevent.kind) {
         case E_ACTIV:
            app_awake();           /* reactivate app */
            break;
         case E_DEACT:
            app_sleep();           /* prepare for suspension */
            break;
         case E_TERM:
            done = TRUE;           /* being terminated */
            break;
         case E_BREAK:
            app_break();           /* app ctrl-break handler */
            break;
         case E_KEY:
            done = app_key();      /* process key */
            break;
         }
      }
   while (!done);

   app_term();          /* application termination */
   m_fini();            /* terminate call to system manager, never returns */
}
/*-----------------------------------------------------------------------*/
void app_init(void)
/*
 * Initialize application
*/
{
   app_display("app_init");
}
/*-----------------------------------------------------------------------*/
void app_term(void)
/*
 * Terminate application
*/
{
}
/*-----------------------------------------------------------------------*/
void app_awake(void)
/*
 * Reactivates application after suspension.
*/
{
   app_display("app_awake");
}
/*-----------------------------------------------------------------------*/
void app_display(char *msg)
{
   char usage_str[] = "press q to exit ...";

   m_setmode(1);        /* set text mode */
   drawbox("SM Hello");

   m_disp(1,5,msg,strlen(msg),0,0);
   m_disp(3,5,usage_str,strlen(usage_str),1,0);
}
/*-----------------------------------------------------------------------*/
void app_sleep(void)
/*
 * Prepares application for suspension.
*/
{
}
/*-----------------------------------------------------------------------*/
void app_break(void)
/*
 * Application control-break handler.
*/
{
}
/*-----------------------------------------------------------------------*/
int app_key(void)
/*
 * Application keystroke processor.
 *
 * Returns TRUE if user has requested termination, else returns FALSE.
*/
{
   if (appevent.data == 'q') {
      return TRUE;
      }
   else {
      m_beep();            /* signal error */
      return FALSE;
      }
}
/*-----------------------------------------------------------------------*/

MAKE FILE FOR BUILDING EXE AND EXM FILES

Below is an NMAKE make file that will build both a TKERNEL and an HP 95LX
version of the example program. The TKERNEL version is called
SMHELLO.EXE and the HP 95LX version is called SMHELLO.EXM.

This file as well as object modules CSVC.OBJ and CRT0.OBJ are provided
in the developer's kit.

all: smhello.exe smhello.exm

# HP 95LX version

smhello.exm: jsmhello.exe
        ..\tools\e2m jsmhello
        copy jsmhello.exm smhello.exm
        del jsmhello.exm

jsmhello.exe: jsmhello.obj
        link @<<jsmhello.lnk
/M /NOE /NOI jsmhello.obj+..\tools\csvc.obj+..\tools\crt0.obj
jsmhello.exe
jsmhello.map;
<<NOKEEP

jsmhello.obj: smhello.c
        cl /c /AS /Gs /Fojsmhello.obj smhello.c

# TKERNEL version

smhello.exe: smhello.obj
        link @<<smhello.lnk
/M /NOE /NOI smhello.obj+..\tools\csvc.obj
smhello.exe
smhello.map;
<<NOKEEP

smhello.obj: smhello.c
        cl /c /AS /Fosmhello.obj smhello.c


RUNNING SMHELLO UNDER TKERNEL

To run SMHELLO under TKERNEL, use the commands

	TKERNEL
	smhello

If TKERNEL is executed when TKERNEL is already loaded, you are asked if you
want to uninstall it.

If desired, the smhello command can be replaced with a command which
runs smhello.exe from a debugger.

RUNNING SMHELLO ON THE HP 95LX

Download SMHELLO.EXM to the root directory of the C: drive on the HP 95LX
and using Memo, create or modify the file C:\_DAT\APNAME.LST to include the
line C:\SMHELLO.EXM,C300,SMHello

Now reboot the system.

At this point, the hot key Alt-CALC is assigned to the SMHELLO program.
