This is file: 11_93QA.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)
==============================================================================

!OTHER__________________________________**********
November 24, 1993
QUESTION: (Ref: 704)
Is there a way to print text strings out to the debug console that let me know
that a particular function in the driver has been called, what a specific
variable value is, etc.  Basically, I want to be able to do "printf" calls to
assist in debugging.


ANSWER:
One successful way of debugging device drivers is to send dubugging output to
serial ports.  Using the serial port is useful if you are using the kernel
debugger, since you'll already have a terminal attached.  However, you can
route also all your debugging output to the centronics (parallel) port, hence
to a pro_printer.  In this way you get a permanent log of what was going on.
The code which could be used to send one byte is

          while((inp(0x03bd) & 0x80) == 0; /* wait for  | Busy */
          outp (0x03bc, Val);              /* write data       */
          outp (0x0ebe, inp(0x3be) | 1);   /* strobe it down   */



Note that (1) it is hard wired for parallel_1, and (2) it will upset any
proper centronics driver.  Both of these restrictions are easy to live with.
All you could do is to write a couple of printf() like routines which send
strings and formatted numbers to the printer using the above code.




!PRINT__________________________________**********
November 24, 1993
QUESTION: (Ref: 496)
Q1. Is the PostScript driver on the DDK level 1 or level 2 PostScript?

Q2. Does this driver support the CMYK color model?


ANSWER:
A1. It is Postscript 1.

A2. It does not support color.  This will come with Postscript 2.




!VIDEO__________________________________**********
November 24, 1993
QUESTION: (Ref: 456)
Q1. Does the PM display driver source code in the DDK V1.0 have any double
    byte character input support?  If yes, can you indicate which example
    driver has this feature (ex.  XGA, 8514, VGA ....)?

    If there is no double byte character support in the driver yet, could you
    provide any information or source code for us to add it to the driver?

A1. There are currently no double byte character drivers on the OS/2 Device
    Driver Source Kit.  OS/2-J, the Japanese version of OS/2, has double-byte
    character set support, but it has not been announced in the U.S,
==============================================================================

Q2. I am writing a DSPINSTL installation script for our PM display driver.
    There are two parameters, CURRENTDRIVER and DEFAULTDRIVER, in OS2.INI for
    specifying the display driver.  Is it necessary to use the same data for
    this 2 parameters?

    My experience is that if the driver in CURRENTDRIVER is invalid, OS/2 will
    try to load the one in DEFAULTDRIVER.  Currently I have only modify
    CURRENTDRIVER and leave DEFAULTDRVIVER in VGA.  Because our hardware has
    VGA capability, therefore should our accelerated driver specified in
    CURRENTDRIVER fails to load, OS/2 will load the VGA driver instead.
    Hopefully this approach will always bring up a PM desktop display for the
    user to reconfigure the display driver if anything goes wrong.

    But it seems that all the example DSPINSTL scripts in the DDK update both
    CURRENTDRIVER and DEFAULTDRIVER with the same information.  I wonder
    whether my way of handling the parameters are correct or not.  Could you
    check it out for me please?

A2. The CURRENTDRIVER is the display driver that is currently installed.  The
    DEFAULTDRIVER is the driver that is highlighted based on the adapter card
    that the system has detected while running DSPINSTL.  For example, if the
    system detects an XGA card installed, the DSPINSTL will have the XGA
    driver highlighted in the list box.  This only means that the system
    points to the driver that needs to be installed based on the adapter card
    that the system has detected.  This can be changed to highlight any other
    driver that the customer wants to install.  When the desired driver is
    highlighted, the DSPINSTL will prompt for the directory path information
    from which to install the driver.  The system updates the OS2.INI file
    with the driver to be loaded and also updates the config.sys device=
    statement with the new driver selected, and also copies the DLL to the
    OS2\DLL.  Therefore, the DEFAULTDRIVER has nothing to do with the
    CURRENTDRIVER and if the install fails, the system does not update the
    OS2.INI and the config.sys and the DLL directory with the desired driver.
    Therefore whichever driver is in useprior to the DSPINSTL will be in use.




!I/O____________________________________**********
November 24, 1993
QUESTION: (Ref: 433)
I have a joystick which I am interfacing to a PC using a digital I/O board.
I'm writing a device driver (under OS/2) which will poll the port on the I/O
board.  The driver will take the input byte (which represents motion on the
joystick) and make calls to MOUSE.SYS to perform specific actions based on the
input from the joystick, e.g.  move in the X-direction, etc.

Also, I'm writing the driver in C and am using Steven Mastrianni's device
driver toolkit (the parallel driver, specifically).

Here is what I need to know:
1. What is the assembly code fragment to attach to MOUSE.SYS? (Note: how would
   the C "wrapper" function look? Any structures required?)

2. What would the assembler fragment look like to make a request to MOUSE.SYS?
   (Again, any C structures, prototypes,would be very helpful)

3. Do I need to use the "TYPE=" clause on the MOUSE.SYS "DEVICE" line in
   CONFIG.SYS?

I have the DDK and have looked at the mouse device driver.  So, I'm also
wondering if there are any routines which I may take from that driver and
incorporate into my own driver to perform the IDC with MOUSE.SYS.


ANSWER:
1) He can refer to Physical Device Driver Reference to get the info.  the
   Device Helper Routine (ATTACHDD) could be used to attach to the mouse
   driver and mouse IOCTL'S could be used to make calls.

2) Use control IOCTL commands.

3) Go through Init.asm,data.asm in ddk\src\dev\mouse directory to get an idea.
   Yes you may have to do this.

The Physical Device Driver Reference gives a good explanation of Device Help
routines.  He can also check out \src\dev\mouse\familyg\pclogic.*.  This is
the code for a small device-dependent driver that attaches to MOUSE.SYS using
the 'TYPE=' option.  The IDC interface that this follows is also documented in
the 'Physical Device Driver Reference' (Document S10G-6266-00)




!VIDEO__________________________________**********
November 22, 1993
QUESTION: (Ref: 431)
Q1. This is a PM/Windows display driver question.  Normally, when you start a
    full-screen Windows application from the Workplace, the PM display driver
    gets a Death() call before the full-screen Windows driver is loaded.  This
    allows the PM driver to keep off the toes of the Windows driver.

    However, if you shutdown the system when a full-screen Windows application
    is active, OS/2 will automatically relaunch that application the next time
    you start up.  The problem is that in this case, it doesn't send the
    Death() call to the PM driver first.  The result is that the Windows
    driver and the PM driver find themselves fighting over the hardware.

    I would imagine that PM considers the Windows app to be started in the
    background, and thus inactive, but there seems to be no way for the
    Windows driver to detect this.  For example, no INT 2F switchout call is
    received during startup (at least as far as I can determine -- and I hook
    INT 2F fairly early in my Windows driver).

    I need some way to work around this situation, since otherwise, the system
    will ultimately crash each time the user restarts -- the only solution is
    to boot off floppy and disable the fullscreen Windows driver, so that the
    next time OS/2 boots, it can't start up the application in question.

A1. One way to work around this without booting from floppy is to change the
    SET AUTOSTART line in his CONFIG.SYS to SET AUTOSTART=NO.  This will keep
    previously open applications from starting up again.

    The session manager has a global variable called "fGrimReaper".  The PM
    display driver and all the other display drivers use this fGrimReaper to
    determine whether the screen group belongs to the application.  The VGA
    code uses this also.  This is declared as a global extern.  Foe example
    the VGA driver \DDK\SRC\VGA32\VGAINC\EXTERN.INC has this variable defined.

    If this variable is set to 0, then it means that the screen group is being
    used by another application.  If this is set to -1, then the screen group
    belongs to the application (or vice versa ?).  When a user switches to a
    full screen from a PM application, the session manager sets this variable.

    As far as the autostart of the windows application is concerned, if it is
    a full screen window application, then it can not be minimized.  If it is
    minimized then it has to be seamless.
==============================================================================

Q2. With my OS/2 and Windows drivers, booting OS/2 with an active full screen
    Windows session causes a crash at the time when OS/2 tries to
    automatically start the full screen Windows session.  The crash occurs
    because the full screen driver assumes that it has control of the hardware
    when it is loaded; since the OS/2 Desktop is still active, this assumption
    is invalid.

    Now, I suspect that the reason this problem doesn't occur under VGA (and
    also 8514, no doubt) is because those boards have a virtual device handler
    that stops any process from accessing the hardware directly unless it owns
    the screen -- i.e.  when the Windows full screen session is loaded, it is
    put to sleep until switched to the foreground, or else it does its
    hardware manipulations to a virtual version of the hardware, rather than
    the real thing.

    Since no virtual device handler (or base video handler) is being used with
    my graphics board, for a variety of reasons, this scenario doesn't occur
    when my OS/2 and Windows drivers are being used.

    I think that my problem would be solved if I could find a way to access
    fGrimReaper from within my Windows driver (rather than the OS/2 driver).
    This would allow the Windows driver to spot that it is in the background
    while it is loading, and skip its normal initialisation.

    So, the question then becomes:  is there any way to read this variable
    from a Windows session, thus allowing the Windows session to determine
    whether it currently owns the screen or not?

A2. I looked at the WINOS2 Windows driver code and found that the code has the
    functions that this developer seems to want.  Please have him refer to
    WINOS2\DRIVERS\DISPLAY\4PLANE.  In this directory SSWITCH.ASM has the
    initialization code for the WINDOWS drivers and this code handles session
    switching/notification etc..  I think looking at this code will help
    immensely.

    Under the OS/2 VDD environment, the OS/2 session manager notifies the DOS
    session manager of screen switches.  The DOS session manager notifies all
    Virtual Device Drivers that are involved in these events (Video, Keboard,
    and Mouse Virtual drivers).  In order to get the notification, the VDDs
    must install user hooks using VDHInstallUserHook to install a VDM_CREATE
    hook.  Additionally, the Video, Keyboard, and Mouse drivers must also
    install VDM_FOREGROUND and VDM_BACKGROUND hooks.  This way, these drivers
    will get the notification during screen switches.  I am sure there are
    similar hooks in the WINDOWS environment.  The WINDOWS DDK I believe has
    references to these hooks.
==============================================================================

Q3. Unfortunately, none of the suggestions to date have lead me to a solution.
    I do indeed have the Seamless Windows supplemental disk, but the VGA
    Windows driver doesn't seem to contain any additional code to handle the
    particular problem I'm having.  I would speculate that this is because the
    VGA driver, having a VDD associated with it, can happily write to the
    hardware all it likes without causing any interference with the real
    hardware registers, if it does not "own" the display -- this is
    transparent to the VGA Windows driver, hence the lack of code to handle
    it.

    I already handle standard mode switches in and out of an active Windows
    session; this has been tested and works fine.  It is only during startup
    that the uncertainty arises (since no switch messages are sent to the
    Windows driver via the INT 2F mechanism).

    Perhaps I could rephrase my question:

    How can a DOS/Windows session tell whether or not it is currently the
    owner of the display?

    or:

    How can a DOS/Windows session tell whether or not it is currently the
    active application?

    In each case, I'm looking for a single call that can be made to OS/2 via
    WinShield from the DOS session to return the instantaneous state of the
    session, rather than a solution that involves hooking something to be
    notified when a transition occurs from one state to another.

A3. I have looked further into this problem.  In seamless processing, three
    components share the video hardware - VVIDEO, PM, and WINDOWS.

    PM and WINDOWS coordinate access to the hardware via FSRamSemaphore.
    However, virtual drivers do not have this mechanism available.  Therefore,
    this interrupt exists to signal VWIN which forwards the request to the VDD
    that the WINDOWS driver must obtain the hardware.  This is accomplished
    through the WINDOWS driver calls to VWIN - accessed via INT 66H.  Has the
    customer coded this interface in his Windows driver ?

    The details about how to interface with VWIN are in Display Device Driver
    Reference in the chapter "Seamless Windows Support".  There is a section
    in there for "Windows Driver Calls to VWIN - Accessed via INT 66".  sect




