This is file: 02_95QA.TXT

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

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

The following KEY WORDS are supported in this file.

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

!VIDEO__________________________________**********
February 22, 1995
QUESTION: (Ref: xxx)
After looking at the version of the PM source code that I have now, I have
some questions that I need answered.

I have been looking at the Bitblt code in the PM driver and I am particurlarly
interested in host to screen BitBlts.

I started at the Bitblt entry point in the dispatch table in eddnbblt.c . If
the source bitmap is in system memory the code calls
PixBltThroughClipsViaPHUNK (in pixblt.c) which sets up the pixblt operation
for the low level blting functions.  Among other things this setup includes
copying the source bitmap to the PHUNK (in chunks, if required) before passing
off the chunks to the low level blitting functions.

What is the need for this mechanism of using the PHUNK and what is the
reasoning behind this design - OS2 operating system reasons, protected mode
reasons, other reasons?


ANSWER:
The PHUNK is an XGA only requirement.  XGA uses bus mastering to do mem to
vram blits.  Therefore it had to copy the data into low fixed memory and
provide the physical address to the XGA HW.  Most adapters pound a port so the
PHUNK is not required at all.




!OTHER__________________________________**********
February 22, 1995
QUESTION: (Ref: GE7)
I would like to change the ST506 driver to allow for 32 bit i/o transfers.  I
would like to change the following code from the addcalls.h file to do this:

#define inswp(port, pdata, len) _asm{ \
          _asm   push es         \
          _asm   push di         \
          _asm   push dx         \
          _asm   push cx         \
          _asm   cld             \
          _asm   mov  cx,len     \
          _asm   mov  dx,port    \
          _asm   les  di,pdata   \
          _asm   rep  insw       \
          _asm   pop  cx         \
          _asm   pop  dx         \
          _asm   pop  di         \
          _asm   pop  es         \
}

and the corresponding outswp routine as well.  I tried substituting insd for
insw, but the compiler did not allow this.  It also did not allow me to use
the .386p command within this construct.  I then wrote a subroutine to perform
the insd command and called it from within the define, but this created a
stack problem, as for some reason cs was pushed onto the stack before the
subroutine call was made.  I would appreciate any suggestions as to how this
code might be changed to allow the 32 bit transfers.


ANSWER:
You could write an assembly module consisting of the required subroutines
(e.g.  insdp and outsdp) and link it to your 16 bit Device Driver Code.

The assembly code could be a mix of 16 and 32 bit code.  You can do that by
using the .286p and .386p assembler directives.  The 16 bit code in the
assembly file would interface with the 16 bit "C" code of your device driver
and would then call the 32 bit code handling insdp and outdsp.

Sample code Ref for the assembly program and 16 bit interface routine:
\ddkx86\mmos2\samples\audiodd\startup.asm :  Also refer CallVDD routine.

The 32 bit insdp and outsdp routines would be on the lines suggested by you
within the _asm directive for the inswp define except that both these routines
(insdp and outdsp) would be preceded by the .386p assembler directive and you
would modify the insw and outsw instructions appropriately within them for 32
bit operations.  Ensure your len parameter is adjusted accordingly.

The C compiler would not support the .386p command within the #define
construct because it is a assembler directive which may not be supported by
the C Compiler.  C Compilers support only a subset of the assembly language
and assembler directives.




!STORAGE________________________________**********
February 22, 1995
QUESTION: (Ref: GE3)
I need to know if an existing RAID SCSI device that is written to be compliant
with the ASPI spec will work with the OS/2 Warp ASPI manager.  The product is
working in a DOS environment using ASPI.


ANSWER:
If the device meets the ASPI Specs.,the Warp level DMD for ASPI Device could
be used.  What you will need is an ADD to drive your own hardware.
Unfortunately, there are no ASPI ADD Drivers on the DDK.  You could get some
more info about these from Adaptec.




!OTHER__________________________________**********
February 22, 1995
QUESTION: (Ref: GE2)
I'd like to report that the wrong information is returned by the GetTupleData
(0DH) (Get tuple data from card services) function as defined by PCMCIA Spec.
Release 2.1 Page 5-39.  The Tuple code and Link fields are being returned in
the tuple data area, (TupleData) from card services.  This should not be the
case.  For compatiblity this should be changed.


ANSWER:
Yes, that is correct.  According to the PCMCIA 2.10 spec this information
should not be returned.  However, this was not the case in PCMCIA 2.00 spec
which is the level we support in OS/2.  When we upgrade to the 3.00 (Berlin)
level of the PCMCIA Specification we will change this.




!MULTIMEDIA_____________________________**********
February 22, 1995
QUESTION: (Ref: GE1)
We have a 16 bit OS/2 Device Driver that needs a mechanism to wait in our
strategy routine.  The wait is in the order of milliseconds and so I thought
of DevHelp_Beep.  However, it appears that the wait does not occur for the
time specified.  I tried a wait of 10 seconds and found that control returned
very quickly.

Am I correct?  Does control get returned to the device driver before a signal
is sent to the speaker?

If this is so, then we are unable to use the Beep to perform the wait.  The
following is the call:

    DevHelp_Beep( 1380, 10000); /* Frequency: 1380, Duration: 10 Secs */


ANSWER:
Use DevHlp_ProcBlock.  In the timeout parameter specify the wait time.  In the
IntWaitFlag parameter set 0. In the EventId parameter specify a 32-bit value.
In your case any arbitrary value.

Ref: Physical Device Driver reference, section on DevHlp_ProcBlock




!OTHER__________________________________**********
February 22, 1995
QUESTION: (Ref: GE0)
I've reviewed the Mastriani book and the VDD reference and I haven't been able
to figure out how one can allocate an area in memory in the VDD and allow all
the VDMs to view that area from DOS programs.  I took a look at vxga.c and I'm
still somewhat confused.

So far this is what I've done:
1.  At VDD Init time, I allocated 1 page of memory using VDHAllocPages();
    I understand the areas for mapping must lie on a Page boundary.

2.  I've managed to load a little do nothing device driver in a VDM
    this is done at VDM create time.  (Got the event hooked)

3.  I'm attempting to map the Area that I allocated at Init Time to a
     region of memory in the VDM. To do this I have:

   a.  VDHAllocDosMem()'d a 2 page (8192) area of memory.
   b.  Since the returned address is a linear pointer, I adjusted this
       pointer to lie on a Page boundary ie: increased the value until it
       was an exact multiple of 4096.
   b.  placed the First area as the Source for VDHMapPages()
   c.  placed the Second (VDHAllocDosMem) area as the Target.
   d.  used VDHMapPages() and the call always fails.

4. Should the mapping go successfully, I would some how pass this address to
   the dos device driver, and in this way allowing other dos programs to
   address the mapped area.

What I'm trying to accomplish I'm sure is quite common, but I don't think I
need to resort to the complexity inherent in vxga.c.  Am I out in left field
here?  Is there some more simple code written that I could use?


ANSWER:
Your step 1 is OK.  Then use VDHReservePages during INIT time.  This ensures
that you can provide global memory access across VDMs (DOS programs).  Use
VDHFindFreePages to return the size and start address(linear) of the largest
region that can be mapped across all VDMs.  Start address returned from this
call should be used to reserve pages using VDHReservePages.  The linear
address returned from step 1 and address reserved using VDHReservePages would
be the source and target respectively for VDHMapPages.  No need to allocate a
block of memory (using VDHAllocDosMem) in order to have global memory access
across VDMs.  Ref :  VDD reference.


FOLLOW-UP QUESTION:
I started reviewing the Dieter & Kogan book on memory management.

Although I think I understand the use of VDHReservePages and VDHFindFree
Pages.  Could you clarify something for me?  After I do the mapping, I get a
pointer to the area being mapped.  If so, this pointer would be Linear, I
would convert it to Seg:Off and pass it to the Little Dos DD that I installed.

Will any Dos program that interfaces with the Little Dos DD get this address
and view the contents of what it's pointing to, namely an area being refreshed
by a PDD or VDD?  Doesn't the target area have to reside on a page boundary?


FOLLOW-UP ANSWER:
The answer to your question is "Yes" provided the VDHReservePages call has
been made in the initialization context.  If the call has been made in a DOS
session task context then only DOS applications running within that VDM (DOS
session) will have access to the mapped area refreshed by a PDD or VDD.  (Ref:
VDD reference VDHReservePages call) and not other DOS applications running in
other VDMs.  You are correct, the target area has to reside on a page
boundary.




!OTHER__________________________________**********
February 22, 1995
QUESTION:  (Ref: GD9)
My hardware (a PC Clone) uses port 64h and 60h to control the watchdog timer,
which is a hardware delayed reset that, once enabled, must be periodically
restarted or it will hard-reset the system on the assumption that the
application got lost and needs an emergeny restart.

