JP>  There are basically two directions for thunking.

JP>  The first is 32->16, where 32-bit code is calling 16-bit libraries,
JP>  such as your Lotus Notes stuff.  This is done by declaring the 16-bit
JP>  API using _Far16 and so forth, and CSet++ will insert pointer and
JP>  stack conversion code in the 32-bit code that calls the function for
JP>  you. As you said, you seem to have this down pat.

JP>  The second is 16->32, and is usually encountered where you need to
JP>  pass a callback function to a 16-bit library.  This is more complex,
JP>  because obviously the 16-bit code will be expecting to call a 16-bit
JP>  function on a 16-bit stack using 16-bit pointers.  Functions written
JP>  for the 32-bit world won't work.

JP>  What you need to do is define your callback function as a 16-bit
JP>  *callable* function.  You do this in the same way as you declare a
JP>  16-bit *called* function, by using _Far16 and friends.  The only
JP>  difference is where the thunking code goes.  This time it goes in the
JP>  callee, not the caller.

JP>  For example, this function is callable by 16-bit code

JP>      void _Far16 _Cdecl callback ( short a, short b ) {}

I already had it declared that way....

JP>  What happens now is that CSet++ at the start of the body of the
JP>  function generates all of the code to convert from a 16-bit stack to a
JP>  32-bit stack, and at the end of the function generates the code to go
JP>  back again.  To the 16-bit world, this looks just like a 16-bit
JP>  function, but the body of the function runs in the normal 32-bit
JP>  world.

It's cool how much the compiler actually does for you ...

JP>  This is all covered in the CSet++ manual, by the way.

I am unfortunately too used to finding everything in the online docs.
The manuals usually just sit in the dusty pyramid box on the shelf. 

I discovered through blurry eyed examination of the disassembly waht was going
on. I noticed that the preamble code was actually doing what I needed it to do
already.  The offending instruction was a PUSH DWORD [EAX]. Turns out I missed
an indirect reference to a pointer in my thunking efforts. My first thought whe

I saw it was the the reference to ESP was bad, Then I notice the brackets aroun

EAX. I can see why some people prefer pure assembler under OS/2. At least you
can see exactly what is going on.

This is really my first attempt at mixing 16 & 32 bit code. What a PAIN. Well a

least I have learned an awful lot. Next time it will be easier. One other
problem I found was that a void * parameter being passed to the call back
routine would not thunk properly. The compiler seemed to insist that it was
already a 32-bit pointer so my thunking efforts merely caused it to thunk 32-16
and then back to 16-32 when I tried to use it. I was forced to use a union to
solve this problem. Is there an easier way ? 

Thank you for your reply. I sure wish all of the old 16-bit libraries would jus

go away.... I spent 3 hours working on the header files for the Notes API. Seem

like they had the job half finished already, but I still had to find and change
all of the "far pascal"'s to _Far16 _Pascal. They claimed that MSC 6.0 was
required. HEH! I showed them! I would rather dump MSC 6.0 all together... It is
after all a Microsoft product.

___
 * MR/2 1.52 NR * I program like a MAN. I use COPY CON PROGRAM.EXE.

--- WILDMAIL!/WC v4.10h