!OTHER !VIDEO___________________________**********
November 24, 1993
QUESTION: (Ref: 410)
I am nearing completion of a Presentation Manager display driver for OS/2 2.1
and I am looking for a way to intercept CTRL-ALT-DEL.

The problem is that if the user presses CTRL-ALT-DEL, either arbitrarily or as
the result of having first selected Shutdown, my display adapater has no way
of knowing that it should disable its own display and restore the VGA display.

The display adapater is based on TI's 34020, and can pass through the host
video signal or generate its own display, both via software control.  The
driver intelligently chooses the appropriate screen at Death() and
Resurrection() time.  However, Death() is never called at reset time, only
when switching to a fullscreen DOS or Windows session.

So, I need some way for PM (or another part of the system) to tell me when it
is about to reset.  I have played with adding a cleanup function via
DosExitList during the initialisation of my driver, but have not had any
success (the function was never called).

Users are currently complaining that when they reset their system, they cannot
see the VGA screen during bootup.

So, any help gratefully received.  As of now, the only driver we supply is a
Presentation Manager driver -- the standard VGA base video handler etc.  is
being used.

ANSWER:
When the CTL-ALT-DEL is pressed, the system sends a shutdown packet to all
physical device drivers registered with the system.  VDDs and PMDDs don't get
these.  I would tell the developer to write a simple PDD that comes up,
registers with the system, then waits for a shutdown packet.  When it receives
a shutdown packet it sends a message to his PM driver informing it that
shutdown has occurred.  This should solve his problem.




!VIDEO__________________________________**********
November 24, 1993
QUESTION: (Ref: 252)
Currently I am working on a VGA video driver for 16 colors at 1024x768
resolution.  Unfortunately, the video card I got uses both A000-AFFF and B000-
B7FF segment when it is in the 16 color 1024x768 resolution.  It is not like
the ET4000 from Tseng Lab that only uses A000-AFFF segment and has bank
switchable memory segemnts on it.  It seems to me that OS/2 does not allow me
to write any video data to B000-B7FFF.  Every time when the driver write to
any location between B000-B7FF, the system just die.  How am I going to tell
the OS2 that my driver using both A000-AFFF and B000-7FFF video segment ?


ANSWER:
These changes allow the video card be able to use both the A000 and B000
segments.  The first change is in ddk\src\vga32\ibmdev32\resolve.asm, from

        device_specific_init PROC SYSCALL

        ;/*
        ;** Initialize the GSSP structure for the EGA
        ;*/

                mov     gsspScreen.cb,10000h ;64k
                mov     gsspScreen.pPhysMem,0A0000h
                mov     gsspScreen.ulSize,sizeof GSSP
                :
                :
to
        device_specific_init PROC SYSCALL

        ;/*
        ;** Initialize the GSSP structure for the EGA
        ;*/

                mov     gsspScreen.cb,18000h ;96k
                mov     gsspScreen.pPhysMem,0A0000h
                mov     gsspScreen.ulSize,sizeof GSSP
                :
                :

This means we want to use video memory from A0000h to B7fffh.

Unfortunately, right after this routine the system calls physical_enable() in
ddk\src\vga32\ibmdev32\egainit.asm.  physical_enable() in turn calls
reprogram_hardware() in ddk\src\vga32\ibmdev32\critsec.asm.
reprogram_hardware() then uses the following parameter data to reprogram the
EGA\VGA card.  One of them (9th line) puts EGA/VGA card back to 64k memory
again.  This keeps above GSSP structure change from working.

   ;/*
   ;** Table of data for programming the EGA/VGA, used by reprogram_hardware.
   ;**
   ;** The entries with "+1" in the port address are marked for special
   ;** handling, which means the output must be performed with asynchronous
   ;** reset.  Since extended time without synchronous reset can cause
   ;** data loss in video RAM, these entries are output within a critical
   ;** section to prevent interrupts, and the whole function has been moved
   ;** to the beginning of its segment to be sure of not crossing a page
   ;** boundary.  This table is accessed outside of the critical section,
   ;** so it can be placed in the main Data segment.
   ;**
   ;** Some of the entries in this table set important mode values, some others
   ;** simply set registers to known values.
   ;*/

           public  inittbl
   ALIGN 4
   inittbl label   word

           dw      EGA_BASE+SEQ_ADDR+1,  SEQ_MODE+(SM_EXTENDED+SM_ODD_PLANE)*
           256 ;memory mode
           dw      EGA_BASE+SEQ_ADDR,    SEQ_MAP_MASK+MM_ALL*256 ;enable all
           planes
           dw      EGA_BASE+GRAF_ADDR,   GRAF_SET_RESET   ;set to black
           dw      EGA_BASE+GRAF_ADDR,   GRAF_ENAB_SR     ;disable all planes
           dw      EGA_BASE+GRAF_ADDR,   GRAF_COL_COMP    ;set to black
           dw      EGA_BASE+GRAF_ADDR,   GRAF_DATA_ROT    ;no rotation, rop=S
           dw      EGA_BASE+GRAF_ADDR,   GRAF_READ_MAP    ;no color compare
           dw      EGA_BASE+GRAF_ADDR,   GRAF_MODE        ;write/read mode 0
           dw      EGA_BASE+GRAF_ADDR+1, GRAF_MISC+(MS_NON_ALPHA+MS_A0000_64K)*
           256 ;grafx misc
           dw      EGA_BASE+GRAF_ADDR,   GRAF_CDC+0Fh*256 ;set to white
           dw      EGA_BASE+GRAF_ADDR,   GRAF_BIT_MASK+0FFh*256  ;enable all
           bits
           dw      0                                 ;end-of-table marker

   _PtrData32 ENDS


So change the 9th EGA/VGA data from

    dw      EGA_BASE+GRAF_ADDR+1, GRAF_MISC+(MS_NON_ALPHA+MS_A0000_64K)*256 ;
            grafx misc

to

    dw      EGA_BASE+GRAF_ADDR+1, GRAF_MISC+(MS_NON_ALPHA+MS_A0000_128K)*256 ;
            grafx misc


After these two changes the video card uses both the A000 and B000 segments.




!OTHER__________________________________**********
November 18, 1993
QUESTION: (Ref: 622)
I'm working on a device driver for SCSI tape drive units, and I'm having some
trouble getting things started.

I've read the book 'Writing OS/2 Device Drivers In C' and have purchased the
DDK CD-ROM.  However, both the book and the DDK-CD seem to recommend using MSC
6.0 for the device drivers.  Our shop uses Watcom C/C++, however, and I was
wondering if there was any tips you may be able to pass along.  I've figured
out I need to alter the calling convention (by default Watcom passes the first
two args via registers) and that the functions are named a little differently
(main_, instead of _main, for example).  Is there anything else you may know
of?  Watcom suggested contacting IBM...we're using the 16-bit version of their
v9.5 C/C++ compiler.


ANSWER:
We do not know of anyone here that wrote a device driver for OS/2 using Watcom
C/C++.  The main point is the difference in the way Watcom passes parameters.
This is likely to affect the ring 0 library routines that the driver will call
(the devhelps).  I would recommend that the developer review the devhelps C
interface in the DDK.  DDK\SRC\DEV\DASD\DISKH\DHCALLS.H defines the C function
prototypes.  The parameters passed by these functions are loaded into
registers via the assembler macros.  To learn more about this mechanism,
please look at DDK\SRC\DEV\DASD\DEVHELP\*.ASM and DHCALLS.INC.  We are not
sure if he will need to rebuild the DHCALLS.LIB ( maybe not).  In any case
please study the C interface to the devhelps.


ADDITIONAL INFORMATION FROM QUESTION SUBMITTER:
I just wanted to follow up on using the Watcom C/C++ 9.5 compiler to write
OS/2 device drivers.  I have got it working with both the sample code from
'Writing OS/2 Device Drivers in C' and with the DHCALLS.LIB (?)  library from
the DDK (v1.0) and thought I'd pass this information back should anyone else
ask.

 1) Instead of _acrtused, the Watcom C runtime library looks for
    cstart_. This should be declared as public in the .asm file.

 2) Watcom provides a special pragma, cdecl, for specifying the
    calling convention used by MSC.  They also provide a _Cdecl
    keyword, as in 'word _Cdecl main(...);'.   The runtime library
    always wants to look for the main() function, however, and
    it looks for main_ (per Watcom calling conventions) instead of
    _main (MSC) at link time.  I defined a special pragma which
    follows the MS calling convention but used the Watcom naming
    convention :
       #pragma aux MSC_Compat "*_"
          parm caller []
          value struct float struct routine [ax]
          modify [ax bx cx dx es]
    which can be used to define main thusly :
       #pragma aux (MSC_Compat) main;

 3) The compiler flag -Zu must be used for SS!=DS, etc.  I believe this
    is equilavent to the MS -Aw flag.

Anyway, I just wanted to pass this along if anyone else should ask about the
Watcom compiler.  It does seem to produce better code than the MS package, and
is much better supported i.e.  they still support it!




!OTHER__________________________________**********
November 18, 1993
QUESTION: (Ref: 578)
What development tools would you suggest using to create OS/2 device.  The DDK
talks a lot of MASM 6.0.  Currently I'm using BC++ 1.0 for OS/2 which has
TASM.  Will this work or would MASM be more compatible for any source I may
acquire?


ANSWER:
The DDK team tested all the DDK .ASM source with MS MASM 6.0A and MASM 5.1.
We provide MASM 5.1.  We cannot assure that TASM will work because we never
tested it.  Its up to the developer to make sure it works or he might have to
modify the code to be able to build with TASM.




!STORAGE________________________________**********
November 18, 1993
QUESTION: (Ref: 331)
I need to find information about writing a device driver to access QIC 40/80
tape devices.  I have both the Physical and Virtual device driver references
from the OS/2 technical library as well as the 'Writing OS/2 Device Drivers in
C' book by Steve Mastrianni.

We are starting the design process for adding tape support to our backup
application, and would like to support QIC 40/80 tape drives such as Colorado
Jumbo and other floppy-controller tape units.  I have obtained the technical
interface specifications for these units from the Quarter-Inch Cartridge drive
standards group, and based on what I've read I believe I need to develop a
device driver to interface to these units under OS/2 2.1.  However, I have
been informed that I would only need to write a filter to use the existing
floppy controller driver.

 My questions are :
   1) Can a filter be written to use the floppy driver (I didn't know
      this even existed), and if so, where is that interface
      documented?
   2) Is there anything like a tape driver already in 2.1 for these drives?


ANSWER:
The TAPE enabling IOCTL interfaces were (unfortunately) left out of the PDD
Ref.

Floppy Tape IOCTLs
------------------
These IOCTLs allow cooperative sharing of the FLOPPY controller hardware by a
separate device driver.

 Cat 8 Fcn 5D

 Cmd Packet: 00 - Suspend Diskette Driver
 (BYTE)      01 - Resume  Diskette Driver
             02 - Query   Diskette Driver


 Parm Packet: 00 - Reserved
 (BYTE)

Suspend Diskette Driver
-----------------------
When this IOCTL returns (without error) the diskette driver will have
relinquished control of the diskette hardware including the IRQ level.
Further requests to the diskette device from the operating system will be
queued.

Resume Diskette Driver
----------------------
This IOCTL wil resume processing of diskette requests by the diskette driver.

Query Diskette Driver
---------------------
This IOCTL will indicate whether or not the diskette driver queue has any
pending requests.  A return code of 0 (NO_ERROR) indicates there are no
pending requests.

If pending requests are detected, then the handling is up to the tape
application.  It is recommended that the tape application do an orderly
clean-up of its activities and then issue a RESUME IOCTL to allow diskette
requests to proceed and subsequently issue another SUSPEND IOCTL to reclaim
the diskette hardware.

Additional Note:

It is anticipated that future versions of OS/2 will provide QIC-40/80 drivers
as part of the operating system base, and will provide a Tape Programming API
to facilitate the writing of backup applications.




!PRINT__________________________________**********
November 18, 1993
QUESTION: (Ref: 315)
Q1. We are implementing the area fill algorithms for a plotter style
    presentation driver and are looking for formal definitions of the PATSYM_*
    fill patterns.  Is there a spec.  that details the spacing of the various
    patterns?