As a first timer in OS/2 development, I want to verify that I may access ports
60h and 64h from the device driver, assuming I can do it without disturbing
the other functions of these ports, namely keyboard controller handling.


ANSWER:
Yes, you may access ports 60h and 64h from a device driver.  However, access
must be read only.  Be sure to do a CLI before the read and an STI after the
read.




!OTHER__________________________________**********
February 22, 1995
QUESTION: (Ref: GB4)
Is there any way to write 32 bits at a time within my physical device driver?
I have a memory-mapped MPEG decoder card that requires that 32 bits be written
at a time.  Currently, my device driver tries to move a ULONG at a time in 'C'
but the generated code breaks this up into two moves of 16 bits each.  I
realize this is caused by the fact that physical device drivers are in 286
mode, but what can I do to overcome this?  (I tried changing the .286
statement to .386 but, as I expected, the code would not even get close to
compiling.)


ANSWER:
You can use the 386 moves, to get around the limitation, you must code the 386
instructions as assembler DBs.  Thus you emulate the 386 instructions by using
DBs with the value of the instruction.  The assembler doesn't know any better,
and assembles these DBs in the code stream.  When exectued, they're
interpreted properly.




!I/O____________________________________**********
February 22, 1995
QUESTION: (Ref: GA6)
I am getting ready to start a device driver under os/2 Warp and I have a few
questions.

The driver will be handling a numeric keypad connected through the
parallel/serial port.  Data is passed to the host by tricking the machine into
thinking that the key has pressed on the main keyboard.

1. Do you have any recommendations/documentation that is available to
accomplish this?

2. I have discovered a book called 'writing os/2 2.1 device drivers in c'.
Are there major diferences between drivers under 2.1 and Warp?

3. What information is available to do this driver in ASM?

I am in the process of subscribing to get the DDK.  Any information you can
give me is appreciated.


ANSWER:
DevCon DDK Version 1 contains the Source Code for the Layered Keyboard Device
Driver.  This is an implementation of the Layered Architecture with a Hardware
Independent Layer & the Hardware Dependent Layer.  The Build Requirements for
the Physical Keyboard Device Driver would be :  Microsoft MASM 5.1 (supplied
with DDK) Microsoft C 6.0 Relevant documents would be the Physical Device
Driver Reference, Input/ Output Device Driver Reference & the PS/2 Hardware
Interface Technical Reference Manual.  The first two are a part of DDK.

Device Drivers for OS/2 2.x are compatible with OS/2 Warp V3 and do not
require additional modifications.  Download DRCOMPAT.TXT from the DUDE for
more information on this matter.

Another book you may want to obtain is "The Design of OS/2" by Deitel and
Kogan.

To order the DDK, call 1 800 633 8266.




!VIDEO__________________________________**********
February 22, 1995
QUESTION: (Ref: G55)
We are trying to provide 256 color display drivers for our customers.  We ran
into some problems with Seamless Drivers.  Any help you can provide would be
appreciated.

Scenario:
We try to test our seamless drivers by running Microsoft's Solitaire or
Minesweepeer games with the Timer turned on.  When we press <CTRL-ESC> to pop
up the Window-List dialog and use the arrow keys to move up and down the list,
the message showing the current time used in the game keep repeating itself at
the same column position but at different row.

Observation:
We think that these off-position messages always show at the same relative
position within different display banks.  These different display banks depend
on the highlight that we traverse up and down the Window-List using arrow keys
or mouse cursor.  While traversing the highlight in the Window-List appearing
in some display bank (bank X) other than the display bank where Timer message
resides (bank Y), when the highlight hits the same relative scanline position
in its bank (X), the most updated Timer Message appears (in bank X).  We can
repeat this scenario by moving Window-List dialog to different display banks.

Questions, Speculation and Analysis:
We believe that we could be getting into semaphore synchronization problem.
In the Seamless Windows Driver, we call request_semaphore to get the right to
access the screen and clear_semaphore routines of IPC.asm to release this
right.  However, we found that there are other screen accesses by someone
(other than Seamless Windows Driver) before clear_semaphore is called.

1. We would like to know if this could happen between request_ and clear_
semaphore calls?

2. Are there more into the screen access synchronization than simple
request/clear_semaphore calls?

We try using Cirrus Logic adapter and the drivers provided in OS/2 2.1
installation disks.  First, we install CL's 640x480x256 color drivers.  Then
we replace the seamless windows driver with ours.  We found that the same
off-position messages appear.  We then switch to the system using our adapter
and 256 color drivers.  We replaced our seamless windows driver with CL's.
The same off-position messages appear again.

3. Is there any priority handling on the semaphores?

4. Any modification necessary besides already provided in the samples on the
OS/2 PM side that deals with Seamless?  (like VDD etc.)

Versions reference:
-- Use Seamless Windows driver sample dated 8/31/93 as base for modification.
-- Use OS/2 2.1 SVGA256 PM drivers in Source Kit 1.1 as base for modification.
(including BVHSVGA.DLL, VSVGA.SYS, SCREEN01.SYS, SVGA.EXE)


ANSWER:
1. There should not be any other Screen Access between your request_semaphore
& clear_semaphore calls.

2. No.

3. There are no priorities associated with these Semaphores.It is served on a
first - come - first - serve basis.

4. There are no other modifications than provided in the samples to deal with
seamless.  Please ensure that the Display Banks have been set explicitly and
you do not make any assumptions about them.




!OTHER__________________________________**********
February 22, 1995
QUESTION: (Ref: G51)
If I have register a timer handler using tickcount devhelp, is there a way to
remove or disable this registration?  I am concerned that if I have registered
an entry point during the early part of INIT processing and later I determined
that an error will force my driver to be unloaded, must I expect calls to my
timer handler entry point.  If my driver is unloaded then the code seg defined
as timer entry point will no longer be valid.


ANSWER:
When installing a timer handler in your driver, don't call SetTimer or
TickCount until the end of the Init section, just before returning to the
kernel.  Timer handlers usually reference DS-relative data items, and these
items become dereferenced when the driver fails and returns 0 code and data
offsets.What happens is that the timer handler is still in the list of timer
handlers to be called, and gets called after the driver fails but before the
timer handler is removed, causing a GP fault.  An alternative is to always
call ResetTimer if an error occurs, prior to returning the 0 code and data
segment offsets, or make the call to SetTimer/TickCount the last operation in
the Init section.




!OTHER__________________________________**********
February 22, 1995
QUESTION:  (Ref: G46)
Q1. How does the RegisterStackUsage devhelp work?  There are several parameters
    for this call and we want to know the EXACT algorithm OS/2 uses to take the
    parameters and come up with a value to extend the stack space by.  We are
    especially interested in how the three different stack size parameters
    (before cli, after cli, and after eoi) are used, and does the nesting
    parameter get used to multiply the stack size(s) provided?

A1. The algorithm for DHRegisterStackUsage is as follows:

      cbDDMax = maximum(su_cbStackCLI, su_cbStackSTI, su_cbStackEOI)
      cbDD = cbDDMax + (su_cNest * su_cbStackEOI)
      if enables interrupts
           if cbDD + cbIntStack > MAX_STACK_LIMIT  (8K)
               return error
           else
               cbIntStack += cbDD
      else
            if cbDD > cbNoEnable
               if cbDD + cbIntStack > MAX_STACK_LIMIT (8K)
                   return error
               else
                   cbNoEnable = cbDD

    After all device drivers are initialized, cbNoEnable is added to cbIntStack
    to find the final interrupt stack size to allocate.
==============================================================================

Q2. What does IBM recommend ADD drivers and NDIS drivers to specify for stack
    space utilization as we don't know how much stack space will be consumed by
    IBM and third party DMD's, filters, and protocol drivers.

A2. The current limits are 4K for per task stacks and 8K for the system
    interrupt stack.  The usage of stacks by the dasd mgr is *NOT* the issue.
    It uses minimal stack space for callbacks.

    The ADD drivers DO NOT use the Register_Stack space API.  It *DOES NOT*
    change the kernel stack space allocation algorithms.  It only returns an
    indication of whether or not a driver's stack space demands can be
    satisfied.  The interface is not designed to allow a driver to determine
    how much stack space is available so it can adjust its usage accordingly.

    Register_StaskUsage is not a particularly useful devhelp due to the way it
    was designed and we don't use it in the ADD drivers.

    If you have not already done so, you may want to refer to the Physical
    Device Driver Reference - Chapter OS/2 Physical Device Driver Design Issues
    - Section Limiting the Number of Nested Interrupts.
==============================================================================

