This is file: 01_94QA.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 !STORAGE_________________________**********
January 28, 1994
QUESTION: (Ref: 875)
I have been browsing through the file list of this BBS but can't find
MITFX001.ADD or MITFX.ZIP which is a device driver for Mitsumi CD-Rom drive
under OS/2.  Can you please help me by telling me if you have this file or
not?


ANSWER:
We do not have drivers on the DUDE for distribution.  According to our
compatability list, available from the MIAN file area as PCMTABLE.ZIP.  the
MITFX.ZIP file is available in two places.

It is available on CompuServe in the IBM OS2SUPPORT section.  It will also be
on the OS/2 2.1 service pack when it is publicly available.

We did some further checking and found it is also on the PCC BBS, formerly the
NSC BBS in Atlanta.  The number there is 919-517-0001.  The file can be found
in section 17.




!OTHER__________________________________**********
January 28, 1994
QUESTION: (Ref: 857)
We have installed the kernel debugger.  We also selected the PM kernel option.
For the debugger video output we are using an ASCII terminal connected to
COM2.  OS/2 is running on a 486DX2/66 using a 32 bit VGA driver.  The debugger
mounts correctly with the message:

 System Debugger 03/16/89 [80386]

 GRE: Debug version, compiled by IBM C Set/2
 Nov 11 1993 18:00:22

 ##

Entering the go command ("g"), we get a long list of error messages.  The
first errors are:

 GRE: Loading IFI Font C:\PSFONTS\MARKSYM.OFM
 GRE  Adding Font to Public Font Table
 WIN1015E  Invalid atom name :

          .... registers list.... CS:IP = D107:13E5

If we enter "I" to ignore we get another error message of the same type:

 GRE: Loading IFI Font C:\PSFONTS\SYMB.OFM
 GRE  Adding Font to Public Font Table
 WIN1015E  Invalid atom name :

          ....register list....

Followed by the message:

 WIN207BE
 Symbol linked (pmmle)
 WIN1304W *** unknown error code ***
 WIN1304W *** unknown error code ***
 WIN1304W *** unknown error code ***
 WIN1304W *** unknown error code ***
 WIN102DS Process : Thread FFFF:FFFF not in semaphore

If we enter "N" (no rip selection) we go promptly to the OS/2 screen without
any other breaks.

Is this behavior normal?

Can we go ahead with the development ignoring these messages?

Apparently, they do not have any practical consequences in the correct
functioning of the driver.


ANSWER:
The error messages when bringing up KDB & PM debugger (PMD), tell him it's
normal.  The errors will appear each time he brings up the system as long as
he's enabled PM debugger.

The errors are in the GRE (graphic engine), but are invisible w/o PMD enabled
and do not affect the driver function. Feel free to go ahead with the
development effort.

Development knows of this problem, but is not looking at it as a "problem that
needs fixing".  It's more of an inconvinience.




!OTHER !STORAGE_________________________**********
January 28, 1994
QUESTION: (Ref: 845)
Is there a way to create a semaphore that is not context sensitive in a IFS?
If so, how do I implement it?


ANSWER:
No, semaphores are ALWAYS context sensitive..else they wouldn't be worth
much.




!STORAGE________________________________**********
January 28, 1994
QUESTION: (Ref: 837)
I am having a problem with my IFS.  The IFS is causing an exception when I use
the FSH_SEMCLEAR helper with the handle of a system semaphore that was created
with an EXE.  For some reason if I use FSH_SEMCLEAR when the semaphore handle
first gets passed to me (in the FS_FSCTL routine) I have no problem, however;
when I try to use the same semaphore in the FS_ATTACH routine I get a
exception.  It may be that my pointer to the semaphore handle is getting
trashed before the CPU gets to FS_ATTACH.  Am I using the FSH_SEMCLEAR helper
properly ?  Are there any special considerations relating to data segments /
heapsize / stack segments / code segments I need to be aware of ?


ANSWER:
The IFS is a 16 bit dll, and as such cannot access 32 bit semaphores (Event
semaphores).  The FSH Sem functions only work on the OS/2 1.x 16 bit
semaphores...




!STORAGE________________________________**********
January 28, 1994
QUESTION: (Ref: 828)
Q1. Our driver (IDE disk to parallel port) loads properly when we connect a
    formatted disk.  However, it seems to come up as D:.  Since OS/2 is
    looking for drivers and other files in D:  as specified in CONFIG.SYS, it
    doesn't boot up.

    Our driver loads after the Adaptec driver which controls C:  and D:.  We
    are running OS/2 Boot Manager.  The OS/2 partition is D:.

A1. The problem may be due to the driver not setting certain fields in the
    request packet as described in the INIT (Strategy) command section of the
    PDD (p15-5).  It has something to do with the Number of logical block
    devices returned in the request packet at the completion of the INIT
    command.

    Based on the information returned in the request packet, the system
    assigns the drive letters to logical devices (in the order they are
    received).  The developer needs to check what is returned in the BPB array
    that each driver returns in the request packet.

FOLLOW-UP QUESTION:
    Thanks for the information you gave in your last message.  However, I
    neglected to tell you that we are developing our driver as an adapter
    driver - and from our reading of the Storage Device Driver Reference
    Manual and the IBM 1S506 IDE driver, the ADD doesn't have to return a BPB
    array.

    We do return the number of supported drives (1) in response to an
    IOCM_GET_DEVICETABLE request.

    Further, we have now removed the Boot Manager.  Our hard disk has two
    partitions; now when we boot, we see C:  (the boot partition), D:  (our
    IDE disk sitting on the parallel port) and E:  (the second partition of
    our hard disk).  Since the Adaptec SCSI ADD controls both C:  and E:, one
    would expect that the native disk partitions would appear in sequential
    order.

    Experimenting further, we added a CD ROM drive which appears as F:  with
    the same configuration for the rest of the system as in the paragraph
    above.


FOLLOW-UP ANSWER:
    The dasd managers and other dasd drivers return the number of units that
    they control, at init time and are made available in the unit parameter
    table.  The kernel during init time uses this table and assigns the drive
    letters.  The kernel goes through the table and assigns drive letters to
    the primary partitions first and then assigns drive letters to the logical
    partitions.

    In this particular case, The primary partition (boot drive) gets the drive
    letter C and the primary partition in the parallel port gets the D and the
    logical partition gets the E.

    The drive assignments are not under the control of the device drivers.
    The user may be able to reorder the drive assignments by ordering the ADDs
    in a certain way or reordering the partitions.  Doing this may not be a
    permanent solution.  Everytime a new disk is added or a disk is
    partitioned, the order will change.  Further even if you use FDISKPM and
    repartition the disks, during bootup, the drive letters may be assigned
    differently than what FDISKPM sees them as.




!OTHER__________________________________**********
January 28, 1994
QUESTION: (Ref: 623)
I am trying to build the IDE driver, IBM1S506.ADD, but I only have MSC 7.0
instead of the required MSC 6.0.  The file builds ok with a few warnings, but
when I try to load the driver, it crashes.  Is there something special I have
to do to use MSC 7.0, or is it just plain incompatible?  If so, how can I get
C6.0?


ANSWER:
MS C 7.0 does not support OS/2.  Customer needs to obtain MS C 6.0.  IBM can
not supply this product.




!PRINT__________________________________**********
January 28, 1994
QUESTION: (Ref: 480)
Windows printer drivers support a profile setting ORIENTATION that allows you
to determine the printer output (landscape or portrait).  There is also an API
to achieve the same effect in your programs.

PM drivers do not support this.  It could be achieved using a DevEscape.  The
only way to set orientation at the moment is via the PM Dialog.

The question is - is this supported but not in the docs yet, is this something
for the future, or is this not possible now & never will be?


ANSWER:
There is no API or way other than the PM Dialog to change orientation.  There
have been complaints about this feature (or lack of).  Printer Development is
aware of the requirement and a design has been discussed.  The design,
however, has not been implemented and is not currently scheduled for
implementation.  This may be included with v2.2.




!BASE !OTHER____________________________**********
January 28, 1994
QUESTON: (Ref: 477)
I have a query about the VDHRegisterAPI that replaces int 66.  This is
referenced in the file \ddk\src\vdev\vcom\vcom.asm.  Is there is any
documentation on this API.


ANSWER:
This call is not documented in the Virtual Device Driver Reference.  It's a
new API call:  VdhRegisterAPI - Set V86 protect mode API handler.  In the case
of vcom.asm it replaced int 66 support and added support for new int 2f calls
from VDM's:

  4010 - get OS/2 VERSION
  4011 - get VDD API entry point

These calls are supported in both V86 and VPM modes.nd




!I/O !STORAGE___________________________**********
January 28, 1994
QUESTION: (Ref: 458)
I am writing a SCSI device-class driver for a Scanner.  This d.c.  driver
talks to OS2SCSI.DMD.  So far I have tested two scanners that are both SCSI-1.
They are (1) Microtek ScanMakerII and (2) HP ScanJet IIc.

When attempting to allocate these devices the following happens:  (Note:  I
have connected these scanners to an Adaptec AHA174X Host Adapter.)

When the Microtek Scanner is turned ON BEFORE I boot the computer so that the
Adapter Card Bios finds the Scanner, when I try to allocate the device after
OS/2 is loaded, I do not obtain a handle.

However, If I turn the Scanner ON AFTER the Adapter Card Initializes but
BEFORE OS/2 is loaded, and then I try to allocate the device after OS/2 is
loaded, I get back a valid handle of 1. When I try to read the device
parameters (function 43h), though, I get a Device Flags return value of 2
meaning that the device is powered off.

I repeated the above experiment with the HP scanner, and in BOTH cases I could
not obtain a valid device handle.

Next, I tried my device class driver out on two SCSI-2 devices; a CDROM player
(device type 5) and a tape driver (device type 1).  Both devices were ON
before booting up the computer.  In both cases I obtained a valid device
handle upon allocation and when I read the device parameters, the device flag
was 0 (which is what I want).

The only thing I can think of why the scanners do not work and the tape and
CDROM drives do is that the Scanners are SCSI-1.  Please let me know if I am
correct in my conclusion and what modifications I have copy to make in my
software to accomodate these SCSI-1 devices.


ANSWER:
I would use the /V switch on the AHA174x ADD to verify that the device is
being recognized by the .ADD before writing a filter driver.  Before they
think about writing a filter to emulate SCSI-2, it would be better to check
that their device is connected correctly, because it is possible something may
be wrong about their configuration.

The description of the /V SCSI Adapter Device Driver parameter is on page 73
of the Storage Device Driver Reference.




