This is file: 02_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__________________________________**********
February 24, 1994
QUESTION: (Ref: 940)
Is it possible to write PDDs in CSet from IBM?  What are the issues to be
taken care of with respect to the 32 bit compilation?


ANSWER:
No.  PDD's under OS/2 2.x are 16-bit.  IBM C Set/2 can only generate 32-bit
code.  You need a 16-bit C compiler such as Microsoft C 6.0.




!PRINT__________________________________**********
February 16, 1994
QUESTION: (Ref: 916)
We are looking for some documentation for the Printer Test Tool.  Could you
tell us where it is located?


ANSWER:
Please tell the customer go to \ddk\book directory on the DDK.  There he will
find a file called PRINTER.INF.  Have him enter "view printer.inf" from the
command line.  This ref contains a great deal of information about printer
test tools.




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 914)
How can I get a copy of the DDK?  What does it cost?  Does it come on a CDROM?


ANSWER:
Please look in the Information File Area on the DUDE for information regarding
the DDK.

To do this, select (from the main menu):

File System (type in F)
Area Change (type in A)
type in INFO
file titles (type in F)
enter

This will give you a list of the files in the Info area.  Three files will be
of immediate interest to you:

   DDKANNOU.TXT
   DDKORDER.TXT
   DDKPRICE.TXT




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 908)
I would like to know the requirements for developing with the POSS/DOS drivers
on the IBM 4693 and 4694 POS registers.  I would like to develop under DOS
using IBMC2 for a retail POS application.  Is this possible with POSS/DOS and
where I can find more information about this device driver package.


ANSWER:
The POSS/DOS Programmer's Guide, part number SC30-3621, is available from IBM
Fulfillment Center, 800-879-2755, at a price of $97.00




!VIDEO__________________________________**********
February 24, 1994
QUESTION: (Ref: 897)
We are attempting to create a seamless Windows driver for our Tseng ET4000
based video card and are encountering the following problem:

When we attempt to pull down a menu on the Windows application we crash
somewhere in the GDI.  The location of the gp-fault is reported as 0016:131C.
As we do not have any debug symbols for the GDI we have no idea what function
we are crashing.  The crash exhibits the following symptoms:

    1.  Attempt to pull down menu, generate fault, select "Ignore"
    2.  The popup menu is drawn
    3.  The application loses focus
    4.  The application regains focus and the popup menu is erased
    5.  The application continues to run

Alternatively we observe different symptoms if we select "Close"

    1.  Attempt to pull down menu, generate fault, select "Close"
    2.  Report of gp-fault at 0016:131C, select "OK"
    3.  Application is redrawn, system menu box and maximize and minimize
        buttons are garbaged.
    4.  Application is terminated

Any assistance you could give us in diagnosing this problem would be greatly
appreciated.  Also, if we could obtain a symbol file for the GDI we could
probably make more progress in isolating this problem ourselves with the OS/2
kernel debugger.  Thank you.


ANSWER:
Unfortunately, our agreements with Microsoft preclude us distributing the
symbol files for WIN-OS/2 components.

Another of our customers ran into a similar problem.  He was getting symptoms
similar to yours and a GPF at the same address.  This custome found a
workaround.  When he removed RC_PALETTE from drivers_RC_caps, the GPF went
away.




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 896)
Is it possible to set breakpoint on "memory write" in os/2 kernel debugger?  I
was trying to use "J" command but it is not working as a conditional
breakpoint.  I need to trigger on some pattern written at memory location in
my driver.


ANSWER:
Use :  BR W1 Location '?  "Data written";.p*;R;g' This will break when the
location will be written to whatever IP is writing to that location.  I never
succeeded to get the conditions to work correctly on the break registers so I
always display the register to locate what instruction is writing to that loc
and I go.




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref:884)
Hello, I am having several problems trying to debug a driver.  Can
you please provide assistance?

Q1. I am able (using the OS/2 debugging kernel) to setup the problem that I am
    trying to debug.  The problem is that if I press a button in the DOS app,
    the machine hangs.  Unfortunately, the ENTIRE machine hangs.  I have been
    able to trace the program into my driver several times, but it seems that
    the only way that I can get it to die is if I just let the application
    run.  If I single step, I will single step all night.  If I run (go), then
    it hangs the machine.  Control-C from the debugging terminal does not get
    the machines attention.  What can I do?