Q3. Should we allocate and switch stacks from the kernel stack at interrupt
    time?  This is something we would like to avoid at all cost, but does IBM
    see any advantage to doing this?

A3. No, allocation & switching to the Interrupt Stack is managed by the Kernel.
    When an interrupt occurs, the system switches into interrupt mode by
    switching from the current kernel stack to a system interrupt stack.

    In general, the OS/2 kernel imposes fairly austere constraints on stack
    space usage.  In general, DDs that have automatic storage requirements
    should allocate from their own private heap rather than relying on the
    runtime stack for dynamic storage.
==============================================================================

Q4. Are TRAP 8's primarily caused by stack overflow on the kernel interrupt
    stack?  What are the other reason for TRAP 8's?

A4. Yes.  Other reasons are overflow of kernel stack and ring 0 stack fault.

    If a driver is getting Trap 8's, I would look for a bug!  In this context I
    would consider any substantial allocation from the stack in a device driver
    a bug.  Usually, examination of the stack space usage after the trap 8
    occurred will help determine the cause of the stack space deficiency.




!OTHER__________________________________**********
February 22, 1995
QUESTION: (Ref: G43)
Would it be possible to have a copy of the source code and make file for
boot.com?  We would like to add extra code to it to enable it to work with our
boot virus protection programs.  With these programs we prevent viruses like
form attacking your hard disk.  To add more detail, we are trying to catch the
reboot that is used to restart the pc and load the alternate os (ie.  os/
running, our false shell unlocks the pc, boot.com runs, dos loaded).

This works fine and the pc ends up in a locked state, but if a flopy boot disk
is put in the pc, the hardisk is not locked.  Thus we need to intercept the
boot.com reboot mechanism and lock the hd before a reboot occurs.

We were looking at access to the source code so we could intergrate our
un/lock code cleanly into os/2.


ANSWER:
We can not provide such source code, but I'm not sure why you need the source
code to BOOT.COM.  I doubt you need it, however, I use DOS.SYS to reboot, so
if you replace or intercept DOS.SYS calls, you will be able to interface with
BOOT.COM.  I'm sure you already know how to intercept reboots under DOS.
Besides, BOOT.COM doesn't have to reboot the machine.  If you put a wrapper
around BOOT, you could use BOOT /DOS /NOBOOT and then do your extra functions.




!MULTIMEDIA_____________________________**********
Febuary 22, 1995
QUESTION: (Ref: G39)
I have gotten my driver to capture properly now and is going into beta
testing.  I am having problems getting it to work with all of the mmio procs.
If I use NO Compression or Ultimotion, it works.  If I use the Indeo
compression (either version), it gives an error.

    Video IN Recorder - Message
    SWVR118: The recording initilization failed.
    Return code is -1 - MMIO Error.

If I reduce my capture size to 256x200, it works.  (512x400 is my default
minimum size.  My board goes from 512x400 to 756x486.  A slight step above the
other capture boards.  :>)

   1) Is there anything that I can do to get Indeo to work?
   2) Is it a design problem with the Indeo compression?
   3) Is it an implementation problem that will be fixed by IBM?


ANSWER:
This is a Design Problem with the Indeo Compression and has to be resolved by
Intel.  This problem cannot be fixed by IBM.




!I/O____________________________________**********
Febuary 22, 1995
QUESTION: (Ref: G05)
PDoes anyone know if the OS/2 MODE command responds to ALL driver names or
only to COM0 - COM3?  I would like to use the MODE command in a REXX exec at
startup to set up baud rates parity stop bits etc on a 16 channel serial
driver.  This will save me generating the IOCtls and a user interface to them
myself.


ANSWER:
PThe MODE Command can only be used with the Base Asynchronous Communication
Device Driver - COM.SYS MODE command supports ports 1 thru 4 only.
Ref: OS/2 Command Ref.  (Online)




!OTHER__________________________________**********
February 16, 1995
QUESTION: (Ref: GD8)
I have MSC 5.1.

1. Will it permit me to create an OS/2 application under 2.1 that will test a
   new device driver?

2. Do I need to get Watcom c?

3. Will the cl386 compiler provided with the DDK suffice?

The application will be simple; just open the device and write to it and close
it.  The device will be the watchdog timer I described in my previous enquiry.


ANSWER:
1. Yes. If you have the relevant documentation you shouldn't have any problems
creating an OS/2 Application.

2. No, this is not necessary. The advantage in using the Watcom Compiler is
that it is a Supported product - Microsoft C for OS/2 is no longer supported
by Microsoft.

3. Yes.




!OTHER__________________________________**********
February 16, 1995
QUESTION: (Ref: GB1)
With OS/2 2.10 and DDK 1.2 I am unable to get past the Card Service
Configuration parameters...

The actual breakdown occurs when an attempt to execute a "CS_REQUEST_IO" from
the card services.  A 'BAD ATTRIBUTE' error is returned.  I tried every
possible combination or lack of any (0) and it still fails.  Below is the
current CONFIG.sys used for the PCMCIA device drivers (with order as seen).

BASEDEV=PCMCIA.SYS        -- CARD SERVICES
BASEDEV=TOS2RMU1.SYS      -- RESOURCE MANAGER
BASEDEV=IBM2TOS1.SYS      -- TOSHIBA SOCKET SERVICES
BASEDEV=OS2C500D.SYS      -- my 'ADD' driver


ANSWER:
The problem has to do with the parameter list passed to the Card Services,
specifically the "IOADDRLines" field.  The offset 0ah of the request IO
structure needs to be set to 10h.  (ie:  You need to set the IO 16 bit lines.)




!OTHER__________________________________**********
February 16, 1995
QUESTION: (Ref: GA7)
Is the socket values '0' or '1' based values?  I have downloaded the
OS2PCM.ZIP file and extracted the socket services for the Toshiba 500 PCMCIA
card.  On start of the debug session the socket value of '0' is returned as an
error by the Card Services.  It is my understanding that version 2.01 or
above, start socket values at '0'.  Socket Services from OS2PCM.ZIP :
IBM2TOS1.SYS


ANSWER:
The socket value starts from 1. Ref :  \ddk\src\dev\pcmcia\cldfm\config.c
Routine Store_Socket_Assignment, case 2 of the switch structure.  The 'if'
statement returns error if socket number < 1.




!PRINT__________________________________**********
February 16, 1995
QUESTION: (Ref: GA3)
We are developing OS/2 Postscript printer drivers.  These drivers are based on
the Postscript Printer driver that comes with the DDK.  I would like to know
why the font download functionality in the printer properties dialog was
removed.  The driver puts up a message box saying perform this from the system
setup.