!BASE !OTHER____________________________**********
January 28, 1994
QUESTION: (Ref: 403)
We have a question about the interrupt dispatch latency period for OS/2 2.1.
We are familiar with the 400 microsecond maximum time that interrupts can be
disabled (see Design of OS/2, Deitel and Kogan, pg.  130).  Our application
will be the only one running, it will be an OS/2 app, and there will be no
nested interrupts.  We will be servicing a burst mode transmission and will
have about 100 microseconds to respond.  It appears to us that we will be
okay, but we want to know if IBM has any empirical numbers on this.


ANSWER:
Lets see.  Suppose the machine is running about 20 million instructions/sec.
(486 at 33MHz will do this, roughly) That is 20 instructions/microsecond, or
2000 instructions in 100 microseconds.  From the time the interrupt is seen,
to the time the first instruction of the correct interrupt handler is executed
may be about 200-300 instructions.  So, there should be time to handle that.
That assumes interrupts are not disabled, and no other higher priority
interrupts are being handled.  So, this could work, depending on what else
might be running, how fast the CPU is, and how long it takes for the interrupt
handler to do its work.  Note that OS/2 RECOMMENDS latencies, but does not
(cannot) ENFORCE them.  If some device driver ignores the recommended
latencies, then the latency for the system is greater.  The proposed scenerio
could work, but needs testing.  Also, I'd recommend some recovery mechanism in
case occasionally the interrupt cannot be handled is 100 microseconds.  There
is not much extra time.  (A clock-tripled 486 or Pentium changes these
numbers, of course.)




!BASE !OTHER____________________________**********
January 28, 1994
QUESTION: (Ref: 345)
Q1. I need to change the base disk device driver IBM1S506.ADD to access a
    special device driver I have developed.  All the drivers I have developed
    however are in MASM and I am unfamiliar with the calls of a C based device
    driver.

    Could you provide me with some sample C code of how a C base device driver
    would use the DevHlp function ATTACHDD to set up inter device driver
    communication and how the request packet and calls would be made.