A1. Please check to make sure the customer has read the OS/2 2.0 Technical
    Library manuals on the Presentation Driver Reference and Programming Guide
    Volume III.  In the presentation driver manual there is an APO for Area
    attributes on page 8-5 describing the possible symbols to use.

    If more detail is required the user may check the Programming Guide Vol.
    3. The PGM GDE covers a whole chapter on area and polygon primitives (Chp.
    5) for graphics.  On page 5-2 there is a table describing the base pattern
    set.  Further coverage of the various patterns continues on in the
    chapter.

    If these manuals and references are not enough I would suggest checking
    the hardware tech manuals for spacing capabilities and definitions.  If
    this answer is not sufficient I will dig into the graphics engine a little
    more for them.uff
==============================================================================

Q2. We are already familiar with this documentation and it does not really
    provide the information we are looking for.

    We are doing a plotter type device driver for a laser printer.  It will be
    a vector device.  We are trying to achieve a wysiwyg type effect so that
    the image on screen matches the image on paper.  We are looking for
    infomation like the following:

        Horizontal line pattern:  lines should be spaced one millimeter apart.

        Diagonal line fill:  Diagonal lines at angle 100 deg, spacing two
                             millimeters.

    These are just examples of the type of info we're looking for.  Does it
    exist?

A2. We checked with the original plotter developer.  There is no such spec.
    that he knew of.  Each driver implemented the spacing according to the
    device.  Since most of the fills were left up to the graphics engine the
    spacing had a tendency to look uniform.  This was all based on the spacing
    in the VGA driver.




!OTHER !STORAGE_________________________**********
November 16, 1993
QUESTION: (Ref: 636)
Q1. I'm trying to access a CD-ROM drive using the OS2CDROM device driver using
    DosDevIOCtl cat 0x80 function 0x44 to do a simple eject.  The drive has 6
    logical addresses.  I'm not sure how to address this in the DosOpen.  I'm
    new to C programming and have included my program.  The DosOpen appears to
    work, but the DosDevIOCtl gives me a RC of 65283.  I'm compiling the
    program with Borland C++ for OS/2 as BCC IOCTL.C without any other
    options.  Unfortunately, the IBM Control Program Programming Reference
    provides a simple example of DosDevIOCtl that is of no real help to me,
    i.e., no paramaters or data buffer usage.

 /****************************************************************************/

#define INCL_DOS
#define INCL_DOSERRORS
#define INCL_DOSDEVICES
#include <os2.h>
#include <stdio.h>

HFILE  devhandle;
ULONG  rc;
ULONG  ulDataLen  = 0;
ULONG  ulParamLen = 4;
ULONG  action;

void main() {
  rc = DosOpen( "CD-ROM2$", &devhandle, &action, 0, 0, 1,
    OPEN_FLAGS_FAIL_ON_ERROR | OPEN_SHARE_DENYWRITE | OPEN_ACCESS_READONLY,0);
  if (rc != 0)
    {
      printf("DosOpen error: return code = %ld", rc);
      return;
    }

  rc = DosDevIOCtl( devhandle, 0x80, 0x44,
             "CD01", ulParamLen, &ulParamLen,
              NULL,  ulDataLen,  &ulDataLen);
  if (rc != 0)
    {
      printf("DosDevIOCtl error: return code: %ld", rc);
      return;
    }

  rc = DosClose( devhandle );
  if (rc != 0)
    {
      printf("DosClose error: return code: %ld", rc);
      return;
    }
}

A1. In the DevIOCtl, the parameter has been hard coded as "CD01" which is
    wrong.  CD01 is a variable #defined as 0x31304443L.  He should set the
    value to any variable with 0x31304443L or '#define CD01 0x31304443L' and
    use CD01 without the quotes.
==============================================================================

Q2. It turns out the problem was really that I was opening CD-ROM2$, when I
    should have been opening the drive letter.  The rc of dec 65283 (0xFF03)
    was not a 65299 (0xFF13), which would indicate the first 4 bytes are not
    "CD01".  I got a compiler error "type mismatch" when I defined CD01 as
    requested.  The following program works after changing the DosOpen.  I
    have another question following the program.

     /***********************************************************************/
     #define INCL_DOS
     #define INCL_DOSERRORS
     #define INCL_DOSDEVICES
     #include <os2.h>
     #include <stdio.h>

     #define OPENFLAG        1L
     #define OPENMODE   0x0000A040

     HFILE hDev;
     CHAR  drive[] = "H:";
     ULONG rc;
     ULONG ulAction;
     ULONG ulDataLen  = 0;
     ULONG ulParamLen = 4;

     void main()
     {
       rc = DosOpen(drive, &hDev, &ulAction, 0L, 0L, OPENFLAG, OPENMODE, 0L);
       if (rc != 0)
         {
           printf("DosOpen error: return code = %#x", rc);
           return;
         }
       rc = DosDevIOCtl(hDev, 0x80, 0x44,
                 "CD01", ulParamLen, &ulParamLen,
                   NULL, ulDataLen,  &ulDataLen);
       if (rc != 0)
         {
           rc = rc - 0xFF00;
           printf("DosDevIOCtl EJECT error: return code: %#x", rc);
         }

       rc = DosClose(hDev);
       if (rc != 0)
         {
           printf("DosClose error: return code: %#x", rc);
           return;
         }

     }

        --------------------------------------------
    New Question:

    In attempting to fix the above problem I tried a couple of things.  One
    thing I did was define param as a character array as follows:

    CHAR param[] = "CD01";

    The doc for DevIOCtl states that this paramater "param" is a pointer, but
    both:

       rc = DosDevIOCtl( devhandle, 0x80, 0x44,
                  param, ulParamLen, &ulParamLen,
                   NULL,  ulDataLen,  &ulDataLen);
     and:

       rc = DosDevIOCtl( devhandle, 0x80, 0x44,
                 &param, ulParamLen, &ulParamLen,
                   NULL,  ulDataLen,  &ulDataLen);

    work, and so does "CD01".  Is the compiler doing a conversion for me based
    on the function prototype, or do I not understand pointers?  This is kind
    of a "C" question, but I would appreciate an answer if possible.

A2. C has the following features:

    - When you declare an array, the name of the array without an index
      refers to the starting address of the array.  This is why passing
      param or &param above have the same effect.

    - When you pass a literal constant such as "CD01", C allocates memory
      to store the constant and passes the starting address.




!BASE___________________________________**********
November 16, 1993
QUESTION: (Ref: 428)
Q1. I have two applications.  One application opens a device.  The process id
    of the application that opened the device gets stored in the device data
    structure.  The second application opens another device.

    In the meanwhile, the first application quits.

    I want to check in the second application whether the first process is
    still alive.  The presence of the process can be checked using process it
    in UNIX it seems.  I want to know which DevHlp call will help me do this.

A1. Are you referring to the PS -ef command in Unix?  If so, then the Doscalls
    in OS/2 is what customer wants.  I don't know of any DevHlp which does
    this .
==============================================================================

Q2. I want to know what I should be doing if the device driver size exceeds
    64k size.

A2. If the customer exceeds 64k size, the he can divide the code into two
    segments 1) main segment 2) Swappable segment.  He can block one segment
    while running the other.

    Good example code is in the Device Driver Source Kit version 1.0

           ddk\src\dev\dasd\ibm\ibm1flpy\
==============================================================================

Q3. We have developed a driver in OS/2 2.0.  I am adding new features.  The
    driver is compiled using Microsoft C 6.0.  It was compiled using the
    compile option /Asnw for small memory model.  Linking is done using the
    slibcer library and driver library in C called drvlib.lib.

    It compiles all the files.  But during linking, warning L4020 _TEXT:code
    segment size exceeds 65500.  fatal error L1070 :  _TEXT segment size
    exceeds 64k.

    So according to the Microsoft C error manual, I tried changing the memory
    model to LARGE.  I gave /Alnw compile option and llibcer as the library to
    be linked.  It compiles fine and creates the driver file.  But when I load
    the driver, during init time, it hangs.  This driver used to load fine
    with small model.

A3. She has two alternatives to avoid this problem.

 1) As I told before she can break the code into two segments.  1) Main
    segment 2) Swappable segment

    She should block one Segment while running the other.  This is more
    effective because it does not need any code change like changing from
    _near pointer to _far pointers.

 2) She could also change from SMALL memory model to LARGE memory model but
    make sure that she changed the code.  I mean all _near pointers to _far
    pointers.  But the _near calls are faster than _far calls.  So, I want to
    know if she changed the code to _far pointers.

    Also the sys3175 is an access violation exception error, and was generated
    when an attempt was made either to load or store data in an inaccessible
    location, or to execute an inaccessible instruction.  If she is using OS/2
    she can do help sys3175 to see the documentation for this error.




!PRINT__________________________________**********
November 16, 1993
QUESTION: (Ref: 388)
Q1. Is SPL2D.DLL supported on OS/2 2.x?

A1. Yes, SPL2D.DLL is supported through OS/2 2.1
==============================================================================

Q2. If so is the plan to continue support under later versions of the 32-bit
    spooler?

A2. No, support cannot be guaranteed for later versions since it is not a
    publicly documented interface.  There may be better methods of job
    notification registration instead of using SPL2D.  Support will continue
    for SPL2D until an external replacement is available for developers.
==============================================================================

Q3. As I understand, SplPdInitPort is called in PrtOpen after the DosOpen.  Am
    I be correct in assuming that SplQmJobStart is called long before DosOpen?

A3. SplQmJobStart is called just prior to the spooler sending the separator
    page to the printer (if one exists) and prior to calling the queue driver
    to print the job.  It is always called before PrtOpen and will be inside a
    SplQmJobStart/SplQmJobFinish bracket [it could be PrtOpen(Separator)
    PrtWrite PrtClose then PrtOpen(Real Job) PrtWrites PrtClose].
==============================================================================

Q4. Assuming I am correct in #3, could I also assume that SplQmJobFinish is
    called after the DosClose in PrtClose?

A4. SplQmJobFinish is called after the queue driver is done printing the job
    and is always after the PrtClose on the caveat that the queue driver and
    printer driver are using the Prtxxxx APIs to print.
==============================================================================

Q5. I am writing a redirector for printer output.  I would like to hook
    SPL2D.DLL to do some initialization before the DosOpen.  Are there any
    major hosers in doing this?

A5. If you need to do initialization before the spooler does DosOpen, you
    could supply your own (16-bit)SPL2D.DLL, put it in the LIBPATH and on the
    next reboot the spooler will call your SPL2D before and after every
    spooled print job.

    To remove your SPL2D.DLL, you must get it out of your LIBPATH (ie:  once
    system is booted, the spooler will have already loaded it).

    When writing a port redirector, you really should not need to use the
    SPL2D interface to initialize before the DosOpen of your port.  A port
    driver should be able to handle it at SplPdInitPort time.

    If using NamedPipes as output ports, the process that services the named
    pipe should be run from startup.cmd, and it should have the ability to do
    its initialization even after the pipe connection is made by the spooler
    output thread(ie:  SplPdInitPort).  The same goes for LPT monitor method
    of port redirection.





!PRINT__________________________________**********
November 16, 1993
QUESTION: (Ref: 387)
I am calling SplMessageBox within an AVIO application.  It modifies the print
job status, displays the text mode message "There is a problem with your
printer.  Check the desktop for more information."  and beeps, but the PM
message box is never displayed.  The return code is MBID_ERROR.  A subsequent
call to WinGetLastError returns 4098 (PMERR_INVALID_HMQ).  I was told that
SplMessageBox didn't have to be called from a PM ap.  Any idea what I'm doing
wrong?


ANSWER:
Any application may call SplMessageBox to notify the spooler of a problem with
a job, but to get the PM message box to display the abort/retry popup the
application must be capable of creating a PM message queue.  So the EXE type
must be PM.




!OTHER__________________________________**********
November 15, 1993
QUESTION: (Ref: 673)
I have the "Writing OS/2 2.0 Device Drivers in C" book.  Is there a lot of new
stuff in the 2.1 version that I should run out and buy it too?