ANSWER:
This was due to a change in the Design.  Since the Fonts were shared with the
System, it made more sense to query the INI file and get the PM_FONTS.  Refer
to the DOWNLOAD.C file which gets the font files from the INI by invoking -
PrfQueryProfileString(HINI_PROFILE,"PM_FONTS,...




!OTHER__________________________________**********
February 16, 1995
QUESTION: (Ref: GA2)
The Physical Device Driver Reference, under the description of the
'PhysToGDTSel' DevHllp call, states that the Results of the call will include
the return in register AX of 'Selector with the modified RPL bits.'  I have
found that the selector is actually returned in register SI.  Is this an error
in the documentation or am I doing something wrong?


ANSWER:
For PhysToGDTSel, EAX will contain the error code if the segment is not
available.  If the pages are locked then AX should contain the selector with
the RPL bits modified.  Did you check the carry bit before looking into AX
register?  SI should be loaded with the GDT Selector obtained from
AllocGDTSelector before calling PhysToGDTSel.  This selector is merely mapped
to a specified physical address.  The documentation in the Physical Device
Driver Reference should be referred to.




!VIDEO__________________________________**********
February 16, 1995
QUESTION:  (Ref: GA1)
Our 32-bit PM driver supports the S3 Software Motion Video (SMV) escapes.

As 8 and 16bpp, SMV works beautifully for us, but at 32bpp (our driver
supports 3 32bpp modes) the movie image appears as four separate monochrome
images about 1/4 of the way down the screen.

Since the driver itself merely steps aside and lets the SMV subsystem draw
into the frame buffer, I doubt that we're causing the anomaly we see.  In
fact, it looks to me as if SMV has never seen 32bpp before and doesn't know
how to handle it.

Can you clarify whether SMV _should_ run correctly at 32bpp?


ANSWER:
There is a twist in the definition for getting Software Motion Video (SMV) and
the Direct Interface Video Extensions (DIVE) to work properly in 24-bit and
32-bit modes (16,777,216 colors).  The following DevEsc function
DEVESC_GETAPERTURE returns the struct APERTURE:

   {
   pPhysicalAddress (of the aperture)
   ulApertureSize    (in bytes, usually 8MB, 4MB, 2MB, 1MB, or 64KB)
   ulScanLineSize    (see below)
   rctlScreen          (inclusive:inclusive where (0,0) is top left
                            corner)
   }

The ulScanLineSize parameter has some alternate meanings depending on the
situation.  First off, the high word of ulScanLineSize always specifies the
offset in bytes from the start of VRAM (the physical address) to the first
visible pel of the screen.  This value is usually zero.  The low word
specifies the number of pixels per scan line in 8-bit and 16-bit modes and
specifies the number of bytes per scan line in 24-bit and 32-bit modes.  One
final twist here:  in 24-bit and 32-bit modes, the ordering of the components
can be RGB or BGR.  To differentiate, RGB mode will return a positive number
of bytes and BGR mode will return a negative number of bytes.  For example:
640x480x32-bit might have a scan line size of 4096 bytes, and if there is no
physical offset and the ordering is BGR, we would have a structure like:

   {
   0xa0000000,      (or whatever)
   0x00400000,      (or whatever)
   0x0000f000,      (-4096 in the low word)
   {0,0,639,479}
   }

For example:  800x600x16-bit might have a scan line size of 2048 bytes, but
remember, in 16-bit mode or less, we specify in pels, and let's say we also
have a physical offset of 512 bytes:

   {
   0x000a0000,      (or whatever)
   0x00010000,      (or whatever)
   0x02000800,
   {0,0,799,599}
   }




!OTHER !PRINTER_________________________**********
February 16, 1995
QUESTION: (Ref: G84)
I am writing a printer driver which I potentially may want to submit for the
next DDK.  Would I be wiser to write it in C Set/2 to match the existing
drivers on the current DDK, or would it be recommended that I use C Set++
since C Set/2 is no longer supported?


ANSWER:
We recommend you to use IBM C/C++.The new drivers that are being developed
here use IBM C/C++ Version 2.0 & above.




!OTHER__________________________________**********
February 16, 1995
QUESTION: (Ref: G82)
The DDK I currently own is the OS2 DDK 1.2 which does not have the "DDK86"
directory.
1. The include file "rmcalls.h" is not found.

2. The structure "HDEVICE" in the "s506type.h" is not defined anywhere.  We
   thought it might be in the "rmcalls.h" file.  Therefore, if we have the
   "rmcalls.h", this problem would be solved as well.


ANSWER:
1. The RMCALLS.H is in the following directory on the DevCon DDK V1.0:
   DDKX86\SRC\DEV\RESOURCE\RSM_H

2. HDEVICE is defined in RMBASE in the same directory as answer #1.




!OTHER__________________________________**********
February 8, 1995
QUESTION: (Ref: GB5)
I am looking for info/docs on the library functions provided with the DDK CD
in the "\ddkx86\lib" directory.  The "dhcalls.lib" functions I can find
documented in the DDK DevHlp docs but the other libs remain a mystery.


ANSWER:
You could get a listing of the Library Functions with the "lib" Command.  Some
of the functions are Private Functions and are undocumented,other functions
are documented in the Physical Device Driver Reference,Presentation Device
Driver Reference,Control Program Reference & the Virtual Device Driver Ref.




!OTHER__________________________________**********
February 8, 1995
QUESTION:  (Ref: G98)
We have developed some special keyboarding for a multilingual application and
we need to load a TSR manager in a DOS box.  Memory is a premium and we want
to load this high.  For some reason that is impossible running with the DOS
emulation of OS/2 after we load NETX for NetWare connectivity.  It works
perfectly under any other DOS version.  Interestingly, if we load DOSKEY (or
any other program) high it works.

What do we have to pass to DOS if we want to EXEC a program in Upper Memory?

We are using Function AH=4Bh (EXEC program) with subfunction AL=00H (load and
Execute Program) via INT 21H (DOS Entry Point).

Since we are able to load programs in the Upper Memory Block when using
LOADHIGH from the Command line there must be something we're do wrong with our
device driver combination.  By the way, even if we use another progam we
cannot do that.

The device driver for the keyboard has a TSR extension to allow switching the
locale since it can handle any language (currently we are supporting a little
over 300 languages).

We're almost sure we could write a TSR independent of our device driver and we
would not be able to load it high.  Is there no way to find out what to do to
load high under the OS/2 DOS?  We are just using plain DOS stuff which works
quite well under plain DOS.


ANSWER:
Below are two (2) possible solutions to your problem:

1. Here are some dos settings to try:
-------------------------------------
Problem:  How does one maximize the amount of free conventional memory
available in a DOS VDM under OS/2?

Solution: Change the following DOS_settings for the DOS session:
   DOS_DEVICE=<empty... make sure there are no entries>
   DOS_HIGH=ON
   DOS_UMB=ON
   DPMI_DOS_API=ENABLED
   DPMI_MEMORY_LIMIT=8
   EMS_MEMORY_LIMIT=4096
   MEM_INCLUDE_REGIONS=C0000-DFFFF
   VIDEO_MODE_RESTRICTION=CGA
   XMS_MEMORY_LIMIT=4096

In the AUTOEXEC.BAT file, ensure that only necessary programs are loaded.
APPEND.EXE, DOSKEY, etc.  may not be needed depending on the application being
used.

Over 734k of free conventional memory can be obtained by using the above
settings.  The above settings also allow for 8mb of DPMI memory, 4mb of XMS
memory, and 4mb of EMS memory.  These settings are usually more than
acceptable to most DOS apps.

If the customer is using the Novell Netware Requester for OS/2, then to get
NETX.EXE to load high, make sure the latest version is in use, AND make sure
the LOADHIGH NETX.EXE statement appears before TBMI2.COM in the AUTOEXEC.BAT
file.  If the customer does not care to run WINOS2 at all in OS/2 then REM out
the TBMI2.COM line.  This will provide NETX support in a VDM with maximum
conventional memory for the DOS session.



2. Here is the description of a defect in OS/2 2.10 (APAR# PJ11202)
-------------------------------------------------------------------
PROBLEM SUMMARY:  After loading NETX.EXE, the LOADHIGH command loads modules
into low memory rather than high memory.  This problem is occurring because
Netware is intercepting INT 21 function 4B00 (load program), loading the
program, and then returning an INT 21 function 4B05 (set program execution
state) to OS/2.  The memory allocation flags for HIGH_ONLY and DOSALLOC are
not being set by OS/2, because OS/2 never gets the INT 21 function 4B00
request.


PROBLEM CONCLUSION:  Code was added to $Loadhigh to issue an INT 21 function
5899 instead of function 5801.  Code was added to $AllocOper to process an INT
21 function 5899.  (Function 5899 is the same as function 5801, except that it
sets the fLoadHigh flag.)  Code was added to $Alloc to set HIGH_ONLY and
DOSALLOC if fLoadHigh is on.  Code was also added to $Exec to clear HIGH_ONLY,
DOSALLOC, and the fLoadHigh flag.  Output Modules to ship to customer:

    \OS2\MDOS\COMMAND.COM
    \OS2\MDOS\DOSKRNL

The defect described above has been closed with a fix available.  Please call
407-994-5544 (OS/2 Supportline) and request the fix by asking for the
resolution/fix to APAR# PJ11202.




!OTHER__________________________________**********
February 8, 1995
QUESTION: (Ref: G90)
Q1.I am having difficulties in managing the request packets, using the DevHelp
functions, PushReqPacket and PullReqPacket (or PullParticular).  I am
attempting to queue a request packet from within the Strategy section of the
device driver, so that data may be exchanged between the device driver and the
application through the request packet data buffer at timer interrupt.  More
specifically, I would like to Block an application thread at Strategy time and
push its request packet to the queue.  In the timer interrupt section, I want
to pull the blocked thread (or threads) request packet, transfer data to the
buffer, then release the request packet and Unblock the thread.

However, I am getting a General Protection fault in the timer interrupt
section when I try to access the request packet data buffer that I pulled out
of the queue (using PullParticular).  I must not actually be pulling the
request packet correctly, because I believe I should be able to do this
operation.  I have a concern regarding the DevHelp function calls.  All of the
request packet management functions require a "Queue head" parameter (NPBYTE
Queue) that marks the "location of the DWORD queue head (which points to the
first request in the list)".

Yet the input parameter to the function calls is an NPBYTE (near pointer to
unsigned character) - is this queue head a DWORD, or an unsigned character?

If it's a DWORD, do they mean it's a far pointer (four bytes), a long, or an
unsigned long?


A1.  In the READ/WRITE request packet the application's buffer address is the
physical address.  OS/2 verifies and locks the buffer segment apriori.  Since
you have to access the buffer in the interrupt context, you will have to map
the physical address to a GDT entry using PhysToGDTSelector.  Before this
allocate a GDT selector using AllocGDTSelector.  Once the physical address is
mapped to the GDT selector you can access the buffer from any context without
a GP fault.  The address becomes sel:0

The PDD must provide storage for the DWORD work queue head, which defines the
start of the request packet linked list.  The work queue head must be
initialized to zero.

Refer to the Physical Device Driver Reference - DevHlp_PullParticular.
Location Queue Head is DS:queue which is a DWORD.  'queue' is the 16 bit
offset of Queue Head and is defined as NPBYTE.  The contents of Queue Head
will point to the first Request in the List.

Confirm if the Carry Flag is clear after the call to PullParticular,if clear
the call has been successful and the problem is with the way you access the
Data Buffer at Interrupt time (If you are not able to pull the right request
packet the Carry flag would be set.)
==============================================================================

Q2. I am wondering if you have any concrete examples of the memory mapping
DevHelp functions (C-code), like PhysToGDTSel, PhysToUVirt, etc.


A2. Please refer to the following sample codes in DevCon DDK Version 1:
 1) PhysToGDTSelector : \ddkx86\src\dev\dasd\os2scsi\scxfrscb.c
                        \ddkx86\src\dev\dasd\os2aspi\aspisrb.c
                        \DDKX86\src\dev\dasd\ibm\ibm2adsk\adskinit.c

 2) PhysToUVirt : \ddkx86\src\dev\screendd\screen01.asm
                  \ddkx86\src\dev\screendd\screen02.asm
    In the book by Mastrianni, refer to Appendix-'C' device driver for
    memory mapped adapter (case RPCLOSE).

 3) PhysToVirt : \ddkx86\src\dev\dasd\os2scsi\scxfrscb.c
                 \ddkx86\src\dev\dasd\os2aspi\aspisrb.c
                 \ddkx86\src\dev\dasd\ibm\ibm1flpy\flp1init.c

 4) VirtToLin : \ddkx86\src\dev\dasd\os2dasd\dmfault.c
                \ddkx86\src\dev\dasd\os2dasd\dmcsubr.c
                \ddkx86\src\dev\dasd\ibm\ibm1flpy\flp1init.c

 5) VMProcessToGlobal and VMGlobalToProcess:
                \ddkx86\src\dev\screendd\svgarout.asm