A1. Here is the sample.

       /* the called device driver name */
       UCHAR        DRIVER_DD[] = "DRIVER$";

       /* ADDRESS_AREA is structure define in 17-19 in Physical DD reference */
       ADDRESS_AREA address_area = 0;

       /* the address of called device driver */
       PFN          IDC_addr = 0;

       /* the address of request packet */
       PREQPKT      pReqPkt;

    In the INIT routine, you have to call Devehelp AtachDD function and set up
    IDC address whom the device driver calls to,

       DevHelp_AttachDD(DRIVER_DD, (NPBYTE)&address_area);

       OFFSETOF(IDC_addr)  = address_area.offEPProt;
       SELECTOROF(IDC_addr = address_area.selRPProt;

    Later, you can call IDC entry point from C source code as follows:

       IDC_addr(pReqPkt);

    In this case you have to make sure that after the IDC emtry point is
    called in the called device driver, the correct DS is set.  Maybe the
    device driver has to set DS by itself.

    Or, you can just call MASM routine which has interface to the device
    driver from C. This means that you have to make one MASM file which gets
    the IDC_addr and request packet, as the parameters and you can set Request
    packet to register and you can call IDC entry point in Tochiba device
    driver.  Please note that usually the caller has to take care of setting
    DS of the called device driver.
==============================================================================

Q2. Could you provide me with some information regarding the various types of
    traps?

A2. TRAP LIST:

    TRAP 0000 - DIVIDE ERROR
               A program attempted to divide a number by zero.

    TRAP 0001 - DEBUG EXCEPTION

    TRAP 0002 - NMI INTERRUPT
               An NMI interrupt is generated by the system when a catastrophic
               error occurs.  There are four possible causes of this poblem.
               These are summarized below:

               110 error - system board memory parity error
               111 error - I/O channel check (adapter card error)
               112 error - watching timeout (may be hardware or software)
               113 error - DMA timeout (may be hardware or software)

    TRAP 0003 - BREAKPOINT
               This is a special instruction (INT 3) used in "debugging"
               software, which was left in the code either acceidentally or
               by design.

    TRAP 0004 - OVERFLOW
               An overflow occurred while doing an arithmetic operation.

    TRAP 0005 - BOUND RANGE EXCEEDED
               A BOUND instruction exceeded the specified limits.

    TRAP 0006 - INVALID OP CODE
               The processor tried to execute an unreserved invalid opcode.

    TRAP 0007 - COPROCESSOR NOT AVAILABLE
               If coprocessor diagnostics run error-free, contact software
               support.

    TRAP 0008 - DOUBLE FAULT

               The processor detected an exception while processing an
               exception. It could be caused by either hardware and software.
               If trap 0002 is also being experienced, contact hardware
               support.

    TRAP 0009 - COPROCESSOR OVERRUN
               The middle portion of a coprocessor operand is protected or not
               present.

    TRAP 000A - INVALID TASK STATE SEGMENT
               A task switch to an invalid task switch segment was attempted.

    TRAP 000B - SEGMENT NOT PRESENT
               The segment being referenced is not present.

    TRAP 000C - STACK FAULT

    TRAP 000D - GENERAL PROTECTION EXCEPTION
               All protection violations which do not cause another exception
               cause a TRAP 000D.

    TRAP 000E - PAGE FAULT
               The page being referenced is not present in memory or the
               procedure referencing the page does not have enough privilege
               to access the page.

    TRAP 000F - RESERVED BY INTEL

    TRAP 0010 - COPROCESSOR ERROR
               The processor detected an error from the coprocessor.  This
               could be caused by hardware and software.

    If the customer wants to know more details about TRAP 000D and 000E, there
    is some explanation in red book volume 4:  Application Development,
    because these two traps occur often when the application programs run.
    (Document Number GG24-3774-00)




!BASE !OTHER____________________________**********
January 28, 1994
QUESTION: (Ref: 269)
Q1. I have the problem of not being able to pass in a buffer larger than 64k
    to a character based PDD.  I am trying to do a DosWrite with a buffer of
    100K.  For every write transfer our driver sends a special end character
    with the last byte.  Since the driver is not aware that there is more
    bytes to be transferred from the same DosWrite request, it sends the end
    character after the first chunk which causes the device that is reading to
    stop reading.  Due to this the next chunk in the 100K buffer never gets
    sent.

    The kernel seems to be breaking up this large buffer into 64K chunks and
    passing it to the driver.  Does the kernel through any of its parameters
    in the read/write request packet inform the device driver that there is
    more data to follow from the DosRead/DosWrite call that issued the
    request.

A1. If the customer uses the DosRead API, there is no way to avoid the problem
    of the file system breaking up each request to the physical device driver
    into 64k byte chunks.

    DosRead/DosWrite functions come to the device driver through the file
    system, and the device driver gets a request packet with READ/WRITE
    strategy commands.  The pointer to the buffer in the request packet is a
    32-bit physical address, not a flat address.  When the application
    allocates a 100k buffer, there is no guarantee that the allocated memory
    is continuous physically.  So the file system breaks it into 64k chunks
    which are allocated continuously, and put the physical address into the
    request packet as the transfer address parameter.

    In this case, the customer should use DosDevIOCtl, not DosRead.  Refer to
    Physical Device Driver Reference version 2.00 of OS/2 2.0 Technical
    Library.
==============================================================================

Q2. I would like to enhance my OS/2 device driver (the 16-bit Character device
    driver) so that Dos applications can also access this driver.  What is the
    best way to do this?  Would this involve adding a virtual device driver
    layer on top of my physical device driver?  Would my physical driver have
    to undergo any changes to accomodate this?  Which manuals can I refer to
    for some detailed information on this?

A2. Yes, the customer needs to develop the Virtual Device Driver.  The
    customer can refer both to the Physical Device Driver Reference and the
    Virtual Device Driver Reference of OS/2 2.0 Technical Library.

    If the customer can get the DDK, there is much sample code, like the Audio
    Device Driver for MultiMedia.  There is also simple sample code in
    Toolkit.




!STORAGE________________________________**********
January 27, 1994
QUESTION: (Ref: 835)

We are developing an HDD.  HDD contents was produced as a FAT system.  When I
tested, this system could be connect by OS2DASD.DMD & OS2SCSI.ADD.

I don't want to use cache, as this HDD contents are changed to asyncronus.
The OS/2 v2.1 user manual states that DISKCACHE statement LW off made FAT
system no cache, but all FAT HDDs are no cache.

Q1. Can user make one specific FAT HDD (example d:,) no cache mode ?

Q2. Can OS/2 API(example DosOpen,DosRead,Write) make specific file no cache
    mode ?

Q3. FAT system cache can write cache or read cache ?


ANSWER:
A1. The FAT file system supports cacheing.  I don't think it supports cacheing
    by drive letter or file name.  The OS/2 command reference has information
    on how to enable the FAT system cache.  It is the DISKCACHE statement in
    the CONFIG.SYS.  Therefore my answer to Q1 is NO.  The user cann not make
    a particular drive as no cache drive.

A2. The OS/2 API's do not have flags for cacheing and therefore, user can not
    specify cacheing in DosOpen etc..

A3. Yes!  FAT file system can write/read cache.  See OS/2 command reference on
    DISKCACHE statement for CONFIG.SYS.

If the user wants to use cacheing on specific files, I would suggest that he
consider using VDISK.  The user can write a TSR program that will update the
hard file from VDISK from time to time and the application can read/write to
the VDISK.




!OTHER__________________________________**********
January 27, 1994
QUESTION: (Ref: 822)
I have a problem where I have a VDD returning a 32 linear address to my PDD
which then needs to pass it back to an OS/2 2.1 32 bit app.  What is the
process for converting the VDD pointer to a 32 bit APP pointer?


ANSWER:
The VDD space is in the system region and must be mapped to the process region
so that the 32-bit app can access the memory.  The VDD must make the 32-bit
linear address hvdm-relative by adding the hvdm to the linear address.  The
PDD must issue the VMGlobalToProcess devhlp and pass the returned 32-bit
linear address to the application.

A 32-bit linear address, such as the address of a variable in a process, is
said to be in the process address space, or mapped into the LDT of the
process.  Addresses within the process address spaace may be used freely by
the application, providing it has the proper access rights.  However, the
address is not valid for a device driver.  Since the device driver is
operating in ring 0, it needs an address which is global, or mapped to GDT
entry.  Pointers which are valid for the device driver are said to be in the
global address space because they utilize a GDT selector for access.

Sharing the pointers between the process and the device driver is easy.  A
linear address in the process address space can be made valid for the device
driver by a call to the VMProcessToGlobal DevHlp function.

Conversely, a linerar address in the global address space can be made valid
for the process by calling the VMGlobalToProcess DevHlp function.  Thus,
processes and device drivers can share each other's common memory areas.

However, please note that if what you want to do is to communicate between a
Dos application and OS/2 application you might want to look into OS/2 named
pipes.




!STORAGE________________________________**********
January 27, 1994
QUESTION: (Ref: 813)
I need to implement the IPX/SPX protocol with my IFS.  The normal way to do
this is to link in a library and use the appropriate calls.  I tried this and
as I suspected it would not work.  I know a IFS can communicate with a
physical device driver and DLL's (only during init) but what is the best way
to call a IPX/SPX library from a IFS?  Is the physical device driver the only
possible way to implement this?  How does lan server solve this problem?


ANSWER:
The only way to do any outside IFS communications is thru a physical Device
Driver with and IDC callable entrypoint (IDC = Inter Device Call)..  The
Netware IPX/SPX device drivers do NOT provide an IDC entrypoint, and thus
CANNOT be called at ring 0.

Lan Server doesn't do IPX, only Netbios, and Netbios DOES provide and IDC
entrypoint at ring 0..

You will have to write a ring 3 daemon that talks to your IFS thru DOSFSCtl()
ring 3 api calls, and redirect IFS requests UP to the ring 3 daemon, which
then sends them out via IPX, gets the response,and writes it back DOWN to the
IFS....

This is called the Split model IFS..




!STORAGE________________________________**********
January 27, 1994
QUESTION: (Ref: 775)
Q1. Can a DMD alloc a drive letter, but hide the letter from an app?

Q2. Is the INT13 ADD usable anytime by the DMD during the boot process?  i.e.
    can we scan the disk via INT13 at all?

Q3. Any FS hook info (if it exists, if it is planned for 2.2)


ANSWER:
A1. No.  Actually, DMD does not assign the drive letter.  Drive letter
    assignment is done by the kernel file system.  It is a simple algorithm.

       1. The kernel loads the first block device manager (DMD).
       2. Ask the device manager, the number of units it manages.
       3. Start with the current drive number/drive letter and add the new
          units to it.
       4. Go to the next block device manager and repeat 2 and 3 until all
          DMDs are loaded and their units are assigned drive numbers/letters.

       Most of the defining of unit numbers for any internal hardfiles and
       diskettes is usually done by the OS2DASD.DMD, thus the loadable device
       drivers always have their units start after the internal drivers and
       volumes.

       Modifications will be necessary to the DMD to be able to hide a drive
       letter from applications.

A2. The INT13 driver (IBMINT13.I13) gets loaded after all the adds and the
    .sys files have been loaded.  This driver determines whether the adds/sys'
    loaded previously have claimed all of the fixed disks as indicated by the
    BIOS fixed disk count.  If not, the INT13 driver will attempt to manage
    the remaining unclaimed fixed disks.  The OEM BIOS must supply the INT13
    support to fixed disks for this driver to work.

A2. This is our position regarding FS Hooks:

     1. There are no new defined IFS interfaces at this time.
     2. There is no committed development effort for FS Hooks at this time.
        If any new interfaces are defined in future releases, they will be
        documented at that time.




!BASE !OTHER____________________________**********
January 27, 1994
QUESTION: (Ref: 826)
I found a problem in the DevHlp_LinToGDTSelector function in the DHCALLS.LIB.

The version that I have is from the 1.1 DDK Source Kit.  It sets both EBX and
ECX to the length of the size of the segment, instead of setting EBX to the
Linear address.


ANSWER:
This problem has been fixed. The next DDK (1.2) will have this fix.




!STORAGE________________________________**********
January 27, 1994
QUESTION: (Ref: 758)
Q1. Is there any information on scatter/gather?

A1. There is documentation on scatter/gather in the Storage Reference manual
    on the DDK.  Steve Mastrianni's "Writing OS/2 2.1 Device Drivers In C" has
    information on scatter/gather under the EDDI (Extended Device Driver
    Interface).
==============================================================================

Q2. Is there a limit to the number of list entries?  We are using the spock
    card.

A2. According to the Storage Device Driver Reference, MaxHWSGList is the
    maximum number of Scatter/Gather elements that your device can handle, but
    this does not mean that this is the greatest number of Scatter/Gather
    entries that will be in a IORB.  It is your drivers responsibility to
    split the IORB into seperate requests.  The OS/2 kernel will ensure you
    that you will not have to split a sector across a MaxHWSGList boundary.

    Adapter capability "MaxHWSGList == contains the maximum number of elements
    supported by the hardware Scatter/Gather List" and not "==contains the
    maximum number of elements supported by the software ADD...", apparently
    there is NO LIMIT.

    The MaxHWSGList value is the number of SG list entries that together must
    represent an integral number of blocks.  When non-passthru commands
    (EXECUTE_IO) are issued, there is NO limit on the total number of entries
    in the list.  The only thing you can count on is that the SG list, when
    broken into sections starting at the beginning and taking MaxHWSGList
    entries at a time, that each section will be an integral number of blocks
    on the device.

    Realistically SG lists will be limited by real memory and a list greater
    than 32 entries in length is unlikely.  If the adapter does not directly
    support scatter/gather, the MaxHWSGList field should be set to 0.

    In the case of passthru commands it is the responsibility of client driver
    to restrict S/G lists to MaxHWSGList entries.  In addition if
    MaxCDBTransferLength is set (nonzero) then the total data transfer length
    must be also restricted to that value.  In the case of current PS/2 uC
    adapters, MaxHWSGList = 16, MaxCDBTransferLength = 0. Client drivers
    should also check AF_16M in the AdapterFlags to determine whether the
    adapter is limited to data transfers below 16M physical.
==============================================================================

Q3. We altered the NVRAM settings to allow post to pass, the disk drive comes
    up without power and we couldn't stop the dasd manager from grabbing the
    resource.  So the SCSI manager thinks the drive is a scanner.  Could this
    cause us any problems?

A3. Use /!DM ADD Command Line option as in the Storage Reference if you need
    to prevent the DASD Manager from allocating the unit.




!OTHER__________________________________**********
January 27, 1994
QUESTION: (Ref: 385)
The Phys Dev Driver Reference says that VirtToPhys can only be used at kernel
and init time (ie.  not at interrupt time).  The ADD reference says that my
ADD can be called at either kernel or interrupt time.

I was using VirtToPhys while processing the call IOCM_GET_MEDIA_GEOMETRY.  I
understand that I cannot be guaranteed that the IOCM_GET_MEDIA_GEOMETRY call
will come at kernel time.  I have changed my code so it doesn't use VirtToPhys
and everything works fine.

I am still wondering if my actual problem was due to the fact that OS/2 uses
IOCM_GET_MEDIA_GEOMETRY during interrupt time.

Is there a way of using the kernel debugger to tell if the IOCM call came in
at interrupt time?


ANSWER:
At the place where the customer sets the break point, maybe in this case at
the IOCM_GET_MEDIA_GEOMETRY process routine, the customer should type in the
".p*" command on the kernel debugger.  The ".p" command shows information
about the thread.  If this thread is "BLK", it is at interrupt time, and if
the current thread is "RUN", it may be at kernel time.




!STORAGE________________________________**********
January 27, 1994
QUESTION: (Ref: 336)
Q1. I am writting a SCSI driver.  As I am testing it, I have found that INT 13
    is returning the wrong values for function 8 (Return Current Drive
    Parameters).

    I then tried the Adaptec driver and it also returns the wrong values.

    The values being returned are cx=7EA4 dx=7F02.
    They should be                cx=EE60 dx=3F02.

    The values being returned by my IOCC_GEOMETRY/IOCM_GET_DEVICE_GEOMETRY
    routine are:

            TotalSectors    = 0xF7800
            BytesPerSector  = 0x200
            Reserved        = 0
            NumHeads        = 0x40
            TotalCylinders  = 0x1EF
            SectorsPerTrack = 0x20

    Note that if I use int 13 to read head 0x01, sector 0x01, cylinder 0x82,
    it does read the correct block.  This means the translation is correct (64
    heads, 32 sectors).

    Is there known bug in the int 13 interface for function 8?

A1. VDSK.SYS only obtains disk geometry from OS2DASD on uChannel Machines.
    For other (non-uC) the fixed disk tables (Int 41/46) are used.  Some OEM
    adapters do not set up these vectors so the information obtained by this
    method is unreliable.

    This is a throw-back to when driver development was split between
    IBM/uSoft.  VDSK needs to be updated to request disk geometry from the
    DASD Mgr for all cases.

    Normally the ADD driver will not 'see' a new geometry request for
    non-removable drives since the disk geometry was obtained at boot time and
    is kept by the DASD Mgr.
==============================================================================

Q2. How does IBMINT13.I13 get loaded?

A2. IBMINT13 and other driver's loading and initialization are described in
    Chapters 2 and 3 in the Storage Device Driver Reference.
==============================================================================

Q3. Can you supply more information on IBMINT13.I13?  eg, is IBMINT13.I13 a
    Virtual Device Driver?

A3. IBMINT13 is not a virtual device driver.  It is physical device driver,
    like other adapter device drivers.  But besides using their own SCSI
    interface to the adapter card, it is using BIOS int 13h interface to talk
    to the devices.  That's why it can read/write to any adapter cards.
==============================================================================

Q4. Do I have any source to the int 13 interface in the DDK?  I can't find
    anything on IBMINT13.* other than IBMINT13.I13.

A4. We do not put the IBMINT13.I13 source codes in the DDK.  The OEM BIOS
    Requirement document which follows provides some information:

    IBMINT13.I13 - OEM BIOS Requirements

    1) BIOS must confine memory access to the following areas

             00000 - 01000h (R/W)
             9e000 - 9ffffh (R/W)
             a0000 - fffffh (R/W)

     Any seg:off that generates accesses within these bounds
     is acceptable.

     These areas (as well as data buffers) provided to the BIOS
     are mapped virtual = real so DMA and Bus Master operations will
     work properly.

    2) BIOS must not use the A20 area or any area other than noted in (1).

    3) BIOS must not attempt to change the processor mode, i.e.  write CR0.

    4) BIOS must support a sector count of at least 80h on read/write/verify
       operations.

    5) BIOS must support INT 13 Functions=0,2,3,4,8,15h.

    6) The BIOS may assume that the BIOS Timer/Counter location 40:6C-40:70 is
       updated and can be polled in wait loops.  The BIOS must not rely on
       directly hooking the timer interrupt or RTC interrupt.

    7) The adapter hw (in general) should not be designed to require accurate
       timings generated by the BIOS.

    8) If the BIOS is interrupt driven, IRQ Levels 3, 4, 5, 9, 10, 11, 12, 14,
       15 (decimal) are supported provided there are no conflicts with other
       adapters.

    9) Non-Interrupt driven BIOS implementations are supported with, the INT13
       driver.  However, ADD drivers require interrupt driven operation to
       perform acceptably.

    10) The IBMINT13 driver does not support sharing of an IRQ level on EISA
        or uChannel systems, i.e.  the SCSI adapter using the INT13 driver
        must be configured on its own level.

    11) It is recommended that the BIOS provide INT 13 support for SCSI Device
        Types 0, 7.

    12) It is recommended that SCSI adapters have a configurable option to
        provide INT 13 support for all type 0,7 targets.  The BIOS must update
        the installed disk count 40:75 appropriately.

    13) Although the INT13 driver should handle DMA boundary alignment
        exceptions, an adapter designed with this kind of problem i.e.  a
        dependency on system board DMA channels is discouraged.

        We are not aware of any SCSI adapter supplier that currently uses
        System Board DMA channels on ISA configurations.

        Also, use of slave DMA channels on uChannel configurations will result
        in a poorly performing design due to the lack of hardware
        scatter/gather support.

    14) We cannot guarantee any particular performance point can be achieved
        with the INT 13 driver.

        Our experience shows that on a typical SCSI adapter (one interrupt per
        request) that performance is 75% of a full function ADD driver.




