.tj B
.ad b
.sh "A GUIDE TO WRITING PROGRAMS FOR KSOS"
The purpose of this Appendix is to provide guidance in developing
software to be run on a system using the KSOS operating system.  This
Appendix will provide guidance in developing software in two different
programming languages, C and Modula.

.sh "PROGRAM DEVELOPMENT IN C"
Developing programs in C for KSOS is not unlike developing C programs
for UNIX.  The principal difference is at link/load time, when it is
necessary to link the C object modules with KSOS-specific object
libraries.  A typical 'ld' command line would look as follows:
.nf

ld -i -s crt0.o crt1.o x.o libKIP.a ETH.a ECC.a EEV.a EDI.o 
        libc.a liba.a NKL.a EMT.a

.fi
.sh
where x.o is the program under development.  The specified modules
are normally found in /ksb/lib and provide the C run-time
environment, the Kernel Interface Package (KIP) with UNIX V6 call
compatibility, as well as access to KSOS-specific services.
.sh
There are also KSOS-specific include files which must be included in
all C source files.  At a minimum, the include file "tcb.h"
must be included in the C source file of any program to be run under KSOS.
This file may be enclosed in ifdef's so that it is only included
when compiling for KSOS.  
.sh
The C-Kernel_Interface consists of 38 C routines.  One interface
routine exists per Kernel call.  The interface routines are used in
conjunction with the types defined in the header file KERcalls.h
.s3

The general procedure followed in the interface routines is to put the
arguments of the interface routine into one contiguous block of memory.
Then through an assembly language subroutine, a pointer to the block
with the arguments is passed to the appropriate Kernel call.  Upon
completion, the Kernel call places any return values into the argument
block and returns an exception.  This exception is then passed upward
by the assembly language subroutine.  The interface routine unpacks the
return values from the argument block and returns the exception to the
calling C program.
.s3
The C interface routines are contained in separate files, named K00.c
through Knn.c (where nn indicates the total number of routines minus
one), and are described in section 2 in alphabetical order.  The
assembly language subroutines are contained in files named EMT00.s
through EMTnn.s.  The C routines are archived into one file (NKL.a) and
the assembly subroutines into another (EMT.a).
.sh
The KIP calls described in Section IV of this manual 
allows developers who do not need any other system
calls to develop and test their programs on UNIX and simply recompile
them for KSOS.
.sh "PROGRAM DEVELOPMENT IN MODULA"
At a minimum the following include files are required in any Modula
source file to be run under KSOS: NKcalls.mod, UDdefs.mod, and npi.mod.
These files are found in /ksb/nksr/include. To compile a Modula
program, the following command line is typically used:
.nf

mod -Iindr -N /ksb/nksr/include/NKSRnuc.s xxx.mod

.fi
.sh
The indr file provides a search path for include files not in the same
directory as the file xxx.mod.  The file NKSRnuc.s must be included
before the Modula source file; this file provides Modula run-time
support.  The file xxx.mod is the Modula source file under development.
.sh
Modula interface routines for the Kernel calls are available in the
file NKcalls.mod.  One interface routine exists per Kernel call.  The
interface routines are used in conjunction with the types and low level
interface procedures defined in NEWcalls.mod.
.s3
The general procedure followed in the interface routines is to put the
arguments into one contiguous block of memory.  Then through an
assembly language subroutine, a pointer to the block with the arguments
is passed to the appropriate Kernel call.  Upon completion, the Kernel
call places any return values into the argument block and returns an
exception.  This exception is then passed upward by the assembly
language subroutine.  The interface routine unpacks the return values
from the argument block and returns the exception to the calling Modula
program.
.sh
Because of the significant differences in services provided by UNIX and
KSOS for Modula processes, testing of Modula code under UNIX is not
practical unless the program is very large and complex.  To test a
Modula process under UNIX, it is necessary to use different system
calls.  These may be enclosed in ifdef's as should the KSOS counterpart
calls.  It would also be necessary to ifdef a different set of include
files.  At a minimum the following include files, which are located in
/ksb/tools/lib, are needed when compiling a Modula program to run under UNIX: 

.nf
          unixcalls.mod
          misc.mod
          chario.mod
          string.mod
          KERnad.mod
          KIOnad.mod
          IOform.mod
          IOEform.mod
          IOFform.mod
          UDMdefs.mod
          c32.mod
          conv.mod
          convio.mod
          bio.mod
          extio.mod

.fi