!OTHER__________________________________**********
February 8, 1995
QUESTION: (Ref:G77)
I tried to debug my parallel port to SCSI adapter for OS2 version 3.0.  I
cannot get the kernel debugger works properly.  Everything seems to work fine,
the screen filled with messages from kernel debugger.  As soon as I hit
Control C from the debug terminal or int 3 within my driver, the kernel
debugger stopped.  All registers are displayed.  The prompt is ##,

I cannot do anything from the debug terimal to continue the debug kernel.  I
tried G and .G command, the kernel debugger cannot understand any commands,
but only another Control C.

Any hints?  Do I not have the updates to the kernal debugger?  I got the
Developer Connection Device Driver version 1.0 and the Developer Connection
version 5 Special Edition.  Both kernel debugger behave the same.


ANSWER:
I found the problem.  The serial port was set as 9600 baud, 7 bit, even parity
and 1 stop bit.  It should be 9600, 8 bit, no parity and 1 stop bit.




!BASE___________________________________**********
February 8, 1995
QUESTION: (Ref: G45)
I am following Mastrianni's recommendation in Chapter 17 of his book "Writing
OS/2 2.1 Device Drivers in C" (Tips and Techniques), for the transfer of data
from the driver to a process allocated buffer during interrupt context (using
VMProcessToGlobal).  However, now I am getting return codes from the functions
DevHelp_VMLock and DevHelp_LinToGDTSelector (decimal 87), which I believe
indicate that I have an invalid parameter (or more) in each function call.

The real problem is that I am not sure how all of these DevHelp routines are
actually supposed to be used.  I don't know how the "linear" pointer to the
process data is supposed to be passed and accessed via the Generic IOCtl
buffer.  I have a general idea, based upon Mastrianni's book and the DEVCON
DDK, of how all of this is supposed to work.

The problem is that there are no clear, detailed examples in either reference
as to how this operation works.  It would be nice to know if somebody out
there really does this sort of thing (there must be), and if so, how is it
actually done (using real code)?


ANSWER:
By default, when DosDevIOCtl passes an address to the Device Driver, it passes
an address in the form of a temporary selector.  This selector is valid only
for the duration of the call and cannot be used to lock the memory using the
DevHlp_Lock.  If you need to lock this memory ,the calling program must use
the DosAllocMem function with the object title (OBJ_TILE) bit set.  If you
pass a pointer to this memory in the call to DosDevIOCtl, the device driver
can use the DevHlp_Lock to lock this memory.  When a strategy routine gets an
IOCTL request packet, apart from other things, it contains two virtual
addresses (16:16 addresses).  One is virtual address of parameter buffer,
other virtual address of data buffer.  You may pass whatever in the data
buffer including addresses.  But you should know what kind of address you are
passing and use it accordingly.  The addresses could be linear (0:32)
addresses, or virtual addresses (16:16).  Steps followed to use the passed
addresses are:

1) The first thing is to lock the parameter, data buffers using LockSeg call.
If data transfer is likely to take >2 seconds, use long term locks, else use
short term locks.  Using short term locks for longer durations ( > 2 seconds)
will cause problems.

2) Pointer conversion.  If a physical address is given then convert to virtual
address using PhysToVirt.  If linear address then convert to virtual adddress
using LinToGDTSelector.

3) Data transfer using MoveBytes. Defined in Mastrianni's book, App-'C'

4) Unlock the buffers using UnLock.

Refer to sample serial device driver code in Mastrianni's book.

When using LinToGDTSelector, make sure that memory being mapped is fixed
locked prior to a call to this function.  Before this you must have allocated
a GDT selector using AllocGDTSelector.

In VMLock check the flags being used. For reference see
\ddk\src\dev\atcom.asm and \ddk\src\dev\dasd\os2scsi\scsubrs.c




!OTHER__________________________________**********
February 8, 1995
QUESTION : (Ref: G41)
Do you know of any information regarding the TESTCFG.SYS driver?  I have a
client that needs low level PS/2 information about their machines, and I
believe this driver could provide it if I could find the IOCTLs and data
provided by TESTCFG.  Any ideas where I might find this info?


ANSWER:
TESTCFG is a device driver used for installation of OEM device drivers.  Using
TESTCFG services, it will be possible to determine hardware adapter presence.
TESTCFG provides DosDevIOCtl services to ring 3 code.  These services are:

  Determine Bus Type
  Determine POS IDs
  Determine EISA IDs
  Access Adapter Memory (make a copy for app to read)
  Input/Output data through IO ports

You can find the source for this device driver in the DDK.




!BASE___________________________________**********
February 8, 1995
QUESTION: (Ref:G38)
1. If I use a request packet queue in my device driver to keep track of
pending requests, how can I detect and remove pending requests from a
process/thread which terminates (normally or abnormally)?

2. Or conversely, what happens when my device driver dequeues and runs a
request from a process/thead that no longer exists?

3. If I control access to a resource using a semaphore, how can I detect and
handle the condition where the process/thread that owns the resource
terminates (normally or abnormally) before releasing the resource?

I read that system semaphores do this automatically, but device drivers can
not create system semaphore.


ANSWER:
(1 and 2).  Use Devhlp_ProcBlock with interruptible_flag = 0. If the return
from the ProcBlock indicates that the sleep was interrupted, some internal
events occured that requires attention ( such as signal, process death
...etc..)  Ref DevHlp_ProcBlock Remarks in PDD Ref...

For sample code ref OS/2 Serial DD code given in Steve Mastriani's book in
Appendix C of "Writing OS/2 2.1 DD in C" under case RPREAD of sample.c

Use error condition =2 returned by DevHlp_ProcBlock to remove the particular
request block from the queue of requests pending using DevHlp_PullParticular.

To identify the request packet you keep a linked list of above requests on a
per process (using process id) basis also.  Process id for a request could be
got by calling GetDosVar DevHlp using Index = LocalInfoSeg both before placing
the requests in the process queues and then calling DevHlp_ProcBlock and then
calling DosGetVar once error =2 is returned after DevHlp_ProcBlock returns to
get the faulting process id and removing all its requests from the request
processing queue.

3.  SemRequest has TimeOut parameter which could be set to take into
account cases when there are abnormal termination.




!OTHER__________________________________**********
February 8, 1995
QUESTION: (Ref:G17)
The Warp Kernel Debugger will not load on my test target machine.  It traps
inside the kernel during initialization.  (Warp Retail kernel loads just
fine.)

