🚀 go-pugleaf

In article <1992Sep25.151807.6092@odin.diku.dk> gogol@diku.dk (Peter Skov Knudsen) writes:
>I just received the Toolkit and as I didnt want to invest the $$$
>in IBM C Set/2, Im using it with gcc 2.2.2 which works just fine.
>Of course I had to patch the header files from the Toolkit
>replacing lines of the type
>  PCHAR APIENTRY SomeFunction(...)
>with
>  PCHAR SomeFunction(...) asm ("SomeFunction")

>But as I understand it,
>the removed APIENTRY directive also serves the purpose of placing
>a linker directive in the objectcode, identifying the function as
>a 32-bit function with the C calling convention.

As far as I'm aware there is no linker directive that is appropriate
in this situation.

Under OS/2 1.x, all APIENTRY does is to tell the compiler (not the linker)
that the function call needs special treatment.  Under 1.X, "special treatment"
meant that the function had a different naming convention (no leading
underscore) and used a different calling convention (so the compiler has to
push and pop arguments in a different manner).

With OS/2 2.x, the sole remaining effect of APIENTRY is to effect a different
naming convention.  Therefore, the change you have made to the header file
is *all* that you need to do.

>Secondly, with the patches I have applied this far, Im unable to use
>any of the old 16 bit system calls (VIO, KBD etc). Those function are
>identified in the header files by something like
>  PCHAR APIENTRY16 SomeFunction(...)
>The APIENTRY16 directive, I understand, place some directives in the
>object code identifying the function as 16-bit, Pascal calling convention.

APIENTRY16 is a clue to the compiler to output different assembly code
that is compatible with the older 1.x calling convension.  There are only
three ways to do what you want:

1. Buy IBM's C

2. Write assmembly language "interpreters" that get called using the standard
gcc/2 calling convention, which re-arrange the arguments and call the 16-bit
function.

3. Add the new calling convention to gcc as a keyword.  [While you're at it,
add _System so that we don't need to modify header files at all any more]

While (3) is the cleanest solution, it should only be attempted by someone
with plenty of time on their hands...

- Colin Jensen
cjensen@ampex.com ljensen@netcom.com