Q2. If I install a breakout switch on the NMI line on the hardware bus, can I
    use this to bring up the OS/2 kernel debugger?  Some debuggers, such as
    Periscope, will catch it if this line gets hit and go into debug mode.
    Does the kernel debugger support this?


ANSWER:
A1. Single step in one time, find the places the debugger needs to stop and
    place breakpoints there, then exit, and continue again with the
    breakpoints set.

A2. An NMI trigger SHOULD be caught in the KDB.  I use one on my machine.




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 880)
This question involves Presentation Driver and Mirrors (for migrating windows
programs)

In Windows, an application can exchange parameters explicitly with the driver
by passing information in an extended DEVMODE structure when it calls
CreateDC.  How do you pass extra information from a Windows program that is
migrated using Mirrors to an OS/2 32-bit presentation device driver.  By the
way, this driver is custom-made for this application; this application
understands the internal data of the driver including the equivalent of
DEVMODE in the OS/2 presentation driver.


ANSWER:
IBM has a contract with One Up Coporation to market and support the Microgrfx
MIRRORS Toolkit.  Their 800 number is 1-800-678-0187.  They should be able to
help you with this question.




!OTHER_________________________________**********
February 24, 1994
QUESTION: (Ref: 871)
Is there any way to query OS/2 for country information, other than parsing the
CONFIG.SYS file for a COUNTRY= line?


ANSWER:
Have him look up the dos call DosGetCtryInfo which is a 16bit API referenced
in the 1.3 Control Programming Reference book.

There is also a 32 bit API called DosQueryCtryInfo which is referenced in the
2.0 Control Program Reference book.

These will tell him what country specific information is loaded in the system
at run time.




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 866)
I have a device driver which currently takes command line parameters for
configuration information.  (It's a replacement for COM.SYS/VCOM.SYS.  The
parameter format matches COM.SYS) In an upcoming revision, I would like to
have an installation and configuration program that runs on the desktop to set
up the hardware configuration.

I would envision this little program storing its information in the OS2.INI
file.  Is there any way for a device driver to access the INI files?  I'm
interested in init time access in particular, but I don't see any DevHlp
functions for accessing INI files at all.


ANSWER:
INI file functions are not available at DD init time as these depend on PM,
and PM is not yet running.




!STORAGE________________________________**********
February 24, 1994
QUESTION: (Ref: 864)
I want to use the IFS helper function FSH_SEMREQUEST to obtain access to a 16
bit system semaphore that was created in another process (a EXE file).  I
passed the handle to the semaphore to the IFS with the FS_FSCTL function.
When FSH_SEMREQUEST gets executed I get a exception.  Am I using the
FSH_SEMREQUEST function properly ?  What is the proper way to establish
semaphore communication between a executable file and a IFS ?


ANSWER:
System semaphores are typically used by a physical device driver to
communicate with an application process.  A physical device driver cannot
create a system semaphore, although it can use the system semaphore that the
application process has created.  The application process must pass the
application's handle to the physical device driver in a generic IOCtl.  The
physical device driver then uses the DevHlp service SemHandle to obtain a
semaphore handle that it can use.  The physical device driver must indicate in
the SemHandle call that the system semaphore is IN-USE by the physical device
driver.  When the physical device driver no longer needs to use the system
semaphore to communicate with the application, it must call the DevHlp
SemHandle and specify that the system semaphore is NOT-IN-USE.

On the FS_INIT IFS entrypoint,the Devhelp function address is passed
as one of the parms

INT far pascal
FS_INIT (PCHAR pcParm,
         ULONG Devhelp,  <------------
         ULONG far *pMiniFSD)




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 863)
I am writing applications that I wish to run on all different national
versions of OS/2 2.x.  Can you tell me how many versions of country.sys there
so that I can test my programs with all of them?


ANSWER:
The only COUNTRY.SYS I am aware of is the same one used by the US.  The
countries I coordinate (BR,DK,FR,GR,IT,NO,NL,PO,SP,SU,SU,UK,LA,CF) all use the
same COUNTRY.SYS.  If there are different versions of this file required to
support AP, Hebrew, Arabic, etc I am not aware.

After checking with the DBCS folks, I found that there are two versions of
country.sys.  The DBCS version is a bit larger than the US/European version.
It contains info for pure DBCS code pages used on the host.