!STORAGE________________________________**********
January 27, 1994
QUESTION: (Ref: 266)
I am writting a SCSI ADD.  If I get a UNIT ATTENTION with ASC=0x29, should I
retry?  Should I set IOERR_DEVICE_RESET?

Also, the section "Error Handling" says that IOERR_RETRY is a flag that tells
the ADD to retry if an error occurs.

 Section "Summary of Error Codes" shows some items as "retry required".

But, section "I/O Request Block - C Definitions" does not have IOERR_RETRY set
for some items that section "Summary of Error Codes" shows to be "retry
required".  The items in question are the following:

        IOERR_ADAPTER_NONSPECIFIC
        IOERR_DEVICE_RESET
        IOERR_DEVICE_NONSPECIFIC

Which part of the document is correct?


ANSWER:
In general when the IORB_DISABLE_RETRY is NOT set in an IORB then the ADD
should retry a command which produces a Check Condition.

There is the following exception to this policy for removable media devices:

1)  A significant event would be masked by a retry:

      - Device Not Ready
      - Ready To Not Ready To Ready Transition (Media Changed)
      - Device Reset

Special considerations for error handling on removable media devices is
discussed in the Q & A section of the spec.

The RETRY_REQUIRED flag in the error codes is intended as 'advice' as to
whether a retry is likely to be productive.  In some cases the nature of the
error leads to the conclusion it will not be corrected by a retry.

The ADD implementer may test this flag to determine whether to proceed with a
retry or ignore the flag provided the considerations in Item 1 are met.

One thing to keep in mind when designing error recovery code in the ADD, is
that once the error is reported out of the ADD driver, it is considered
non-recoverable.  In general Device Managers that implement their own error
recovery logic will set the IORB_DISABLE_RETRY bit so they can manage error
recovery themselves.  If this bit is not set then the ADD writer should assume
that if an error is reported, it will result in an error pop-up on the user's
screen.




!OTHER__________________________________**********
January 17, 1994
QUESTION: (Ref: 834)
What would you recommend as the best source of information of OS/2 2.1 DevHlp
rountine and the parameters required, etc.  Is there a book which you suggest
or is this information contained on the OS/2 2.1 DDK ?  If it is on the DDK,
under what filename ?


ANSWER:
Documentation on the use of devhelps is in the PDD reference which is included
in the DDK.  Another good source of documentation is WRITING OS/2 2.1 DEVICE
DRIVERS IN C by Steven Mastrianni published by Van Nostrand Reinhold 115 Fifth
Avenue, New York, NY 10003.

The book, "Writing OS/2 2.1 Device Drivers in C", by Steve Mastrianni, is
available on CompuServe from Compubooks (GO CBK), from Van Nostrand Reinhold
(800-842-3636), or from IBM (800-879-2755, P/N SR28-4392).




!PRINT__________________________________**********
January 17, 1994
QUESTION: (Ref: 815)
Is there a problem with the MiniDriver that ships with DDK 1.1?


ANSWER:
We did find a problem with the Minidriver which is worth mentioning.


1. The Minidriver (DDK Version 1.1) does trap occasionally or does not print
   at all when used with the version of EPM that shipped with OS/2.  I don't
   know if this was the trap that the customer discovered but it is worth
   mentioning anyway.  This problem can be corrected by inserting the line

                lrc = TRUE;

   in function DeviceSetAttributes() in file \src\prntdd\mdriver\attrib.c
   before the break statement in cases PRIM_IMAGE and PRIM_LINE respectively.

2. As far as installation of the Minidriver (or similar) is concerned, the
   Printer Object Install utility should be used and this will take care of
   inserting all the required INI file entries while installing the driver.
   The ini file entries that are inserted by the install utility for the
   Minidriver Generic Raster Printer driver are as follows:

   In os2.ini:
               App Name:  PM_DEVICE_DRIVERS
               Key Name:  MDRIVER
               Data:      C:\OS2\DLL\MDRIVER\MDRIVER.DRV

   In os2sys.ini:
               App Name:  PM_SPOOLER_DD
               Key Name:  MDRIVER.Generic Raster Printer
               Data:      MDRIVER.DRV;;;

3. The DDINSTAL utility cannot be used for Presentation drivers like the
   Minidriver.




!OTHER__________________________________**********
January 17, 1994
QUESTION: (Ref: 807)
I am working with your "PCMCIA Data/Fax Modem Client Driver Source Code".  I
was having trouble with Socket Services returning a zero for the number of
sockets.  You suggested I change IBMSS02.SYS to IBMSS01.SYS and ICRMU02.SYS to
ICRMU01.SYS.  After changing these two files in my config.sys, Socket Services
now indicates I have 4 sockets.

I have an IBM ThinkPad Model 750 with just two PCMCIA slots.  Why would I get
4 when I call GetCardServicesInfo?


ANSWER:
The default value of the ISA bus is four slots.  And for the ISA sockets
services driver, there is no way to find out the actual total number of slots.
ISA socket services always returns four.  This means that the value which you
got is correct.

If you want to get the real value, you can add the following parameter in
CONFIG.SYS:

    DEVICE=C:\OS2\IBM2SS01.SYS /S0=2




!OTHER !STORAGE_________________________**********
January 17, 1994
QUESTION: (Ref: 806)
Is there any document regarding an .ADD driver for a PCMCIA SCSI card?


ANSWER:
Curretly there is no standard for PCMCIA SCSI cards.  The PCMCIA General
Commitee is working on the standard.  IBM OS/2 does not support PCMCIA SCSI
cards at this time.




!BASE !OTHER____________________________**********
January 17, 1994
QUESTION: (Ref: 799)
The doc says that the Environ element of the StartParams struc must be 0 if
starting a VDM.  However, I have sample source code from IBM which violates
this but works.  Specifically, Environ gets a bunch of 0-terminated strings
which correspond to the settings available in the DOS Settings button of the
Session page of the DOS session notebook, e.g.  DOS_HIGH=1.  I want my VDM to
use a different AUTOEXEC.BAT than the default, but if I put a DOS_AUTOEXEC=
line in Environ, the VDM causes a system error and terminates.  How can I get
my VDM to use an AUTOEXEC in the path of my choosing?


ANSWER:
DosStartSession in the CP Programming Reference is not correct for starting
VDMs.

Provided the user is on 2.1, what they tried should have worked provided they
only used a different name and not a different directory.  It will not work
with a fully qualified path.  I believe this is a hold-over from DOS, it will
only recognize the autoexec.bat in the root.  This DOS setting appears to only
allow name changes and not directory changes.

The DOS_AUTOEXEC setting is applied to the Shell statement.  A "/P" indicates
you should use the default Autoexec (ie.  C:\AUTOEXEC.BAT).  No "/P" indicates
no autoexec is to be run.  The third possibility is "/P=c:\abc\xyz.bat" will
run the specified file as the autoexec.  Note, the "=" can also be a ":".  The
4th, and last variant, is "/P='c:\abc\xyz.bat 1 2 3'".  This will run the
specified file as the autoexec and will pass in parameters.  Note, the name
and parms must be contained in quotes.  Use can use ' or " quote marks.




!OTHER__________________________________**********
January 17, 1994
QUESTION: (Ref: 797)
I am writing a virtual device driver that inserts a dos device driver into the
dos session.  How do I obtain the current HVDM from within the dos call to the
device driver.  Would it be safe to assume that the instance data is available
once protected mode is reached?  Are there any special considerations?


ANSWER:
The VDD contains a separate linear region called an "instance region" much
like instance segments in DLL's.  All references in the VDD to this region are
fixed up to a region in the VDM between 1meg + 64k and 4meg with the same
linear address fro all VDM processes.  A base register isn't needed to access
variables in the current VDM context.

During VDD initialization, the VDD informs the kernel how much instance data
is needed and the kernel returns the instance data's offset from the VDM's
base linear address( the VDM handle).  To access an instance data item, the
VDM handle is added to the offset returned from the call at init time plus the
offset of the data item within the data area.

   ;         (EBX) = VDM handle

              add   ebx,vdd_vdm_DataOffset  ;setup at init time
              mov   eax, ebx.InstanceVar




!BASE_____________________________*********
January 17, 1994
QUESTION: (Ref: 747)
On trying to reply to a READ request packet (having got a selector using
phystoGDTSelector), the data I write to the buffer does not get back to my
application.

Before progressing to talk to our adapter card I am trying to write text into
a read buffer and return it. But when the read returns there is no data in the
read buffer.  I have tried the read using DevHelp_PhysToVirt and
DevHelp_PhysToGDTSelector with the same result.


ANSWER:
For an application to be able to get addressability to a memory area, the
driver must do a PhysToUvirt.  PhysToUvirt returns a far pointer to converted
virtual address.  The application can then use the returned virtual address.
Alternately, the application can pass a flat 32 bit address to the driver and
the driver does a VMLock, A VMProcessToGlobal.  This will return the linear
address of the mapped global address.  The application can then use the linear
address return to access the memory area.  See both the PhysToUVirt and
VMProcessToGlobal in the PDD reference.




!VIDEO__________________________________**********
January 17, 1994
QUESTION: (Ref: 727)

We are having difficulty using the palette management function
GpiQueryPaletteInfo.  We load a 24 bit TARGA file from disk and place the
image in application memory.  We then create an optimum palette for this
image.  Next, we create an 8 bit memory device context and select a bitmap
into the DC.  We then select the palette we created into the memory DC and
into the window the image is going to be displayed in.  We then transfer the
image from our application memory to the memory DC we created by using
GpiSetBitmapBits.

Next we transfer the image from the memory DC bitmap to the PM window using
GpiBitBlt.  This whole procedure works just fine, the image looks great.  The
problem is that transfering the image from our application memory to the
memory DC bitmap is very slow when GpiSetBitmapBits must perform a closest
match of 24 bit data to the 8 bit data using our custom palette.

