Page 2

Tech Note #44: Using Executable Programs

1 October 1998

http://www.tatanka.com

Page

2 of 4

executable

program

(from BBC)

application

published API

interface library (from BBC)

application or service

program (from

customer)

message

passing

(locally or

over network)

The libraries are provided as C source code. We do not expect you to change the libraries, so
they are uncommented and difficult to read. However, they can be compiled by almost any
ANSI C compiler. Since you compile the libraries yourself, there is no specific version required
for any particular development environment or toolset.

Each function call in the API is converted to a message, which is sent to the running executable
program. A return message provides the output parameters. The libraries use the Berkeley
sockets interface to send messages to our programs. You must link your application with the
appropriate sockets libraries. Otherwise, we expect only common POSIX procedures in your
platform’s libraries.

Because we use socket calls, your applications can reside on separate machines from the
running executable code. Our libraries take care of byte order and packing differences among
platforms. TCP/IP must link the application platforms with the platforms running our
executable programs.

The application libraries are provided for the supported platforms. They can be modified for
unsupported platforms by the customer, allowing applications to reside on unsupported
platforms while our executables run on supported systems. For example, you can host our
DSM-CC on an x86 Linux machine, with your own video pump operating on a separate RISC
platform.

Customer-Provided Functions

Some software requires the customer to provide certain services to the executable engine. For
instance, the customer must provide the video pump for DSM-CC.

Customer-provided functions are built using routines included in the application libraries,
which come with the executable code. The customer must provide a separate process for each
function. Each service process repeatedly executes a two-step loop:

Receive an incoming message requesting a service operation