So all languages which use single byte versions of country.sys (US, European,
etc.)  use the same COUNTRY.SYS shipped with the US version of OS/2.  There is
also only one version of COUNTRY.SYS for OS/2 DBCS support.  The version of
COUNTRY.SYS on OS/2J is the same one as on OS/2K and OS/2T.




!OTHER__________________________________**********
February 24, 1994
QUESTION: (Ref: 853)

I am writing a Level 1 Physical device driver to communicate with a
proprietary Microchannel card.  I am using Steven J. Mastrianni's DevHlp
library and have the following questions.

Q1. When performing a DosDevIOCtl function, how does OS/2 verify the Parameter
    and Data buffers before calling the driver?

Q2. In SJM's book his examples VerifyAccess is called before LockSeg and
    while scanning the Question.txt file I see answers that state the Lock
    should be performed before the Verify.  Which one is true?

Q3. If the buffer's passed to the IOCtl function have been allocated on the
    stack (by the calling process) does it need to be locked and verified or
    does the fact that OS/2 passed the call through indicate that the pointers
    are valid?


ANSWER:
A1. OS/2 does not verify the parameter and data buffers in an IOCtl, that's
    why you must call VerifyAccess DevHlp.

A2. The Lock/Verify question is a tough one.  Bottom line is that it works
    both ways.  Locking is costly (timewise) and I've written over 60 drivers
    using VerifyAccess first, none have ever failed.  My read on this is that
    the VerifyAccess never gets preempted before the call to Lock.  If you
    have control over both the app and the driver, you're safe, in my opinion,
    to do it either way.

A3. It's best to always define your IOCtl buffers DS-relative, i.e., define
    them in your application and initialize them.  For example:

    USHORT buffer^8192 = {0};


It's much easier to debug this way with the kernel debugger, since the kernel
debugger cannot display automatics.  Both buffers should generally be small
anyway.  If they will be large, allocate them up-front in the application.




!BASE !OTHER____________________________**********
February 24, 1994
QUESTION: (Ref: 852)
What is the recommended way to install drivers where there is a need to MODIFY
the existing contents of config.sys.


ANSWER:
The answer is that the developer can use the ":RUN" statement in the
DSP file.  The ":RUN" will be called first and can be a cmd file or program
that will parse the CONFIG.SYS file and make the necessary changes.

The syntax for the ":RUN" is:

    :RUN
     A:BARNEY.CMD




!I/O____________________________________**********
February 24, 1994
QUESTION: (Ref: 843)
I am currently writing device drivers for DOS, OS/2, and Windows.  We have
received an IBM ThinkPad to do testing with because it has an ISO point device
installed.  The problem occurs when we connect a mouse to the PDP port and we
wish to send commands to this mouse.  It appears from our data that any
commands being sent to the PDP mouse never reach it other than a RESET mouse
command following by other commands (probably part of the BIOS).

Is there any way (in DOS and OS/2) which we can send commands to the mouse
which is installed on the PDP device?

Is there any way that we can disable the ISO pointing device and have the
commands sent directly to the mouse installed on the PDP?

In DOS would these be special INT 15 calls, if so what would they be?


ANSWER:
The answer is that all production level Thinkpads and the PS/2 'E' have the
capability to allow the on-board pointing stick to be disabled.  There is no
hardware capability for them to be re-enabled though so a hardware reset,
(machine re-power), must be done to get the pointing stick back.  The original
700 series machines which were manufactured before February of 1993 have the
old level bios which does not support the disable command.

    Send the following two commands to the 8042 to retrieve the ROM version.
       E2h
       46h

       The returned value should be ABh or higher which is the value that
       signifies that the machine supports the disable command set.

         - The 700 returns a 98h which shows it as invalid for using the
           disable command set.

    If the machine supports the disable, the following command set will
    disable the pointing stick.

       E2h
       45h




!OTHER !STORAGE_________________________**********
February 04, 1994
QUESTION: (Ref: 883)
Is there a newer version of the OEMSPEC than version 0.4?  If so, where can I
obtain a copy (preferably softcopy).


ANSWER:
The document is now called Storage Device Driver Reference.  It is available
on the DDK under that name.  On earlier DDKs, it is under its part number,
S71G1897.  The document can also be purchased alone, for $29, by calling
1-800-633-8266.




!OTHER__________________________________**********
February 03, 1994
QUESTION: (Ref: 865)
Would it be possible to borrow an IBM system to do some testing?


