This is file: 02_96QA.TXT

This file contains questions asked of the Driver Development Support Center
(DDSC) and the answers given to that particular question.  Entries are
appended to the top, so the most recent entry is available first.

Each entry starts with a header line that has a KEY WORD (or words) included
to allow the reader to "search" on KEY WORDS of particular interest.  Each KEY
WORD starts with the exclamation point character (!).  This allows for search
arguments that will limit matches to the header lines.

The following KEY WORDS are supported in this file.

KEYWORD                      DEVICES/TYPES OF QUESTIONS
===========   ==========================================================
!BASE         Loader, Memory Management, Strategy/Architecture
!I/O          Serial/Parallel, Pointing Device, Trackball, Keyboard, Pen
!MULTIMEDIA   Motion, Sound
!NETWORK      LAN,
!OTHER        PCMCIA, APM, Miscellaneous
!PRINT        Printer, Scanner
!STORAGE      DASD, SCSI, Tape, CD-ROM, ASPI, IFS
!VIDEO        VGA, SVGA, XGA, 8514, Display
**********    Entry separator (10 *'s)
==============================================================================

!VIDEO__________________________________**********
QUESTION: (Ref : JA8)
I am attempting to utilize VioGlobalReg and VioRegister
rc = VioGlobalReg("dllname","regfun",VR_VIOWRTNCHAR,0L,0);
In Dll,
  APIRET16 APIENTRY16 regfun(unsigned a, unsigned b, unsigned short index)
    {
      ...

Upon issuing VioGlobalReg, a status 426 is returned ERROR_VIO_REGISTER
I would like to use a 32-bit function call as the registered function, but at
this point would just like to see the thing work.
Alternately, I have changed the code as follows, replacing VioGlobalReg with
VioRegister:
rc = VioRegister("dllname","regfun",VR_VIOWRTNCHAR,0L);
In Dll,
  APIRET16 APIENTRY16 regfun(unsigned a, unsigned b, unsigned short index)
    {
      ...

And get returned a status 9, which in Bseerr.h specifies an invalid mem block.
As I am sure you are painfully aware, Vio documentation is lacking to say the
least.

ANSWER:
We also tried the sample code (gviospym.c) provided in DevCon Vol-9 CD-1,
directory
       \source\pmsample\agviospy
              and got the same error 426 for the VioGlobalReg API call.
However we tried the sample code ( viospym.c) for VioRegister  in the
directory
       \source\pmsample\aviospy
              and did not get any error.
The details of the VioXXX APIs are given in chapter Video Function Calls,
OS/2 Programming Reference( PRCP.INF)
Alternatively, You can use PM_ED_HOOKS to intercept the dispatching of Gre
functions for monitoring or other purpose.
Refer: 1. OS2_PM_DRV_ENABLE : Subfunction 0Ch ( PM_ED_HOOKS )
            2. Article in " Monitoring Display Driver Interface Calls " in
                                        DevCon News Vol 6.

!OTHER_______**********
QUESTION: (Ref: JA9)
I'm writing a device driver that needs to handle processor-independent
delays (i.e. 3 seconds), and I'm having a hard time using
DevHelp_ProcBlock().  I'll get a trap when this routine is called during
run-time, but during init-time, it's OK.  I notice that the
documentation for "Block" specifies that only the Strategy sections of
the device driver can call Block.  If this is the case, and I need to do
a delay in interrupt mode, what is the best method of doing it?  I know
it's not a good idea to do delays in interrupt mode, but in this case,
it is absolutely necessary.

ANSWER:
You could adapt the following procedure to get a delay in the interrupt mode.

At INIT time you could use DevHlp_AllocateCtxHook to allocate a context hook
which will be used to execute the interrupt time code after the required
delay.
Also, register a timer handler using DevHlp_TickCount. The tick count
parameter set in this call must be larger than the time in which you expect the
interrupt This is done so that the timer handler is not called before interrupt
occurs.
At Interrupt time, in your interrupt handler you should call DevHelp_TickCount
with the delay you require to incorporate in the interrupt mode and then
return from the handler.
When the timeout occurs, the timer handler is called and here call
DevHlp_ArmCtxHook and DevHlp_TickCount with the same large tick countvalue
( To avoid timeout occuring before Interrupt) and return.
The next available task time thread calls the hook handler where you could
execute the Interrupt Code after the delay.
Note that the Hook Handler is run in Interrupt Context, so avoid using DevHelp
calls which are not valid at Interrupt time.
Following is the pseudo code for the procedure described :

StrategyRoutine()
{
   case INIT :
     DevHlp_AllocateCtxHook( HookHandler, HookHandle )
     DevHelp_TickCount( TimerHandler, TickCount )
     break ;
     : :                                                                                                                                                                                                        }

InterruptServiceRoutine()
{
    DevHelp_TickCount( TimerHandler, DelayCount )
    return
}

TimerHandler()
{
   DevHelp_TickCount( TimerHandler, TickCount )
   DevHelp_ArmCtxHook( HookHandle )
   return
}

HookHandler()
{
   Code to be executed after delay as a part of Interrupt Service Routine.
}

You could free the context hook using DevHlp_FreeCtxHook before CLOSE
operation in the driver.
You could refer to sections AllocateCtxHook, ArmCtxHook, FreeCtxHook, and
TickCount, chapter Device Helper Services in Physical Device Driver reference
for more info.


!OTHER_____________________**********
QUESTION: (Ref: JA7)
I just got the Developer Connection Device Driver Kit for OS/2 with the hope
for updated documentation on OS/2 Physical Device Drivers, since the PDD
manual which I have for OS/2 2.0 is incomplete.  What I found was that the
"current" online documentation for PDDs has been taken almost verbatum from
the 2.0 document, with no updates to the sections which I need more info on.
Specifically, the section on semaphores is woefully inadequate!  The semaphore
usage section is written based on OS/2 release 1 semaphores (RAM and system
semaphores, setting and clearing them), whereas, the DevHelp routines have
routines for use with the OS/2 release 1 type of semaphores plus routines for
handling Event semaphores.  Are SemRequest, SemClear, and SemHandle for Warp
Event or Mutex semaphores?  These routines talk about a system semaphore.  Is
this a "private or shared" application semaphore?  The documentation indicates
that NONE of the Event semaphore DevHelp routines are available in interrupt
context, whereas SemClear and SemHandle are available in interrupt context,
making them more useful.  Where can I get better documentation on semaphore
usage in physical device drivers?


ANSWER:
The SemRequest, SemClear and SemHandle Device Helper calls can be used for
both Event and Mutex semaphores depending on the design, event semaphores
being used for communication between two processes and mutex semaphores
being used for communication between more than two processes.
The SemHandle, SemClear and SemRequest DevHelp calls cannot be used with
32-bit application semaphores. To use these DevHelp calls in the PDD, the
application must create a 16-bit code chunk using 16-bit Semaphore APIs like
Dos16SemRequest, Dos16SemClear etc. and have the 32-bit application call this
code via thunk.
The RAM semaphore is a private semaphore where as the System semaphore is a
shared semaphore.
Refer section "Semaphore Management", chapter "OS/2 Physical Device Driver
Design Issues" in Physical Device Driver reference.
The Event semaphore DevHelp calls are not available during Interrupt time.
The SemHandle and SemClear DevHelp calls can be made at task and interrupt
time. Note that to access the RAM semaphore at Interrupt time, the physical
device driver must locate the semaphore in the physical device driver's data
segment.
Refer section " Semaphores",chapter "Interprocess Communication" in "The
Design of OS/2" by H.M. Deitel and M.S. Kogan for more information on
Semaphores.

!OTHER________________________________**********
QUESTION: (Ref: JA5)
Can I develop .SYS code (16 bit) with VisualAge ?? It seemed to imply this
but I did not have must success in doing so. Any help ??

ANSWER:
The Visual Age is a 32 bit compiler and can be used only for the development
of Presentation Drivers & Virtual Device Driver.They cannot be used for .SYS
development which is a 16-bit PDD.For the 16-bit PDD development,you
could use Watcom C 10.5.