We want to speed things up by performing the palette matching using our own
algorithm.  We are trying to use the function GpiQueryPaletteInfo to obtain
the RGB data and index locations of the palette selected into the memory DC
then, using this information, perform the closest match of our 24 bit image
using our own algorithm.  We then pass this 8 bit image to the function
GpiSetBitmapBits, alleviating GpiSetBitmapBits from needing to perform the
palette matching.

GpiQueryPaletteInfo does not appear to return the index locations for the RGB
values.  When we use this function using a default palette there appears to be
no problem, but when we try it with a custom palette it does not seem to work.


ANSWER:
The indices of the "optimal palette" that the developer creates are the
indices in the memory DC.  There is no need to do a QueryPaletteInfo.  In our
pallete management document, it states:

    For a memory DC, the "color information associated with the bitmap
    is inherited from whatever ... palette is currently associated with
    the presentation space. ... The physical indexes in the bitmap are
    indexes into this ... palette."

Therefore, if you want to do a mapping from 24bit color to an 8bit, 256 entry
palette - the 8bit memory DC palette is exactly identical to the 8bit palette
created and selected into the presentation space.

Note, however, that a mapping will occur between the palette indices in the
memory DC (the same indices used to define the palette) and the true hardware
palette (as set when WinRealizePalette is called).  This will occur when the
image is blt'ed to the PM window.




!BASE !I/O______________________________**********
January 17, 1994
QUESTION: (Ref: 654)
In the PDD Reference, the DevHlp functions are shown with return values in
some cases.  Often these are error codes.  The PDD Ref lists the possible
errors in English, but does not give the numerical equivalent.  To make
matters more confusing, the manual does not give the English error
descriptions in a format that matches an assembler "EQU" directive.  The
manual also does not indicate in which include file the error codes can be
found.

In my particular example, I am considering using the ArmCtxHook DevHlp
function.  One of the possible errors listed is "Hook already armed".  This
string appears nowhere in the \ddk\inc directory.  Neither does
"HOOK_ALREADY_ARMED" or any other variation I have tried.  I have checked the
BSEERR.INC file in particular, but did a directory scan with a text search
utility to examine all of the include files.

Where are the error codes defined?  Which include file must be used?  What are
the proper equates to use in my source code to test for these errors?


ANSWER:
The error text "hook already armed" is not supported right now.  All it
returns is INVALID_PARAMETER.

The file bseerr.inc is the include file that must be used for other errors.




!BASE___________________________________**********
January 17, 1994
QUESTION: (Ref: 651)
Can a single event semaphore be shared between an application, a virtual
device driver, and a physical device driver?

Specifically, can an application create an event semaphore that can be used by
a device driver (VDD and PDD) to signal that the event has occurred?


ANSWER:
A semaphore cannot use VDD space and the application space.  The services to
do this do not exist.




!STORAGE________________________________**********
January 17, 1994
QUESTION: (Ref: 520)
Will DevHelp_RegisterStackUsage behave as I expect if I call it multiple times
for the same IRQ?  MCA & EISA systems can share IRQs, and I call
DevHelp_RegisterStackUsage once per SCSI adapter just before I call
DevHelp_SetIRQ.

In this driver, there are 6 unique ISR headers:  one per IRQ used by an
adapter.  If adapter 0 uses IRQ 10, then IsrHeader0 will be registered to IRQ
10.  IsrHeader0 will set AX=0 and call DeviceInterrupt which is the real ISR
procedure.  If two adapters use IRQ 10, then IsrHeader0 and IsrHeader1 will be
both registered to IRQ 10.

IsrHeader0 will call DeviceInterrupt and ask adapter 0 if the interrupt was
generated by adapter 0. If not, DeviceInterrupt exits saying the interrupt did
not belong to it.  OS/2 will then call IsrHeader1, asking if adapter 1
generated the interrupt.  It did, so DeviceInterrupt processes adapter 1's
interrupt.  That is how I have written my interrupt routine.

Just before DevHelp_SetIRQ, I called DevHelp_RegisterStackUsage for each
adapter as well.  I am using RegisterStackUsage primarily to tell OS/2 how
many levels of nesting is possible for a particular interrupt handler (one per
adapter).  If two or more adapters share the same IRQ, I would call
RegisterStackUsage with nesting level of 1 for each adapter.  This doesn't
work because that was not how it was designed.  So I registered the number of
adapters to a particular IRQ (e.g., 3 adapters at IRQ 10 would yield one call
to RegisterStackUsage with nesting level 3).  This seemed right, but I wanted
verification.

I don't really use RegisterStackUsage for anything other than keeping OS/2
from disabling the interrupt at the PIC which the manual said would happen if
more than 2 levels of interrupt nesting occurs.  I guessed at the stack usage.
I'm more interested in the interrupt nesting level than stack usage.

The RegisterStackUsage documentation says that the maximum nesting level
should be passed in in the SU_cNest field of the StackUsage structure.  The
RegisterStackUsage docs say nothing about a limit on this value.  The Limiting
the Number of Nested Interrupts section of the PDD states that the number of
nested interrupts should be kept to a minimum, preferably no more than two.
So if I have more than two nested interrupts can I have problems?  In
particular, do I need to worry about OS/2 disabling interrupts for the rest of
the boot session?


ANSWER:
DH_RegisterStackUsage doesn't do any magic!  In particular it does not cause
OS/2 to allocate a larger interrupt stack.

The call's primary purpose in life is to tell installable (optional) drivers
whether they can work without exceeding the system interrupt stack limit (8K).
In the example you cite you would issue the RegisterStackUsage call once per
ISR entrypoint you register.  ADD drivers do not usually issue this call.

As a general rule device drivers should be very stingy in their stack usage.

You should plan your data structures so that you allocate per device storage
out of your data segment rather than automatic storage from the stack.

Recursive situations should be avoided by unwinding the recursion as soon as
possible.

For example if your service routine is busy (processing an interrupt) and an
interrupt for another adapter you own comes in; you should clear the
interrupting condition on the adapter, record the interrupt and exit the
interrupt handler.  When the interrupted instance of your driver completes it
should check for any events which have occurred across all the adapters you
are servicing prior to returning to the interrupt manager.

As far as we can ascertain, there is no inherent perfomance advantage in
interrupting servicing of one adapter you own to service another.  It will
only result in building up the system stack to the point where OS/2 will
crash.

There are a number of examples of interrupt nesting control in the DDK.

The code to handle the nested interrupt is

   int nest_level=-1;

   isr()
   {
      nest_level++;      // count interrupt occurance
      Dev_help_EOI;      // enable pic
      if(nest_level==0)  // only process for first level interrupt
      {
        while(nest_level>=0)  // process while counter says there is one
          {
          // enable interrupts
          // handle interrupt // do whatever your dd needs to handle interrupt
          // disable interrupts
          nest_level--;       // decrement counter
          }
       }
      // set carry, irq claimed
    }




!STORAGE________________________________**********
January 17, 1994
QUESTION: (Ref: 517)
In the event that the SCSI bus hangs, what is the correct response for the
SCSI ADD?  In DOS, we issue a SCSI bus reset and requeue all the requests
which were actively being processed.  The problem occurs when some device
driver sends Mode Selects to a SCSI target to configure it, a SCSI bus reset
will reset the device to its defaults.  The device would now be configured
differently from what the device driver expects.

It seems to me that a SCSI bus reset is NOT a good idea since the ADD has no
idea how long a particular SCSI command will take.  A low-level format is one
example.  Another is a SCSI tape erase or seek to end of tape or rewind from
end of tape.  These commands may take several minutes or even hours to
complete.

Even more of a problem is that a SCSI reset will set all Mode Selects back to
defaults.  If requests were retried after a SCSI bus reset, the device would
now be using default values while the application/device driver is expecting
the target to be using the Mode Select values.

If a SCSI bus reset is what is OS/2 requires ADDs to do, then I will only be
doing it for IOCC_EXECUTE_IO commands for disk devices.  I will have to let
SCSI passthru commands hang indefinitely.  This is what Adaptec's 1542 driver
does, but I think this is very bad error handling.


ANSWER:
In general we discourage use of the hard reset alternative.

Instead when a command timeout is detected, the ADD should try to isolate
error recovery to the target by sending a bus device reset message.

Further attempts at timeout error recovery are up to the individual ADD
suppliers.  If a hard reset is issued, then it is the ADD's responsibility to
restart IORBs which do not have the DISABLE_RETRY flag set.  Other IORBs
(those with DISABLE_RETRY) set should be returned to their issuer with
IOERR_DEVICE_RESET.

Any Device Manager which establishes non-default settings on a device is
responsible for reestablishing those conditions in the event of a SCSI Bus
Reset.  The device manager can detect the reset either by the
IOERR_DEVICE_RESET error code or by the SK=06/ASC=29 sense code on a
subsequent request issued to the device.




!BASE___________________________________**********
January 17, 1994
QUESTION: (Ref: 429)
Q1. Where is the include file(.h file) for the C-Callable interface to OS2
    DeviceHelp(DevHelp Service) and where is the C function lib in the DDK Ver
    1.0 CD.

A1. Some of the C interface for DEVHlp calls are in the directorys
    src\dev\dasd\diskh\dhcalls.h and src\dev\dasd\devhlp\*

    There is a makefile in the directory which creates dhcalls.lib

    Also there are some more DEVHlp routines in
    ddk\mmos2\mmtoolkt\samples\audiodd\cdevhelp.asm

    All these C interface for Devhelp are user specific.  Customer can modify
    them if he wants or he can use the existing ones.
==============================================================================

Q2. Is there any simple start-up routine for PDD in the CD ?

A2. Yes . There is an ASM file in
    ddk\mmos2\mmtoolkt\samples\audiodd\startup.asm
==============================================================================

Q3. Is there any routine for transfering data to and from the device driver in
    the CD ?

A3. There is no independent routine as far as I know which does this.  But he
    can refer to MultiMedia Audiodd to get some idea.
==============================================================================

Q4. Under the directory \DDK\SRC\DEV\DASD\DEVHELP, there is a C callable
    library for the device service usage, may I use it to develop the PDD?

    The device helper services entry point is obtained during device driver
    initialization, so how to link the program, as the linking time the entry
    point is unsolved.

    If I use C library, after the entry point is obtained during INIT, how do
    I pass the entry point to the C function?

    In your samples, some make a call like " call [_device_help] ", some like
    " call [DevHlp] ", is there any difference ?