ANSWER:
The new version contains a chapter on working with pointers, a chapter on
PCMCIA, a chapter of Q's & A's, additional source code, and a companion
diskette.




!STORAGE________________________________**********
November 15, 1993
QUESTION: (Ref: 288)
We are testing OS/2 2.0 and will shortly be testing OS/2 2.1 with RAID arrays
of disk drives.  This has made it possible to configure very large disk
capacities.

Please tell me what the current capacity limits are for OS/2 2.0 and 2.1.  In
particular, What is the capacity limit for A FAT partition?  For a HPFS
partition?

As long is these limits are not exceeded is there a limit on the drive size
itself?  I need this for both ver 2.0 and 2.1.


ANSWER:
From OS/2 2.0 Redbook Volume 1:  Control Program, section 6.2.3, pages 74-75:

    " The maximum size for a disk volume under OS/2 2.0 is 512GB using
      HPFS and 2GB using the FAT file system ...."

A search of the online OS/2 2.1 Redbook Update revealed no changes to these
numbers.




!PRINT___________________________________**********
November 15, 1993
QUESTION: (Ref: 279)
We recently received the OS/2 DDK CD and were surprised to find that it did
not contain a sample PCL printer driver.  Was this code available in a
previous DDK release?

Will it be available in a future release?

Is the code for the current PCL driver proprietary?

The PCL driver, which services many of the most common printers, would be a
useful addition to the DDK.  Any information pertaining to PCL driver
development would be appreciated.


ANSWER:
I am afraid that the answers to the question your customer is posing are
probably not exactly what they want to hear, but they are not all bad either.

First:  No, there will never be a PCL driver released in any DDK that is put
out by IBM.  There are several reasons for this but they must stay internal to
IBM.

Second:  The code for a PCL driver might be proprietary.  I am not sure; that
is a question for IBM legal to handle.  I know that there are agreements
between IBM and other companies that must be considered in this issue.

Finally; to address the question of usefulness, I understand that a PCL driver
sample would be useful, but then again where's the fun in a puzzle if you
already know the answer.  We can not help the customer reduce their device
driver development time directly, but I can say that in the next DDK update
(hopefully), we will be releasing the IBM42XX printer device driver.  This is
a bitmapped driver and can be used as an example for writing a PCL driver.  It
is not that hard to figure out were to put your PCL calls once the bitmap is
constructed.  Using the 42XX driver as an example should give the customer a
huge hint as to solve their puzzle.

Ordering info for the DDK:

     Title:             Device Driver Source Kit for OS/2
     Part Number:       71G3703
     Phone Number:      (800)633-8266




!VIDEO__________________________________**********
November 15, 1993
QUESTION: (Ref: 277)
When I try to compile the VSVGA.SYS - the virtual device dirver, one file is
missing from the DDK.  I can not find VVDP.INC in the DDK\SRC\VDEV\VVIDEO.
This is the message I got when I try to compile the VSVGA.SYS by using "nmake
vsvga"


        Operating System/2 Program Maintenance Utility
        Version 2.000.000 Aug 28 1992
        Copyright (C) IBM Corporation 1988-1991.
        Copyright (C) Microsoft Corp. 1988-1991.
        All rights reserved.

        masm -Ml -p -t -Z   -DSVGA vvint10.asm,vvint10.sga;
                vvint10.asm(70): error A2116:
                Include file not found: vvdp.inc

Would you tell me where I can find the file - vvdp.inc?


ANSWER:
This developer is correct.  This include file does not exist.  It is created
by the makefile in the process of building the driver.  He needs to rerun the
makefile without the parameter 'vsvga', which will build this driver
correctly.  In looking at the makefile, the developer has commented out the
necessary statement to build just the vsvga driver version of this include.
So for now, you must build everything for it to work.




!OTHER__________________________________**********
November 15, 1993
QUESTION: (Ref: 281)
Q1. The Processor Bindings only specify OS/2 16 bit Protect Mode Clients.  Is
    there any document on 32 bit clients?

Q2. Is a Socket Services driver written as simply a character device driver?

Q3. Will IBM be writting Socket Services for all of the popular socket adapter
    cards?

Q4. Has IBM provided a method to allow a DOS window to access Card Services?


ANSWER:
A1. OS/2 2.1 provides only the 16 bit bindings documented in the PCMCIA 2.0
    Card Services specification.  No 32 bit bindings in product or plan.

A2. Yes, the Socket Services device drivers written by the IBM Hardware Lab
    (vended to IBM Yamato) to support their products are all character DDs.

A3. The PCMCIA Architecture has defined the responsibility of Socket Services
    as that of the hardware system vendor.  IBM hardware system products which
    support PCMCIA all provide OS/2 Socket Services DDs.  This set of drivers
    covers the ISA and microchannel systems.  I do not believe any development
    has been done for EISA (ie., COMPAQ systems).  Hence, I think the answer
    is no.

A4. In OS/2 2.1 we did NOT provide virtualized Card Services interfaces for
    the DOS and Windows environments.  However, we do believe this is a very
    real requirement which we will address in the next release of OS/2.




!BASE !OTHER____________________________**********
November 15, 1993
QUESTION: (Ref: 223)
I am ask for either a 16 or 32-bit call gate.  I assume if I'm calling if from
32-bit C Set/2 code, then I should ask for a 32-bit call gate?  Or does the
fact that it "points" to a 16:16 worker routine in my device driver mean I
should ask for a 16-bit call gate?

What do I do with the selector that is returned by the DynamicAPI call?  I've
passed it back to my application program via a DosDevIOCtl, and that's where
I'm stuck.  I know I'm somehow supposed to do a FAR CALL using that selector,
but I don't see how to do that from C Set/2.  Is there any sample code
available anywhere that shows how to best use this capability?

If I'm reading data (via my ring-0 worker routine via the dynamically created
call gate) can I simply pass the 32-bit "flat" process-level address of my
read buffer to my routine?  Or is there some other memory translation that
must be performed?


ANSWER:
You are using the DynamicAPI to get the 32 bit callgate selector for the
VME_READ and VME_WRITE functions within his PDD.  Now, through the
DosDevIOCtl, his application has the selectors for both these functions.
These selectors can be used as function pointers by the application and used
to execute these functions.  The application must declare a function pointer
with parameters as in the VME_ functions.

Example:  int (*readvme) (* parm1, *parm2 etc..);

The function pointer must be set to the selector and the function can be
called from the application.

Example:  readvme = selector;
          readvme(*parm1, *parms2 etc..);

The 32 bit selector is a direct pointer to the function.  If it is a 16:16
worker routine, then the selector will have the function number with an offse
of 0. This selector can be used by the application to call the function using
the function number with offset of zero.  Example:  If the 16 bit function
number is 273, then the function must be called using 273:0.




!OTHER__________________________________**********
November 15, 1993
QUESTION: (Ref: 195)
When I attempt to set graphics mode 12 or greater from within a DOS window I
receive the following error message:  "The system does not have emough memory
to support this OS/2 or DOS window."  at which point the DOS window becomes
suspended.

ANSWER:
This is the way OS/2 works.  If it is Dos fullscreen, it continues to work.
But if it is Dos window, it becomes suspended.




!OTHER !VIDEO___________________________**********
November 15, 1993
QUESTION: (Ref: 193)
Q1. Can we execute the mode initialization out of the BIOs?

Q2. Any thoughts?

Q3. Map a selector to the Video ROM Bios?


ANSWER:
A1. Because BIOs is Real Mode, if you are calling from Protect Mode, some
    things won't work, namely memory references using physical addresses.

A2. You should still be able to do this, but will probably need to use
    PhysToVirt to convert the addresses.  Note:  You will need some Ring 0
    code to get at the physical addresses.

A3. Use PhysToVirt or PhysToUVirt.




!I/O !OTHER_____________________________**********
November 15, 1993
QUESTION: (Ref: 190)
Questions about the async COM.SYS driver:

Q1. What is ABIOS used for in this driver?  There are lots of checks for it
    sprinkled throughout the source code, but not much actual work done with
    ABIOS.  Am I correct in thinking that the driver itself doesn't really use
    ABIOS but keeps ABIOS up to date on what the driver is doing with the COM
    ports?

Q2. Also, how many COM ports does ABIOS support?  I have found a call to
    DevHlp_GetLidEntry that gets relative entries, and I'm wondering just how
    many entries ABIOS has that it could make available.


ANSWER:
A1. Yes, your answers are correct, ABIOS is just kept up to date.

A2. 4 COM ports are supported.




!VIDEO__________________________________**********
November 15, 1993
QUESTION: (Ref: 202)
I am attempting to initialize the graphics hardware during physical_enable by
calling into the SVGA's BIOS.  The following questions relate to performing a
task switch from protected mode to real mode

Q1. Does the DevHlp service DevHlp_ProcToReal guarantee that the real mode
    thread will be the only thread executing (i.e.  It won't be interrupted?)

Q2. What ring (protection level) am I at once I've performed the task switch
    and am running in real mode?

    What is the state of the system after the task switch?  Can I just begin
    executing code or do I need to perform additional initialization prior to
    executing code?

    What are the parameters for the DevHlp_ProtToReal and DevHlp_RealToProt
    when using the DosDevIOctl function?  Are they deliniated in the DDK?

    Is "OEMHLP$" the correct file to user for the DevHlp_ProtToReal and
    DevHlp_RealToProt calls?

    Is there any example code of what I'm attempting to perform?


ANSWER:
A1. It looks like this developer is trying to force a task switch using the
    Devhlp services.  The ProtToReal and RealToProt services are only for
    temporary mode switches, and these helpers are only available at interrupt
    time.

A2. Following a mode switch to real mode, there are no rings (0, 1, 2, etc..),
    he is in REAL MODE.

    Following a mode switch, you can start executing code.  Just beware that
    your register set and all other important system data has been switched
    out along with the protected mode.  Also exit from the interrupt routine
    in the same mode as it was entered in or else you will crash the system.
    Example follows:

         Interrupt routine (this can be a timer or a set_irq):

                       Prot_To_Real

                       call your V86 code

                       Real_To_Prot     <== Do not forget this step

                       Exit

    The Prot_To_Real helper sets the Z_Flag if a mode change has taken place,
    so you would only do the Real_To_Prot if the Z_Falg is set.




!OTHER !STORAGE_________________________**********
November 15, 1993
QUESTION: (Ref: 186)
Q1. We are developing an ADD SCSI driver for OS/2 2.0.  A Presence Check
    function and a Device Driver Profile were developed to provide for
    installation of the driver.  The Presence Check function was tested by the
    'OS/2 Device Driver Installation' configuration utility during an install
    of OS/2.  The response was an error message indicating that the file could
    not be executed.

    I then tested a Device Driver Installation using the example Presence
    Check function, PC_SAMP.EXE, and the Adaptec Presence Check function,
    154XPRES.EXE.  Both of these executables were provided with the Device
    Drivers Development Kit (IBM OS/2 2.0 ADD/DM Kit).

    The response by the system was the same:  a Device Driver Installation
    Error message indicating that the file could not be executed.

    Why is the error occuring?  Is the correct installation utility being
    used?

Q2. When will the problem be fixed?

Q3. A problem has occurred when processing a request for the command
    IOCC_ADAPTER_PASSTHRU :  IOCM_EXECUTE_CDB.  This command specifies a value
    for the 'Flags' field of 'PT_DIRECTION_IN'.  Several of the SCSI commands
    received by the ADD do not transfer any data, either IN or OUT.  The
    'Flags' field needs to specify that the SCSI command is either :

        .  transferring data in,
        .  transferring data out or
        .  executing a command without data transfer.


ANSWER:
A1. I may be able to clear up some of your problems.  There are a few
    problems with DDINSTAL, but you can get around them.  What you need
    to do is make sure that the *.DDP file that you are using is in the
    same directory as the presence check executable you want to run, and
    ddinstal has to be invoked from that directory.

A2. The problem with having the presence check executable in the same
    directory as the *.ddp file has been fixed in the last build.  So now you
    can specify a valid path and file name e.g.  \os2\preschek.exe) in the
    presencecheck tag and ddinstal will execute that program whereever you
    specified it resided.  Also you no longer have to have the *.ddp file in
    the same directory as where you invoked ddinstal.  This was also fixed in
    the current driver.

