OS/2 Shareware BBS: 10 Tools/10-Tools.zip/thnk11.zip/THUNKER.DOC

Text File | 1995-03-24 | 10KB | 214 lines

4/30/94

While OS/2 2.X has many wonderful features it has one source of irritation
to programmers used to almost any other system. That source of irritation is
the fact that somebody at IBM made a poor decision and eliminated the KBD
MOU and VIO system calls from the 32 bit version of the operating system.
Whatever the reasoning behind this choice, it left the system crippled.
I would guess that one of the excuses given for deleting these calls was
that command line programs are "obsolete". In addition it was probably also
argued that programmers could always create thunks to the existing 16 bit
API's if they needed to.
    Trust me on this; the source code necessary to create the thunks to
the almost 100 missing API functions is so ugly that in a controlled test
mere exposure to it resulted in the sterilization of frogs at a distance of
more than 100 paces.
    Fortunately I was able to hide all of this ugliness inside of nice
clean little .DLL file so that the rest of you won't have to see it.

The files in THUNKER.ZIP are:

* (Changed, see below)

THUNKER.DLL --- This converts 32 bit calls to 16 bit for you.
THUNKER.LIB --- This allows 32 bit C & asm to call MOU KBD and VIO functions.
THUNKER.H   --- This allows C to pretend there are 32 bit MOU KBD & VIO API's.
THUNKER.DOC --- Obviously this document.
THNKTEST.C  --- Sample for use of the 32 bit MOU KBD and VIO API's
THNKTEST.MAK -- Sample make file showing the linking.
THNKTEST.DEF -- Def file for sample.

* (Changed, see below)
    Maybe the fact that this DLL exists will encourage IBM to correct
their horrendous blunder and make real 32 bit versions of these functions.
In any case, as long as the 16 bit calls exist in the system this .DLL makes
them accessible for your use.
    The only 32 bit C which I have is GNU C. While the header functions
correctly with it,I have not tested it to work with commercial C compilers.
About the only source of potential trouble would be if some items in
THUNKER.H were already defined in your other headers. It is very plain
vanilla C - nothing compiler specific about it.
    There is no reason not to call the functions from assembly code, but
be aware of the following:

* (Changed, see below)

    1. The function names are preceded by an '_'. EX: _VioWrtTTY
    2. The stack is left dirty with the calling parms.
    3. Parms are pushed in reverse order from the 1.x calls
* (Changed, see below)

All 3 of the above are for C's benefit.

THIS CODE IS RELEASED INTO THE PUBLIC DOMAIN AND MAY BE USED FOR COMMERCIAL
PURPOSES. UNDER NO CIRCUMSTANCES WILL THE AUTHOR BE LIABLE FOR ANY DAMAGES
RESULTING FROM THE USE OF THIS CODE.

ABOUT:
    The code: THUNKER.DLL was written in 32 bit assembly and assembled
with MASM 6.0 under OS/2.

    The author: Robert E. Canup II has been involved in the micro
computer revolution since the pre-IBM S-100 days as an engineer and
programmer. He has held the world record for the fastest micro computer
design.


I am interested in any comments about this code including bug reports.
My CompuServe number is 73513,216

                        Bob
Rev 1.1 Notes 3/20/95

As I said above, when I originally wrote the DLL the only 32 bit development
tools that I had were 2.1 and 2.2 versions of GNU C which I downloaded from
CompuServe. The original DLL ran fine with them. The DLL was made by linking
my asm code with the DOSCALLS.LIB that came with OS/2. Two problems occurred
with this procedure.

1.) DOSCALLS.LIB has no linkages to the PM versions of the VIO calls.
2.) Despite the fact that all of the documentation has the API calls in
mixed case DOSCALLS.LIB has them in uppercase (VIOWRTTTY etc.).

When I linked the original DLL I forgot to use the /NOI switch on Link386.
This was ok with both masm and GNU C 2.1 and 2.2 but it blew up in my face
when I tried to use it with GNU C 2.5.4 from the Hobbes CD Rom. In addition I
have since obtained IBM's C-Set First Step and the OS/2 developers toolkit.
The new version has the case problem taken care of. The rev 1.1 DLL is linked
to the toolkit's OS2286.lib which has the PM versions of the VIO calls in it.

The differences between GNU C and IBM C require that there be two versions of
the DLL's.  In GNU, as I said above, function names are proceeded by _ as
in _VioWrtTTY while in IBM C (at least in the C-Set first step) the name is
simply VioWrtTTY. In addition it is necessary to change the header file
to use the APIRET APIENTRY pair before the functions. C-Set uses registers
to pass variables unless the APIENTRY keyword is used.