Here's precisely what appears on my terminal emulator at boot:

System Debugger 03/16/89 [80386]
Symbols linked (os2krnl)
Symbols linked (clock01)
Symbols linked (screen01)
Symbols linked (kbdbase)
Symbols linked (ibmkbd)
Symbols linked (print01)
Symbols linked (ibm1flpy)
Symbols linked (ibm1s506)
Symbols linked (os2dasd)
Trap 13 (0DH) - General Protection Fault aa04, LDT
eax=00c80042 ebx=ab780000 ecx=00000000 edx=fff00020 esi=ab560030 edi=ab562875
eip=00000910 esp=00005c52 ebp=00005c8e iopl=3 rf -- -- nv up ei pl nz na po cy
cs=0160 ss=0030 ds=0030 es=00d0 fs=0000 gs=0000  cr2=abad700d  cr3=001d6000
0160:00000910 8e5e8e         mov     ds,word ptr [bp-72]           ss:5c1c=000
##ln
0160:00000904 os2krnl:DOSHIGH4CODE:dir$CheckForDevice + c
0160:00000950 h_fValidFATDisk - 40
##k
0160:00000001 a3af 0150 00c8 0000
0160:00004855 5eec 0000 ffdf 0001 devphys$DevReturnHandle + 8d
0160:00004573 0010 0000 0000 0000 FatDirtyBitClear + 3b
0160:00000001 7846 0158 5f24 62d4

-------------------------------------------------------------------------------

Hardware details and background:

Machine:

Dell XPS-90 with revised Intel Neptune PCI chipset (i.e., 90MHz Pentium)
AMI BIOS, Dell revision A03
Quantum 540M IDE drive attached to (conventional ISA) motherboard IDE interface
Any SVGA board I've tried (Number Nine I-128 PCI or Stealth VRAM ISA)
6Mb RAM

Software configuration:

OS/2 Warp 3.0 as configured by installation for VGA (I have made no attempt
yet to install our driver.)

To install the debug kernel I simply copied it from the Warp Retail CD-ROM.
likewise copied the contents of the SYM_1 and SYM_2 directories into drive C:

In testing this configuration I have tried to make sure that all unessential
devices and drivers have been removed from the system.  Thus, I removed the
AHA2940 SCSI adapter and its device driver from the configuration.  No
modification of the configuration has changed the location of the trap.

The same hardware has run the OS/2 2.11 Debug Kernel for months without a
problem.


ANSWER:
Refer to APAR PJ 15378. The fix for this is available in the IBM1S506.ADD

This error condition has only been seen with the PCTECH RZ1000 Chip.  The
IBM1S506.ADD has been modified to work around the anomaly with the PCTECH
RZ1000 PCI chip.  Obtain newer IBM1S506.ADD driver to correct this situation.




!BASE___________________________________**********
February 8, 1995
QUESTION: (Ref:FZ3)
A data-translation frame grabber, model DT2867, is resident on the ISA Bus
structure of a clone running OS/2 3.0 (WARP).  The grabber's device-driver
must operate in real-time, unloading the frame memory buffer onboard the 2867.
Since the local memory is only sufficient to hold one frame, and since a
minimum of 32 sequential frames are required, the unload speed to main memory
must be fast enough to transfer a 256x256x8 b&w frame in 1/30 of a second upon
receipt of an interrupt.

The machine on which this code runs contains 128 megabytes of direct-access
RAM in the OS/2 address space.  It must be capable of operating under the
<MEMMAN = NOSWAP,PROTECT> setting of the memory manager in "CONFIG.SYS".  The
processor is an Intel 486DX2/66.

Since the page-commitment rate of the operating system is not guaranteed to
any specific minimum value, all buffer space must be pre-committed.  As there
is no guarantee that any particular process will be paged-in when an interrupt
occurs, the memory buffer must be present in the common address space of all
processes.  This requires that the buffer be allocated in GDT space.

Therefore, in order to write an efficient device driver, we must:

1. Allocate a Virtual Memory block of 32 Megabytes and precommit paging
   under all of it.

2. Convince the hardware (ie. the 486DX) to transfer the grabbed frame
   information as efficiently as possible to the upper memory block as
   consecutive interrupts are serviced.  Transfers must be sufficiently
   fast that sequential frames are moved without missing interrupts.

3. The transferred frames must be available in the address space of the user
   process which requested the data.


ANSWER:
1. Allocate the memory using VMalloc. This must be accomplished during the
"INIT" call when the device driver is being initialized.  By using a code of
080ah in EAX as input to the call to DevHlp_VMAlloc, the operating system will
correctly allocate the memory, precommiting the pages and returning in EAX the
linear address of the allocated address space. These pages are returned
permanently locked. Subsidiary calls to commit paging are not required.

Set Bit 11(VMDHA_USEHIGHMEM) in the Flag Word which gets loaded into EAX
before invoking the DevHlp_VMAlloc.
Flags = 080ah;
MOV EAX,Flags

Bit 11 is not documented in the version of the OS/2 Technical Library
"Physical Device Driver Reference (Version 2.00)". I believe that bit 8 is a
relatively recent addition to the function's flags word. I shall here note
that the function of bit 8 is incorrectly documented. Under the heading
"DevHlp Services and Device Contexts", DevHlp_VMAlloc is specified to work
correctly during either Kernel or INIT phases of operation. This is not the
case for bit 8, which may only be invoked during INIT. This was the reason
for my original problem. I was calling for virtual memory allocation during
Kernel-time rather than INIT-time.

2. Having a correct linear address we next require the means to use it: an
appropriate GDT selector. Note of course that LDT selectors will be of no
particular use because the paging structure is modified during task-switch
and we do not control the paging context during a hardware interrupt. A
brief reading of the device-help functions reveals no way to create a
page-granular, writable, USE32 GDT selector, which would be the most obvious
way of addressing the 32 megabyte block of memory. But wait, there is
something odd here. When the interrupt occurs, it turns out that the
es-register contains a selector for just such a descriptor. It is
page-granular, origin zero physical, and spans the machine. With this
selector loaded, the interrupt service routine can address the entire
address-space of the machine (less that which is paged out). Linear
allocations in high-memory are guaranteed to be permanently co-addressable
by the operating system, hence sharable between all processes. Otherwise
VMGlobalToProc wouldn't work. This selector turns out to be 158h on my
machine (note that this is declared a ring-zero selector).

With this selector loaded into es, the interrupt service routine can simply
utilize a string-movement hardware instruction of the 486DX to move its data
directly anywhere in the buffer. In my case, the instruction sequence is:

                 push    es

                 cld
                 mov     es,magicCookie
                 mov     edi,LinearAddress
                 mov     edx,portAddress
                 mov     ecx,numberOfWordsToTransfer
                 db      67h
                 rep     insw

                 pop     es

the 67h is the override prefix for long addressing. Note that all four bytes
of edi must be valid to achive a comprehensible result. Note that the DT2867
performs two-byte transfers autoincrementing its pixel counter by a two-count
upon each port read.

3. To access the buffer from a C++ program, use a 32-bit compiler, which
generates an address-space for use with two-selectors, one code and one
writable data, spanning the lower 512 Mbytes of the process linear memory
space. A call to DevHlp_VMProcessToGlobal from the device driver will map
all 32 megabytes down into the process address space via page-aliasing. This
must be requested by the process via a call to the device driver, while the
process is executing, in order to provide the system with the proper paging
context. To implement this call, I utilize the dev_open function of the
device driver. As noted in the documentation, this call can only be
performed during kernel-time.  You may see that this is true by noting that
none of the process context, page or segment, has been allocated at
INIT-time. Also, the process-context is not normally available at
interrupt-time, but the mapping makes it so in this case. I use dev_close to
release the process mapping making the paging available to other processes
if necessary.

To access the buffer from C++ use a cast of a pointer declared to have file
scope.




!STORAGE________________________________**********
February 8, 1995
QUESTION: (Ref: FY8)
I need to ask for some clarification on OS/2 support on some of the SCSI
peripherals AMD has in our SCSI compatibility lab.

We are experiencing some problems running OS/2 with SCSI removable media and
floptical devices.  With regards to SCSI removable media support, it seems
like OS/2 treats it as one big floppy drive.

1. Are there any plans for OS/2 to support removable media like a SCSI fixed
disk drive (i.e.  one can partition the drives using OS/2 fdisk )?

2. Also, there are SCSI removable devices that one can jumper to report itself
in the SCSI inquiry command as a hard disk (0x00) or as a magneto optical
device (0x07) with the removable bit set (MaxOptix Magneto Optical Device -
Tahiti drives).  It seems like OS/2 treats it like a floppy if the hard disk
jumper is set and does not even see the device if the (0x07) drive reports as
a magneto-optical drive.