A3. cSGlist == 0 indicates no data transfer should take place.




!VIDEO__________________________________**********
November 15, 1993
QUESTION: (Ref: 181)
The 32-bit PM display driver for the service pack (XR06055) that I am
developing has the following problem:

After an OS/2 application changes the default WorkPlace Shell palette, the PM
shell fails to reset to its default palette automatically when the application
is switched out of focus.  I have to bring up the task manager, then click on
the desktop background in order to force the default WorkPlace Shell palette
to be re-realized.

Is it the display driver's role to reset the palette?

Which call should the display driver issue to achieve?

When should the display driver issue that call?

The 32-bit PM display driver source is based on the IBM SVGA source that
conditionally assembles chip dependent code for various SVGA chip sets (not
the DDK 2.1 source released in Jan 1993).



ANSWER:
It is very much an implementation issue, in that the display driver 'can'
change the palette.  There is nothing in the graphics engine or PM that will
automatically change the palette when focus is changed.  Therefore it is up to
you to decide who does the job the app or the display driver.  I would suggest
that the driver should NOT be performing this function.

If the display driver wanted to reset the palette, it would use the
appropriate ring 3 API to perform the function.




!OTHER !STORAGE_________________________**********
November 15, 1993
QUESTION: (Ref: 172)
Since a scatter/gather list represents non contigous physical memory for
linear memory which appears contigous to a program, I now need to know if I
can rely on the fact that the paging has not temporaraly changed the logical
mapping by the time my driver starts some I/O.

Q1. If I have a S/G list with 4 elements and I use PhysToVirt to convert the
    1ST entry to a virtual address, will the following code work?

          mov cx,full_length_of_all_sg_entries

Q2. Will the stosb cover all of the non contigous physical memory which is
    represented by the S/G list?  Or - could the memory be disjoint to the
    stosb?


ANSWER:
A1. No...  You should process each entry of the page list...cannot do it in
    one chunk like this.

A2. You are correct in saying " could the memory be disjoint to the stosb".




!OTHER !STORAGE_________________________**********
November 15, 1993
QUESTION: (Ref: 170)
Q1. How do I get a far pointer to the buffer?

Q2. The IORB_ADAPTER_PASSTHRU only supplies a scatter/gather list of physical
    pointers.  My controller uses PIO and must use far pointers (I can't use a
    scatter/gather list).


ANSWER:
A1. Get a selector using DEVHLP PHYSTOVIRT (use physical access obtained in
    the page list).

A2. Assemble a far pointer using the MAKEP function (make p (selector,
    offset))




!VIDEO__________________________________**********
November 11, 1993
QUESTION: (Ref: 161)
How can we determine:
1) If a 16 bit or 32 Bit Graphics Engine is currently in use for the display?

2) If a 16 bit graphics engine, precisely which driver is being used?  We
   specifically wish to positively ID the IBM VGA 16 bit display driver.


ANSWER:
1) Check header bits inside of PMGRE.DLL which indicates if it is a 16 or 32
   Bit.

2) Scan DISPLAY.DLL for signatures.
   a)  Symbols / unique code sequences
   b)  or, do a CHECKSUM
   c)  You might check file size, as they should be unique and size is much
       easier to check.




!VIDEO__________________________________**********
November 11, 1993
QUESTION: (Ref: 156)
Q1. I am using the 32 bit PM source running OS/2 2.0 (CSD level XR06055), and
    32-bit Graphics Engine 2.01.1 (CSD level XR02010).

    I have a Windows application that changes the default palette.  When it
    comes into focus in seamless mode, it changes the palette display in the
    'Edit Color' pop-up of the Color Palette tool in the System Setup folder.
    Subsequently, the color is correct for the Windows application but not for
    the OS/2 desktop.  This is what I expect to see.

    When I click on an OS/2 desktop object, the OS/2 palette is not restored.
    I have to select the object, then click on the desktop background in order
    to restore the OS/2 default palette.

    Is it a bug with my palette management code?  Who is responsible for
    requesting a repaint or refresh of the palette, is it the PM driver or the
    seamless WIN-OS/2 driver?

A1. When the color was correct for the WIN/OS2 app but not for the desktop,
    that is a problem right there.  The desktop should realize its palette and
    regain correct colors immediately after the palette is changed by the
    WIN/OS2.  At this point, there is a bug probably in the drop of OS/2 you
    have.  You list revision levels for OS/2 and GRE.  (meaningless to me!)
    Try updating to the latest.
==============================================================================

Q2. Also, when the OS/2 palette is reset, it stops the Windows application
    from animating the palette.  The palette animation is resumed when the
    Windows application is brought into focus again.  Is it a bug?

A2. Palette animation is not allowed in the background because a background
    app is not guaranteed the hardware palette.  No bug.
==============================================================================

Q3. Check_hw_access and request_semaphore expects cx,dx,di and si to point to
    the cursor exclusion rectangle.  When the rectangle is not readily
    available, what should be used as the exclusion rectangle?

    This is the case in processing SEAMLESS_ESC_REQSEM and OEMSetPalette
    procedure.  "When the palette address pointer in OEMSetPalette is not
    NULL...The Windows S/L driver must take care to request the video
    semaphore prior to, and then clear the semaphore after updating the
    hardware palette."

    Or should I implement a get semaphore routine that does not call the PM
    exclusion code instead of calling request_semaphore?

A3. For the exclusion rectangle, just use the entire screen dimensions when
    you don't have an exclusion rectangle.




!I/O !OTHER_____________________________**********
November 11, 1993
QUESTION: (Ref: 155)
The PDD reference section on the async driver refers to Enhanced Mode in many
places.  The supplemental source code I have, also refers to Enhanced ports,
but the two don't seem to be talking about the same things.  The source has
indications of the Hayes ESP adapter being the "enhanced port."  The PDD ref
doesn't mention Hayes, and implies that "enhanced"is a PS/2 DMA-capable serial
port.  What is the meaning of "enhanced"?


ANSWER:
Enhanced means you have a intelligent serial board (Artic Card).




!BASE !STORAGE__________________________**********
November 11, 1993
QUESTION: (Ref: 135)
I have two questions regarding the 16 meg boundary.  We are developing a add
to support all ISA/MCA and EISA scsi host adapters.

Q1. If I report that the host adapter does not support morethan 16 megabytes
    in the get device table in the Adapter flags field, does the DMD and/or
    Kernel gaurantees that all the read/write request buffers are below 16 mb
    address.  The reason for asking this questions is, whether add should
    check the requests physical address for 16mb physical boundary ?

Q2. For certain scsi host adapters, the CCB physical address should be below
    16 meg.  During the alloc_phys call, I can either specify below 1meg or
    above 1meg.  Is there any performance impact on the system, if I allocate
    large amounts of memory below 16 meg ?  Is there any other way to get the
    memory below 16 meg ?


ANSWER:
A1. All allocations done thru 16 bit devhlps (that deal with memory, ie:
    allocphys, lock etc) will return buffers below 16 meg.  32 bit devhlps (ie
    vmalloc) allow the caller to specify if they want (need) memory below 16
    meg.  If the adapter flags field is set to not support greater than 16
    meg, the kernel will force allocations to be below 16 meg.

    If the device locks the read/write request buffers, there is no need to
    check what the physical address is, since the lock call itself will force
    the physical address below the 16 meg boundary.  If the buffer are not
    locked or locked by another device the test will be needed.

A2. AllocPhys will always return physical addresses below 16 meg.  Allocating
    large amounts of 'physical' memory will always impact the system,
    regardless of where they are.  Below 1 meg is worse than below 16 and
    below 16 is worse than greater than 16, as far as system performance is
    concerned with respect to physical allocations.  I don't understand the
    last question.  If it's talking about a device driver allocating physical
    memory, there are two ways; 1) the 16 bit allocphys call and 2) the 32 bit
    vmalloc call.




!VIDEO__________________________________**********
November 11, 1993
QUESTION: (Ref: 132)
We have separate drivers that can run full screen Windows in 1024x768 256
color mode.  Seamless Windows does not seem to know in what mode the desktop
is in.

Is there a setup parameter that must be used to tell seamless Windows what
resolution and number of colors the desktop is using, or, is there a separate
driver that needs modification to run Windows in seamless mode?  Or, is there
a module within VSVGA.SYS that must be modified to identify the PM mode and
return the information to seamless Windows?


ANSWER:
Reference the _SM_WINDRV structure in the SEAMLESS.INC file located in
\DRF6\SRC\VGA32\VGAINC directory where you can do do any one of the following
at the time of DeviceSeamlessInit:

   1.  Modify the signature field of the structure to indicate the
       PM Desktop resolution. For example, use "VG10" to indicate
       1024x768 resolution, etc.

   2.  Add resolution and color information at the end of the structure.




!OTHER STORAGE__________________________**********
November 11, 1993
QUESTION: (Ref: 140)
We have four questions regarding using DOSxxx API calls.  We need to display
messages from the ADD during the task time and interrupt time after
Initialization.  We know that we can not use DevHelp_Save_Message after
initialization.  We also realize that we can not make DOS API calls during
base driver init time.

Q1. Can we use DOSAPI call DosPutMessage during task time and interrupt time
    from the ADD?

Q2. In which library are DOS API calls built in ?

Q3. How do they interface with the kernel ?

Q4. Is it the same way as DevHelp calls ?


ANSWER:
A1. No, physical Device Drivers are only able to use the DEVHELP API's after
    INIT time.

A2. Available from PDK, but once again, only good for applications.

A3. Ring 3 call gate.

A4. No, DEVHELP is a single call gate at RING 0.




!OTHER !STORAGE_________________________**********
November 11, 1993
QUESTION: (Ref: 125)
When writing a device driver, debug output to the COM port can be done by
direct IO_ADDRESSING as shown in the routine DPRINTF belonging to the SCSI
"ADD" device driver.

Is this the only way of accessing the COM port from a device driver without
loading any serial communication driver?


ANSWER:
From a device driver, the only way is to write to the COM port directly.

DPRINTF is an internal function of the SCSI "ADD" device driver.  All DPRINTF
does is write to COM port with OUT instructions from the device driver.  So,
there will be no access control.




!BASE !VIDEO____________________________**********
November 11, 1993
QUESTION: (Ref: 121)
If I move, resize or maximize a Windows application, it will result in hanging
OS/2.  The cursor remains active and stays as a MS Windows cursor.  All
processes are blocked.  Eventually I'll get the following message in the
debugger:

   DelayHardError SYS3175: 4 string(s):
   Pid 0002 Tid 0016 Slot 002b HobMte 00e8
   c:\os2\pmshell.exe
   c0000005
   15b67491
   P1=00000000 P2=ffffffff P3=XXXXXXXX P4=XXXXXXXX
   EAX=00000000 EBX=15bc0033 ECX=00020001 EDX=9bff0000
   ESI=00030147 EDI=00030098
   DS=0053 DSACC=d0f3 DSLIM=1bffffff
   ES=0053 ESACC=d0f3 ESLIM=1bffffff
   FS=150b FSACC=00f2 FSLIM=00000030
   GS=0000 GSACC=**** GSLIM=********
   CS:EIP=005a:15b67491 CSACC=d0df CSLIM=1bffffff
   SS:ESP=004a:01363fa4 SSACC=d0d3 SSLIM=1bffffff
   EBP=01363fbc FLG=00012297

   IBMVGA32.DLL 0002:00007491

Another problem I have is the screen is occasionally corrupted with a
rectangle that looks like the cursor mask.  The rectangle itself is corrupted.
If I do not move the cursor, then the corruption will not occur.


ANSWER:
You need to make sure that the PM Device Driver's data and code is being
mapped properly.  When we were developing the first seamless Device driver, we
ran into memory corruption problems were we were mapping to the wrong place in
PM (i.e.  the HeartBeat variable pointer was referencing a different area of
memory in the PM driver).