ANSWER:
There is the possibility of access to the GE Lease/Rental program through our
DAP (Developer Assistance Program).  There are some conditions that must be
met to be eligible though.

Please call the DAP and inquiry about this.  The number is (407) 982-6408.

This is the only source of equipment that I know of at this time.




!BASE !OTHER____________________________**********
February 04, 1994
QUESTION: (Ref: 861)

The PDD reference indicates on pages 3-5 and 3-6 that strategy and interrupt
routines in a PDD can rely on OS/2 preserving any registers used by the
driver.

Does this include segment registers?  Will OS/2 let me exit from a strategy or
interrupt routine having altered DS, ES, FS or GS.

While I'm at it, are there any restrictions imposed by OS/2 on the use of the
FS and GS segment registers?


ANSWER:
I set a breakpoint, using the kernel debugger, on the exit of PDI_Int_Handler
routine which is the interrupt routine for the PDI mouse.  I altered DS,ES,FS
and GS before returning to the kernel and there were no problems.  I also
altered CS and SS for grins and major problems occurred.

I believe that the only way to reference the FS,GS registers is to use an
assembler pragma ".386p" which enables use of the extra 386 registers and the
high word of the general registers.  Use ".286p" to toggle back to 286 mode.




!STORAGE________________________________**********
February 04, 1994
QUESTION: (Ref: 847)
I am developing an ADD to control a "dumb" SCSI controller.  Emulating SCB
support will take a lot of code and a lot of development time.  I have noticed
that both the OS2ASPI and OS2SCSI drivers support ADD's which do not enable
IOCM_EXECUTE_SCB comands.

My question is: how important is it to emulate SCBs?

Do the other major vendors support this functionality?

Is supporting IOCM_EXECUTE_CDB sufficent?


ANSWER:
The IOCM_EXECUTE_SCB and IOCM_EXECUTE_CDB are command modifiers used for
issuing SCSI formatted commands.  The SCB format is used by systems that
support ABIOS (like on Microchannel machines).  All other systems use the CDB
format.  Therefore all IBM SCSI drivers support SCB.  I would assume that
major vendors would support SCB for their adapters that support ABIOS.




!OTHER__________________________________**********
February 04, 1994
QUESTION: (Ref: 854)
I have used version 1.1 of the DDK to write some very simple VDDs.  I have
written these VDDs entirely in C, using the tools in the DDK.

Q1. Can I use a different compiler and linker to build a VDD?

Q2. Do you have sample code (VDD and caller) for the VDHRegisterAPI function?
    The address returned to my WinApp by INT 2FH, AX = 4011H, in ES:DI points
    to an ARPL [BX+SI], SP instruction.  When the WinApp calls this
    instruction, the kernel takes a trap 6.

Q3. The VDD documentation says a VDD's interrupt hook must set a CPU status
    flag to indicate whether the interrupt should be reflected to the next
    interrupt hook in the chain.  My VDD is entirely in C. I have found
    through experimentation that returning 0 from the interrupt hook causes
    the interrupt to be reflected to the next hook, that returning any other
    value causes the interrupt not to be reflected.  Are these rules valid?


ANSWER:
A1. Yes you can use different compilers to build the VDD.  CSET2 should be
    fine.

A2. Good Samples in DDK that use the VDHRegisterAPI function are

           a) VDSK  b) VMOUSE c) VTOUCH.

A3. Chaining of interrupts are decided based on whether CARRY flag is set or
    clear.  IF he does any operation in his C VDD that sets or clears the
    CARRY flag then he is safe.  Return of 0 or non zero is not fool proof.
    Return Zero/Non Zero Not Recommended.




!STORAGE________________________________**********
February 04, 1994
QUESTION: (Ref: 847)
I have some questions regarding the FAT system.

Q1. If I use DISKCACHE statement, DosDevIOCtl(direct sector read/write
    Category9,Function64) can i access DISK directly ?

Q2. If I use DISKCACHE statement, can removal disk(A:,B:)  be accessed
    directly?


ANSWER:
A1. By using DISKCACHE= statement in the CONFIG.SYS, the DevIOCtls will still
    go through the DISKCACHE.  It will not be direct read/write from/to the
    disk.

A2. The diskette drives are not cached by DISKCACHE.  It caches only the
    fixed drives.  Therefore any access to drives A and B will be direct.




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