Excerpted from message dated 12-26-95, David Noon to Murray Lesser:

DN>Try this for an expanded version of your KBDKEYINFO type.

DN>     DEFINE STRUCTURE
  >          1    KBDKEYINFO,
  >               2    chChar              CHAR(1),
  >               2    chScan              CHAR(1),
  >               2    fbStatus,
  >                    3    Interim_char        BIT(1),
  >                    3    Final_char          BIT(1),
....balance of code snippet deleted

DN>This will allow you to address the individual flag bits by means of
  >mnemonic names, rather than masking them with bitwise "ands" the way
  >you would in C.

Hi Dave;

    Thanks for the idea, but I think I will pass on it for the time
being.  The bitmask detail isn't required for what I am trying to do
now, but I have filed the complete snippet for possible later use.

    Here are a couple of listings that appear to implement a portion of
the "_getch" function correctly:  The first, keywait.pli, is a
separate-module subroutine that waits for a keypress and then returns to
the main program.  No attempt is made to identify the key in this
version.  The second is a test driver: test.pli ATTACHes a second thread
(that beeps half of every second) and then calls keywait; the beeping
will continue until a key is pressed.  Any comments would be
appreciated.

......
 keywait: proc() options(linkage(pascal16));
   define alias UCHAR char;
   define alias USHORT fixed bin(16) unsigned;
   define alias ULONG fixed bin(31) signed;
   define structure
       1 KBDKEYINFO unaligned,
          2 chChar type UCHAR,
          2 chScan type UCHAR,
          2 fbStatus type UCHAR,
          2 bNlsShift type UCHAR,
          2 time type ULONG;
   dcl KbdChar entry (
            byaddr type KBDKEYINFO,
            type USHORT,
            type USHORT)
            returns(optional byvalue fixed bin(16) unsigned)
            ext ( 'KBD16CHARIN' )
            options(byvalue nodescriptor linkage(pascal16)) external;
   dcl keybdinfo type kbdkeyinfo;
   call KbdChar(KeybdInfo, 0, 0);
   return;
  end keywait;
.......
 test: proc options (main);
   dcl keywait external entry () options (linkage(pascal16));
   dcl TI1 TASK;
   attach Blooper THREAD (TI1);
   display ('');
   display ('     Press any key to stop beeping');
   call keywait;
   display ('just before detach');   /* Just testing!  */
   detach THREAD (TI1);
   display ('Have a good day');      /* Again! */
 exit;

 Blooper: entry () OPTIONS (LINKAGE(SYSTEM));
   dcl DosBeep entry (
                    unsigned bin fixed(31),
                    unsigned bin fixed(31))
                    RETURNS(bin fixed(31) optional)
                    OPTIONS (LINKAGE(SYSTEM) NODESCRIPTOR BYVALUE);

   do loop;
      call DosBeep(523,500);
      delay(500);
   end;
 end test;
.....

    I linked test.obj to keytest.obj with 2MB stack space.  (It is very
hard for us old DOS programmers to get used to the idea that unused
stack space doesn't cost anything!  When test.exe is beeping, OS20MEMU
says it "owns" 5556 KB of memory, of which only 144 KB is resident, 0
swapped.)  The final thing that made the subroutine work was to declare
keywait with options(linkage(pascal16)).  I thought the internal (within
keywait.pli) linkage declaration to the 16-bit API call was sufficient.

It wasn't!  The "external" declarations cured all the thunking errors.
This would imply that one can't mix 16-bit and 32-bit code in the same
module.  (I think I read something to that effect in some manual or
other, but one tends to forget .)  Now, I will stop testing and try
it on a useful program!

    Regards, with much thanks,

          --Murray

___
 * MR/2 2.25 #120 * Never send a PM program to do a character-mode job
                                                                        
---