A4. Under the directory \DDK\SRC\DEV\DASD\DEVHELP, the C callable library can
    be used for the DeVHelp functions within a PDD.  A PDD can be written in
    C. Please be aware that the C callable library in the above mentioned
    directory is only a C interface to the DevHelp functions.

    In order to develop a PDD in C, you need to write the INIT routine, the
    STRATEGY routines and the INTERRUPT routines.

    The INIT routine is executed during BOOT time when OS/2 loader encounters
    the DEVICE= statement in the CONFIG>SYS.

    The STARTEGY routine is executed when the driver is called by the OS/2
    kernel as a result of an I/O request.

    The INTERRUPT routine(s) execute in response to external interrupts such
    as a character being received from a serial port.

    A simple device driver consists of a Data segment and a Code segment.  For
    a device driver, the data segment must always load first (before the code
    segment).  The first set of data that appears in the data segment must be
    the DEVICE DRIVER HEADER.  The device driver header is a fixed length,
    linked list structure that contains the information for use by the kernel
    during init and normal operation (including the entry point).

    When writing device drivers in C, a mechanism must be provided for putting
    code and data segments in proper order.  Since the Device Header must be
    the first item that appears in the data segment, the C compiler must be
    prevented from inserting the normal C startup code before the Device
    Header.  This can be solved with a small assembly language stub that is
    linked in with the device driver.  Please refer to
    \DDK\SRC\DEV\DASD\IBM\IBM1S506\S506SEGS.ASM in the CD, for an example of
    the assembly language stub.  This will prvent the C startup code from
    being inserted before the driver's data segment.  The segment ordering
    directives in the assembly stub ensures that the data segment precedes the
    code segment.

    After the entry point is obtained during the INIT, the entry point is
    passed in the request packet by the OS/2 kernel.

    The DASD device drivers (PDDs) are written in C and are in the directory
    \DDK\SRC\DEV\DASD\IBM.  Please look at these programs for examples on how
    to use the DvHelp C interface calls.

    The difference between using (_device_help) and (DevHlp) is only in how
    theqa.42 functions are defined in the function headers between the
    assembler headers and the C headers.  The functionality is the same.  If
    you are writing PDD in C, use the functions as defined in
    \DDK\SRC\DEV\DASD\DISKH\DHCALLS.H.




!STORAGE________________________________**********
January 17, 1994
QUESTION: (Ref: 420)
Does OS2DASD double buffer disk requests which require it?  I have a
bus-mastering adapter and a DMA adapter which can only address 16MBs of system
memory.  Do I need to double buffer requests above 16MBs, or am I guaranteed
never to get requests whose physical address is above 16MBs.

Does the same hold true for SCSI/ASPI requests?


ANSWER:
OS2SCSI/OS2ASPI do not support addressing above 16MB There is a Capability Bit
Strip in the device header and bit 1 is NOT ON for both of the drivers.
(Please refer to page 3-5 in Physical Device Driver Reference.  )

OS2DASD and OS/2 memory management can handle >16MB memory.

   * >16MB support is evalutated on a per unit basis using IOCTL 08/63
     (Get Device Parms). The appropriate bit is documented in the 2.0 PDD ref.
   * If the bit (>16MB) is not set for all block units, then memory
     management will use memory above 16MB as a paging cache.

Additionally there is a bit definition telling the device manager whether an
adapter can support >16MB or not in AdapterFlag of the Device- table.  This is
defined in the Storage Device Driver Reference.




!I/O !PRINT_____________________________**********
January 17, 1994
QUESTION: (Ref: 361)
I have modified the serial.pdr file in the DDK to support 32 com ports.  I am
using this with my 32-port replacements for COM.SYS and VCOM.SYS.

I copy the modified serial.pdr file to the \OS2\DLL directory, and pull off a
printer from the templates.  I then RMB on one of the existing ports to get to
the Install New Port dialog (can also do it from the output page in the
printer notebook after the printer is installed).

I next change the directory to <d:>\OS2\DLL and click refresh.  The dialog
then shows me all 32 ports, as well as the three lpt ports.  If I select any
serial ports from COM1 to COM9 and click "install", these ports seem to be
installed as valid spooler output choices for the printer.

If I select any ports from COM10 to COM32 and click "install", the
installation starts, then stops with a "Printer" dialog displaying "Y N A R
I", offering only a "cancel" button.  If I press cancel, the "ports
successfully installed" dialog appears, but the ports are not installed.

My questions are:

What does "Y N A R I" mean?  I read many Compuserve messages where this was
seen during 2.1 beta installs, and I saw it myself then.  There was a lot of
speculation on user's parts, but no answer from IBM as to what this means.  "Y
N A R I" seems to me like a message I got from Ami Pro once that said "Bad
Magic!!"  (not intended for customer eyes).

Is there a parsing limit on the printer output ports that is preventing any
serial port greater than COM9 from being used?


ANSWER:
"Y N A R I" is the message text for error ID 0 in system message file.  It is
incorrectly being displayed by the print object.  To get COM10-COM32 ports
installed, a slight change needs to be made to the serial port driver sample
code.

In SplPdInstallPort, just before the last PrfWriteProfileString(...
APPNAME_PM_SPOOLER_PORT....), a check must be made due to some(old) spooler
checks.  Only ports named COM1 - COM9 can put default initialization data as
the key value for this PrfWriteProfileString.  All other port names must put
";" as the key value.