The C-Set variable passing method is as follows:

    Left most parm in EAX
    Second parm in EDX
    Third parm in ECX
    Fourth through N parms pushed on stack.
Remember parms are pushed from right to left in C.

Shortly after I posted the zip file to CompuServe I discovered a typo in the
header file. The new Rev fixes that problem.

About a month ago Morton Kaplon 73457,437 pointed out a problem with the high
16 bits of the values returned by the thunked functions. Checking my code I
realized that I had neglected to mask the high 16 bits of the eax register
off before I returned the values. That is also fixed in the current release.

There are some things about using this DLL with C that need to be pointed out.
On both GNU C 2.5.4 and IBM's C-set it is necessary to lightly modify some
of the header files that come with the compilers. Specifically there is a
conflict between Thunker.h and BSESUB.h. The headers have some #defines like
this:

#define VioWrtTTY Vio16WrtTTY

these #defines need to be commented out as they conflict with the prototypes
in the Thunker.h file. The #defines are controlled by an opening control
statement that reads something like this:

#ifdef INCL_SUB
    #define INCL_KBD
    #define INCL_VIO
    #define INCL_MOU
#endif /* INCL_SUB */

The easiest thing to do is simply move the comment earlier as follows :

/* This is the mod to allow THUNKER.h to work.
#ifdef INCL_SUB
    #define INCL_KBD
    #define INCL_VIO
    #define INCL_MOU
#endif  INCL_SUB */

Now the INCL_SUB won't do anything.

The second .h file that needs changing is the PMAVIO.H file. This is a some-
what more difficult case but is still easy to fix.

Simply locate the offending code (most of the header) and surround it with

#ifdef NO_THUNK
.
.
.
#endif

Since NO_THUNK is not defined anywhere the troublesome part of the header
in effect disappears.

There is only one THUNKER.H file supplied as this works for both IBM C and
GNU C.

The new files in this zip file are as follows:

THUNKGCC.DLL --- This converts 32 bit calls to 16 bit for you. For use with
         GNU C.
THUNKGCC.LIB --- This allows 32 bit GNU C & asm to call MOU KBD and VIO
         functions.
THUNKICC.DLL --- This converts 32 bit calls to 16 bit for you. For use with
         IBM C-SET compiler.
THUNKICC.LIB --- This allows 32 bit IBM C & asm to call MOU KBD and VIO
         functions.
THUNKER.H   --- This allows C to pretend there are 32 bit MOU KBD & VIO API's.
THUNKER.DOC --- Obviously this document.
THNKTEST.C  --- Sample for use of the 32 bit MOU KBD and VIO API's
THNKTEST.MAK -- Sample make file showing the linking.
THNKTEST.DEF -- Def file for sample.
THNKTEST.EXE -- Executable compiled with C-Set.
THNKTEST.ASM -- Asm file produced by C-Set compiler (/Fa switch) showing how
        to call the code from assembly programs (without a macro).

The only difference between THUNKGCC.DLL and THUNKICC.DLL is that the
function names have a '_' in front of them in the GCC version and don't in the
ICC version. This allows the same C source code to be used with both of them.
The ICC version is probably preferable for use with MASM since you don't have
to include a '_' on the front of the names.

Hopefully one of the two will work with Borland and Watcom C. If not then I
can create versions that will if someone will give me the register passing
and naming protocols for these C's.

Part of the reason that it would be nice to have real 32 bit versions of the
API's as opposed to thunked versions involves the problems inherent in the
mapping of flat 32 bit addresses to the tiled 16-16 segments used by the 16
bit version of the API's. Two restrictions occur from this difference:

    1. Passing an array which overlaps a 64K boundary will cause the
       code to crater. In the tiled system the probability that this will
       happen in a given piece of code is (size of array-1/65536). This
       means that adding variables to your code can cause it to fail.
       This problem won't show up until we have enough variables or
       stack usage (local variables use the stack) to exceed 64K.
    2. OS/2 reserves the first 16 bit selector for its own use. Under
       GNU C I find it necessary to sometimes include a dummy char array
       to take up the first 65537 bytes. Why the value is 65537 and not
       65536 I have not a clue.

As I said in the original documentation for these files leaving the KBD MOU
and VIO calls out of the 32 bit version of OS/2 cripples programmers. With
the standard version of the API's all one can do is crawl around helplessly
trying to do I/O using DosRead and DosWrite (Arrrrgh). With these files I am
providing programmers with a wheel chair. Now that is a huge advance over
crawling but it doesn't compare with being able to walk.

            GIVE US OUR LEGS BACK IBM!!!

                        Bob Canup
                        73513,216