As far as the mouse goes, make sure that you disable ANY mouse operation in
the Windows Device Driver.  All of the mouse drawing functions are done in the
PM side.




!STORAGE________________________________**********
November 11, 1993
QUESTION: (Ref: 115)
If the ADD can be entered in both Kernel(task) and Interrupt contexts, and the
address to the SCSI sense data passed in the Status Block is a virtual
pointer, how can we guarantee that we can get the a physical address pointing
to the sense data?

Since you cannot perform a VirtToPhys in interrupt context, you might not be
able to get the physical address to the SCSI Sense Data!  This is a major
problem for those controllers that do not automatically retrieve Request Sense
data and are DMA or Bus Master controllers.

What we have come up with is to set up a local data area for each device that
we can get the physical address of at init time and use that for SCSI request
sense data.  This is problematic due to the fact that we have to allocate a
buffer large enough for the largest possible Status Block/Sense Data request
and how large should that be?


ANSWER:
Refer to DMCSUBR.C(VirtToPhys) in dk_adddm\src\dev\dasd\os2dasd for an
alternate method of calculating physical addresses which is context
independent.




!OTHER__________________________________**********
November 11, 1993
QUESTION: (Ref: 112)
Q1. Why is there no reference in the include files to DosSMRegisterDD?

Q2. The SMDDData structure is not defined in any include files that I could
    find - is it anywhere or do I have to do that myself?.

Q3. DosSMRegisterDD is in os2.lib (under MSC6.0) but does not exist in
    OS2386.lib (in the OS/2 2.0 toolkit).


ANSWER:
A1. Any 16-bit calls referenced in the include files will be listed as
    Dos16Xxxx rather than DosXxxx.  These Dos16Xxxx calls are thunked to their
    16-bit counterpart.  If you want to use this call, you will have to use
    the 1.3 toolkit.

A2. It is called "RegisterData" and is in DOSCALLS.H.

A3. OS2386.LIB includes the 32-bit calls, including Dos16SMRegisterDD.
    OS2286.LIB includes the 16-bit calls, including DosSMRegisterDD.



!STORAGE________________________________**********
November 11, 1993
QUESTION: (Ref: 105)
Q1. Can we tell OS/2 (somewhere in the config.sys file) not to take over all
    the devices on the SCSI bus ?

Q2. Supporting IOMEGA devices on SCSI Adapters that OS/2 has built-in support
    for (eg.  Adaptec-1520, Adaptec-1640, etc ):

    Under these circumstances the SCSI Adapter normally does not have a hard
    disk but may have CD-ROMs or other SCSI devices.  We would like to know if
    we could shut off OS/2's built-in support for the adapter altogether.  We
    may then replace the support with our own driver software.


ANSWER:
A1. For the IBM2SCSI add, support may be disabled on a per adapter basis by
    specifying:

    BASEDEV=IBM2SCSI.ADD /A:0 /I

    where /A:x indicates the adapter number.

A2. ADD support for other adapters may be disabled by removing the
    corresponding BASEDEV stmts from CONFIG.SYS.

    We would encourage you to write a FILTER ADD to support removable
    partitioned media rather than trying to disable/replace components of the
    DASD subsystem with your own components.




!STORAGE________________________________**********
November 11, 1993
QUESTION: (Ref: 098)
Q1. Is there a CDROM development package similar to the one for SCSI?

Q2. Assuming that the OS2CDROM.DMD is a device manager driver and not a class
    driver:
       - Is the interface specifications to the existing OS2CDROM device
         manager official, or do I have to write my own manager?

Q3. In case the existing OS2CDROM device manager can be used, do the existing
    CD-ROM class driver and the virtual driver stay unchanged?

Q4. For the OS/2 Windows mode, should standard MS.  Windows drivers and
    matching virtual drivers work without any modifications?

Q5. What other technical manuals other than the PDD, VDD, and PM ref.  do you
    recommend when writing a proprietary CD-ROM device driver for OS/2.


ANSWER:
A1. Yes, on the 02/93 release of the DDK.

A2. The name of the CD-ROM device manager is OS2CDROM.DMD.  It is included in
    the OS/2 2.1 beta and replaces the CDROM.SYS driver which shipped in 2.0.
    The IOCTL definitions for the CD-ROM device driver is currently published
    in the IBM PS/2 CD-ROM II Technical Reference (pub order number
    S10G-3359), which is a hardware tech ref.  It is currently not published
    in the OS/2 tech refs, but will be included in the future.

A3. Yes

A4. Yes, If using full screen.

A5. The on-line SCSI documentation.  The Storage Device Driver Reference
    manual available on the DDK.




!OTHER !VIDEO___________________________**********
November 11, 1993
QUESTION: (Ref: 094)
What could have prevented a Windows driver that runs in full-screen WIN-OS/2
session from reaching Enable() in a windowed WIN-OS/2 session (I assume that
Enable() is the first device driver routine that GDI calls upon)?

If Enable() is never called in a windowed session, does it mean WIN-OS/2 has
failed to load the windows driver?  If so, what could have prevented the
windows driver from being loaded?  Does WIN-OS/2 expects the binary code of
the Windows driver to follow certain format to determine wether it is a valid
seamless Windows driver?

Answer:
There are two possible problems here:

When you attempt to start a "seamless" session the driver that gets loaded is
the "sdisplay.drv=" driver in the SYSTEM.INI file in your OS2/MDOS/WINOS2
directory, NOT the "display.drv=" driver.  It is possible that your drivers
name just needs to be listed in the correct field in the SYSTEM.INI file.

The first thing to get called in a windows driver is actually
DRIVER_INITIALIZATION not ENABLE.  There may be a problem there.



!I/O !OTHER_____________________________**********
November 11, 1993
QUESTION: (Ref: XXX)
The PenPM Device Driver Reference manual lists the following as related
documents:

  - PenPM Programming Guide and Reference

  - PenPM User's Guide

  - PenPM Developer's Toolkit: Getting Started


ANSWER:
The name "PenPM" was changed at the last minute to "Pen for OS/2". The
PenPM Developer's Toolkit.... manual was never released. The remainder
of the documents are available as listed below.

Ordering Pen for OS/2 Publications:

 - The User's Guide is only available when you purchase the Pen
   for OS/2 product (61G1171). To order, call 1-800-3IBMOS2.

 - The Programming Guide and Reference and Device Driver
   Reference are available on CDROM as part of the Developers
   Connection for OS/2.  To order, call 1-800-633-8266.

 - The Device Driver Reference is available on CDROM as part of
   the IBM Device Driver Source Kit for OS/2.  To order,
   call 1-800-633-8266.  You can also purchase a hardcopy
   version of this book separately through puborder.
   The order number for this book is S71G-1899.

NOTE:  Internal customers can get the Pen for OS/2 product and
       documentation from OS2PROD.  (The User's Guide is
       available without artwork.)




!BASE !OTHER____________________________**********
November 10, 1993
QUESTION: (Ref: 572)
It would be VERY helpful to have an API to grab the NMI just like there are
for the normal IRQS.  We have an application that must get immediate
notification, regardless of the IRQ state.  Windows has a defined interface
that we use.

The functions would probably be something like:

   SetNMI, UnSetNMI and a DismissNMI.

All this can be done at ring 0, but it would be nice if there were an API to
do it.

ANSWER:
Ring 0 code can register to get control on an Interrupt from a particular IRQ
- effectively the code registers as an interrupt handler.  There is no
equivalent Ring-3 interface.