Please have them replace the last PrfWriteProfileString with the following:

     if (strlen(pszPortName) > 4 )
     {  if !PrfWriteProfileString( HINI_SYSTEMPROFILE,
                                   APPNAME_PM_SPOOLER_PORT,
                                   pszPortName,
                                   ";" ))
            return (WinGetLastError(hab));
     } else {
        if (!PrfWriteProfileString( HINI_SYSTEMPROFILE,
                                    APPNAME_PM_SPOOLER_PORT,
                                    pszPortName,
                                    DEF_INITIALIZATION))
             return(WinGetLastError(hab));
     }       return(WinGetLastError(ha




!OTHER__________________________________**********
January 17, 1994
QUESTION: (Ref: 339)
I have just purchased a copy of the IBM OS/2 Device Driver Kit (DDK).  I would
like to use the included Microsoft CL386 C compiler to write some test
programs for the drivers I will be creating.

I have attempted to compile and link a (simple) test program.  It turns out
that a few things (like CLIB) are missing from the DDK which detract from what
otherwise could be an outstanding offering.  Please provide me with CLIB for
CL386.  The documentation (advertising, promo material, CD-contained) for the
DDK says "includes Microsoft Ccompiler CL386".  The compiler is incomplete
without the CLIB library.


ANSWER:
The CL386 compiler is a Microsoft internal compiler that IBM and Microsoft
used while jointly developing OS/2.  The JDA (Joint Development Agreement
between Microsoft and IBM) which stipulates what we are allowed to ship.
While we are allowed to ship the CL386 compiler, we are only allowed to ship
the OS2286.LIB and OS2386.LIB libraries that were created by Microsoft and are
required by a device driver.  So LIBC.LIB is not allowed to be shipped.  We
recommend that you use C Set/2 for new development.




!STORAGE________________________________**********
January 17, 1994
QUESTION: (Ref: 308)
Q1. Currently, our device driver which runs under OS/2 2.0 requires that an
    OS/2 file (OS2DASD.DMD) be patched to support sector sizes other than the
    standard 512 bytes.  What modifications can be made to our driver so that
    we no longer have to patch the OS/2 file ?

A1. Patching OS@DASD.DMD is not a solution to support sector sizes other than
    512 bytes.  This is not a restriction imposed by OS2DASD.DMD.  The 512
    bytes sector size is the limit that the OS/2 file system supports.  If the
    adapter's maximum transfer size exceeds 512 bytes, the driver is
    responsible for issuing multiple operations to the unit to complete the
    caller's request.  The IORB_EXECUTEIO control block structure contains the
    following fields:

             RBA              I/O starting address
             BlockCount       Sector count
             BlocksXferred    Number of sectors transferred
             BlockSize        Number of bytes per sector

    The driver must have an algorithm using the above fields to determine the
    number of sectors to transfer.  The BlockCount field is used to carry the
    number of sectors to transfer.  The BlocksXferred is used to keep track of
    the number of sectors transferred within the driver's algorithm.  The
    BlockSize is the sector size.
==============================================================================

Q2. The QUERY DEVICE PARAMETERS request (Category 8, Function x63) refers to
    an Extended BPB.  The Strategy entry command BUILD BPB wants the driver to
    copy the Boot Block structure to our own BPB table and then return a
    pointer to it.  Should the extended fields be maintained/copied here, 31
    bytes ?  36 bytes ?

    Why does the technical reference manual show the Boot Sector format as
    having a WORD size for the 'Hidden Sectors' field instead of a ULONG size?
    And 2 bytes for the Jump field instead of 3 bytes ?

A2. The QUERY DEVICE PARAMETERS function returns the device parameters for the
    specified device at location ponted to by the passed BPB pointer.  This
    will be a 36 byte area where the device parametrs are copied.
==============================================================================

Q3. We still have some questions on this.  The Technical Reference Manuals are
    quite clear that the QUERY DEVICE PARAMETERS request is to return a 36
    byte BPB.  What is not clear is the strategy command BUILD BPB.

    First, On entry to the BUILD BPB command, the transfer address in our case
    is going to contain Boot sector information.  Since the Boot Sector Format
    described on page 15-10 of the Physical Device Driver Reference Manual is
    inaccurate, I need to know how many bytes of Boot Sector Info to transfer
    FROM the buffer pointed to by the transfer address to my BPB table, 31, 36
    or something else ?

    Second, the device driver is to return a pointer to the built BPB table.
    Is this table to be 31 bytes, or an extended BPB of 36 bytes ?

A3. You need to transfer 31 bytes of the boot sector info from the buffer
    pointed to by the transfer address.

    The BPB table is to be of 31 bytes.  The BPB structure is:

        /*
        ** BIOS Parameter Block
        */

        typedef struct _BPB  {                  /* BPB */

         USHORT        BytesPerSector;
         UCHAR         SectorsPerCluster;
         USHORT        ReservedSectors;
         UCHAR         NumFATs;
         USHORT        MaxDirEntries;
         USHORT        TotalSectors;
         UCHAR         MediaType;
         USHORT        NumFATSectors;
         USHORT        SectorsPerTrack;
         USHORT        NumHeads;
         ULONG         HiddenSectors;
         ULONG         BigTotalSectors;

         UCHAR         Reserved_1[6];
         } BPB, FAR *PBPB, *NPBPB;

         typedef BPB    near *BPBSY";      /* An array of NEAR BPB Pointers */
         typedef BPBS   far  *PBPBS;       /* A pointer to the above array  */
==============================================================================

Q4. The Strategy entry command INIT wants the device driver to return a far
    pointer to the BPB array for the logical units.  Currently, the device
    driver returns a far pointer to an array of data seg offsets to each BPB
    table for the individual units.  Is this correct ?

    Why does the INIT request want a Far Pointer to an array of near (data seg
    offsets) pointers ?  The Physical Device Driver Reference Manual page 15-5
    seems to be saying that it wants a far pointer to an array of sequential
    BPB structures, not a far pointer to an array of NEAR (data seg offsets)
    pointers which point to each of the individual structures ?

A4. Yes, this is correct.  The Physical Device Driver wants a pointer to to an
    array of NEAR pointers.  Here is an example:

         EXTERN NPBP InitBPBArray[30];
         EXTERN BPB  BPB_144MB;

         ReqPkt->BPBArray = (PVOID) InitBPBArray;
         InitBPBArrayY0" = &(BPB_144MB);
         InitBPBArrayY1" = &(BPB_144MB);




!STORAGE________________________________**********
January 07, 1994
QUESTION: (Ref: 796)
I have questions about the OS/2 IFS interface.
Q1. DosQueryFSAttach (DosQFSAttach)

    I don't have any OS/2 1.3 documentation availible to me at this time but
    looking at the 2.0 documentation I don't understand what DosQueryFSAttach
    is suppose to return in the rgFSAData field.

Q2. cdfsi (Current Directory File System Independent)

    On page 1-25 of the IFS doc I downloaded from the DUDE it states that
    cdfsi may be modified by FS_ATTACH and FS_CHDIR but page 2-13 states that
    FS_CHDIR must not modify cdfsi.  FS_ATTACH does not receive or return a
    pointer to cdfsi so I cant modify cdfsi there either.  How does the cdfsi
    structure get initialized / modified ?

Q3. fsfsi (page 1-20)

    What volume info am I suppose to put in fsi_hvpb?

Q4. FileFindBuf structure (used for FS_FINDFIRST)

    I am using the FileFindBuf structure that came with Microsoft C6.  It is
    279 bytes long.  When I receive a FS_FINDFIRST level 1 request the cbData
    field is only 278.  I can't modify the last byte.  Am I using the right
    structure?  Is the achName field suppose to bea 256 byte array?


ANSWER:
A1. You return an asciiz string with any info you would like.

    The File system name has already been retrieved into the buffer for you by
    the file system.  YOU don't deal with the structure returned by
    DosQueryFSAttach, you just return ONE ASCIIZ STRING

A2. The CDFSI is the INDEPENDANT portion and should NEVER EVER be changed
    by the IFS. The note isn't clear, but should say that the CDFSD
    (File system DEPENDANT portion) can only be changed by FS_ATTACH &
    FS_CHDIR entrypoints. FSH_GETVOLPARM can find the CDFSD if you need
    it.

A3. The Volume ID in the FSI (independant, don't touch it) is returned on the
    FS_FSINFO level==0 call for LOCAL file systems only.

A4. The FileFindBuf structure IS 279 bytes long, correct, but that does NOT
    say how big the APPLICATION buffer passed to you is.

    Many applications DO NOT use the full structure, and leave room ONLY for
    an 8.3 name..  256-13 = 243 bytes not used, so you could have a buffer
    only 279-243=36 bytes long...

    Note that if you have a FAT drive & max file names of full 8.3 long, then
    more than ONE file result will fit into a FILEFINDBUF structure (279/36) =
    7 files...  plus 27 bytes left over...




!OTHER__________________________________**********
January 07, 1994
QUESTION: (Ref: 791)
Is there any documentation available on drivers for multiprocessors?


ANSWER:
We do not have any documentation on drivers for multiprocessors at this time.




!OTHER__________________________________**********
January 07, 1994
QUESTION: (Ref: 787)
I have a question about the PCMCIA Card Services and AT-bus Socket Services
provided for OS/2 2.1.  We see that PCMCIA support is provided as an option
during OS/2 2.1 installation.

Can you provide information on the interface that an OS/2 device driver would
use to access the Card and Socket Services which we understand is provided in
the IBM OS/2 PCMCIA Support driver ?

Additionally, could an application also interface to the OS/2 PCMCIA Support
driver, or are only OS/2 device drivers permitted access ?

Any information/documents which you could provide would be helpful.


ANSWER:
The PCMCIA General Committee publishes the following specifications for the
software archtecture components:

    CS 2.00 Specification
    SS 2.00 Specification

They can be order via:

    PCMCIA Office
    1030G East Duane Avenue
    Sunnyvale, CA 94086

    (408) 720-0107 Voice
    (408) 720-9416 Fax
    (408) 720-9388 BBS

There are three major software components defined in the PCMCIA architecture:

   - Clients
   - Card Services
   - Socket Services

OS/2 2.1 includes only the Card Services device driver which is the part that
is normally included with the operating system.  Socket Services is normally
provided by the system/chip vendor.  Client Server is normally provided by the
card vendor.

The references mentioned above will give you a lot of information.  Basically
Card Services driver communicates to Socket Services and Client driver.
Client driver has the communication to its application through DosDevIOCtl
API.

All interfaces are defined in CS/SS specifications in the above.  The latest
DDK Input/Output Device Driver Reference has a PMCICA chapter, and describes
more detail about the interface between Clients and Card Services.  In
addition, it has a lot of other material about PCMCIA throughout the DDK.




!VIDEO__________________________________**********
January 07, 1994
QUESTION: (Ref: 752)

I am developing WinOS2 Seamless driver.  Well, I am almost done, however, I
need some explanation to an issue in the seamless driver.  This relates to
Saving/Restoring Video Hardware registers and resources.  In the manual:
"Device Driver Source Kit for OS/2 ver 2.1, Display Device Driver Reference",
it says about an alternative apprach in Chapter 7 (Seamless Windows Support)
under caption:  "Save/Restore Processing of Video Registers/Hardware" para 2.
It requires marking associated registers and resources with handles.  Can you
please explain this as to how it can be done?

 Display Driver Reference:
   DDK 1.1, file is \DDK\BOOK\DISPLAY.INF
   Chapter:      Seamless Window Support
   Section:      Seamless Design Issues
   Sub-section:  Save/Restore Processing of Video Registers/Hardware
   Entire text of this sub-section follows.

"A straightforward approach to save/restore processing is to force both the PM
and seamless windows drivers to explicitly set video hardware registers
anytime the registers are required.  Since the video FSRamSemaphore must be
used to coordinate hardware access, this semaphore can be obtained, the
necessary register(s) set and used, and the semaphore released with no
problem.

An alternative approach is to design the necessary save/restore processing and
mark the associated registers and resources with handles (such as
SessionIDs)."

A search of all DDK documentation for the term SessionIDs turns up only one
hit, this one.  A search of all DDK documentation for tthe term "handles"
turns up many, many hits.  I sampled some of these hits shows that most are
uses of the word as a verb.


ANSWER:
I was involved in the original design of the Seamless WINOS2 Display Device
Driver.  We achieved Hardware Synchronization through the use of the Fast Safe
Ram Semaphore.  Until now, I had not heard of any other mechanism for
coordinating access to the hardware.  I do not see how the marking of the
associated registers and resources with handles could work.  The bottom line
is that, unless we have a working seamless model using this option, the entire
paragraph should be removed from the DDK documentation.




!I/O____________________________________**********
January 07, 1994
QUESTION: (Ref: 610)
We have developed OS/2 COM Port drivers for the IBM ARTIC adapter and would
like to have DosDevConfig report the addition of our COM ports.  I cannot find
any information in the PDD manual regarding updating information reported by
DosDevConfig.

After we install the Arctic card with the 16 ports and install the device
drivers, DOSDevConfig still only reports 2 ports.  We would like it to report
18, not 2. We have referred to the control programming reference, which states
that calling DOSDevConfig with the parameter DEVINFO_RS232 will return the
number of attached ports.

- We would like to have DOSDevConfig return the proper number of com ports.
  Is there a way that they can update the information returned by
  DOSDevConfig?

- If the answer to the above question is yes, how do they do it?

- If the answer is no, then why?  Is it because DOSDevConfig queries the bios
  and the bios only knows about the original com ports?


ANSWER:
No, I dont think they can return the proper number of COM ports using
DOSDevConfig.  He has to write code to get this information from the CPP.
Yes, it is because DOSDevConfig queries the BIOS.




!BASE !OTHER____________________________**********
January 07, 1994
QUESTION: (Ref: 522)
Q1. I'm trying to build a VDD that hooks software int 14h (COMM).  Where do I
    put my "szDriverName" string, and what do I have to use to convert the
    pointer to 16:16, in order for the DOS session to be able to access it and
    print it out?  This is NOT something the DOS program should try and change
    (i.e., it's read-only).

A1. A C set/2 application is a 32-bit process, and pointers within the
    application are 32-bit linear addresses in the process address space.
    Linear addresses are special addresses which are decoded by special page
    decoding hardware to produce a 32-bit physical address.  PDD, however, is
    a 16-bit program which must deal with the 32-bit addresses generated by
    the 32-bit compiler.

    When a 32-bit application calls the OS/2 kernel via a standard device
    driver request, the kernel converts the addresses contained in the request
    packet to 16:16 addresses.  Thus, the PDD sees only 16:16 addresses, and
    has no direct knowledge if the application is a 16-bit or 32-bit process.
    This can be accomplished by invoking the DosSelToFlat or DosFlatToSel
    macros.

    Pointers in a VDM:  DOS applications running in a VDM utilize real mode
    addressing.  A 20-bit real mode address in the segment:offset form can
    refer to a physical address within the VDM's one megabyte address space.
    If the VDM makes an IOCTL call to your device driver with pointers in the
    private data and/or parameter buffers, the driver must take an extra step
    to ensure the pointers are converted correctly.  The driver checks the
    TypeProcess variable in the local info.  seg structure to determine if the
    application is a VDM application.

    If it is a DOS application, the driver allocates a GDT selector and
    converts the segment:offset address to a VDM-relative physical address by
    shifting the segment left 4 bits and adding in the offset.  This is the
    same way the physical address is calculated in real mode for a real-mode
    application.  The driver then calls LinToGDTSelctor with the 20-bit
    physical address of the VDM application's buffer and/or parameter address.
    This call maps the 20-bit physical address to the caller's address using a
    GDT selector which can be accessed at kernel or interrupt time.  The
    selector should be released by a call to FreeGDTSelector when the driver
    is finished with it.  It is important to note that normally,
    LinToGDTSelector requires a 32-bit linear address and not a 20-bit
    physical address.
==============================================================================

Q2. Can the C++Set/2 SUBSYSTEM library functions be used within my VDD code?
    If so, how the heck do I prevent the compiler/linker from changing the
    entry point to the code from my "#pragma entry(MyVDDEntryPoint)" to the
    SUBSYSTEM entry point?  Along the same lines, do I need to make a call to
    _DLL_Init() from within my VDD entry routine?

A2. Yes, he can use CSET/2 ++ subsystem library functions in VDD.  I would
    guess he is missing something in his switches.  I suggest he download
    example code put on COMPUSERVE in OS2DF1; the file name is CDISK1.ZIP.
    The makefile should give him his answer.

    Also, I recommend that he read Steve Mastriani's book WRITING OS/2 2.1
    DEVICE DRIVERS IN C (VNR COMPUTER LIBRARY).
==============================================================================

Q3. My virtual device driver needs to pass a POINTER to a string that is
    contained in its (the VDD's) data area, back to the DOS application, so
    that the DOS application can access the string pointed to.  DOS needs to
    access data within the VDD's space via a pointer passed BACK to DOS FROM
    the VDD.

    I've tried all of the obvious ways of doing something like this, including
    converting the "flat" VDD pointer to a sel:off (GDT or otherwise) and
    passing that back to DOS...  with no success.  I've also used "#pragma
    seg16(...)" to make sure things are aligned correctly prior to the
    conversion, but DOS still can't get at it.  I obviously am either missing
    some step (perhaps I have the VDD's string allocated in the wrong data
    segment for doing what I want to do), or I need to allocate some DOS
    memory (VDHAllocDOSMem?)  and copy my string into there first, and then
    give the DOS app that address in 16:16 form, or remap the memory or
    whatever.

    The point is, I've tried most of the above and still can't get at that
    string from the DOS app.  I also know that it CAN be done, since I've seen
    at least two other VDD's that do (somehow)...

A3. There are memory management virtual dev help services available to allow a
    DOS application to map into a VDD's data area.

    The following types of virtual dev helps may be used:

        VDHCopyMem
        VDHWriteUBuf
        VDHExchangeMem
        VDHMapPages

    The VDD reference explains the use of these virtual dev helps.  The
    following VDH service would be the architected way of doing this.  The DOS
    app issues the int 2fh and the VDD returns the string.  Here's the
    description of VDHRegisterAPI:

    /***EP+ VDHRegisterAPI - Register a VDD's API handlers
     *
     *      Sets either a V86 mode or protect mode (or both) API handler for
     *      a particular VDD.  Each VDD must register with a unique VDD device
     *      identifier.  This service provides a mechanism for DOS application
     *      to directly communicate with the VDD.
     *
     *      ENTRY
     *          pszName    - Name of the VDD; maximum length is MAXLENXDD.
     *          pfnV86Hook - V86 mode hook routine address (or NULL if no V86
     *                       mode handler is needed).
     *          pfnVPMHook - VPM mode hook routine address (or NULL if no VPM
     *                       mode handler is needed).
     *
     *      EXIT-SUCCESS
     *          returns TRUE
     *
     *
     *      EXIT-FAILURE
     *          returns FALSE
     *                out of memory or VDD name already registered
     *
     *      VDM TERMINATION IMPLICATIONS
     *          None.  The hook(s) will be freed when the VDM is terminated.
     *
     *      CONTEXT
     *          Task
     *
     *      NOTES
     *          1) Hook routine interface:
     *              VOID HOOKENTRY pfnhook(p, pcrf)
     *                  ENTRY  PVOID p    - reserved
     *                         PCRF  pcrf - pointer to client register frame
     *
     *                  EXIT    none
     *
     *
     *                  USES    EAX, ECX, EDX, FS, GS, Flags
     *
     *                  CONTEXT VDM Task
     *
     *          2) V86/VPM mode calling procedure (int 0x2f)
     *
     *              Get OS/2 version:
     *
     *                DOS apps can use this to determine if they are running
     *                under OS/2 or not.
     *
     *                Entry:
     *                 AX = 4010
     *                Exit
     *                 If OS/2 is present
     *                  AX = 0
     *                  BX = OS/2 version number (ex: BX=1400 for OS/2 2.0)
     *                 If not running OS/2, AX will be unchanged
     *
     *             Get VDD API Entry point:
     *
     *                DOS apps can use this to get the address to call to invoke
     *                the VDD entry points.  If the int 2f is issued in V86 mode,
     *                a V86 mode breakpoint that invokes the V86 VDD API handler
     *                will be returned, if issued in VPM mode, a protected mode
     *                breakpoint that corresponds to the VDD VPM API handler will
     *                be returned.  The DOS application can then issue a far call
     *                to the address returned to call the VDD API handler.
     *
     *              Entry
     *               AX=4011
     *               DS:(E)SI=pointer to asciiz name of VDD register with
     *                        VDHRegisterAPI
     *
     *              Exit:
     *               If VDD API handler exists:
     *               If VDD API handler exists:
     *                ES:DI = breakpoint address
     *               otherwise:
     *                ES:DI = 0
     */




!VIDEO__________________________________**********
January 07, 1994
QUESTION: (Ref: 464)
I would like to load a DOS device driver during vvCreate in the virtual video
driver.  This DOS device driver hooks INT 10 and has several command line
parameters.  The goal is to have the device driver hook INT 10 BEFORE the VDD
hooks INT 10.

Currently the VDD hooks the interrupt first so that we get the following
order:

         device driver -> VDD -> bios

The order I am trying to get is

         VDD -> device driver -> bios.

Is this possible?  If not, can you provide me with some other suggestion as to
how to accomplish this?


ANSWER:
We do not see a straight forward method to accomplish what the customer wants
to do.  It has been recommended that the customer write a small VDD that would
look for his adapter and if found load the VDD that needs to hook to INT 10
and then load the HIGH_RES.SYS.  It is not clear whether the device chain gets
set on a LIFO basis and the customer must verify if this happens and then
determine which driver is to be loaded first.  IT IS NOT ADVISIBLE TO
MANIPULATE THE DEVICE CHAIN.




!BASE___________________________________**********
January 07, 1994
QUESTION: (Ref: 432)
I have a question regarding the usage of DevHlp_Lock and DevHlp_Unlock,
specifically when is it necessary to lock a segement.

For example, an IOCtl request has the following:

    Parameter Buffer Address
    Data Buffer Address

Do these segments have to be locked?

Also, lets assume that in the Parameter and Data buffers are pointers to Ring
3 application memory, do these segments have to be locked?


ANSWER:
The Physical Device Driver Reference of OS/2 2.0 Tech library has the
information about the mentioned Dev_hlp routines.

Lock need be done only on segments that have not been locked already by the
OS/2 Kernel (for example, an address that is passed to the physical device
driver throuth an IOCTL- OTHERWISE the Kernel will have access and data may
get corrupt).  If the physical device driver plans to lock the segment down,
it should call Lock before calling VerifyAccess.




!VIDEO__________________________________**********
January 07, 1994
QUESTION: (Ref: 364)
We would like to create a windows driver that can be used for both seamless
and full screen operations.  A crucial step in this process is being able to
determine wether or not we are seamless.  There is a call in the example
4plane seamless code that makes an INT 66 call to VWIN with the function code
VWIN_AM_I_SEAMLESS (AH=80).  Is there any documentation for this interface?


ANSWER:
This function will be documented in the next revision of the VDD Reference
which will be included on the September 93 release 1.1 of the DDK.




!VIDEO__________________________________**********
January 07, 1994
QUESTION: (Ref: 363)
The IBMDEV32 code was modified slightly to run 1024x768x16.  Everything works
fine until a seamless windows driver calls far_exclude.  After thunking to the
PM cursor code an attempt is made to access EnumBankFlag in the _DATA segment.
At this point no accesses are allowed to the _DATA segment.  Access to
_PtrData32 is allowed.  A simple solution was to move EnumBankFlag to the
segment _PtrData32.

A seamless windows session makes a far_exclude call.  A THUNK is performed to
get to the PM driver's far_exclude function in the PM driver segment
_PtrCode32 (32 bit land).  From PM's far_exclude function, attempts to
reference varibles in PM's own _DATA segment result in an invalid address.  It
doesn't matter what varible in the _DATA segment you try to access, all
accesses are invalid.  This is reproducable via the debugger and is also
reproducable by putting a varible reference in (PM's) _PtrCode32 segment that
accesses the PM Display Driver's own _DATA segement.  Data accesses to the
PM's _PtrData32 segment are fine.

This is reproducable with the 640x480x16 32 bit PM Display driver that is on
version 1.0 of the DDK.  My question is, why can't a seamless far_exclude call
access the _DATA segment?


ANSWER:
The answer is that the customer is trying to access data that is not permitted
by the OS.  OS/2 is inhibiting the effort to change data because of the
architecture and hardware architechure.  The suggested solution is to convert
this driver to a presentation driver.  Otherwise, the system is just working
as designed.  He should note that the kernel will not allow him to modify ring
2 code from ring 3. He is attempting to use a VDM to modify 32-bit protect
mode code.

The kernel had just been modified resently to allow him to get as far as he
did.  I would suggest that he take time to consider converting his device
driver to an OS/2 presentation driver.  I believe this would be more
advantageous than the modifications he is trying to make.




!OTHER__________________________________**********
January 07, 1994
QUESTION: (Ref: 289)
Can I get details on the interface for DevHlp_RegisterPerfCtrs?  It is not in
the PDD reference manual, and it appears in the COM.SYS driver source in an
area where I may impact its input parameters.  I need to know what's going on
there.


ANSWER:
SPM/2 2.0 provides documentation for this API, plus it provides the APIs
necessary to retrieve this information and analyze it.  SPM/2 2.0 gets this
information through APIs in OS/2 that are available in the OEMI document only.

SPM/2 2.0 allows you to register and update performance hooks.  You can then
collect them with SPM/2 and generate reports.  You can use this for debugging,
where you code the hooks during your development and remove them before
shipping.  For example, you could use this as a profiling tool to count the
number of times a procedure gets executed, or the amount of time spent in a
procedure.  You could also define a set of hooks that would be useful to your
customer, for example hooks to measure response time.  You could then ship
these hooks in your code and tell your customers that your product is enabled
with SPM performance hooks.

SPM/2 is the IBM System Performance Monitor/2 and the OEMI document is part of
the package.  Here are some information that I got from the development group.

 DevHlp_RegisterPerfCtrs is not the correct name for the API.  There are
 actually three registration calls for ring 0 apps to use:

  - dh_RegisterPerfCtrs - for device drivers
  - fsh_RegisterPerfCtrs - for file system device drivers
  - vdh_RegisterPerfCtrs - for virtual device drivers

These are documented in the "User Metrics:  Overview" section under "Ring 0
applications" in the SPM documentation.  You can also look at the file
SPMUH.INC that is installed in the \API subdirectory off of the main SPM
subdirectory if you install with the /API option.



=================== Administrative Stuff ===================
________________________________________**********
January 24, 1994
