home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Hack-Phreak Scene Programs
/
cleanhpvac.zip
/
cleanhpvac
/
X00-202.ZIP
/
X00-DOC.EXE
/
CHLLAPI.DOC
< prev
next >
Wrap
Text File
|
1994-07-09
|
7KB
|
165 lines
Why use the C HLLAPI
Every multitasker that I have examined insists on managing INT
14h. The FOSSIL specification is basically an extension of the
normal BIOS INT 14h functions. However, in implementing a FOSSIL
with features that are not supported by BIOS's INT 14h, additional
registers were used to pass additional parameters. Some
multitaskers will intercept the INT 14h calls and will alter
registers that are not normally used by BIOS. Quarterdeck's tech
support confirmed to me that they may change the DS register when
DESQview intercepts an INT 14h (when released, version 2.26 of
DESQview is supposed to correct this). What this means is that
some FOSSIL functions will work correctly with a multitasker and
others will not. Additionally, it means that if one application
program uses a FOSSIL function that another application does not
use, then one of the programs may work fine with a multitasker
and the other may not.
My first task in solving problems with multitaskers was to
eliminate the need for X00 to be called using an INT 14h. Starting
with version 1.20 of X00, I have included quick and dirty HLLAPI
routines for some high level languages. More are yet to come.
Applications programmers should replace references to library
routines in their existing source with the replacement routine(s)
included in the X00 distribution file. Then include the appropriate
object module in the linking process. At this writing, HLLAPIs are
included for:
Microsoft C, all models
Borland's Turbo C
Borland's Turbo Pascal
Microsoft Quick Basic
The first time the HLLAPI is called, it will determine if X00 is
the active FOSSIL. If X00 is the active FOSSIL, then it will be
directly called instead of using INT 14h. If X00 is not the
active FOSSIL, or if there is no FOSSIL, the HLLAPI will issue an
INT 14h. After the first call to the HLLAPI, a maximum of only 4
assembly instructions are added to the execution thread no matter
what FOSSIL is installed. The addition of 4 instructions to the
execution thread should have no effect on execution speed of the
application program.
Using the HLLAPIs to access X00 with a multitasking system can
result in significantly faster execution because the multitasker's
management of INT 14h is not executed. Additionally, the
multitasker has no opportunity to change the registers and all
FOSSIL functions should work correctly.
Those using assembly language to access X00 should replace INT 14h
instructions with a CALL BYPASS and include BYPASS.OBJ in the linked
program. BYPASS should be declared as a FAR external,
i.e. EXTRN BYPASS:FAR
CHLLAPI
I am not a C programmer, so please forgive any documentation
blunders and or systax errors in the example C code fragments.
Now included in the X00 distribution are 5 object modules that allow
access to all X00 functions from Microsoft C. A different object
file is included for each memory model. Just is case you can not
figure it out:
CSMALL.OBJ is for small model programs
CMEDIUM.OBJ is for medium model programs
CCOMPACT.OBJ is for compact model programs
CLARGE.OBJ is for large model programs and
CHUGH.OBJ is for huge model programs
Additionally, a file (X00.H) is included to provide the prototypes.
All of these files are in the archive CHLLPAI.ARC. Some of the
object modules are identical. I thought it best to include an
object module for each model to protect the innocent. All of these
modules provide an identical (looking) interface to X00 for the
various memory models.
Two routines are defined, they are X00 and X00X (defined with upper
case). These routines are intended to be near direct replacement
routines for the C library functions int86 and int86x respectively.
The only difference in the calling sequence(s) is that the interrupt
number is not passed as a parameter.
To use these interfacing routines, the programmer basically sets
variables is a structure that corresponds to the processor's
registers and passes the structure address(s) to X00 or X00X. When
X00 or X00X is invoked, it copies the variables in the structure
to the processor's registers and then calls X00. Upon return from
X00, all of the processor's registers are copied into the output
structure. The input structure and output structure may be the same.
In the case of X00X, a third structure address is passed. This
structure is used as both input and output for segment registers
values.
For a more complete description of the C structures and their uses,
read the documentation about the library functions int86 and int86x
in the appropriate Microsoft C reference manual. These routines
may work with other C compilers, but have only been tested with
Microsoft's C. I am told that Turbo C is identical. X00 and X00X
do not use the data segment so the small model should also work
for Turbo C's Tiny model.
The code fragments below (written by a C programmer) are intended
to provide examples of replacing int86 and int86x calls with X00
and X00X calls.
My thanks to Doug Boone for helping with documentation and testing
the C HLLAPI.
#include <dos.h>
#include "X00.h"
union REGS regs;
struct SREGS sregs;
char input_bufr[1024];
char far *input_ptr;
/*
==============================================================*/
/* If you are using int86 calls then substitute: */
int86(0x14, ®s, ®s);
/* with */
X00(®s, ®s);
/* If you are using int86x calls then substitute: */
int86x(0x14, ®s, ®s, &sregs);
/* with */
X00X(®s, ®s, &sregs);
/*
==============================================================
First, A call to X00X (this loads segment registers)
============================================================== */
input_ptr = (far *) input_bufr;
regs.h.ah = 0x18; /* Block Read func code */
regs.x.di = FP_OFF(input_ptr); /* Buffer offset to DI */
sregs.es = FP_SEG(input_ptr); /* Buffer Segment to ES */
regs.x.cx = 1024; /* Max bytes to xfer to CX */
regs.x.dx = 0; /* Using COM1 (Port 0) */
X00X(®s, ®s, &sregs);
/* Upon return, regs.x.ax contains the actual number of characters
put into input_bufr */
/*
==============================================================
This is a call to X00
==============================================================*/
regs.h.ah = 0x03; /* Stat Request func code */
regs.x.dx = 0; /* Using COM1 (Port 0) */
X00(®s, ®s);
/* Upon return, regs.x.ax contains the returned status for COM1 */