[leecher]

Hallo liebe OA-Gemeinde,

Ich weiß jetzt zwar nicht, ob irgendwer von euch seine eigenen Languagecall-Routinen für Open Access entwickelt und mein Programm daher brauchen kann, aber ich entwickle gerade ein ZVT Kassenterminalinterface für OpenAccess und hierbei hat es mich ziemlich genervt, dass man nach jedem mal compilen eine .OSA Datei erstellen muss, indem man alle Funktionsnamen mit zugehörigen Funktionstypen und Parameterzahl angeben muss.

Gerade wenn man mehrere Funktionen schreibt und das Ganze eigentlich nur testen will, ist das ziemlich nervtötend und man vergeudet sehr viel Zeit damit. Scheinbar gibts von Open Access aus selber keine Möglichkeit, eine OAC batchmäßig zu erstellen, zumindest das Entwicklerhandbuch beschreibt nur den Weg über das OSA-Hilfsprogramm.

Nachdem das .OSA Dateiformat aber ansich recht simpel gestrickt ist, habe ich mir gedacht ich schreib mir mal schnell selber so einen OSA Compiler. Und falls ihn wer brauchen kann stell ich ihn hiermit auch mal ins Forum. Wer weiß...

Anbei die Beschreibung aus der README in Englisch (damit das Ganze auch international verwendbar ist, wer weiß, vielleicht gibts ja noch OSA-Entwickler.

What is it ?
===========
When developing SPI Open Access OSA Language calls, debugging them can get extremely annoying because in order to create an .OAC, you always need to use the OSA Language call module in OA3 and enter all the Calls and their type everytime. If you are creating a module that consists of many calls you need to test, this is just a real waste of time. It would be far more convenient to create an .OAC file during compilation so that you can test it immediately.

Because of this annoyance, I had a look at the .OAC file format and found out that it was very simple and easy to understand, so I wrote my own OAC compiler which you can find in here.


How to use it
=============
First, create a list file with the Language calls you want to use in your .OAC file. The list file may include comments, commented lines must start with a ; Each line in the file specifies a call. It consists of 3 fields which are seperated by TAB or spaces. The first entry is the function name, followed by the function type and the number of parameters.
Here is an example:

;Funct    Type    Params
;---------------------
ZVINIT    1    0
ZVOPEN    301    2
ZVCLOSE    301    0

The file has to be named [OSA-Name].LST Compile your OSA Language call as usual:

  cl /ACw /Gs /c [OSA-name].c
  link [OSA-name].obj,,,osa.lib,nul.def

Now you have an .exe and an .obj file. Now just type:

mkosa [OSA-name]

and it should create a [OSA-name].OAC file. That's all!


The OAC file format
===================
As far is I have discovered, the header of the file consists of the following structure:

typedef struct
{
  short hdr1;    // Always 0x04 ? Maybe compiler version?
  short type;    // Seems to be related to the function types passed in
  short count;     // Number of functions
} OAC_HDR;

The type seems to be dependent on the function types of the functions in the file. As you know from the OA development documents, each function has a type number. Every function type class is a multiple of 100, so we have 1, 2, 100, 101, 102, 200, ... etc. (see Page 27 in the Language
Calls Reference). If we devide it by 100, we have the appropriate class. 2 SHL <class> gives us a type number bit to set in the type-field of the header.

Following the header there is an entry for each function of the following type:

typedef struct
{
  char  Name[8]; // Name of function padded with 00
  short Offset;  // Offset to function in segment
  short type;    // Type of function, i.e. 301
  short params;  // Number of args to pass
} FUNC_ENTRY;

The first page of the file consisting of Header and entries is always 1K in size. The rest of the page is padded with NULLs. Following this header page, there is just a copy of the .EXE file. The offset can obviously extracted from the .OBJ file. With the M$ C Compiler, the real code always seems to start at offset 210h, so add 10h to the offset from the .OBJ file to get the correct offset for the OAC.