ANSWER:
Support for Removable partitionable disk is a known requirement.  Today one
can do with with the lockdrv filter (supplied on the DUDE) to force the media
to non-removable.  you can only change by rebooting.




!STORAGE________________________________**********
February 8, 1995
QUESTION: (Ref:FU5)
Does anyone know where (or when) FSD Helpers, libs and headers will be
available for 32 bit (ie hpfs386)


ANSWER:
The FSD helpers are 16 bit only.  There are currently no plans to make 32 bit
helpers.There are no plans to make 32 bit file system either.  Doesn't say we
won't CHANGE our mind at some future date, but as of today there are NO PLANS.




!MULTIMEDIA_____________________________**********
February 8, 1995
QUESTION: (Ref:FS6)
I am looking at writing a sound driver for a SB Pro 16 compatible sound card
and am hoping that source exist for the SB drivers.  I did not see it in the
Developer's Connection CD.


ANSWER:
The source code is available on the Developer Connection Device Driver Kit
Version 1.  This is available as an option to the DevCon.

Driver Description:
The Pro AudioSpectrum 16** driver provided with this DDK is the source used to
create the MVPRODD.SYS device driver that ships with MMPM/2.  The Pro
AudioSpectrum 16 (PAS16) device driver source describes an OS/2 16-bit
physical device driver designed to communicate with IBM Multimedia
Presentation Manager/2* (MMPM/2) audio stream handlers.

Build Requirements:
        Pro AudioSpectrum 16 Device Driver:
        Microsoft MASM** 6.0
        Microsoft C 6.0 (16-bit)




!OTHER__________________________________**********
February 03, 1995
QUESTION: (Ref: GD0)
I was wondering if the PACK.EXE file for compressing files for the OS/2
installation process is available on the DUDE.  I looked but didn't see it.


ANSWER:
PACK.EXE is not on the DUDE.  However, it is available, along with PACK2.EXE,
on DEVCON Volume 5. The location depends on whether you are working with the
original volume 5 or the special edition volume 5.

ORIGINAL:
DEVTOOLS\TKBETA\BIN           - PACK, PACK2
DEVTOOLS\TOOLKT21\OS2BIN      - PACK

SPECIAL EDITION:
DEVTOOLS\TOOLTK21\OS2BIN      - PACK
DEVTOOLS\WARPTLKT\TOOLKIT\BIN - PACK, PACK2




!OTHER__________________________________**********
February 03, 1995
QUESTION: (Ref: G85)
Which tools should I be using from the following list?  Items preceded with a
'*' are what I am intending to use.  Are these recommended?

## Device Driver Kit for OS/2 ##
\DDKX86\tools\masm.exe
\DDKX86\tools\c1_386.exe
\DDKX86\tools\c1l_386.exe
\DDKX86\tools\c2_386.exe
\DDKX86\tools\c3_386.exe
\DDKX86\tools\cl386.exe
\DDKX86\tools\lib.exe
*  \DDKX86\tools\link.exe
\DDKX86\tools\link386.exe
*  \DDKX86\tools\rc.exe
*  \DDKX86\tools\implib.exe
\DDKX86\tools\ipfc.exe
*  \DDKX86\tools\mapsym.exe

## Developers Toolkit for OS2 WARP ##
\TOOLKIT\bin\link386.exe
\TOOLKIT\bin\rc.exe
\TOOLKIT\bin\implib.exe
\TOOLKIT\bin\ipfc.exe
\TOOLKIT\bin\mapsym.exe

## Microsoft MASM 6.11 ##
*  \MASM611\bin\ml.exe
\MASM611\bin\lib.exe
\MASM611\bin\link.exe
\MASM611\bin\implib.exe

## IBM CSet ++ for OS2 2.1 ##
*  \IBMCPP\bin\icc.exe
*  \IBMCPP\bin\lib.exe


ANSWER:
1. The tools you referred to from the Developer's Toolkit for OS/2 Warp are the
   same tools from the Device Driver Kit for OS/2.

2. The tools you use depend upon the type of device driver, please refer to
   "Using your DDK Components & Build Requirements" on the DDK.

3. IBM CSet ++ for OS/2 2.1 is fine for 32bit device drivers but not for 16bit.
   Some examples of 16-bit compilers are IBM C/2, Watcom C16, MS 6.0 (used in
   the DDK) and Borland 3.5.

4. MASM 6.11 does not support OS/2.  However, MASM 6.0 does.




!VIDEO__________________________________**********
February 03, 1995
QUESTION: (Ref: G81)
Q1. Could you provide an example of how the VDHRegisterAPI call works?

A1. For some examples of the usage of VDHRegisterAPI you could refer to the
following files in the DDK:

      ddk\src\vdev\vtouch\vthook.c
      ddk\src\vdev\vmouse\vmuser.c
      ddk\src\vdev\vdsk\vdsk.c
==============================================================================

Q2. I have setup a short VDD that seems to work, but uses the VDHPopInt call to
    return to the VDM session.  Otherwise the VDM tells me I've accessed an
    invalid region on the return.

A2. If you are talking about returning from the routine registered via
    VDHRegisterAPI to the DOS/DPMI application in the DOS session, a simple
    'return' should be sufficient.  Refer to the sample sources stated in A1
    above.
==============================================================================

Q3. Is using the VDHPopInt the correct way to exit an API routine?  Also, what
    does the PVOID pointer (the first parameter in the function) point to?

    I am using this VDD to migrate from a Desqview environment that had many
    nice mailbox/semaphore api's that can be called from DOS sessions.  This
    would allow me to replicate these api's as well as expand the capabilities
    of my DOS applications that must be able to "talk" to each other.

A3. Which function are you refering to?  VDHPopInt does not take any
    parameters.  You could also refer to the Virtual Device Driver Reference
    for a description of the parameters.




!STORAGE________________________________**********
February 03, 1995
QUESTION: (Ref: G75)
I noticed that some files are missing in the DDK CDROM.  Listed below are the
missing files:


 \DDKx86\SRC\DEV\DASD\LIBOBJ
    AFULSHR.OBJ
    ANFAULDI.OBJ
    ANFAULRE.OBJ
    ANFAULSH.OBJ
    ANLDIV.OBJ
    ANNALDIV.OBJ
    ANULSHR.OBJ
    ATAPINIT.DBJ

Please let me know where I can find these files.  They are needed when I try to
build a DEBUG version of the ATAPI Device driver e. g. nmake debug.


ANSWER:
The Makefile does not support the MAKE of the Debug Version of the ATAPI Device
Driver.  We regret the defect in the Makefile code and this capability will
subsequently be removed from the Makefile.




!STORAGE________________________________**********
February 03, 1995
QUESTION: (Ref: G68)
I'm writing device drivers for a new set of PCI-IDE chip sets coming on the
market.  I've found very little refrerence to PCI in my delivered DDK data.  I
did find a couple refrences in the 'ddkx86\src\dev\resource\rsm_h\rmbase.h'
file that generated more questions than answers on how OS/2 deals with PCI.

Could you please give me any source code, text, etc.  on the state of PCI as it
relates to OS/2?


ANSWER:
The WARP loader (OS2LDR) provides two levels of function for PCI devices.

1) Support for PCI devices sharing interrupts:

   This loader examines the configuration space for interrupt lines used by
   PCI devices.  Upon finding such an interrupt, this line is marked as
   shareable in the kernel interrupt manager.

2) Provides a set of PCI IOCtls in OEMHLP$, also accessible through IDC:

This IOCtl is accessible through function 0x0b.  The first parameter of each
request packet is a subfunction byte.  The five subfunctions are as follows:

     1) 0x00 Get PCI BIOS Information
     2) 0x01 Find PCI Device by DeviceID and VendorID
           Make repeated calls while incrementing Index to find all
           devices.
     3) 0x02 Find PCI Device by Class Code
           Make repeated calls while incrementing Index to find all
           devices.
     4) 0x03 Read Configuration Space
           Size field describes data size.
     5) 0x04 Write Configuration Space
           Size field describes data size.

This set of IOCtls roughly maps to the PCI BIOS calls.  This should allow both
device drivers and installation applications to find their devices and query
their configuration space.

Also, see PCI BIOS Specification Rev.  2.0

The OEMHLP - PCI IOCtls are documented in the Physical Device Driver Ref.  The
DUDE BBS contains a sample of how to Access OEMHLP from Ring 0 (RMBASE.ZIP &
OEMHLP.ZIP are in the Main file area on the DUDE).  PCI Documents are available
from & maintained by the PCI Special Interest Group at 1-800-433-5177.