NMIs are not like IRQs.  NMIs are TRAPs, like executing invalid instructions.
There are 4 reasons for NMIs.  Parity error on the planar, Parity error on an
adapter card, Channel DMA Timeout, Watchdog Timeout.  I can not envision why
we would want to give an application or device driver control for any of the
1st 3` failures.

My guess is that Windows has an API to handle the 4th, Watchdog Timeout.  A
Watchdog timeout says that some piece of software has stayed disabled past a
specified time.

The system state at NMI is disabled for all interrupts, ring-0, running under
the trap handler.  In windows, an application may disable.  In OS/2, Ring-3
apps do not have that capability.

It would be interesting to understand how valuable this API is to Ring-0 code.
I do not believe there is any chance we would risk system stability by giving
a Ring-3 app control out of the Trap handler.




!OTHER !VIDEO___________________________**********
November 10, 1993
QUESTION: (Ref: 317)
I'm now working on DSPINSTL for DMQS.  I looked at the source code for the
DSPINSTL Action routine and found structures for DMQS.  The functions in the
DLL don't use them.  The documents for DSPINSTL that is in the on-line help
doesn't have any info for making a DSPINSTL that works with DMQS.

It seems like the code for DMQS is being implemented in DSPINSTL.  If this is
true, I just need some documentation from the developers.  Otherwise, I need
to know how and where to add in the list of supported monitors.  I assume we
need to open up a window (Display Device window?)  which reads in the monitor
structure from MONITOR.CFG and displays the monitor strings?


ANSWER:
DSPINSTL copies DMQS files onto the startup drive if the files are defined as
part of the bundle for a specific driver.

DSPINSTL does not "use" DMQS".  DSPINSTL has a requirement to identify the
adapter during initial installation.  They (the IBM developers) experimented
with DMQS but now rely on base video routines, which they copy into their
code.




!VIDEO__________________________________**********
November 10, 1993
QUESTION: (Ref: 245)
Question regarding VDD Mode Setting for the driver:
---------------------------------------------------

I am currently experiencing the following problems which I believe to exist in
the VDD portion of the video driver:

A) When switching between a full screen Win-OS/2 session (with background
execution turned off) and the PM Desktop screen corruption occurs.  This is
using OS/2 2.0 without the Service Pak loaded.

B) If the Service Pak is loaded, and currently in a full screen Win-OS/2
session (with background execution turned off), I can not switch to the PM
Desktop by clicking on the Desktop icon.  It will only switch to the PM
Desktop when the Alt-ESC or Ctrl-ESC key sequence is pressed.  There is never
screen corruption in this case.  If the full screen Win-OS/2 session is closed
by clicking on the upper right hand corner, it will successfully return to the
PM Desktop without any screen corruption.

C) Currently, background execution must be turned off in the Win-OS/2 settings
to prevent a large amount of screen corruption.  I believe that the VDD is not
currently implemented correctly, and that it should work fine with background
execution turned on.  The VDD does not currently use the "SVGADATA.PMI" file
information.  All of the DOS full screen and windowed DOS sessions run without
any problems or screen corruption.

Given the above information/problems, I have the following questions:

Q1. What parts/functions in the VDD driver code are responsible for Win-OS/2
    screen switches?

Q2. What part/functions in the VDD driver code are responsible for switching
    to the PM Desktop from a full screen Win-OS/2 session?

Q3. Where may I find information on how to correctly implement the
    "SVGADATA.PMI" file for the VDD driver for OS/2 2.0?  Since the VDD is a
    very complex piece of code, it would be very helpful if you could shine
    some light in this area so that these problems may be corrected.


ANSWER:
A1. The screen switches are handled by the VVideo code.  The VVideo code maps
    a portion of memory for use as a logical video buffer used to store screen
    states for the switch.  I would suggest that he is probably corrupting
    this buffer.

A2. Same answer as A1.

A3. SVGA.exe source available in DDK Version 1.0.  Look there.




!OTHER__________________________________**********
November 10, 1993
QUESTION: (Ref: 579)
The reason I was having problems is that all examples use LINK.EXE with
OS2.LIB to make the DLL (SYS).  I use LINK386.EXE and I have NO LIB's.

The question is:  What products supply OS2.LIB?


ANSWER:
As you know, LINK.EXE is a 16-bit linker and LINK386.EXE is 32-bit. The
original OS2.LIB (16-bit) was on the OS/2 toolkit. OS2.LIB has been replaced
by the two files OS2286.LIB and OS2386.LIB in the latest toolkit. OS2286.LIB
is for 16-bit and OS2386.LIB is for 32-bit.

These files are available in the following products:

         OS/2 Toolkit
         OS/2 Developer Connection (which contains the toolkit)
         Device Driver Source Kit (DDK) in the directory DDK\LIB




!OTHER !VIDEO___________________________**********
November 10, 1993
QUESTION: (Ref: 576)
I was trying to make SVGAINST.DLL  from DDK 1.0.  But I found out that I need
a tool ICC (I think it is a C compiler) to make it.  Any idea where can I find
it?


ANSWER:
The tool that is being referred to is IBM C Set/2, NOT C/C++.  It should be
available commercially.  However, the IBM C/C++ compiler is a replacement for
the IBM C Set/2 product.




!OTHER__________________________________**********
November 10, 1993
QUESTION: (Ref: 320)
Subject: Problems with C/Set 2

Apparently the VDD .H files that are provided on the DDK CD are for the
Microsoft compiler.  Since we are using the C/Set 2 compiler (386) we had to
hack the .H files to make them work with C/Set 2.

I would like you guys to provide both types of H files on this BBS and the
next DDK CD.


ANSWER:
He is not out of line asking this question.  However, he probably does not
understand the current mission of the DDK.

The DDK is meant to provide examples or sample code for the device driver
developers.  This extends to virtual driver development as well.  We are not
chartered to re-write any of the internal drivers in IBM, so we put the code
on the CD as we receive it from the development groups.  We do require that
the developer have MSC in some cases, and in others we require C/SET 2. This
is all based on the development groups original device driver.

It would be nice if the DDK was uniform in the compilers it required, but we
can not be since the drivers were developed over distinct time spans and
requirements.  Also, we do not wish to provide working drivers for outside
development teams.  We only want to provide working samples of current
drivers.

If they (outside developers) have problems converting the current code to a
different compiler, they will have a lot more trouble developing their own
presentation or physical device driver.  It would be nice to do more for the
developers, but there is a limit on current resources.  If we do get drivers
with both types of compilers we will provide them both.

In the next release of the DDK (V1.0), we will be providing a sample VDD with
C/SET 2's next release of compiler.  Hopefully, this will be satisfactory.  We
will not be converting any of the current virtual drivers (video) to C/SET 2
for the next DDK.  Hope this answers your questions.




!BASE !I/O______________________________**********
November 10, 1993
QUESTION: (Ref: 324)
The System Crash and Burns on the MoveData Call.  The calls before that all
show no errors.  Could you address the following questions?

Q1. In the C-Set App do I have to use a Memory Alloc function or can my Struct
    exist in my app ie.

           Type A:
                AD_CONFIGURATION        *ad; [ then use some Memory Alloc
                                               function to grab memory ]
           Type B:
                AD_CONFIGURATION         ad; [ this stands alone ]


A1. The structure can exist in your application (statically allocated).  Or
    you can dynamically allocate it using one of the memory allocation calls.
    It all depends on the buffer size, number of buffers, design, etc.
==============================================================================

Q2. When I call DosDevIOCtl and send the Address of my structure [ ( PVOID )
    ad {Type A} or ( PVOID ) &ad {Type B} ] when it ret from the Dev Drv at
    VirtToPhys call what level of indirection is it [ ie.  pointer to a struct
    - pointer to a pointer to a struct - pointer to a pointer to a pointer to
    a struct ] ?


A2. You should be passing a pointer to the structure.  After the VirtToPhys
    call, you have a 32-bit physical address to the structure.
==============================================================================

Q3. After the VirtToPhys do I have an Address that is LIVE, or are futher
    translations necessary ?  Another words can I directly access this struct
    in equates ?


A3. After the VirtToPhys call you have a 32-bit physical address to the
    structure.  Before the call, the device driver can move data into the
    structure using the virtual address, after the call the device driver can
    move data into the structure using the virtual or physical address.  The
    only reason to use the physical address is when the hardware needs the
    physical address for direct memory access (DMA) or busmaster.
==============================================================================

Q4. Should the Pointer I send to the Dev Drv ( in the DosDevIOCtl call ) be a
    32 bit flat memory pointer or a 32 bit Seg:Off pointer ?


A4. The Seg:Off address is refered to as a 16:16 address, not a 32-bit
    address.  I am assuming the application is a 32-bit application, therefore
    the pointer to the static data is a 32-bit flat address (PVOID).
==============================================================================

Q5. If I save the Incomming address ( after VirtToPhys ) is it still
    accessable after the UnPhysToVirt and UnLockSeg calls ?


A5. You do not need to issue UnPhysToVirt in OS/2 2.0 or 2.1.  When you issue
    UnLockSeg, the memory area can be swapped out to disk.  When you try to
    access it using the physical address, the code will access whatever
    currently existing at that memory location (probably not what you expect).
    When you try to access the structure using the virtual address, the
    swapper detects that the memory object is not resident, loads it into RAM
    (probably not at the same physical address).  So the physical address is
    not guaranteed to be valid after you unlock the memory so don't use the
    physical address.
==============================================================================

Q6. When I put data into the C-Sets's buffer at Interrupt time do I use
    equates ( ie *buff_add = value ) or do I have to use a DevHelp function ?


A6. At interrupt time, you can move the data directly into the memory
    allocated by the definition of the variable.  Who is moving the data into
    the buffer, the processor or the DMA controller?  If the DMA controller,
    then you need to program it using the physical address returned from the
    PhysToVirt call.  If the processor is moving the byte into the memory then
    use the virtual address (*buff_add = value).  The one item to make sure of
    is that the buffer is locked into memory, then the device driver can use
    either the physical or virtual address to access it.




!I/O____________________________________**********
November 10, 1993
QUESTION: (Ref: 329)
Subject: Send key to VDM

We are designing a automation system that needs to be able to send key stroke
to Virtual Dos Machine under OS/2 2.0 and 2.1 as well. My understanding of
Virtual Device Driver is that VDD gets key stroke from PDD. OS/2 application
can communicate with VDD using DosRequestVDD API. The question is, can we use
DosRequestVDD just like PDD use VdhRequestVDD to send key over.

ANSWER:
The answer is Yes, he should be able to use DosRequestVDD to send the
keystrokes in like VdhRequestVDD.  But, note that hotkeys(like Alt-Home) will
not work when sent in this way.




!VIDEO__________________________________**********
November 10, 1993
QUESTION: (Ref: 297)
DSPINSTL.EXE from 6.514 does not work the same as 6.498

I have a set of .DSC and .DSP files that I am using to install my 32 bit SVGA
drivers.  I have two problems that have surfaced:

1. Using the example DSC/DSP files that I have included, everything is fine
   under ServicePack(6.427) and March Beta (6.498).

If the latest code is used (Gamma 6.514), the following the sequence of events
happen:

           a. DSPINSTL reads \OS2\INSTALL\*.DSC files
           b. User selects my OEM .DSC selection
           c. A window confirming source and destination directories
              is displayed.
           d. Selecting the "INSTALL..." button from that menu dumps
              the user back to the command prompt.  No warning or
              error messages are displayed.  No log file entries
              are made.

It looks like the optional "Action DLL" is now a requirement.  Is this true?
If so, it sure would be nice if you would send a notice to a list of people
known to be developing SVGA drivers for your product.

2. How do you get DSPINSTL.EXE to look to drive A:  for .DSC files?


ANSWER:
After placed a volumn label into the .DSC file, your problems disappeared.




!VIDEO__________________________________**********
November 10, 1993
QUESTION: (Ref: 284)
I need to configure DSPINSTL to handle installation from multiple source
diskettes but I can't get the thing to do what I want:

I'm using DSPINSTL from (basically) the Service Pak.

If I place all the .DSP files on the first diskette, DSPINSTL aborts when I
choose an option requiring drivers from the second diskette.  It reports that
it can't find the file it needs in the current directory.  (Of course not!)

If I place the .DSP files on the same diskettes as the drivers they install
(which, as I read the in the DDK, is what I'm supposed to do) then DSPINSTL
reports "A display profile (.DSP) file could not be found in the source
directory."  And when the user then clicks on OK, the only option available,
he/she is dropped back to the "Specify Source Directory" dialog box.  This is
totally unsatifactory as an end-user prompt.

What I want DSPINSTL to do is to say "Place (your source message here) into
Drive (your drive) or change to the directory containing display drivers for
(your resolution here)."  That's what the DDK docs imply is supposed to
happen.  How do I make it happen?


ANSWER:
The volume label of the diskette, where the code resides, needs to be entered
in the .DSC file.




!VIDEO__________________________________**********
November 10, 1993
QUESTION: (Ref: 273)
I'm modifying the DLL for the DSPINSTL utility to have it display and install
our supported drivers according to the video memory size and chip set.

The DSPINSTL shows the correct resolutions and copies the drivers specified in
the DSP files.  It then gives me an error message "A display profile (.DSP)
could not be found in the source directory".  I verified the DSP files, and
they are present in the source directory.

Can you please tell me what I'm doing wrong ?  I tried to search through the
DLL code for the error string above, but couldn't locate it.


ANSWER:
Your problem was that you were only using one .DSP file per resolution.  Since
your files spanned two diskettes, you need one .DSP file on each of the two
diskettes.  Each .DSP file needs to be tailored to the files that are
contained on that particular diskette.




!STORAGE________________________________**********
November 10, 1993
QUESTION: (Ref: 232)
The following pertain to a proprietary SCSI disk controller.

Several aspects of the ADD specification are unclear.  Please provide
clarification to the following issues.

Q1. The purpose of several of the ADAPTERINFO fields is unclear.  The values
    in these fields are not placed in any IORBs from the Device Manager Driver
    (DMD):

        AdapterDevBus
        AdapterIOAccess
        AdapterHostBus
        AdapterSCSITargetID
        AdapterSCSILUN

    Do these values effect the generation of IORBs or the execution of a
    Device Manager Driver (DMD) ?  If so, how?


A1. The customer said " The values in these fields are not placed in any IORBs
    from the Device Manager."  Does it mean that the customer thinks the ADDs
    get these parameter from DMDs ?  If they think that, it is wrong.

    These fields should be filled up by ADDs, not DMDs.  Only ADDs knows
    adapter parameters.  Anyway, some of them are used in DMD.  For example
    AdapterDevBus is used in OS2DASD, and AdapterSCSITargetID is used in
    OS2ASPI.  And some of them are not used in any DMD.  In DDK, OS2DASD and
    OS2ASPI source code are included.  The customer can take look at them.
==============================================================================

Q2. The purpose of several of the UNITINFO fields is unclear.  The values in
    these fields are not placed in any IORBs from the Device Manager Driver
    (DMD) :

        UnitSCSITargetID
        UnitSCSILUN
        QueuingCount

    Do these values effect the generation of IORBs or the execution of the
    DMD?  If so, how?

    Our disk controller has multiple SCSI buses under its control.  A SCSI
    device is uniquely identified by a bus number and a SCSI target ID.  Is
    the UnitSCSITargetID value ever used to identify a device?

    If so, it will not adequately identify a device on a Tricord SCSI
    controller.


A2. These parameters also should be filled up by ADDs.

    UnitSCSITargetID is used for physical unit number which returns to the
    device- class driver in OS2SCSI/OS2ASPI.

    UnitSCSILUN is used for logical unit number which returns to the
    device-class driver in OS2SCSI/OS2ASPI.

    QueuingCount is used in OS2DASD to know how many more IORB OS2DASD can
    send to ADDs.

    UnitSCSITargetID means physical device ID which is connected with SCSI
    adapter card and each physical device has multiple logical devices (
    Maximum 8 ). This logical device is UnitSCSILUN.  In their case can they
    identify the device uniquely with these two numbers?

    I thought about it by myself.  If there are two SCSI buses and one bus has
    two physical devices and the other SCSI bus has two physical devices, I
    can think the following two ways to identify the device.

    CASE 1:
    AdapterSCSITargetID   SCSI busID     UnitSCSITargetID   UnitSCSILUN
    --------------------------------------------------------------------
         7                   0                0                 0
         7                   0                1                 0
         7                   1                2                 0
         7                   1                3                 0


    CASE 2:
                          (SCSI busID)
    AdapterSCSITargetID  AdapterSCSILUN   UnitSCSITargetID   UnitSCSILUN
    -----------------------------------------------------------------------
         7                   0                0                 0
         7                   0                1                 0
         7                   1                0                 0
         7                   1                1                 0


    In CASE 1, ADD has to handle the multiple SCSI buses by itself.
    In CASE 2, I recognized that SCSI bus ID is equivalent to AdapterSCSILUN.

    Each SCSI bus and the units associated with it should be reported out as a
    separate AdapterInfo structure followed by UnitInfo structures.

    In AdapterInfo structures (following the first for the adapter), the bit
    AF_ASSOCIATED_DEVICE_BUS should be set in the AdapterFlags to indicate the
    additional AdapterInfo structures are bound to a single adapter.

    (NOTE:  The information about AF_ASSOCIATED_DEVICE_BUS is available in
    Storage Device Driver Reference on DDK#2.)
==============================================================================

Q3. The purpose for some the the IORBs sent by Device Manager is unclear.
    With 2 drives in the system, the DMD sends the following sequence of
    IORB's :

        Command                  Modifier              Unit      Flags

        IOCC_CONFIGURATION  IOCM_GET_DEVICE_TABLE       0          0
        IOCC_CONFIGURATION  IOCM_GET_DEVICE_TABLE       1          1
        IOCC_UNIT_CONTROL   IOCM_ALLOCATE_UNIT          0          1
        IOCC_UNIT_CONTROL   IOCM_ALLOCATE_UNIT          1          1
        IOCC_GEOMETRY       IOCM_GET_DEVICE_GEOMETRY    0          1
        IOCC_GEOMETRY       IOCM_GET_DEVICE_GEOMETRY    1          1
        IOCC_CONFIGURATION  IOCM_GET_DEVICE_TABLE       0         10
        IOCC_CONFIGURATION  IOCM_COMPLETE_INIT          0          0

    Why is the command modifier IOCM_GET_DEVICE_TABLE called 3 times?

    Why do the 'Unit' and 'Flags' fields change each time it is called?

    Is some different action required by the ADD each time it is called?


A3. I wonder how many device managers are installed when they test it.  In my
    understanding, the device manager calls ADD with IOCM_GET_DEVICE_TABLE
    just once at initialization.  I guess the customer installed three device
    managers.

    The first one may be called by OS2SCSI.DMD, because the value of the
    request flag is zero.

    The second one is called from OS2DASD.DMD, and it recognized two logical
    devices from device table, and it calls ADD with IOCM_ALLOCATE_UNIT twice.
    In OS2DASD's case it always set IORB_ASYNC_POST in request control.
    That's why they always get 1 in the flag.

    The third one is called by the third device manager, I guess.  And unit
    handle is just named by the device manager for communication purpose,
    uniquely for each device.  In their case OS2DASD got two unit tables by
    IOCM_GET_DEVICE_TABLE, and named them 0 and 1.

    About IOCM_COMPLETE_INIT, as far as I know, no device manager calls ADD
    with IOCM_COMPLETE_INIT.
==============================================================================

Q4. The ADD being developed is defined so that it will be called by the OS/2
    kernel when shutdown is being performed.

    When shutdown is being performed, the ADD's Strategy 1 routine is called
    twice.

    Why is the Strategy routine called 2 times?

    What stage of shutdown is being executed each time it is being called?


A4. On page 15-23 of the PDD Reference manual, the IBM Strategy Command
    1CH/SHUTDOWN is described.  There is a remark which says that "Each device
    is called twice.  On entry of the START SHUTDOWN call, the function code
    is set to 0. On entry of the END SHUTDOWN call, the function is set to 1."
    Some of ADDs do not support this function.
==============================================================================

Q5. The source code for the IBM ADD 'IBM2SCSI.ADD' is used for reference when
    developing our ADD.  However, our SCSI disk controller is used in a
    Non-ABIOS machine.  As a result, it is not always clear what functions are
    to be performed by the ADD for certain IORB commands.  In particular, it
    is not clear what is to be done for :

         IOCC_DEVICE_CONTROL     IOCM_ABORT              and
         IOCC_DEVICE_CONTROL     IOCM_RESET

    Please explain the required functionality of these 2 commands.


A5. IOCM_ABORT => Abort both of the active and queued IORB requests.
                  This request must be handled immediatly.
                  For the queued IORB, ADD can handles in its code, and the
                  way to cancel the active IORB shouled be defined in the
                  customers specification.  The IORB which is aborted returned
                  with IOERR_ CMD_ABORTED.

    IOCM_RESET => Send reset command to the device.  This interface should be
                  in the customers H/W specification.
==============================================================================

Questions 6 & 7 seem to be similar.  It is not easy to seperate the answers,
so they are being rolled together.


Q6. Several of the ADD command line parameters require a specific device unit
    to be identified.  This is true of the /SM and /DM parameters.  The units
    are identified by a SCSI Target ID or a (SCSI Target ID, SCSI LUN) pair.

    Our disk controller has multiple SCSI buses under its control.  A SCSI
    device is uniquely identified by a bus number and a SCSI target ID.

    It is not possible to idenitfy a unit by just a SCSI Target ID or a (SCSI
    Target ID, SCSI LUN) pair.

    Is it possible to use an alternative syntax to specify units?


Q7. The purpose of the ADD command line parameter for 'Adapter
    Indentification' is unclear.  There appears to be no purpose to specifying
    the '/S:d' or the '/P::hhhh'.  It is not clear why it would be necessary
    to reorder the adapters.

    The only purpose for the '/A' parameter appears to be to indicate a
    specific adapter for unit parameters which follow on the command line.

    Please clarify the purpose of the 'Adapter Identification' parameters.


A6. (Also see answer 2) Support /S:  and /P:  parameters are optional.  In
A7. general SCSI adapter suppliers scan their adapters in a predetermined
    order so that /S:  and /P:  are not implemented by most SCSI ADD drivers.

    Command Line parameter formats for multiple-bus adapters have not been
    finalized at the present time.  It is recommended in the interim that each
    bus be reported as a separate adapter, i.e with its own /A:  entry.

    For ex:
    BASEDEV=MYADD.ADD /A:0 /!SN /!DM:(1,0) /A:1 /!DM:2




!STORAGE________________________________**********
November 09, 1993
QUESTION: (Ref: 234)
We are developing an ADD SCSI driver for OS/2 2.0 for a proprietary SCSI disk
controller.  Several aspects of the ADD specification are unclear.  Please
provide clarification to the following issues.

     The IORB field 'Flags' can be set to IORB_CHAIN.  This indicates
     that 2 or more IORB's are chained together.  All of the IORB's are
     for the same unit.

     Under what circumstances are IORBs chained?  What causes them to be
     chained together?

     Must they be returned by the ADD to the DM as a chain?  Must they be
     returned at the same time?

     Must the IORBs be executed in the same order as the chain order?  What
     problems will result if they are not executed in that order?


ANSWER:
Right now OS2DASD sends IORB with IORB_CHAIN only when it sends IOCC_EXECUTE_
IO command.  This is for performance improvement.

Generally the device manager gets QueuingCount of each unit at initialization.
The device manager knows how many IORB ADDs it can queue.  When the ADD gets a
chained IORB, it just puts the IORB into the queue and processes it normally.
This means that the ADD processes each of IORBs and returns to the DMD each
time.

To determine how the IORB gets picked up from the queue and the order to pick
up IORB, the customer should refer to the IBM2SCSI.ADD source code.




!VIDEO__________________________________**********
November 09, 1993
QUESTION: (Ref: 229)
Q1. OEMDrawBits
     How do we test this?
     We've run all the programs in the DDK, PDK, prodtools, DTT, etc,
     but nothing calls the OEMDrawBits entry point.

     Is there an application that tests this?

   * (The customer has modified our drivers to work on his cards. The problem
     is that he needs to know when OEMDrawBits is called so that he can test
     his driver. I believe he said the entry point is in IBMDEV32.DLL. On the
     DDK, the reference to OEMDrawBits is in the DRAWBITS.ASM file.)

A1. You will need to write a program which will draw points on the screen.
==============================================================================

Q2. DSPRES.DLL
     How do we build this?
     How do we get the source code, resource scripts, etc?

   * (The customer changed the source and compiled IBMDEV32.DLL, IBMVGA32.DLL,
     DISPLAY.DLL, and DSPRES.DLL. They are not sure what DSPRES.DLL is and
     want to know if they need to modify it. If so, how?)

A2. DSPRES.DLL has all of the font handling routines for the driver. This was
    created in the 2.1 OS/2 release to offload some of the font overhead from
    the main driver DLLs. These routines should not require any modification.
    There will be a complete discussion of this DLL in the new Display Driver
    reference book due out with the May DDK (v1.0).

    The DSPRES.DLL contains no code...  none what so ever.  It contains font
    resources only (and is therefore owned by the group that owns all the
    other fonts).

    DSPRES.DLL was created for a number of reasons:

      - Remove all the font resources from the display drivers.

      - Introduce consistency between drivers so that they all use the same
        fonts and they all look the same.

      - Reduce the size of the display drivers on diskette -- when the fonts
        were included within the driver we would have much larger DLLs for
        each display driver.

    The contents of DSPRES.DLL are loaded by display drivers with the
    DosGetResource API call, the parameters that are needed for this are
    documented in the file DSPRES.RC (from /drf6/src/isofonts directory) which
    should be part of the DDK.  As I said, there is no code in the DLL only
    font resources, so there are no entrypoints to call.

    In most cases a display driver developer should not need the source to
    this DLL, we expect and encourage them to use the fonts contained in
    DSPRES.DLL (for reasons of consistency, etc).

    HOWEVER...  the developer may be getting ahead of us.  Our DSPRES.DLL
    contains only fonts appropriate for display resolutions up to 1024x768.
    If someone is creating a driver for 1280x1024 or 1600x1200 resolutions
    then there is a need to add additional fonts to DSPRES.DLL (the fonts will
    be larger and so will significantly increase the size of the DLL).  In
    this case we have some choices.

    A) Release the source to DSPRES.DLL so that the developer can add the
    fonts he needs for the higher resolutions.  Developer must be encouraged
    not to remove any existing fonts, change their resource ID assignments, or
    change the design.  We should also encourage them to return to us any
    additional fonts that he defines so that we can role them into our
    DSPRES.DLL.

    B) Create a new DSPRES.DLL ourselves (so we keep control) with larger
    fonts and release it.  We need to do this anyway because the S3 drivers
    that we are working on are going to work at higher resolutions and so will
    need bigger fonts.  I think we have some larger fonts lying around that we
    can use, but we should probably formally ask Neil Clark (in Human Factors)
    to supply them so that they are consistent in design to the current fonts.

    Because (B) will take time, we may want to do (A) in the interim -- but
    make sure that we control the resource IDs assigned to the larger fonts.

    Other than adding larger fonts, there is no reason what so ever to release
    the source to DSPRES.DLL.
==============================================================================

Q3. VGA vs. SVGA
     We've noticed differences between VGA and SVGA installations.
     What are the differences?
        - .INI files
        - CONFIG.SYS
        - Font files
     What are the font and resource files called?

A3. There are several differences between these drivers. I don't know the
    actual file names right now (because I don't have access to the books)
    but I can point out one difference now that comes to mind. There is a
    utility called SVGAUTIL.EXE which is only used with the SVGA drivers.
    This utility needs to be run (by the person installing) at install time
    to create the file SVGA.PMI, which contains register and memory mapping
    information specific to the hardware and SVGA driver. Whenever the
    hardware or driver is modified, this utility must be rerun to update
    the PMI file. Once again, complete information will be contained in the
    new Device Driver reference in May.




!OTHER__________________________________**********
November 09, 1993
QUESTION: (Ref: 260)
We attempted to increase the size of the scroll bar sliders without success
(DISPINFO.ASM).  We are also unable to find specific resources for sliders.
How is this accomplished?


ANSWER:
The slider is not a system resource like other objects are (EX:  the arrow
buttons at the ends of the scroll bar).  It is the responsibility of the
application to manipulate the slider size through GPI API calls.  On other
resources (like the arrows) there a bitmaps provided in the source directories
that can be modified.




=================== Administrative Stuff ===================
________________________________________**********
November 24, 1993