!OTHER__________________________________**********
February 03, 1995
QUESTION: (Ref: G67)
I have been unable to find a version of the Microsoft C version 6 compiler.  I
have the Visual C++ compiler (V 8.0) but it cannot be run in OS/2 (It only
works in a MS DOS protected mode environment).  I've called Microsoft and they
know this problem exists and say they have no more copies available and
certainly won't help the competition.  This causes me a lot of hastle when I
want to write device drivers.  I end up having to reboot to normal DOS and
bring up windows every time I want to compile any of the delivered 16 bit DDK
code.

I've purchased the Borland C++ OS/2 Version 2.0 compiler.  This compiler is
strictly a 32 bit compiler and won't work (as far as I know) in writing device
driver code.

I quess my main question is what does IBM plan on doing about the weak support
given to the OS/2 development by way of a good solid Compiler?  You'd think
that IBM would spend some money and write a single compiler that could be used
to support their own new platform and not rely on the whims of the competition!


ANSWER:
Not all device drivers which are part of DDK need MS C V6.0.  To determine
which particular compiler/assembler is needed for a specific device driver,
refer to the "Using your DDK" online reference under "Components and build
requirements" or "Compilers/Assemblers used".

The DDK contains MASM 5.1 and MS CL386.

If you are planning to develop your own 16-bit device drivers, you could use
WATCOM C/C++ V9.5 or 10.

We are sorry we cannot be of any help in getting you Microsoft C v6.0.but if
you are doing you own development you could migrate to WATCOM for 16 bit
drivers.




!STORAGE________________________________**********
February 03, 1995
QUESTION: (Ref: G66)
I'm writing a driver for a new PCI-IDE controller chip set.  While trying to
write the hardware existance check program I have found that calls to the
DosDevIOCtl calls for I/O input are returning an error.  To troubleshoot this
problem I compiled the DDK version of the TESTCFG.SYS driver and used it to get
more info on the error.  I've found that the error is occurring when a call is
made to the 'RMAllocResource' function.  I've been able to get a good return
code from this function when I make the following change to the IOFlags
parameter of the Resource structure (i.e.  or'd RS_SEARCH to the existing
RS_IO_EXCLUSIVE parameter).

     .
     .
     .
     Resource.IOResource.IOFlags        = RS_IO_EXCLUSIVE | RS_SEARCH;

     if (RMAllocResource(DriverHandle,&ResourceHandle,&Resource))
     .
     .
     .

This brings the following questions:

Q1. Why doesn't the RMAllocResource work with the normal RS_IO_EXCLUSIVE only?

A1. The failure means someone else has already allocated that resource.
    RS_SEARCH actually goes and allocates an unused resource -> useful for
    PCMCIA which is programmable.

    When a search is performed and is successful, the BaseIOPort field will be
    updated to indicate the start of the allocated I/O Port Range.
==============================================================================

Q2. Does the fact that I'm using a 32 bit interface to the DosDevIOCtl make a
    difference?  If so, can you show me a typical 32 bit interface that will
    work?

A2. No, using the 32 bit interface to the DosDevIOCtl should make no
    difference.
==============================================================================

Q3. Does the fact that I'm using a PCI bus make a difference and if so what
    should I do to make my hardware existance code work?

A3. No, but your identification should use the PCI IOCtls available through
    OEMHLP.  This is documented in the Physical Device Driver Reference in the
    DevCon DDK v1.
==============================================================================

Q4. Why is there not source code for the RMAllocResource et.  al.  code?  I
    have found the .H files for the code but not the function source code.

A4. The code for the resource manager will probably not be released -> it
    doesn't actually run any hardware, it's just a service provider.  There are
    examples of its use in the DDs in the DDK.  Let me know if you will need
    the documentation for RMAllocResource.
====================================================== =======================

Q5. If, ultimately, this change is necessary to make accesses to the
    TESTCFG.SYS driver, how would this change get to all the delivered OS/2
    TESTCFG.SYS programs?

A5. I don't think you need to.  You should be using the PCI OEMHLP IOCtls.




!OTHER__________________________________**********
February 03, 1995
QUESTION: (Ref: G60)
I am in the process of aquiring the necessary tools to build a physical device
driver for OS2/2.1.  I would like to use both assembly and C and need to know
what tools are needed.  I currently have MASM version 5.10A.15, and Microsoft C
386 compiler version 6.00.054.

Q1. These Microsoft tools were shipped with a Beta version of the OS/2 Device
    Driver Kit (1-1993).  The 1993 DDK does not include the standard Microsoft
    CL.EXE (why?)  and does not have a CL286.EXE (needed??).


A1. The DevCon DDK Version 1 does not contain Microsoft C v6.0.  CL386 V6.0 and
    MASM V5.10A.15 are part of DDK, CL is NOT.  This is due to certain
    Licensing Problems with Microsoft.
==============================================================================

Q2. I am currently waiting for the next available release of the Developers
    Connection (available end of Jan 95) but am pressed for time, so I am
    attempting to use the old Microsoft tools described above.  I would like to
    know what tools are needed to create drivers, i.e do I need an old version
    of Microsoft C that is no longer available (arrg!), and an old version of
    MASM (double arrg!)???  Or, can I just buy the new Developers Connection CD
    and presto- solve all my problems?

    I also have Borland C/C++ & TASM for OS/2, however, I found a note buried
    deep within a help file that quite matter of factly states :  "TLINK does
    not support linking of device drivers.  "


A2. To build some of the drivers in the new DDK you would still need MASM 6.0,
    Microsoft C 6.0, IBM CSet/2 & Borland C++.  These compilers do not come
    with the DDK.  DDK contains only MASM 5.1 & Microsoft CL386.  To determine
    which particular compiler/assembler is needed for a specific device driver,
    refer to the "Using your DDK" online reference, under "Components & build
    requirements" or "Compilers/Assemblers used".

    We do not have the Borland C/C++ documentation and therefore cannot really
    comment on the TLINK statement.  However if you are developing your own 16
    bit driver and having problems using TLINK, you could use the LINK which is
    contained in the DDK.




!STORAGE________________________________**********
February 03, 1995
QUESTION: (Ref: G32)
Q1. I'm looking for a way to get the position of a file within the HPFS.  If
    it's possible I would prefer a way to get this from *any* FSD/IFS.  I need
    the block, sector and allocation unit of the beginning of the file on the
    disk.  The best way to do that is with the use of API calls, but if it's
    only possible to perform some low level accesses to the HPFS, I would do
    that too.  I need a long integer value; a fixed value which will not change
    as long as the file isn't moved).  I don't want to perform low level
    manipulation of the file system or anything else.  The input parameters are
    disc, path and filename.  If part of the information needed to get the file
    position is classified, please tell me.

A1. There is no API to do this, so the only way would be to understand the
    internals of the filesystem, and dig out the information yourself.  This is
    not trivial for any filesystem (except FAT).  For HPFS, you'd have to know
    how to traverse a directory b-tree, find the entry for the file, then find
    the FNode and traverse the storage b-tree.
==============================================================================

Q2. It would be nice to have more information for accessing the HPFS filesystem
    low level The only documentation I've got is something from Microsoft, so
    it will be out of date.

    The above answer states that I have to get the FNODE to find the beginning
    of a file on the disc.  Because of my knowlegde of the Unix system and the
    SysV1k filesystem, I think the FNODE must be a unique (long integer) value
    for every file within the filesystem.  If I could get the FNODE a little
    bit easier than the file position this would be great.

A2. We do not expose the FNODE in any way to the user.  You need to understand
    the HPFS format, write a low level routine to scan the partition for the
    FNODE.  The HPFS disk format has not changed therefore the Microsoft
    documentation on the disk format is still valid.

    This information is described in detail during sessions at the 1995 IBM
    Technical Interchange.  Please download the file MAYCONF.TXT in the INFO
    Area for details about the Technical Interchange.
==============================================================================

Q3. My next question is how to check for a local/remote file system.  I have to
    check whether or not the file system is in the local machine or a networked
    drive.

A3. Please download the TESTDEV.ZIP sample from the DUDE which can tell you
    whether the drive is supported by local or remote file system.
==============================================================================

Q4. Does the HPFS (like the DOS-FAT) prevent HSR files from being moved by a
    compression program?  If not, how to prevent a file to be moved to another
    position on the disk?

A4. DOS-FAT does *not* prevent HSR files from being moved by compression
    programs.  That feature is done by the compression programs as a safety
    measure (some copy-protection schemes have unmovable files).  If your
    utility realizes this, it may emulate that behavior on HPFS.  There is
    nothing HPFS does to prevent file movement (file location is not something
    anyone above the file system is supposed to care about).
