This is file: 05_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)
==============================================================================

!PRINT__________________________________**********
May 30, 1995
QUESTION: (Ref: HH1)
I am trying to write a print-capture driver for OS/2.  To explain further,
some Windows programs provide a print-capture driver that allows other apps to
direct print output to the print capture driver, which then produces a bitmap
which is "imported" into another app

For example, Intel ProShare whiteboard provides such a print-capture driver.
With the driver installed, an e.g.  Word document can be 'printed' from Word
and the resulting output is a bitmap displayed inside the ProShare Whiteboard.
(If you are not familiar with ProShare(!), it is similar to the IBM Person to
Person utilities which are included in the Warp BonusPak).

A fax printer driver must work somewhat the same.

For Windows one can write a printer capture driver like this by using the
UNIDRV printer driver.  UNIDRV is a generic printer driver.  It provides the
handling of all drawing operations to a bitmap.  To write the print capture
driver one uses UNIDRV for all drawing operations and hence only need to write
code to deal with the completed bitmap.

Question
--------

1. Is there any equivalent to UNIDRV for OS/2?

2. If not, does the DDK include any "brute force" (color) printer drivers that
would provide a good starting point for a capture driver?  The mini-driver
looks like the best option.


ANSWER:
1. There is no equivalent to UNIDRV for OS/2 provided in the DDK Source.

2. The DevCon DDK V1& V2 provides the printer driver that supports a raster
capable printer.  Refer to the directory \ddkx86\src\prntdd\mdriver2 for Mini
Driver2 source files.  This does not contain the device specific code.  This
source code can provide a starting point for a capture driver for a printer.




!OTHER__________________________________**********
May 30, 1995
QUESTION: (Ref: HF9)
I am having a little difficulty starting my driver.  I am trying to figure out
what include files I need to communicate between the various layers in the
OS/2 device driver model.  I have included a diagram below that describes my
situation.  I need to know which include files are used to communicate between
my .SYS driver and OS2SCSI.DMD and I am interested in knowing what include
files are used to communicate between OS2SCSI.DMD and the .ADD drivers.
Likely canditates include SCSI.H, SCSCSI.H, IORB.H, and SCB.H.  I have listed
what I believe to be the interfaces between my driver and the application and
also, the DevHelp functions.

          +-------------+
          |             |
          | Application |
          |             |
          +-------------+
                |   DosOpen, DosClose, DosRead, DosWrite, DosDevIOCtl
                |
                V   devhdr.h, devcmd.h, strat2.h, reqpkt.h, bse.h, os2.h
          +-------------+
          |             |
          | xxx.SYS     |-------------+
          |             |             |
          +-------------+             |  dhcalls.h
                |                     |
                |   ????              |
                V                     V
          +-------------+       +-------------+
          |             |       |             |
          | OS2SCSI.DMD |------>| DevHelp     |
          |             |       |             |
          +-------------+       +-------------+
                |                     A
                | ????                |
                V                     |
          +-------------+             |
          |             |             |
          | XXXXXXX.ADD |-------------+
          |             |
          +-------------+
                |
                |
                V
          +-------------+
          |             |
          | Host Adapter|
          |             |
          +-------------+
                |
                |
                V
          +-------------+
          |             |
          | Tape Drive  |
          |             |
          +-------------+


ANSWER:
The list of header file required are as follows.  The required header files
depends on what calls and data structures you are going to use in your driver.

Your driver xxx.SYS should include the following :  os2.h, devcmd.h, error.h,
dskinit.h, dos.h, devhdr.h, infoseg.h strat2.h, dhcalls.h, iorb.h, scb.h,
reqpkt.h, scsi.h

OS2SCSI.DMD should include :
os2.h, error.h, devhdr.h, devclass.h, devcmd.h strat2.h, dhcalls.h, reqpkt.h,
scb.h, iorb.h, scsi.h, scscsi.h, scgen.h, scproto.h

Adapter driver should include :
os2.h, dos.h, bseerr.h, dskinit.h, iorb.h, reqpkt.h, dhcalls.h, addcalls.h

If MCA bus then include scb.h, abios.h in ADD.

Ref : ddkx86\src\dev\dasd\ibm
      ddkx86\src\dev\dasd\os2scsi
      ddkx86\src\dev\dasd\addcalls




!STORAGE________________________________**********
May 30, 1995
QUESTION: (Ref: HF1)
When I read or write (64h or 44h) more then 9 sectors to a disk with 9
sectors/track, the read or write operation still returns RC == 0!

Can read or write do any more then 9 sectors?  Doc states that the calls do
not bump the tracks/heads.  I should get a failure, yes?

When I attempt to do a VERIFY TRACK (65h) I crash (after 1 or two calls); I am
passing buffers etc, just like I was going to do a write.  If I substitute a
READ TRACK (64h), the routine works just fine.  The parms would seem to be the
same for either operation.

The BPB layout you supplied was appreciated.  I was able to use the additional
information to determine disk type, as Query Device parms (63h) documented
cylinders, type and attribute are of little use.  It tells me 80 cyls on a
360K disk!  and type 1 for a 360K disk!  and type 7 for a 720K disk!  not very
useful.


ANSWER:
In theory it is possible to format a diskette with 256 byte sectors with > 9
sectors per track.  Should someone wish to do a thing like this, the simplest
solution is to try to read beyond the expected end of media, i.e.
CHS=(40,1,10).  If you are successful you have something other than 360K media
in the drive or the media is unformatted.  Reading at some other valid place
on the media CHS=(0,0,1) for example will tell you whether it is formatted.




!OTHER !STORAGE_________________________**********
May 30, 1995
QUESTION:  (Ref: HF0)
I am a developer in the UK.  I have a working device driver for the ISA
version of my product, devloped without the DDK under Warp 3.0 and Watcom
10.0a (painful).  I need to create a driver for my PCI card.  All your online
documentation refers to U.S.  800 numbers which I cannot access from the UK.

Q1. How can I get a hold of the Devcon DDK in Europe?  None of the UK dealers
I have tried have heard of it.

A1. Please download DDKORDER.TXT from the INFO area on the DUDE for
information on ordering the DEVCON DDK outside of the U.S.
==============================================================================

Q2. Will this contain the information I need about PCI?

A2. There is no PCI information on the current Devcon DDK, version 2.0, but
there are two files in the MAIN file are on the DUDE that contain PCI info.
The filenames are OEMHLP.ZIP and OEMBASE.INF, please download these files.




!OTHER____________________________________**********
May 30, 1995
QUESTION: (Ref. HD3)
I and trying to compile the MDRIVER2 but it appears that I am missing the
BUILTIN.H file.  Is there any way for me to download it via the DUDE, if not
can you tell me how to get it in a hurry.


ANSWER:
The Build Requirements for the Minidriver 2 Code is IBM C/C++ 2.01.  The
INCLUDE Directory of this Compiler has the BUILTIN.H File.  Just make sure
your Environment settings for INCLUDE is correct (if you have the right CSet
Version).


FOLLOWUP QUESTION:
I am not using C set but Watcon C/C++ 10.0a.  Obviously the header file is not
supplied with it so can I get a copy of it or is there a alternative way to
build without it?


FOLLOWUP ANSWER:
We are not authorized to distribute the CSet Header Files and there is no
alternative to build without it.  Sorry we couldn't be of any help.




!OTHER__________________________________**********
May 30, 1995
QUESTION:  (Ref: HC9)
I am working on a ddp that copies a new driver to the hard drive.  I was
wondering if it is possible to have that ddp rename the current driver on the
hard drive before it copies the new one to the drive.


ANSWER:
In the .DDP file, there is no option to rename the existing driver file but it
can be done by you.  Include that functionality into the .EXE file specified
in the PRESENCECHECK option.

Ref: Storage Driver reference, Ch - 2, section on "presence check function"
and Physical driver reference, Ch - 7, section on "Installation of external
loadable device drivers".




!VIDEO__________________________________**********
May 30, 1995
QUESTION: (Ref: HC6)
I need to know the code changes in the IBMS332.DLL made by the APAR's PJ10311
and PJ12059.


ANSWER:
Both fixes have been incorporated in the DDK v1.

APAR PJ10311 corresponds to Defect # 74185.  The code changes were
incorporated in DRAWBITS.ASM.

PROBLEM RESOLUTION
------------------
Made two modifications to OEMDrawBits to finish converting the module to
32-bit flat addressing.

MODULE CHANGED
In the DDK this would be - DDKX86\SRC\VGA32\IBMDEV32\DRWABITS.ASM


APAR PJ12059 is related to Defect #78036.

Basically the following file was modified -
DDKX86\SRC\PMVIDEO\32BIT\DRAWBITS.C

The failure was caused by an uninitialized ul PixelOp.  Set the direction
flags for low level */ HARD_DRAW code.




!I/O____________________________________**********
May 30, 1995
QUESTION: (HC5)
Need help in the following areas:

1) How to do mouse init in a ps/2 world?

2) How to get the ps/2 port to stop pulsing at 1pps or so.

3) Any other info on aux port init stuff for ps/2.


ANSWER:
The files referred to below can be found on the OS/2 DDK v1.0

1. Refer to PDINIT.ASM for mouse init and the routines dealing with PDIINIT
and ResetMouse.  Routine HotPlugPDI deals with reinitialization of PDI mouse
hardware attached to PS/2 or PDI port.  For a bus mouse refer to bus.asm and
for serial mouse refer to serial.asm.

2. SetSampleRate routine in PDI.ASM can be used to set reports per second.

3. Refer to CheckForPDIDevice routine in PDI.ASM, UTIL1.ASM, INIT.ASM (for EMI
driver using AUX port) in ddkx86\src\dev\mouse directory.




!OTHER__________________________________**********
May 30, 1995
QUESTION: (Ref: HC0)
I'm using journalplayback hook to insert WM_MOUSEMOVE messages that are
received from the Window's remote machine.  Problem if you insert a
WM_MOUSEMOVE message on a host (OS/2) machine that does not have a mouse, you
will receive a GPF (SYS3175?)  at

                PMMERGE.DLL in the Ring0MoveCursor32 proc + 0x15
                      call dword ptr [ebp+8]  note value is NULL.

                stack trace ( looks correct )

                Ring0SetDisplayPos + b8
                SkipSysMsg + ed
                XScanSysQueue + 9f0
                Win32PeekMsg + 4b7

Note:  PMMERGE needs to check for NULL value prior to call.


ANSWER:
This problem has been verified and a defect has been opened.  Refer to APAR
PJ18606.




!OTHER__________________________________**********
May 30, 1995
QUESTION: (Ref: HB6)
We're invoking the PhysToGDTSel, x'54', DevHlp entryPoint.  On return we
expect AX to contain the selector contents with the modified RPL bits (as per
documentation).  What we find in a clear condition code, indicating a
successful operation, but the contents of AX are zero.  Caused us to crash and
burn.


ANSWER:
Refer to ddkx86/src/pmvideo/xgasys20/xgaring0.asm for usage of PhysToGDTSel,
which returns modified sel in SI, not in AX.  The error in the documentation
will be corrected in the next release.

Please verify the parameters you are passing to the DevHlp PhysToGDTSel.  Also
ensure that the indicated segment must either be a fixed block of memory or
locked before invoking the PhysToGDTSel DevHlp.




!NETWORK________________________________**********
May 30, 1995
QUESTION: (Ref: HA7)
I am dealing with NETBIOS programming and need some help.

1. Is it possible to include 00h symbol in a NETBIOS name (I'm speaking about
non-first and non-last positions)?

2. Can I launch several concurrent processes that are receiving NETBIOS
packets with the same destination name?

3. Are there any restrictions or any special ways to do this?

4. Please point me to good NETBIOS books and specs!


ANSWER:
1. Yes
2. Yes
3. You have to use a group name.
4. Order the IBM LAN Tech Ref  SC30-3587-00.




!OTHER__________________________________**********
May 30, 1995
QUESTION: (Ref: H89)
In spite of the books on OS/2 I have at my disposal, I cannot find a clear
explaination of the difference between 16 and 32 bit calls to the strategy
routines.  This was, in fact, the problem with my function call of the DosOpen
function.  It was apparently implementing the 32 bit format for the call, but
the Kernel was expecting 16 bit format.

I understand that the kernel intercepts these function calls, reformats the
data into a request packet and passes it to the strategy routine.  However, I
do not understand what determines if the kernel uses 16 or 32 bit format.

1. Do I have any control over this matter?  Is it fixed and permanent?

2. If it IS possible to control it, is it a "system wide" setting, or is it
possible to make one stategy routine 16 bits while another is 32 bits?


ANSWER:
Only the IOCtl interface has 16 and 32 bit formats.  All other strategy
commands have only the 16-bit format.This has been done for compatibility with
OS/2 1.x For details regarding the 16/32 bit IOCtl formats you can refer to
PDD ref, Ch-10, section on "Generic IOCtl example".

1. The Device Driver determines whether it supports the 16 or 32 bit IOCtl (or
both) Interface.  All the drivers that are in the DDK support the 16-bit IOCtl
interface.  If you intend to use the 32 - bit IOCtl you will have to ensure
that the DD supports DosDevIOCtl2.  The Device Attribute Word in the Device
Header- should be set to Level 2 (bit9-7=010) and the Bit 0 of Capabilities
Bit Strip should be 1 if DosDevIOCtl2 request packets are to be supported.

2. There is no system wide setting.  The same strategy routine could support
both the 16-bit and 32-bit IOCtls and process accordingly depending on the
parameters received.  This depends entirely on the way the DD processes
request packets.


QUESTION:
The requirements for my device driver have changed somewhat.  The special
hardware that this driver must support controls several devices.  This means
that the device driver must support both the board itself and also up to 16
devices connected to it.

I am familiar with the linked Device Headers that are used.  I have already
implemented this and it seems to work just fine but some things have happened
that I was not expecting:

It seems that the INIT routine is called by the Kernel once for every device
in the linked device header list.  Common sense tells me that I should have
expected this however I am now unsure of how the INIT routine should handle
the global variables I have set up.

The device driver book I have read recommends the creation of global data
which stores various things at INIT time, such as:  the "process ID", the open
count, the pointer to the DevHlp entry point and other things.

I understand that a device header record must exist for each device, but what
about this other data?  Do I need to store one record of these elements for
each device?

With this driver supporting multiple devices and the Kernel calling the init
routine once for each device, what is to be done about the request packet
return data which contains the final offsets of the code and data segment?

It is my understanding that the kernel regards memory beyond these offsets as
"initialization related" and releases that memory once initialization is
through.  Since the INIT routine is now being called more than once, at what
point will the kernel release this memory?  If I provide the offsets the first
time the INIT routine is called, will it immediately release the memory?  Does
it wait until it encounters the device header link terminator before releasing
it?  If not, how do I write my code so that the kernel does not release this
memory until the INIT for ALL devices has been carried out?

Also, if the first INIT routine (for the board) fails, can I stop the
kernel from attemping the INIT with the devices, as this would be futile?


ANSWER:
1) For each device header the corresponding strategy routine will be called at
its INIT entry point.

2) You could have separate set of variables for each device.

3) Even though there are multiple device headers and strategy routines they
all finally call the same main() routine.  The final DS,CS values to be
returned correspond to this main() routine only.  Ref :  "Writing OS/2 2.1
Device Drivers in C", Steve J. Mastrianni, Appendix-C, "C startup routine",
Ch-5 fig 5-8, section titled "Strategy Section".

4) The kernel releases this memory after calling all strategy routines at
their INIT entry point.  Kernel waits till it encounters the device header
link terminator.

5) Even if the first INIT fails, the kernel calls INIT entry point of
remaining devices.  You could however have a global variable which could be
set on any device failure.  On receiving the the Init Request Packet,you would
check for this variable and continue further processing only if the global
variable is cleared.





!VIDEO__________________________________**********
May 30, 1995
QUESTION: (Ref: H85)
I am currently making changes to the device dependant portion of the
Presentation Display Driver (IBMS332.DLL).  Several escape calls already
exsist.  For example, GreEscape DEVESC_ACQUIREFB and DEVESC_GETAPERTURE.

I am trying to make calls to these escapes in a PM program, but I am having no
luck.  The GreEscape() function keeps returning DEVESC_ERROR(-1).

I am using the following for references:  Presentation Device Driver Reference
for OS/2 Vol 1 and 2 and the Display Device Driver Reference for OS/2.


ANSWER:
The possible errors could be one of the following (defined in PMERR.H)

PMERR_INV_LENGTH_OR_COUNT         0x2092
PMERR_DEV_FUNC_NOT_INSTALLED      0x2023
PMERR_INV_ESCAPE_DATA             0x2066

Please check your source for these possible errors.  Also please also refer to
online display driver reference manual available on DevCon DDK V1.0, section
on "S3 display driver".




!OTHER__________________________________**********
May 30, 1995
QUESTION: (Ref: H84)
How can I load a 32bit dll from the 16bit bvhsvga.dll?  I want to use a 32bit
DLL for my init code, is this possible under warp?


ANSWER:
Yes, it is possible to load another 32 bit DLL from a 16 bit DLL.  There are
various considerations though.  Note that it is also possible to statically
link the 32 bit and 16 bit DLL (with some restrictions).  The dynamic link is
also most certainly possible.  A very good reference is chapter 16 of the IBM
C/C++ language reference manual.  I have no information about the WATCOM
compiler though.  To summarize, proper prototypes, right tools, and correct
linkage are some of the things to be careful about.

Also refer to application design guide,ch-3, "calling 32-bit code from 16-bit
code".

It could be done from BVHSVGA.DLL, but then you will have to have your own
code for thunking and the 32 bit DLL should have a 16 bit Entry Point.

If the intent is to SetMode through another DLL,you could use the PMI
approach.  Modify the PMI File and IBMGPMI.DLL.  This is documented in the
DDK.




!OTHER__________________________________**********
May 30, 1995
QUESTION:  (Ref: H12)
I have an NDIS PCMCIA device driver that was compiled using Microsoft
Assembler 6.0.  I have created a .NIF file and have been successful at
installing the driver via NTS/2 LAPS.  When I re-boot the workstation, the
following error occurs accompanied by a black screen:

A program in this session encountered a problem and cannot continue.

          c0000005
          P1=00000001   P2=00004ccc   P3=XXXXXXXX P4=XXXXXXXX
          EAX=000010d8  EBX=00c90064  ECX=fdf30000  EDX=000003d7
          ESI=0000056a   EDI=ff3f0000
          DS=0840   DSACC=00f3  DSLIM=00000fa7
          ES=0130  ESACC=00f3  ESLIM=00005133
          FS=0000   FSACC=****   FSLIM=********
          GS=0000   GSACC=****  GSLIM=********
          CS:EIP=005b:00004ccc   CSACC=d0df  CSLIM=1bffffff
          SS:ESP=0017:00000f6e  SSACC=00f3  SSLIM=00000fff
          EBP=00000fb8  FLG=00013246

Q1. What assembler options should I use with ml to assemble and link?

A1. No specific assembler options are required.  But, in the source, you can
include the following assembler directives.
Ref:  ddkx86\src\dev\pcmcia\socket\ss_segm.inc.

      .286p
      .small
      segment:use16
==============================================================================

Q2. What linker should I use (OS2386, OS2286, DOSCALLS, etc..)?  This driver
needs to run under both OS/2 2.11 and OS/2 3.0.

A2. You can use the following linker options -
      /noe /noi /nod /align:16 /exepack /map /far

      Libraries to be linked are -
      os2286p.lib, doscalls.lib

      Ref: ddkx86\src\dev\pcmcia\socket\makefile.
==============================================================================

Q3. Is there any way to use the above error information with an assembler
listing to try and quickly figure out where the problem is without setting up
an elaborate debugging mode.

A3. C0000005 corresponds to an access violation.  It is a hardware generated
exception.

You could generate a list file and a map file.  Locate the instruction being
pointed to by CS:EIP with the help of list and map files to find the
problematic instruction.

Ref:  Control Program programming reference, Appendix-C, system exceptions.
==============================================================================

Q4. I expect to be getting the Periscope debugger to OS/2 any day now and
would like to do SOURCE LEVEL debugging, if possible.  That is, assemble the
code with the debugging options enabled and walk thru the driver assembler
source code.

A4. The Kernel Debugger could also help you walk through the Assembler Source
Code.  Periscope would be helpful in walking through your C Source Code.
==============================================================================

Q5. Is there an interrupt to get the system time and day?  The following code
hangs under OS/2 2.11 on the int 1AH call.

      push cx
      push dx
      move ah,0
      int 1Ah


A5. To get the information in a PDD, use the GetDOSVar DevHlp call.

Use GETDOSV_SYSINFOSEG as the index for the call.  For details regarding usage
of the GetDOSVar Devhlp refer to:

       - PDD Reference manual.
       - Appendix A of Steve Mastriani's Book "Writing OS/2 2.1 Device
          Drivers in "C".

The Virtual Device Driver has the BIOS Software Interrupt Support.  The
Virtual CMOS device driver component supports read-only access to the Real
Time Clock Device.  Please refer to the Virtual Device Driver Ref.  chapter -
Base Virtual Device Drivers,Section - Virtual CMOS Device Driver.




!OTHER__________________________________**********
May 19, 1995
QUESTION: (Ref: HE6)
Is there a way for an application (or a surogate who knows the application's
client window handle) to determine through API calls what all of the current
visible rectangles within it's client window are?

Any sample code would be greatly appreciated if it exists.


ANSWER:
This type of question can be best answered by the DAP group.  The DAP handles
application related development and you can register with them by calling
407-982-6408.




!OTHER__________________________________**********
May 19, 1995
QUESTION:  (Ref: HC4)
I am working on an OS/2 printer driver and at the moment I have a few problems
with semaphores.  Is there a tool available which displays semaphores and
maybe even destroys them when needed?  It would also be nice to have a tool
which displays which DLL (or drivers) are currently loaded.


ANSWER:
We are not aware of any tool to display/destroy semaphores.  THESEUS2 can be
used to find out which DLL/Drivers are currently loaded.  In the "System"
pull-down menu, under "General System", the "Modules" option displays
currently loaded DLLs and "Device Drivers" displays currently loaded drivers.
THESEUS2 is part of the SPM/2 2.0 product, the product# is 96F8379.




!STORAGE________________________________**********
May 19, 1995
QUESTION:  (Ref: HB7)
There is a problem with many PCI machines running OS/2 2.x.  Soft reset
(ctrl--alt-del) doesn't reset PCI devices.  As a result, PCI busmasters are
still running and writing into system memory which is no longer theirs.

We are observing a complete hang during the soft reboot of OS/2 2.x on PCI
boxes using our busmaster card/driver.  The only way the driver can stop the
hardware is the ndis 2 "Close Adapter" call but it is never issued when OS/2
is shutdown.  In fact, it is never issued to the driver even if "net stop" is
used.  Do you know of any way to issue "Close Adapter" to the NDIS2 driver?
Is there a way to have a "shutdown".cmd file in OS/2 similar to the
startup.cmd?


ANSWER:
PCI support was not available for OS/2 2.1; and PCI Support is available on
OS/2 2.11 only through a CSD.  Please contact OS/2 Tech Support at
1-800-992-4777 and ask for the fix which is APAR PJ14230.  PCI Support is also
available on OS/2 Warp.




!OTHER__________________________________**********
May 19, 1995
QUESTION: (Ref: HB5)
In our device driver we will be allocating memory dynamically in the strategy
section which will possibly be used on the interrupt level.

We will use the following method to allocate and use the memory.  Please let
us know if this is a correct method and if it is the preferred method.  It
seems complicated to have to do the DevHlp_PhystoVirt all the time.

(code removed for security)


ANSWER:
Your seqence of DevHlps will work, but you could eliminate an extra DevHlp
call at Interrupt time,by using a PhysToGDTSelector DevHlp call.

An alternative procedure for global access to memory is as follows -

In the INIT section of the driver, issue

DevHlp_AllocPhys
DevHlp_AllocGDTSelector
DevHlp_PhysToGDTSelector

This way you can setup access to the memory via the GDT.  Then the memory can
be accesses in all contexts.  You can use the MAKEP macro to convert the GDT
selector to a virtual address (16:16).

Ref :  For sample source refer to Ch-10, "Memory Mapped Adapter and IOPL",
section "access to adapter memory in interrupt handler".  In the sample in
place of 'board_address', you will have the physical address returned by
DevHlp_AllocPhys.  MAKEP macro is in drvlib.h given in Appendix - C listings.
Both of the above mentioned references are in "Writing OS/2 2.1 Device Drivers
in C", Steve J.Mastrianni.  This book is available online as part of DevCon
DDK V1.0

Also refer to source in ddk\mmos2\mmtoolkt\samples\audiodd\audiodd.c




!MULTIMEDIA_____________________________**********
May 19, 1995
QUESTION: (Ref HB0)
We are writing s/w to play WAV files on the MACPA card in order to understand
how the calls to the DD are made.  The call to DosDevIOCtl AUDIO_IOCTL_CAT
AUDIO_BUFFER (0x80 0x43) returns with 3. Where can I find out what the meaning
of the error codes are?


ANSWER:
Module Name: BSEERR.H  (ddkx86\h)
This file includes the error codes for Base OS/2 applications.




!STORAGE________________________________**********
May 19, 1995
QUESTION:  (Ref: HA6)
I am trying to write a Ring 2 DLL which provides access to a device on the PCI
bus, specifically a PCMCIA chip which is being used to generate a bus for a
digital cardcage system.  I do not understand all the implications of trying
to do that.

I have C code which tries to do OEMHLP IOCTL's to set PCI parameters and
eventually there will be an IOCTL to PMDD (probably) to request a linear
pointer to the memory mapped I/O at the 128 meg boundary which is supposed to
be mapped to this bus generated by the PCMCIA chip.

Then I will put in functions to actually transfer blocks of data to and from
the space; and that should be about it for the DLL.  So far I have once found,
quite by chance, the right combination of checkboxes in the zillions of CSET
setup dialogs for ICC and CLC Link so that the DLL actually compiled and
linked and I was able to call it from a test program.  Everything went fine,
including some printf's I threw in to see at what point it was going to crash,
until it hit the first IOCTL call.  That generated an exception.

Now I have lost the combination necessary to make it compile the DLL.  I think
last week I discovered I needed to edit the .mak file and put in some .lib or
another but I forgot which one.  I did use implib to generate a .lib from the
.def for the dll and I am linking that in with the test program.  The latest
error is "the operating system cannot run AISA" (meaning AISA.DLL).  I also
get a "no stack segment" warning when linking.


ANSWER:
1. The PCI Support is available on OS/2 2.11 only through a CSD.  Please
contact OS/2 Tech Support at 1-800-992-4777 to confirm whether or not you have
the CSD.  The PCI Support is also available on Warp.

2. The name of the device that you open with DosOpen should be 8 characters.

3. You can use the 'NMAKE' utility to build your DLLs.  You can refer to
Appendix - C in "Writing OS/2 2.1 Device Drivers in C" by Steve J. Mastrianni
for examples on creating DLLs with IOPL.  This book is available as part of
DevCon DDK V1.0

You need to allocate memory for the pointer OEMHlpPCIParameters1 before
initializing the members of the structure.  Similarly for OEMHlpPCIData also.
Then pass it as parameters to DosDevIOCtl.  This could also be a problem.

In the third and fourth DosDevIOCtl calls, you are initializing the members of
OEMHlpPCIParameters4 but passing OEMHlpPCIParameters1.




!VIDEO__________________________________**********
May 19, 1995
QUESTION:  (Ref: HA1)
I Cannot find source for PMDD or docs on its IOCTLs.  I need to allocate a 32
meg space at the physical address at the 128 meg boundary.  I was told at the
Presentation Drivers workshop that PMDD.SYS has this functionality.  In other
words, I can use an IOCTL to allocate and lock such a section of "memory"
(which the PCMCIA device will present as the interface to the memory-mapped
I/O on the bus which it is generating) and have this IOCTL return a linear
address which is directly usable as a C pointer.

I am trying to write a Ring 2 DLL which can then use that pointer to access
the memory-mapped I/O as well as do some PCI-specific initialization stuff
involving port I/O and OEMHLP PCI functions.  The DLL will probably simply
have three or so exported functions, INIT, READ, and WRITE.  I suspect that
IOCTL category 80h Function 0Bh (SCREENDD_GETLINEARACCESS) may be what I'm
looking for.

Under the "remarks" section in the pddref.inf, it says "If an application
requires access to a video aperture other than 64KB between A000 and BFFF, it
may obtain a linear address by way of this IOCTL."  That statement could mean
either "this ioctl can provide access to a video aperture with a size other
than 64K but it must still be between A000 and BFFF" or "this ioctl can
provide access to any size video aperture anywhere".

Q1. Which is it?

A1. Screen$ IOCTL 0x80,0xB can be used to allocate any physical memory size
into the linear address space.  If it is to be used by multiple processes,
atleast one (first one) would call the ioctl with flags MAP_PHYSICAL |
MAP_SHARED and all subsequent processes need to call the same IOCTL with
MAP_ATTACH flag in order to gain access to the same linear address.

The callers of the screen$ api have to be trusted to use the linear address
prudently as it obviously allows them to wipe out any chunk of the physical
arena they wish.

As described in the PDD reference, "remarks" section, if you read ahead, it is
mentioned that the physical address and the aperture size are limited only by
the adapter's memory mapping capabilities on a given system.
==============================================================================

Q2. Will I then be calling PMDD or SCREEN01?

A2. For SCREENDD_GETLINEARACCESS you would use SCREEN$.

IOCtl functions 7eh, 7fh are also supported by PMDD.SYS (SINGLEQ$).  7eh =
Allocate global VRAM 7fh = Access global VRAM

Ref:  Display driver reference, section "obtaining pointers to video memory"
(online version).  Also, you can refer to the function "GetVRAMPointer" for
using these functions in the display driver reference.  For usage of the
IOCtls, refer to the "setup and sharing of video RAM" section on display
driver reference.
==============================================================================

Q3. Will I get linear access to the whole 32 megs, unencumbered by 64K
boundaries?

A3. It is dependent on the memory mapping capacity of your adapter card.
==============================================================================

Q4. Where can I find out what else PMDD can do?

A4. The source code for the PMDD is not available on the DDK.
      GetVRAMPointer source is in the file eddefldb.c
      ddkx86/src/pmvideo/s3tiger
      ddkx86/src/pmvideo/32bit




!STORAGE________________________________**********
May 19, 1995
QUESTION:  (Ref: H94)
I am currently working on an ADD driver for a SCSI host adapter.  I have some
questions on scatter/gather support under OS/2.  Will each segment of
individual scatter/gather be Double Word aligned?  Is the starting transfer
address (i.e.  first S/G entry) Double Word aligned?

I know that OS/2 2.0 does not have double word boundary align but what about
OS/2 3.0?  These questions are extremently important for us to design a high
performance SCSI controller.  If double word boundary is not possible, the
hardware needs to spend a lot of overhead to handle it.


ANSWER:
You're correct, in OS/2 2.x there was no guarantee that each segment or
starting transfer address would be double word aligned.  Unfortunately, there
are no changes in Warp (OS/2 3.0) in this area.  It is not documented in Warp
because there are no changes.  The hardware should handle this and present
aligned addresses.




!VIDEO__________________________________**********
MAY 19, 1995
QUESTION: (Ref: H80)
I am looking for the source code for MONITOR.DLL and DISPLAY.DLL for OS/2
WARP.  I wish to modify the files to work in PAL resolutions.  The resolutions
I need to support are 640x576x16 and 800x768x16.  I didn't see source code for
these files on the DDK CD.  Do you know where I can get the code?


ANSWER:
The source codes for MONITOR.DLL & DISPLAY.DLL are not available on the DDK.
We don't make this source available.




!MULTIMEDIA_____________________________**********
May 19, 1995
QUESTION: (Ref: H78)
1. Can I have a sample .RGN file and instruction on how to hook it up to
vidvbc1.ini in \mmos2 ?

I have written a tv tuner/video capture driver, but can't enable the tuner
portion without the Video-In application complaining about Error 5143 =
Invalid Tuner Region.  After hunting around a bit, I found references to
\mmos2\region\*.RGN files.

2. Where is the install script to add .RGN files to a user's \mmos2\region
directory?  Do you have one handy?


ANSWER:
Yes.  If you install the Win/TV support under WARP you will get all the region
files...they will be placed in the \MMOS2\REGION subdir.  Here is the text
that seems to be in the WIN/TV setup page help.

CREATING A REGION FILE
__________________________________________________

A region file is an ASCII text file that specifies the frequencies of all the
channels in a region, starting with channel 0 and ending with the high
channel.  Region files ("region.RGN") are stored in the \MMOS2\REGION
directory.

The region file is keyword driven and has the following format:

       YTUNER"
           description=USA Cable
           lowchannel=2
           highchannel=99

           frequencies= 0, 0, 10050, 10150, -1, -1, -1, -1, 29000,
                        :
                        : (10 more rows of 9 entries)
                        :
                        30725

       Where :

       o   "description=" specifies a translatable string that
           is displayed on the setup page to identify the
           region.

       o   "frequencies=" specifies a list of channel frequen-
           cies, expressed in units of 10,000 cycles per second
           (10 KHz).  For example, 10050 is 10050 x 10,000 Hz,
           or 100.5 MHz.

           Frequencies with a 0 value are out of range.  If a

           frequency has a -1 value, the channel will be skipped
           when channel selections are made.

           All lines in the frequency list, except the last line
           in the list, must have 9 entries, and must end with a
           comma.

       o   "lowchannel=" and "highchannel=" indicate the range
           of channels for the particular region. The high
           channel must be greater than the low channel.

           Channel selections for the list of frequencies start
           with channel 0 and continue to the channel indicated
           by the "highchannel" keyword.  For example, if the
           low channel is 3, then 3 frequencies (for channels 0
           through 2) must be specified before the frequency for
           channel 3 is given.  Any number can be used for these
           unused values, but 0 is recommended.

           If there are more channels in the broadcast region
           than the value for the high channel, they will be
           unselectable.

 *************** Start of Sample Region file below *******************
 ; NLS: Translate ONLY the text to the right of description=
 Ytuner"
   description=USA Air
   lowchannel=2
   highchannel=69

frequencies= 0L,  0L,  5525L,  6125L,  6725L,  7725L,  8325L, 17525L, 18125L,
18725L, 19325L, 19925L, 20525L, 21125L, 47125L, 47725L, 48325L, 48925L,
49525L, 50125L, 50725L, 51325L, 51925L, 52525L, 53125L, 53725L, 54325L,
54925L, 55525L, 56125L, 56725L, 57325L, 57925L, 58525L, 59125L, 59725L,
60325L, 60925L, 61525L, 62125L, 62725L, 63325L, 63925L, 64525L, 65125L,
65725L, 66325L, 66925L, 67525L, 68125L, 68725L, 69325L, 69925L, 70525L,
71125L, 71725L, 72325L, 72925L, 73525L, 74125L, 74725L, 75325L, 75925L,
76525L, 77125L, 77725L, 78325L, 78925L, 79525L, 80125L

*************** End of Sample Region file above *******************


The Default Region File is USAAIR.RGN and Channel 3 with no finetune value as
I recall.  The WIN/TV setup page will change the default for the Win/TV card
by adding and changing the following line
PARMSTRING=REGION=USA,TVCHANNEL=29,FINETUNE=0 to the MMPM2.INI file under the
correct Digital Video device.


There is nothing special about the install .SCR file simply specify another
destination directory destindir="\\MMOS2\\REGION\\"=10 then specify the files
to copy

         /* Disk  Group Dest Source  Filename       comment   */
              0       1   10      0  USACATV.RGN
              0       1   10      0  USA.RGN
              0       1   10      0  CCIR.RGN
              0       1   10      0  CCIRCATV.RGN
              0       1   10      0  JPNCATV.RGN
              0       1   10      0  JAPAN.RGN
              0       1   10      0  AUS.RGN




!MULTIMEDIA_____________________________**********
May 19, 1995
QUESTION: (Ref: H61)
What are the steps necessary to compile an OS/2 Dev Driver that came with the
OS/2 DDK?  The driver is an audio driver for the Pro Audio Spectrum 16 sound
card.  I have tried unsuccessfully to compile it.  Since I am developing a
similar driver, I would like to use this audio driver to shorten development
time.

The driver is in dir ddkx86\mmos2\samples\pastk.  What do I need to do to get
masm60 and msc60 to run under OS/2?.


ANSWER:
You can find the required information on how to compile the PAS16 driver by
using the following procedure.

1. Goto the "USING YOUR DDK:" icon
2. "DDK ROADMAP"
3. "BASE BUILD STRUCTURE"
4. "MULTIMEDIA DRIVERS"
5. "PRO AUDIO SPECTRUM 16**

Also, be sure you have run the setup program for MASM and MSC6.  The setup
utility is located in DDKX86\SETUP\COPYASM6.CMD
                                  \COPYC60.CMD




!VIDEO__________________________________**********
May 19, 1995
QUESTION: (Ref: GR9)
I'm debugging the 32 bit XGA driver.  I tried to put a patch which requires me
to do a 'out dx, ax' where dx is 211ah, and ax is 0450h.  I put the code in
the file hwaccess.asm right before the line

        memregwrite     pixel_op, eax

        in the routine, CopyMemoryToVRAM.

While when I debug it.  The kernel debugger return me an error message
'displayharderror sys3175!'

My questions are:

1. What's the meaning of 'displayharderror sys3175'?

2. Where can I find the document about those hard error?

3. How can I do I/O in the display driver?  E.g. at the above place?

4. Where can I find the error code that returned by dosdevioctl, dosopen &
dosclose called?  I encounter an error code 6 returned by dosdevioctl and
error code 2 returned by dosopen during my patch experiment but I can't find
the meaning of the error code.


ANSWER:
1 & 2. To get details of "Displayharderror sys3175" type the following at the
OS/2 command prompt

        Help Sys3175 or
        Help 3175

3. The XGA PM Device Driver is written to run at Ring 3 and does not access
the XGA hardware directly.  All the XGA hardware access is handled by the Ring
0 Device Driver (XGA.SYS / XGARING0.SYS) which is the Physical DD packaged
with the product and which executes at Ring 0. The XGA PM DD uses a selector
obtained from the Ring 0 DD ( which maps the selector to the Memory Mapped
registers of XGA hardware ) via IOCTL calls for its access to the XGA Memory
Mapped registers for all its drawing operations.  This architecture improves
performance because no ring transitions in the protected mode is required
while accessing the XGA hardware.

In the hwaccess.asm you will notice two 'CopyMemoryToVRAM' routines.  One of
them is for the 8514 hardware and the other for XGA ( so you need to look in
the ifndef _8514 section).  As you would notice there is no direct I/O done in
this section of the code.

For any I/O access you need to do either of the following :-

i. Modify the Ring 0 XGA DD code (XGA.SYS/XGARING0.SYS) to add the I/O routine
you would like to have and provide an IOCTL interface to the Ring 3 XGA
Presentation DD.  So whenever the Ring 3 XGA Presentation Driver need to do
the specific I/O it could call the DevIOCTL interface.  ( If you are going to
use this I/O frequently .. you would have some performance overheads because
of the Ring transition and the DevIOCTL call overhead).  But your Ring 3
Presentation DD would be Ring 2 conforming and would be in line with the 32
bit Presentation DD architecture.  (Ref "Introduction to OS/2 Presntation
Drivers "- Chapter 1 of Presentation Driver Reference.)

ii.  Place the code required to do the I/O in a seperate segment with IOPL
privilege and link the code with the rest of your XGA presentation DD
code.This option also has an overhead of a ring transition (Ring 3 to Ring 2)
but slightly less performance overhead than option i. But this would not
strictly conform to the 32 bit Presentation DD architecture of having the
Presentation Device Driver as Ring 2 conforming.

4. Look at the file BSEERR.H on the DDK.  This file includes the error codes
for Base OS/2 applications.

CONCLUSION:  Finally I got it!  I patched my patch.  What I did is comment out
the dosclose(ring0_handle) called in the eddefpdb.c file so that the
/DEV/$$$XGA20 is always openned as ring0_handle.  In that case, my dosdevioctl
can always communicate with my ring0 I/O access routine.




!STORAGE________________________________**********
May 16, 1995
QUESTION: (Ref: HE4)
I'm looking for information about IFS programming.  I ordered the Developer
Connection Device Driver Kit for OS/2 and found absolutely NO information
about IFS.

I joined EMEA DAP to scan their BBS and I searched the D.U.D.E.  and I found
several files.  But those several files are really just 2 or 3 packs in
different (OLD!)  versions.

1. Is IFS Development some kind of secret to be locked away from public????

2. Is IBM not interested in IFS Development?


ANSWER:
Other than what you found on the DUDE BBS, this is all that we have to offer
on IFS information.  However, if you have any IFS related questions/problems,
you can post them on the DUDE BBS and we will forward them to development.




!OTHER____________________________________**********
May 16, 1995
QUESTION: (Ref. HC2)
To debug my physical device driver, I use a 2nd screen ( monochrome MDA).  I
directly access to the Monochrome memory area (physical address:  B0000).  In
OS/2 2.1 it works fine, I can see messages on my monochrome screen.  In OS/2
Warp 3.0 i can't see anything.

1. WHY does the following SOURCE CODE EXAMPLE work only on OS/2 2.1?
2. What do I need to change to make it work on OS/2 Warp 3.0?

SOURCE CODE EXAMPLE

 #define SCR_BASE_MONO 0xB0000L

 void my_printf_on_the_monochrome_screen(void)
 {
   char far *scr_ptr;
   char debug_message[31]="hello on the monochrome screen";
   short i;

   rc=DevHlp_PhysToVirt((PVOID)SCR_BASE_MONO,(unsigned long) 0x1000, &scr_ptr);
   for ( i=0 ; i<31 ; i++ ) *(scr_ptr+i)=debug_message[i];
 }


ANSWER:
With a monchrome screen in OS/2 WARP you need to add outp(3b8,0x29) to
validate monochrome screen.  This was not necessary in OS/2 2.1.




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref: HA3)
1.25MB of memory is needed to be allocated and locked into contiguous physical
address space.  The Linear Address of PhysAddress is passed to VMAlloc and
when the requested memory is fixed and contiguous, the Linear Address is
passed back in &LinAddress and the Physical Address is passed back in
&PhysAddress.  So at this point a 1.25Mb buffer is contiguous
(flags=0x0000000a) and fixed.  How do I give memory access of this buffer to
the application.  Should VMGlobalToProcess be used in this case?  And if my
application is running in a thread of another application, will that app also
have access to this buffer?


ANSWER:
You can use VMGlobalToProcess devhelp to map the global address space to the
process address space.  You can have an IOCtl interface between the DD and the
application so that you can pass the address to the application.  For the
usage of the call (assembly version) refer to
ddkx86\src\dev\screendd\svgarout.asm

If a process - A is running in a thread of another process - B, and process -
A maps the same memory to its own space then both processes will have access
to the same global memory.  You need to synchronize the memory access between
the two processes.

If you set bit 5 (100000b) in VMAlloc then the address returned will be in the
process address space and no special work is required to access it from the
ring 3 app.




!GENERAL________________________________**********
May 16, 1995
QUESTION: (Ref: H91)
We would like to be able to utilize a Windows VxD under Win-OS/2.  Is this
possible?  The VxD communicates directly with the parallel port so we
recognise that OS/2 won't be able to print.  We need to do this as a
demonstration only.  We've tried this with WARP for Windows.  It has also been
tried by booting a VM and then loading regular Windows.  None of this seems to
operate.


ANSWER:
I found various information concerning Windows VxD's with OS/2.
Unfortunately, none of it is very supportive of what you are trying to do.
The information was found in various OS/2 Books.
==========================================================================

From Application Considerations
                Incompatible Programs

The following identifies categories of programs that do not work correctly
with OS/2:

WIN-OS/2 does not support real mode programs.  Also, Windows enhanced mode
programs that load specific Windows Version 3.1 virtual device drivers (.386
or.VXD) will not run in WIN-OS/2 enhanced compatibility mode.  This mode uses
an unsupported method.  However, some of these programs will run in WIN-OS/2
standard mode.  To run programs, set the WIN_RUN_MODE setting to Standard.
==========================================================================

From OS/2 Frequently Asked Questions List (FAQ)
        (0.4) Special Report on OS/2 for Windows

Will OS/2 for Windows support "seamless" mode?  Enhanced mode?  VxDs?  Win32s?

...Vxds, or Windows virtual drivers, are not supported while executing under
OS/2 for Windows and, by implication, neither is Win32s.  Only a tiny number
(four at last count) of applications require one or both of these features.
(Microsoft NT, in fact, does not support VxDs at all.)  Again, OS/2 for
Windows preserved an existing Windows 3.1 setup, so such applications, if
absolutely necessary, can be run under DOS/Windows.  On the other hand, OS/2
for Windows allows Windows users to run any of the thousands of OS/2
applications available (none of which are available to users running DOS with
Windows NT, or any other environment except OS/2).
==========================================================================

From Technical Information
        Technical Qs & As
             OS/2 2.x/3.x Technical Qs & As
                  OS/2 Installation/Compatibility Qs & As
                       OS/2 2.x/3.x General Installation/Compatibility Qs & As

Q. Because OS/2 for Windows uses actual Windows 3.1 code, does this mean that
I can use Windows applications that use Virtualized Device Drivers (VxD's)?

A. No.  Just as OS/2 for Windows provides all the function of the full-pack
code, so does it include the same limitations, and VxD's would violate the
integrity of the operating system if allowed to run under either form of OS/2.
Still, because an OS/2 for Windows system is by definition a dual-boot system
(and optionally set up for Boot Manager as well), you may boot to DOS/Windows
and run your VxD apps as you would on a DOS/Windows-only system.




!BASE___________________________________**********
May 16, 1995
QUESTION:  (Ref: H88)
Is there a hardcoded limit on the number of devices a driver can support?  Can
I support as many devices as I have memory for device headers?

Presently our device driver supports 256 RS-232 ports.  I was under the vague
impression that this was some magic number but could not really find any
references to this.


ANSWER:
The number of devices supported is constrained only by the available memory.
The Device Header is contained in the First 64K Data Segment.  If your headers
fillup the first Data Segment, you could have multiple data segments as
dicussed in the PDD Ref., Chapter-PDD Architecture & Structure, Section-PDD
Programming Model.

Theoretically, there would be no constraint on the number of headers your
driver could support.  It is the memory which is the real constraint.




!BASE___________________________________**********
May 16, 1995
QUESTION:  (Ref: H86)
I am working on a device driver and service (daemon) that provides control
functions to other systems residing on a shared VME bus.

The system has 2 megabytes of dual ported memory that needs to be reserved for
our purposes (not available to OS/2).

I have been able to utilize a linear address handle to physical memory by
having the device driver VMAlloc() a linear address and passing back to the
client service via IOCtl().

My question is, how does the device driver "reserve" physical memory from
OS/2?  In other words, the physical memory needs to be dedicated to our
purpose and addressable from the device driver and service.  Is this what
VMSetMem() is for?


ANSWER:
VMSetMem commits/decommits physical storage.  During VMAlloc, if the
VMDHA_RESERVE flag option is set then virtual memory is only allocated but not
mapped.  So, if an attempt is made to access this uncommitted memory then it
results in a GPF.  So VMSetMem is used to commit (system maps the pages to
physical/swap memory for backing that page) the memory.

If you are using WARP, you can reserve memory by using the resource manager.
For details refer to RMBASE.INF, section on "reserve.sys".  The resource
manager documentation (RMBASE.INF) is available on the DUDE BBS (RMBASE.ZIP in
the Main file area).




!BASE___________________________________**********
May 16, 1995
QUESTION: (Ref: H83)
I am interested in using a call to DosDevIOCtl2.  In the application program
one passes not only the VALUE of the Data/Parm buffer maximum permitted
lengths, but also the ADDRESS of current lengths of those buffers.  This leads
me to believe (hope?)  that there should be a way to pass back info to the
calling APP about just how many bytes of data were placed in these buffers.
The desired functionality is kind of a network packet deal:  the app makes a
custom IOCtl2 call with maximally sized data and parameter buffer sizes.  The
driver places what it can in the buffers and needs to let the app know just
how many bytes it placed in each buffer.

Can I do it or do I need to break it all down to reads and writes on each
packet one at a time?


ANSWER:
The action you desire cannot be accomplished as you describe it.  I recommend
that you control the data transfer yourself.




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref: H82)
I am using the IBM DEVCON WIN-OS/2 and OS/2 process message interchange
virtual device driver example.  I am encounting several problems.  After
calling the Virtual Device Driver DOS API entry point, I get this entry point
from INT2F serv 4011H, OS/2 either gets an exception or hangs.

The example that I have does not provide the code for the DOS side to make the
call to the VDD.  I am trying a couple of things and referencing the VDD
manual but it does not help.

The compiler to compile the VDD is OS/2 2.1 C/C++ and the version of the
TOOLSKIT is 2.1.  The DOS test program is compiled under WATCOM C/C++ v10 and
it is a 16 bit application.

In addition, I have tested the OS/2 side for this VDD.  I have looped back the
message send from an OS/2 process to itself.  Now I am trying to make a call
from DOS to VDD as my next step.

Q1. Am I allowed to make this service call, Int2f 4011H, get the DOS API
entry point and call this entry point from a DOS (real or Protected) session?

A1.  Yes, you are allowed to make the service call Int2f 4011h from your dos
program running in the DOS Session of OS/2.  Ref:  VDD Reference, study the
VDHRegisterAPI C language virtual Devhlp service for details and parameters.
==============================================================================

Q2. Could I have a C or Assembler coding example to make this call?

A2.  Refer to /ddkx86/src/vdev/vtouch/vthook.c for sample code.  Refer to the
VTDOSLink V86 API Hook routine.  You need to take proper care of the client
stack using the client register frame-PCRF.

To check if the VDD has registered the V86 hook routine, once the DOS Session
is created, run DEBUG.COM.  Use the Assembly command of DEBUG and do the
following:

      - A
      mov si,1000
      mov  ax, 4011
      int 2f
      int 3
      - E 1000 "Name of VDD"
      - G (start execution of code.. the code will break due to int 3).
      - r (use register command to check values of es:di).

If es:di is OK, it means the VDD has registered the V86 API Hook properly.  If
your code still hangs after doing the suitable modi- fications as suggested in
the VTHOOK.C sample, then check if you are making a far call to the address
returned in es:di for the V86 API Hook entry point.
==============================================================================

Q3. How can I make the virtual device driver (OS/2) call back to a DOS
function?  (i.e.  32 bit VDD call back either a 16 or 32 bit DOS function.)

A3.  You could use either of the two following DevHlp calls in your VDD code
to call back DOS routines.

      - VDHPushFarCall (Refer to /ddkx86/src/vdev/vtouch/vthook.c
         & Vtint7f.c samples)

      - VDHPushInt (Refer to /ddkx86/src/vdev/vkbd/vkbdint.c
        /ddkx86/src/vdev/vvideo/vvmode.c for sample code).




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref: H77)
I want to develop a device driver which must access the memory mapped
registers of a PCI card (base address is placed in the pre- defined header of
the PCI configuration space).

Q1. In which way must I process the base address to modify the memory mapped
registers?

A1. You can use the VMAlloc dev help call for mapping the adapter registers
to the global space.  For details of the call, refer to the section on "device
helper services" in the PDD ref.  You can also refer to sample code in
"Writing OS/2 2.1 device drivers in C" by Steve J. Mastrianni, App-C, "device
driver for memory mapped adapter".  This book is available as part of DevCon
DDK v1.0
==============================================================================

Q2. On what peculiarity must I pay attention?

A2. You need to be careful while using the "flag" parameter in the VMAlloc
call.  You can map the base register address then access the other registers
by adding the appropriate offsets.  VMAlloc returns a linear address and you
need to convert this to a virtual address to use it in your driver.  For this,
you can use the LinToVirt dev help call.
==============================================================================

Q3. Are there any source code samples on this topic?

A3. See reference to Steve Mastrianni's book in the first answer above for a
source code sample.




!I/O____________________________________**********
May 16, 1995
QUESTION: (Ref: H66)
I developed a Pen for OS/2 device driver for my customer a couple of years ago
under OS/2 V2.1 and Pen for OS/2 V1.0.  This driver seems to still function
properly as a Pen under Warp; and so far as I know it should not require a
rebuild.

However, my customer has successfully used the same driver as a
device-dependent mouse driver under previous versions of OS/2 and this does
not work under Warp.

Does the Mouse.Sys driver shipped with Warp support a Pen device driver using
the TYPE= parameter on the config.sys line?

The device independent Mouse driver does not complain during initialization,
but the VMOUSE fails to load.  If I try to run without VMOUSE (assuming I
don't care about DOS FS sessions), the POINTDD driver doesn't load - there is
no error msg (and no cursor either).  I believe that when they run the Pen
driver as a mouse under the old version of OS/2 they disable VMOUSE.


ANSWER:
The mouse device driver mouse.sys accepts TYPE, STYPE command line options.

The TYPE= keyword tells mouse.sys (which is the device independent driver) the
name of the device dependent driver.  Refer to the I/O driver Reference,
Section on mouse pdd.

The STYPE= keyword allows a secondary pointing device to be attached to the
system.  Refer to ddkx86\src\dev\mouse\init.asm.

Try adding the following lines in your config.sys to solve your problem.

   device= <your driver file>
   device= ($PATH)\mouse.sys TYPE=<your driver name (as in device header of
                                   your device driver)>

This STYPE is for a secondary device dependent mouse driver.  For example, if
you had a serial mouse with the 8516 touch monitor both the PDIMOU$ and
SERIAL$ mouse drivers would be needed.  One as a TYPE= and the other as an
STYPE=.




!I/O____________________________________**********
May 16, 1995
QUESTION: (Ref: H59)
I am looking for more information on the following undocumented mouse
parameter I came across while writing a digitizing tablet device driver for
OS/2.  It appears that MOUSE.SYS supports an undocumented parameter, STYPE, as
in the following config.sys statements:

       rem
       rem *** tablet.sys has device name TABLET$ in its header
       rem
       device=c:\driver\tablet.sys  SERIAL=COM1
       device=c:\os2\mouse.sys      STYPE=TABLET$

This parameter seems to behave identically to the TYPE= parameter described in
the OS/2 online help except that MOUSE.SYS will also initialize and support
any mouse it finds on the mouse port.  IE:  there can be 2 pointing devices
working at the same time !!!  (in this case a mouse on the mouse port and a
digitizing tablet on the serial port).

Is there documentation (official or otherwise) to describe the use of this
parameter, as well as hints or caveats for the programmer who needs to use it?
Will this feature remain in future releases of OS/2 for support of multiple
pointing devices?


ANSWER:
STYPE is for a secondary device dependent mouse driver.  For example, if you
had a serial mouse with the 8516 touch monitor both the PDIMOU$ and SERIAL$
mouse drivers would be needed.  One as a TYPE= and the other as an STYPE=.
There is no documentation available and there is no guarantee that it will be
supported in future releases.




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref: H56)
I need to know how to examine my data with the Kernel Debugger.  The debugger
reports that the symbol table for my driver is successfully loaded but how do
I reference it?  How do I find out where my data is, view it and manipulate
it.  The documentation for the Debugger does not cover this.

I need to be able to write SHORT, SIMPLE OS/2 programs which test the various
API functions that I develop.  ie:  OPEN, CLOSE, READ, WRITE etc.  I do not
want these test programs to be full-blown OS/2 desk top applications.  I would
like to just run them from the OS/2 command line and print the results to the
text screen - the old fashioned way.

Do you have a very simple template program that would provide me with what I
need?  - Something that can accept keyboard input and print text output to the
screen.

I need to know which MicroSoft C libraries and header files I should and
should NOT use in a program of this sort.


ANSWER:
Symbols are displayed using KDB commands such as DW,DB or DD.  Use these
commands along with the symbolic names preceded by the underscore "_" if the
symbolic names are part of a "C" file to display the symbolic variables.  Once
the address of the variables are known in the display data provided by the KDB
you could use other commands like Enter data command (E) to modify and
manipulate data.  Only those PUBLICS which are listed in the MAP files could
be referenced from your Kernel Debugger with their symbols.The disassembler &
the 'bl' command also displays address symbolically if the symbol exists for
the address.  Refer to Chapter 13 in the book "Writing OS/2 2.1 Device Drivers
in C" by Steve Mastrianai and the Online Debug Kernel Reference (both are
available in the DDK v1.0).

The other alternatives you could consider are Debugo (a friendly interface for
the Debug Kernel) and Periscope for OS/2 - which is a Source Level debugger.

As far as setting small testing programs you could refer to some of
Mastrianni's Sample Programs in his book (mentioned above).

For Microsoft C you could use similar C function calls defined in the
SLIBCEP.LIB library files.  Since the start up code is being replaced by your
own, some of the Library Functions might not work.  You would also have to use
OS/2 libraries such as OS2286.LIB.  The Header files will depend on the
functions that are being used.  These are available on the DDK - DDKX86\H
Directory.




!I/O____________________________________**********
May 16, 1995
QUESTION: (Ref: H53)
I am writing a device driver for some specialist AT-bus controllers that do
bus master DMA transfers.  The problem is that the DMA transfers are extremely
long (potentially up into the megabytes) and, because of the nature of the
hardware, cannot be broken down into smaller chunks.

In the absence of I/O map or scatter/gather hardware, the memory buffer must
occupy contiguous physical addresses.  Because of the large quantities of data
involved, it is not feasible to buffer it in kernel memory and copy it into
the process's memory afterwards.

Another complication on modern machines is that the buffer must be below 16
Mbytes to be addressable by the AT-bus controllers.

What I did under UNIX was to implement a pseudo-device driver, which allocated
a big chunk of contiguous memory at boot time, effectively taking it out of
the general memory pool, and then managed it for client programs.

A program wishing to use the memory would open a "channel" to the driver,
issue an IOCTL to get the physical base address, and then map it into the
process's address space.  Other IOCTL's then provided malloc/free type
functions to allocate buffers, which could be passed to the actual device
driver for the AT-bus controllers.

During an initial scan through the DDK CD, I found the DevHlp routine VMAlloc,
which looks like it could possibly form the basis for a similar pseudo-device
driver approach.

Q1. I guess the question is whether this really will do what I want.  Will
VMAlloc be happy to allocate as much as, say, 4 Mbytes of contiguous physical
memory below the 16Mbyte boundary?

A1. Theoretically, it is possible to get up to 4 Mbytes of contiguous memory
below the 16 MB boundary.  Refer to DevHelp function VMAlloc in the PDD Ref.
Use Flags value as VMDHA_16MB, VMDHA_FIXED, VMDHA_CONTG in the VMAlloc Flag
parameter.  The success of the call depends on factors like Max Physical
Memory in the system, Max Disk Swap space and number of Device drivers and
applications running in the system at the time the VMAlloc call is made.
Refer to VMAlloc DevHelp function in PDD Reference Manual.  (I was able to get
only 1MB contiguous memory on my 20 MB PS/2).
==============================================================================

Q2. Can the memory thus allocated be mapped into the virtual address space
of both the pseudo-device driver and one or more OS/2 processes, and used
like any other memory? Including passing it as a buffer to another device
driver?

A2. The memory allocated can be mapped into the virual address space of one
or more process and used like any othe memory.  Ref:  VMGlobalToProcess
DevHelp function in PDD ref manual.  You can pass the buffer allocated to
another PDD using IDC interface provided by OS2.  Ref:  Inter Device
Communication in PDD Reference.
==============================================================================

Q3. Is there a way for an OS/2 device driver to check whether the buffer
passed is actually contiguous in physical memory?

A3. There in no way for the OS2 device driver to check whether the buffer
passed is actually contiguous in physical memory.
==============================================================================

Q4. And is a pseudo-device driver for the contiguous memory the best approach
under OS/2, or is there a better way?


A4. Your approach of pseudo device driver for the contiguous memory is one of
the best approaches under OS2.




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref: H45)
Q1. Is there a complete listing somewhere for ALL names to use in a DosOpen?
e.g.  SCREEN$, COM1, etc..  What name do we use for the CPU calls, such as
asking how much memory is on the machine?

A1. To get the names of all drivers installed in a system, you can either -

   (a)  Use a utility called DDINFO.EXE. For using this you need to
        install a driver called DDINFO.SYS. These utilities are not
        part of DevCon DDK.IBM Internals could use OS2TOOLS to access this
        utility.

   (b)  If you have kernel debugger (KDB) installed in your system then
        issue .d dev nuldev command, then chain thru the linked list of
        installed drivers via the next driver field (of the driver
        header).

To know how much memory is present in the system, you can use the OEMHLP IOCtl
call, function 09h (query memory info).  For details refer to Appendix-D of
"Writing OS/2 2.1 device drivers in C", by Steve J. Mastrianni.  This book is
available online in DevCon DDK V1.0

You could also use DosQuerySysInfo.  This is documented in the Control Program
Programming Ref.
==============================================================================

Q2. It appears that disk calls only address the drive, not the type of
diskette currently mounted.  How can we query the diskette type?

A2. Determination of media change is not possible from the application. You
need to develop a PDD from which you can directly read the appropriate
register and pass the results to the application via a IOCtl interface.

To determine whether a disk is write protected, issue a write ioctl function
44h category 8 and check the return value.  If you are getting the value 19
(ERROR_WRITE_PROTECT) it means diskette is write protected.  THIS IS A
DESTRUCTIVE TECHNIQUE.  There are no other IOCtls to determine this.
==============================================================================


Q3. Media sense (60h) always returns a 0 (indeterminate) no matter what kind
of drive is present...even on one which supports 'media sense'.  Please
explain.

A3. Media sense works correctly. You can verify with the following sample code.

    UCHAR cmd, media;
    rc = DosDevIOCtl( (PVOID) &media, (PVOID) &cmd, (USHORT) 0x60,
                      (USHORT) 0x08, (HFILE) dhandle);

The "media" will give the media sense information.
==============================================================================

Q4. Found out that the track write/reads for a 1.44 disk (18 sectors) RUNS on
a 720 disk??  Something is amiss.  IOCtl 63h identifies disk as type 7 (other,
incl.  1.44) and attrib 6 (removable, changed, >16MB).  ON BOTH 1.44 and 720K
disks!  Function 60h Media sense always returns a 0, media can't be
determined.  A 360K disk is reported type 1 (1.2M) and attrib 6. Media sense
always returns 0.

A4. For track read/write you could use IOCtl functions 64h & 44h, respectively.
Refer to the PDD Reference, Chapter 10, Section on "Generic IOCtl Commands".
Use the 16-bit IOCtl Interface as used in the above code.
==============================================================================

Q5. What call is necessary to find out what kind of video is present (VGA,
XGA, etc.)?

A5. From the command line you could use qsystem.exe which is in ddkx86\tools.
You could also use the OEMHLP IOCtls and the Screen IOCtls (Category 80h).
Refer to the PDD Reference - Generic IOCtl Commands.
==============================================================================

Q6. We'd like to have a coding example showing the DevIOCtl call along with
the DosOpen and the precise parameters for each.

A6. Please try the following code to Query Device Parameters. This code was
written in Microsoft C v6.0. Link SLIBCEP.LIB & DOSCALL.LIB. Refer to
\ddkx86\h\sysbloks.h for BPB structure.

 /******Sample Code to Query Device Parameters Cat. 8 Fn.63 IOCtl **********/
#pragma pack (1)

#define APIENTRY        far     pascal

typedef unsigned short  APIRET;
typedef unsigned long   ULONG;
typedef unsigned short  USHORT;
typedef void far        *FARPOINTER;
typedef void            *HFILE;
typedef void            *PVOID;

USHORT  APIENTRY DosDevIOCtl( FARPOINTER, FARPOINTER, USHORT, USHORT,
USHORT );
USHORT  APIENTRY DosOpen(FARPOINTER, FARPOINTER, FARPOINTER, ULONG,
USHORT, USHORT, USHORT, ULONG);


#include <stdio.h>
#include <stdlib.h>

void main()
{
  APIRET rc;
  USHORT handle;
  ULONG  action;

  struct x
  {
  unsigned bytes_per_sector;         /* sector size                  2 */
  unsigned char sectors_per_cluster; /* sectors per allocation unit  1 */
  unsigned reserved_sectors;         /* number of reserved sectors   2 */
  unsigned char nbr_fats;            /* number of fats               1 */
  unsigned root_entries;             /* number of directory entries  2 */
  unsigned total_sectors;            /* number of sectors            2 */
  unsigned char media_type;          /* fatid byte                   1 */
  unsigned sectors_per_fat;          /* sectors in a copy of the FAT 2 */
  unsigned sectors_per_track;        /* number of sectors per track  2 */
  unsigned number_of_heads;          /* number of heads              2 */
  unsigned hidden_sectors;           /* number of hidden sectors     2 */
  unsigned reserved_1;               /*                              2 */
  unsigned large_total_sectors;      /* large total sectors          2 */
  unsigned reserved_2;               /*                              2 */
  char reserved_3[6];                /* 6 reserved bytes             6 */
                                     /* total byte size = 31     */

  unsigned short   cyln;
  unsigned char    type;
  unsigned short   attr;
  }databuf;

  struct y
  {
    char cmd;
    char unit;
   }parambuf;


  handle=0;
  rc=DosOpen("A:",&handle,&action,0L,0,1,0x80c2,0L);
  if (rc != 0)
  {
     printf("Device Open Error %d\n",rc);
     exit(0);
  }  /* endif */

 printf("Device Handle =%d\n",handle);
  parambuf.cmd = 1;
  parambuf.unit = 0;
  rc = DosDevIOCtl( &databuf,
                    &parambuf,
                    (USHORT) 0x63,        /* Function */
                    (USHORT) 0x08,        /* Category */
                    handle);
  if (rc != 0)
 {
     printf("IOCtl Error %d\n",rc);
     exit(0);

 }  /* endif */

printf ("No.of Sectors=%d\n",databuf.total_sectors);
printf ("Media =%x\n",databuf.media_type);
printf ("Device Attributes = %d\n",databuf.attr);
}




!I/O____________________________________**********
May 16, 1995
QUESTION: (Ref. H41)
I notice that the ddk mouse code get version function does nothing.  It is
fully commented and explains the functionality but the code for this function
is a single assembler statement - ret.  Can you establish which mouse IOCTLs
are meant to actually do something?


ANSWER:
IOCtl Function 6ah is the only IOCtl which is not functional.  All the other
IOCtls - work as documented in the PDD Ref.  A defect has been opened for the
Function 6ah and should be fixed by the next release.  Meanwhile, you could
modify the code available in the DDK in the IOMR_GV Routine to return the
Version Information as documented in the PDD Ref.




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref. H16)
One of our Porting Clients has a requirement to disallow user access to OS/2 -
sealed app only.  This wasn't too difficult before the ALT F1 boot breakin
facility was added to WARP (wonderfully useful though it is).  Does any one on
the team know of a way to disable this feature?


ANSWER:
If you erase \OS2\BOOT\ALT*.* then the ALT-F1 feature will be disabled.  If
the user presses ALT-F1 when the white block and OS/2 is displayed in the
upper left hand corner, an error message will be displayed.  The error message
cannot be eliminated without kernel changes, but you'll only get the error IF
someone presses ALT-F1.  Shouldn't be a big issue.




!OTHER__________________________________**********
May 16, 1995
QUESTION: (Ref: H03)
Q1. Where might one find info on making a driver behave with the system trace
utility?  What are the formats of the .TDF and .TFF files in the
/os2/system/tracesubdirectory?  What utilities are available for end-users
and/or sys-administrators to enable/disable tracing, view trace logs...etc.?

A1. Have you looked at the Dynamic Trace Customizer on the Devcon DDK v1.0?
If you have not please do so and let me know if it contains what you are
looking for.  Otherwise, let me know what it is lacking.
==============================================================================

Q2. Ok, I found the trcust pkg.  and things look pretty nice, actually with
the exception that I do not seem to be able to get the formatted output part
to work with @STATIC tracepoints.  The TFF file is generated OK, but TRACEFMT
complains that it is invalid and the tracedata (sent by the driver via the
SysTrace DevHelp call) is just unformatted hex bytes.  Is there any way to
specify how to pick appart the various pcs.  of a structure that arrived in a
trace buffer from driver?

I only see examples of printing a register and/or flags value in a @STATIC
trace point definition.

A2. I am assuming you are on Warp and you get no warnings creating your TFF
file with TRCUST.  You stated that Tracefmt complains about the TFF file, what
do you mean by this?  Does the DESC description entry (in the TSF) display in
Tracefmt for the major/minor codes?  Since you are getting the data in hex, it
seems Tracefmt cannot find your TFF file for the major code.  TFFs should be
in the \os2\system\trace directory.  As far as the trace structure coming from
the kernel trace buffer, I would have to research this.
==============================================================================

Q3. I am assuming that you are on Warp and you get no warnings creating his
TFF file with TRCUST.

::correct.

You stated that Tracefmt complains about the TFF file, what do you mean by
this?

::if the buffer I pass to SysDevTrace (DevHelp call) is not precicely a
  null-teminated string of the correct count then TRACEFMT complains that
  the TFF file has an invalid format.  I suppose this is fine, since
  the FMT= statement I have in the TSF file is "%s".

Does the DESC description entry (in the TSF) display in Tracefmt for the
major/minor codes?

::yes.

Since you are getting the data in hex, it seems Tracefmt cannot find your TFF
file for the major code.  TFFs should be in the \os2\system\trace directory.

::Correct.  It is.

As far as the trace structure coming from the kernel trace buffer, I would
have to research this.  I know of someone who worked with this area who may
possibly be able to look at the problem.  However I believe you would be
happier if you could get Tracefmt to format your tracepoints verses having to
decode the kernel trace buffer.

::My problem is that the buffers I want to pass up are variable lengths so
  want to make statements in the TSF file like:

 MINOR=0x12, TP=@STATIC
 DESC="location 12 in WRITE routine dealing with variable len data buffer:"
 FMT="data buffer looks like: %U"
 LEN=(some specification that the first 4 bytes of the trace buffer gives
      the length of the data to follow)
 MEM=(some specification to agree with above LEN)
 ...several statements like this as what I am sending in the trace buffer
    is more like a "chain" of a sequence of buflen,bufdata:
         struct {
                 ulong   len;
                 uchar   stuff[len];
                 } many[];

:: as in interim solution what I am doing is sending one element only of this
   structure up at a time to SysDevTrace which appears to work OK..  That is,
   the length of each buffer is implicit as the length of the trace buffer.

   What would be MUCH nicer would be a way to use the MEM= and LEN= facilities
   described in the sections of the TSF file where TP={not @STATIC).  Infact,
   the reason I use the @STATIC statement is just that in the case of a
   driver, it appears that TRCUST does not insert tracepoints in the
   executable module.  Even though when I use TRCUST like that -- giving it
   the name of my MAP file (MSC 6.00) -- it seems happy.  So is TRCUST
   supposed to be actually modifying the executable or only marking the
   locations somehow; which locations are "broken on" then when hit and
   the trace record generated ??  I'm not clear on this.

A3. It sounds like you want to do something that is not implemented in
static tracing. Static tracing only allows the key words: DESC, MINOR, and
FMT to preside in the definition of the tracepoint. MEM/LEN combinations are
used in dynamic tracing only.

It sounds like you are doing the correct thing by sending one structure of
len, data at a time to the trace buffer.  I know of no other way to handle
this via static tracing.  Since static tracing is a debugging tool and
performance is not a great concern compared to the overall objective, doing it
this way seems acceptable.  Perhaps you may want to implement dynamic tracing
to obtain the results he desires.  Dynamic tracing does not hinder performance
when the trace is not activated on the specified module.

You are correct, TRCUST does not insert tracepoints into the modules.  TRACE
modifies the exe upon load for dynamic tracing according to the TDF generated
by TRCUST.
==============================================================================


Q4. Ok, so I should try to use Dynamic Tracing.  Dynamic tracing though only
"modifies the exe upon load" as per the TDF file.

Does this mean that Dynamic tracing is NOT possible with a device driver that
is loadef from the CONFIG.SYS?

This is my conclusion since I have tried to implemnt dynamic tracing on my
driver as well and though TRCUST happily produces TFF and TDF files from it
without any error messages, no tracing occurs.  SO if it is in fact true that
the DYNAMIC tracing only works with DLL's but NOT with drivers then I suppose
@STATIC is the best one can do..

A4. You correct.  Device drivers can only use static tracing due to
restrictions at Ring 0.




!VIDEO__________________________________**********
May 10, 1995
QUESTION: (Ref: HB9)
I find I'm still confused about some basic points about getting access to
hardware registers, such as the one that gives me the address of our
memory-mapped register area -- including the address of the video aperture.

The sample sources that I've seen in the DDK either get the physical address
by hardcoding it (A000) or by using a custom PDD (XGA.SYS, etc.).  What I'm
hoping to do is avoid using a custom PDD, but use SVGA.EXE/PMI/BVH to do the
mode get/set, and modify SCREENDD as little as possible for the rest.  Our
hardware uses a memory mapped register space, which means I should have to do
very little in the way of real register I/O.  However, I do have to read a few
registers (including the one that tells me where the memory mapped register
area begins).

I'm looking at the SCREENDD IOCTL to return manufacturer-specific adapter data
(IOCTL fn 9).  I'm planning to add code to the SCREENDD processing of this
IOCTL, to do some register I/O and fill in a few register addresses as part of
the manufacturer data field of the OEMINFO data structure (the packet returned
by the IOCTL).

Does this seem reasonable?  Are there limitations on how big the manufacturer
specific data can be (I see that Diamond uses it only for BIOS revision data,
and Orchid uses it only for MCA slot number)?


ANSWER:
Your approach to get address of memory mapped register area looks to be OK.
Screen Control IOCtl function 09h can be used to provide additional data to
applications and system that is unique to a specific adapter.  Currently the
packet length field of the data packet format is 10 bytes.  The manufacturer
specific data is a DWORD field.

By modifying the SCREENDD source you can add code for IOCtl function to return
the address of memory mapped register area.

The only disadvantage in increasing the Data Packet would be incompatibility.
But, then you could have your own private IOCtl interface.




!OTHER__________________________________**********
May 10, 1995
QUESTION: (Ref: H92)
I am wondering if it is possible to write a physical device driver using the
IBM C/C++ v2.0 compiler.  I cannot find any documentation on this.


ANSWER:
IBM C/C++ v2.0 is a 32-bit compiler.  Physical device drivers arw 16- bit.
Therefore, you can not use it to build a PDD.  If you goto the "Components and
Build Requirements" section on the DDK (using your ddk icon), you will see the
what components are needed to build device drivers.




!OTHER__________________________________**********
May 10, 1995
QUESTION:  (Ref: H75)
Although a Robot Controller card is the only device installed in the system on
IRQ 2, when I issue the DevHelp_SetIRQ call, OS2 returns IRQ not available.
What does OS/2 think it has installed on IRQ 2?


ANSWER:
In OS/2, IRQ 2 is the IRQ used to cascade the slave 8259 interrupt controller.
Please try using another IRQ for your card.

On the IBM *AT* (ISA bus), the IRQ 9 pin is identical with the IRQ 2 pin on
the original IBM-PC.  If you have an earlier 8-bit adapter whose documenation
states that it uses IRQ 2, be aware that this will actually be interpreted as
IRQ 9 when plugged into the 16-bit ISA bus.  Therefore, if you set an ISA
adapter to IRQ 2, this adapter will be known to OS/2 as IRQ 9. The reason for
this is there are two INTEL 8259a (or compatible) Programmable Interrupt
Controllers (PICS) in the ISA bus architecture.  Each PIC can handle eight (8)
interrupts.  IRQ 2 which is located on the master PIC cascades to IRQ 9 of the
slave PIC.  This is a function of the hardware and not the OS/2 operating
system.




!MULTIMEDIA_____________________________**********
May 10, 1995
QUESTION: (Ref: H69)
Since the DDK only supplies the PDD samples source code for MediaVision's Pro
AudioSpectum 16, and we must put a lot of effort to convert it for our own.

1. So, if you could provide me the Sound Blaster 16 Sample Source Code for
PDD, we'll able to write our own device driver quite easily and speedly.

2. Also, I have referenced the command set of the Debug Kernal but found no
I/O trap related command.  Could you give me some examples?


ANSWER:
1) We are unable to provide you with a sample of the SOUND BLASTER 16 source
code, legally we are not allowed to provide this code.

2) You could use the following Kernel Debugger Commands -

vsf *
or
vtf *

vsf - Intercept Trap Vector, except Ring 0 Interrupts
vtf  - Add Interrupt/Trap Vector, All Rings

Besides these, there are no I/O Trap related commands.




!VIDEO__________________________________**********
May 10, 1995
QUESTION:  (Ref: H54)
In the Display Device Driver reference (from the DDK) there is a page called
"SetUp and Sharing of a Pointer to VideoRAM".  It describes the SCREEN IOCTLs
7Eh and 7Fh.  In the discussion of 7Eh (AllocGlobalVRAM), it describes the use
of the Flags field of the PARMS structure passed to the IOCTL.  The
documentation says that the flag should be 0 if the pointer returned is to be
accessible only from Ring 0; if it is set to 1, the pointer will give access
to VRAM at any privilege level.

This seems to contradict some (successful, working) code that I have.  This
code has a GetVRAMPointer routine that sets the flag bit to 0 and a
GetVRAMRPointer (Ring 0) routine that sets the flag bit to 1. The DDK's SRC_S3
code also has a GetVRAM Pointer that sets the flag bit to 0, and seems to get
access at any privilege level.  Could you please verify that the on-line
documentation is correct?


ANSWER:
The documentation for AllocGlobalVRAM as mentioned in the Display Device
Driver Reference is correct (DevCon DDK v1.0).

For further information regarding the usage and application of the above
DevIOCTL call supported by PMDD.SYS, refer to "Obtaining Pointers to Video
Memory" in the Display Device Driver Online Reference Manual, Section:  S3
Display Driver.  The GetVRAMPointer returns an address that could be used only
at Ring 0 in the address space of the calling process.  If other PM processes
also require addressability, they must issue an AccessGlobalVRAM(Function
0x7F).




!VIDEO__________________________________**********
May 10, 1995
QUESTION: (Ref: H49)
Recently, I make a OS/2 Warp system for Chinese Language.  With the drivers
(IBMDEV32.DLL, IBMVGA32.DLL, and BVHSVGA.DLL which are build from the DDK 3.0,
they almost make the system work normal except one problem.  It happens in the
session of "OS2 full screen", the screen is abnormal.

I have found that the system auto-loads the value into the registers (such as
3C2h, 3Dxh,3Cxh..,etc) for the video mode "640x480 16 colors", but it does not
clear some extended registers for the special SVGA card, so the screen is
abnormal working.

I want to know which function in BVHSVGA.DLL must be excuted while system
enters into the session of "OS/2 full screen", then I can clear the extened
registers.  I need your help to know what it is, or you can tell me another
method to solve this problem.


ANSWER:
On SVGA systems, extended registers are taken care off via the imported
VIDEOPMI interface.  BVHSVGA (Warp level) has no built-in device support, it
instead completelly relays on functions imported from the VIDEOPMI.DLL which
in turn gets the device specific information from the PMI file.  Therefore,
any SVGA for which we have a PMI file in the Warp should be taken care of.
However, there were devices, such as Weitek, for which the base video support
was not supplied by IBM and a custom BVHSVGA was shipped in a binary format.
You need to find out if you have a PMI file for the device in question (you
can run svga on from a DOS full screen prompt and look for svgadata.pmi on
\os2 directory).  If so, you need to make sure that the file exists before you
reboot so that bvhsvga can take advantage of the svga services.  If the
problem persists after the PMI file is created, then two different things may
be happening:

1) If there is a section for 640x480x16 in the PMI file, it may have a bug
(incomplete or erroneous io access).  Such a bug would be hard for you to fix,
unless you know the device in question.

2) There is no section for 640x480x16 in the PMI file, in which case a section
called "Cleanup" is executed before the set mode call is passed down into
BVHVGA.DLL which executes standard VGA 640x480x16.  The cleanup section may be
in error, which will again be hard for you to fix.  It is best if you ship the
PMI file and information on the specific SVGA adapter (chip, memory, DAC chip,
BIOS level) to us and we may be able to fix it.  If there is no PMI support
for the device in question, you basically need to provide SVGA support.  You
can read the DDK on the PMI syntax and on svga.exe and how to modify it to
provide support for new devices.




!NETWORK________________________________**********
May 10, 1995
QUESTION: (Ref: H30)
We would like some tools for testing an ndis 2.01 driver under os2.


ANSWER:
I have received some information on a tool called "NDIS DEVICE DRIVER TOOLKIT
FOR OS/2 AND DOS".  The number to call and receive more information is
1-800-633-6284.




!OTHER__________________________________**********
May 10, 1995
QUESTION: (Ref: H09)
CL386.EXE doesn't work ?
I want to add 32-bit disk access in this driver.  I need to modify ADDCALLS.H
and S506IORB.C.  I inserted assembly instruction "insd" and "outsd" in
ADDCALLS.H.  I also changed original C compiler cl.exe to cl386.exe in
MAKEFILE.  Then I re-compiled ADDCALLS.LIB and some syntax errors occured
(cl386.exe is in /DDK/TOOLS).

         cl386 -c -Zp -Zl -J -Owit -Gd -Gs LIBCODE  -I. -I..\..\..\..\h
 -I..\diskh -IC:\DDK\SRC\DEV\DASD\ADDCALLS addservc.c
 addservc.c
 ../../../../h\dos.h(171) : error C2143: syntax error : missing ')' before '*'
 ../../../../h\dos.h(171) : error C2182: '_far' : has type void
 ../../../../h\dos.h(171) : warning C4105: '_far' : code modifiers only on
 function or pointer to function

These messages were not shown with C cpmpiler cl.exe.  Could you tell me how
to solve this problem ?


ANSWER:
You will have to include header files defined in ddk\h386 directory.  CL386 is
a 32-bit compiler so 'far' keyword is not defined for it.  We did not face any
problem with _asm keyword .

You could also refer to some sample codes on the DDK -

          ddk\src\vdev\vmouse\vmio.c
          ddk\src\vdev\vvideo\vv8514.c


You could also 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 with the _asm directive and 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.




!BASE___________________________________**********
May 10, 1995
QUESTION:  (Ref: GZ9)
My driver will support an IOCtl function call to query device status.  I know
that if the driver is to copy data into the IOCtl buffer at interrupt time,
the following rules apply:

  The application must:
  - Allocate the IOCtl buffer using DosAllocMem with the object tile
    (OBJ_TILE) bit set.

  The driver must:
  - Lock the data buffer.
  - Verify the IOCtl data buffer using the VerifyAccess DevHlp call.
  - Use the VirtToPhys DevHlp call to get the physical address of
     the IOCtl data buffer.
  - Convert this Physical address to a virtual address.

But suppose that the driver does not copy the data to the IOCtl buffer at
interrupt time and instead copies the data to a local buffer within the driver
at interrupt time.  When the interrupt routine completes and the driver
detects that it has received data, the driver then copies the data from its
local buffer to the IOCtl data buffer.

Using this scheme:

Q1: Can the application allocate the IOCtl buffer statically?

A1: The data buffer specified in the DosDevIOCtl call is allocated statically
    in the application.  Ref:  DosDevIOCtl call in the Control Program
    programming reference.
==============================================================================

Q2: Is it necessary for the driver to verify access to the IOCtl data buffer?

A2: In the DD, the sequence of steps to be followed are:

      - VerifyAccess to check if the caller owns the specified data buffer
      - Lock the segment down (DevHelp_Lock)
      - Do data transfer (movebyte.asm routine in App-C, Mastrianni's
         book)
      - Unlock the segment (DevHelp_Unlock)
      - return RPDONE

    Ref: "Writing OS/2 2.1 Device Drivers in C" by Steve J. Mastrianni,
    Appendix - C, Simple OS/2 Parallel Device Driver, case RPIOCTL, case 0x02.
    This book is available online in DevCon DDK v1.0
==============================================================================

Q3: Are there any other caveats, related to memory management, to be aware of?

A3: There are no other issues.
==============================================================================

Q4: I still have some questions about the requirement for the driver to lock
    the IOCtl buffer.  I plan to use an IOCtl function call to get device
    status. To do this, the application will make the following call:

      #define NULLP           0
      #define GETSTATUS       0x01
      #define USERCATEGORY    0x80

      unsigned char statusbuf[256];

      DosDevIOCtl(statusbuf, NULLP, GETSTATUS, USERCATEGORY, handle);

    Note that statusbuf is statically allocated.  I would prefer to avoid
    forcing the application to dynamically allocate the status data buffer.

      The driver will operate as follows:

      - When the IOCtl status request is received from the application, the
         strategy routine will issue a status request to the board and block
         the process until data is received.

      - The interrupt routine will capture the data returned by the board,
         copy it to a local buffer within the driver, and signal the strategy
         routine that data is available.

      - When the strategy routine is signalled that data is available, it will
         copy it from the driver buffer to the IOCtl data buffer then run the
         blocked process.

    The documentation on the DevHelp_Lock function indicates that the buffer
    passed by the IOCtl call is in the form of a temporary selector and offset
    that cannot be locked unless the buffer was allocated by the application
    using DosAllocMem with the OBJ_TILE bit set - i.e.  a buffer that was
    statically allocated cannot be locked.  However, in a reply to a previous
    query, I was told that locking is only required if the data is copied into
    the IOCtl buffer at interrupt time.  My scheme avoids this, the data is
    copied to the IOCtl buffer by the strategy routine after the interrupt
    completes.  However, I cannot guarantee how much time may lapse between
    when the request is issued to the board and when the data is returned
    (i.e.  how long the process is blocked), although typically it should be
    less than one second.

    Why is it necessary to lock the buffer in the first place?  Is it because
    the operating system may otherwise swap the memory?

A4: Since the driver blocks for data, it must lock down the buffer to ensure
    its availability when the driver is unblocked.  The operating system may
    swap the buffer otherwise.  If the process is blocked for more than 2
    seconds, you should use long term locks else short term locks should be
    used.
==============================================================================

Q5: Is it possible, using my scheme, that the blocked process could be
    swapped?  If so, will I need to lock the IOCtl buffer even though I am not
    accessing it at interrupt time?

A5: The associated data structures of a blocked process can be swapped out.
    You have to lock the IOCtl buffer even if you are not accessing it at
    interrupt time.
==============================================================================

Q6: Is it always the case that a statically allocated buffer cannot be locked
    or will lock fail only if the interrupt routine attempts to lock a
    statically allocated buffer?  That is, can the strategy routine lock an
    IOCtl data buffer that was statically allocated by the application?

    In a reply to a previous question, I was referred to the example of the
    parallel device driver in Mastriani's book for an example of the correct
    procedure for locking.  I have studied the example at length.  His
    strategy routine locks the IOCtl buffer before copying data but he makes
    no mention of a requirement that the application allocate the buffer using
    DosAllocMem.  In fact, his example of the application's IOCtl function
    call uses the same buffer as is used for DosRead.

A6: Yes, the strategy routine can lock an IOCtl buffer allocated statically.

    The same buffer could be used in DosDevIOCtl and DosRead.  In the former
    case, the DD will explicitly lock down the buffer whereas in the latter
    case, the kernel will lock down the buffer.

    DosAllocMem with the OBJ_TILE flag holds if DevHlp_Lock is to be used to
    lock down the memory.
==============================================================================

Q7: If DosAllocMem with OBJ_TILE flag holds if DevHlp_Lock is to be used,
    then how do I go about locking an IOCtl buffer that was statically
    allocated by the application (i.e.  not allocated using DosAllocMem with
    OBJ_TILE)?

A7: Use the DevHlp_VMLock for the statically allocated memory.  Lock is used
    for the 16:16 type virtual address and VMLock is used for 0:32 bit linear
    addresses.  Use VirtToLin to convert the Selector:Offset Pair (of the
    statically allocated memory) into a Linear Address.
==============================================================================

Q8: Is it just that DevHlp_Lock will not work for statically allocated IOCtl
    buffers or is it the nature of the way that IOCtl buffers are passed that
    they cannot be locked at all unless allocated using DosAllocMem with the
    OBJ_TILE flag set?

A8: The OBJ_TILE ensures that the memory is allocated in the first 512MB of
    virtual address space which is the Compatibility Region.  If the memory is
    not allocated with this API, you could have problems in Locking.
==============================================================================

Q9: If it is possible to lock statically allocated IOCtl buffers but
    DevHlp_Lock will not do it, is there another way to do it?

A9: Please try VMLock and let us know if it helps.
==============================================================================

Q10: Will I be required to write my own locking routine?  Is there any
     documentation available for designing such a routine?

A10: We do not have any documentation for designing the Lock Routine.
     Hopefully you will not have to do this.
==============================================================================

Q11: DevHlp_VMLock seems to work - i.e.  it doesn't return an error.  Since
     there is no way to verify that memory is locked and since my machine has
     plenty of memory, I won't know for sure that it is working unless it
     swaps which may never happen.  But I will assume that I can now lock
     statically allocated IOCtl buffers.

     I have one more question regarding IOCtl buffers.  My driver supports a
     couple of IOCtl functions that return data immediately.  There is no
     blocking and no delay in the driver.  In this case, is it necessary to
     lock either:

      - Read-only buffers before the driver reads the information (i.e. the
        IOCtl parameter buffer which passes parameters which are only
        read by the driver).

                                  OR

      - Read-write buffers before the driver writes the data to the buffer
        (i.e. the IOCtl data buffer which receives the data supplied
        immediately by the driver).

     In Mastriani's example, he does not lock IOCtl buffers for IOCtl
     functions that get an immediate response from the driver.  I assume that
     this is because if there is no delay within the driver, there is no
     chance that the application's buffers can be swapped.  Is this correct?

A11: You need not lock IOCTL buffers for IOCTL functions if there is no
     blocking, delay, or you do not use DevHlp's like VirtToPhys etc.  during
     the IOCTL fuction processing within your device driver.




!OTHER__________________________________**********
May 10, 1995
QUESTION: (Ref: GX1)
We are using a device driver to accomplish port I/O.  I need a way to
determine if a device, such as a serial port or floppy disk, is in use by one
or more processes.

What I REALLY need is exclusive hardware access to a system resources so that
I may perform port I/O without disturbing anyone.  So I want to be able to
somehow test if a device is free or not.

We have looked at the documentation concerning the resource manager base
device driver in a document called rmbase.inf.  It appears that the main
purpose of this driver is to maintain a system wide view of the hardware
resources and the software that is responsible for controlling these
resources.  It also allows resource manager device drivers to intelligentlly
allocate hardware resources and avoid resource allocation conflicts.  Most of
the resource manager services are provided to device drivers via the devhelp
call interface.  Only 2 IOCtl calls are available to ring 3 applications.

What we need to be able to do, is to gain temperory access to some generically
specified hardware resource (DMA, I/O, IRQ, Memory) for testing purposes.  We
would like to do this without interfering with any device driver that might be
controlling that resource.

My current thought was to determine the device driver's name from the resource
manager calls somehow and to pass this information to the test module (dll).
The test module would then open the device for exclusive access.  If granted
access, it would call our physical device driver to actually access the
hardware resource.  Then, when the testing is done, close the device that was
exclusively opened.  Since we have a very good idea of what hardware is to be
tested, we try as best we can to save and restore the state of the hardware.

What we are trying to do is somewhat similar to what a Plug & Play / PCMCIA
device driver would like to do.  Is there an approach along these lines that
is available to us?


ANSWER:
You could use RMGetDriverName - this helper service can retrieve the name of a
device driver from a base device driver init packet

Calling Sequence -

#include <os2.h>
#include <reqpkt.h>
#include <rmcalls.h>

VOID RMGetDriverName (PRPINITIN pRP,PSZ pBuf,USHORT size)

Calling Parameters  -

pRP (PRPINITIN) Pointer to init request packet
pBuf (PSZ)      Pointer to character buffer for device driver name
size  (USHORT)  Buffer Size

Returns -
Contents of pBuf will be a null-terminated device driver name.  If unable to
determine the Device Driver name, the contents of pBuf will be a zero length
null terminated string.

All the physical device drivers on OS/2 do not support Exclusive Access.  Also
to communicate with the Physical Device Driver (over which you want control),
it has to have the IDC bit set.  Only if this bit is set in the corresponding
Header will you be able to communicate with it and get control (if it allows
exclusive access to the device).

The physical ASYNC device driver does not prevent multiple processes from
concurrently opening the same device name.  The PDD uses standard file system
contention control.  An application or subsystem that needs exclusive access
to the COM device will open it with access rights set to DENY_ANY.

For exclusive access to the Parallel Port refer to I/O Device Driver Ref.,
Chapter - Physical Parallel Port Device Driver, Section - Sharing Parallel
Port with other device drivers.

Since you are using WARP you can use the Resource Manager to reserve
resources.  Resources include IRQ level, DMA channel, memory, ports etc.  You
may go thru the Resource Manager documentation which is on the DUDE BBS
(RMBASE).  Relavent header files are in DevCon DDK V1.0 in
ddkx86\src\dev\resource\rsm_h directory.  In the CONFIG.SYS file insert the
following line (MUST BE THE FIRST LINE) BASEDEV=RESERVE.SYS /IO:  x,y /SHA
/IO:x,y /SHA ....

where x -> port number in hex
      y -> number of ports (in decimal)

      SHA -> the resource will be granted to any requestor that requests the
             resource as shared. The resource can be used by any driver
             at any time without interference from each other.

If you want exclusive access, remove the /SHA option.  Default option is
exclusive access.  In that case one driver has to explicitly release the
resource before other driver can access it.  For details refer to section on
'reserve.sys" in RMBASE.INF

In case of exclusive access to resources, for claiming/releasing resources
issue resource manager calls RMAllocResource, RMDeAllocResource.  For details
refer to 'Linking Resource Manager Services' section in RMBASE.INF

For the floppy, there's an IOCTL, category 8, function 0x5D which gets you
exclusive access to the floppy.  Making the IOCtl again releases it.  I don't
think the hard disk can be had exclusively, since it must be able to swap and
page in code, perhaps even the code for the diagnostic.




!MULTIMEDIA_____________________________**********
May 03, 1995
QUESTION: (Ref: H87)
I downloaded mpeg.inf.  In the source code section it says the source for the
DD is on the Dev Con.  Device Driver Source Kit for OS/2.  I have "The
Developer Connection Device Driver Kit for OS/2 - Version 1 1994" I can't find
the files mentioned in the source code section.  Do I have the wrong CD?
Where are these files?


ANSWER:
The source was not available for the DDK v1.0.  The next version of the DDK
will have the MPEG source.




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref: H81)
I would like to install the debug kernal for the fullpack GA.  Do you guys
have it?  If so, where?


ANSWER:
WARP Fullpak KDEBUG is located on the WARP fullpak cd.




!VIDEO__________________________________**********
May 03, 1995
QUESTION: (Ref. H55)
Do you know where I can obtain source code for a "16 color" OS/2 WARP SVGA
display driver which supports both 640x480 and 800x600 resolutions?


ANSWER:
The SVGA Base Video Handler is in the directory - ddkx86\src\svdh.  The output
file generated by nmake has the .DUS extension because it is the US language
version of the DLL.  It ( BVHSVGA.DUS ) needs to be renamed to the
corresponding DLL (BVHSVGA.DLL) before being used.




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref: H52)
We just purchased the OS/2 DDK, and it doesn't appear to have the debug
version of the kernel for Warp 3.0.

1. Are we mistaken, or is there some place we can get an update so we can
continue to develop device drivers for Warp?

2. Also, we would like to write 32-bit device drivers, but have been
unsuccessful in getting MASM 6.11 to work under Warp.  The assembler crashes
when we try to run it.  Are there any suggestions?  (We just downloaded the
.TIP file on this, and we will try it, but we want to be sure we get it
going.)


ANSWER:
1. If you are using WARP FULLPAK, the KDEBUG can be found on the WARP FULLPAK
CD.  The KDEBUG on the DDK is for WARP (NON-FULLPAK).  The DEVCON VOL6 also
has the KDEBUG.

2. Physical device can only be 16 bit.  Device drivers that are 32-bit are
Video, Printer and VDD.  Also, the DDK requirements for building OS/2 physical
device drivers are MASM 6.0 and MSC 6.0.  MASM 6.11 may not be compatible.
Under the "Usng Your DDK" icon, there is a section called " Components and
Build Requirements" which details what compilers are needed.




!OTHER__________________________________**********
May 03, 1995
QUESTION:  (Ref: H46)
I am having difficulties compiling the sample device driver for the Pro audio
spectrum 16 audio adapter whose source code is provided in the OS/2 DDK.  I
have MASM 6.11 and am using the visual C/C++ compiler but the compiler
complains about file os2medef.h.  CL complains about lines 104, 105, 115 of
this file and then it errors out.

I am new to OS/2 development and I may not have my environ- ment properly set
up but I think that I've done all that I was supposed to.  The DDK indicates
that Microsoft 6.0 and MASM 6.0 was used to compile the code.  Should I be
using these compilers instead?.  By the way, the MASM 6.11 was able to compile
the file startup.asm which is part of the sample audio device driver to .obj
with no problems.  It was Microsoft's C compiler that errored out.


ANSWER:
MASM 6.11 is not the OS/2 Version, MASM 6.0 was the last Microsoft Assembler
on OS/2 and you need to have this to run the DDK Code.  Although MASM 6.11 may
compile fine it does not support OS/2 and may cause problems later.
Unfortunately, MS Visual C/C++ does not support OS/2 either.  Please use MSC
6.0 and MASM 6.0 per the DDK requirements.  If you happen to use MASM 6.0B,
please be aware that it will produce compilation errors that require some
coding changes to reconcile but is is usable.  Another alternative would be to
try modifying the code for MASM 5.1 which is available on the DDK.




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref: H44)
I have unzipped oemhlp.pci and I have duplicated some of the sample code
contained in that file.  When I compile, the header file <reqpkt.h> cannot be
found.  I do not know what reqpkt.h is or what it should contain.  Any clues?


ANSWER:
REQPKT.H defines OS/2 Request Packets for BLOCK type devices.  The header file
is located on the DDK (DDKX86\SRC\DEV\DASD\DISKH)




!STORAGE__________________________________**********
May 03, 1995
QUESTION: (Ref. H40)
The problem I have is, with OS/2 2.0+ physical device driver devHLP services
the 'SetROMVector' function was rendered non-operational.  So here is the real
problem.  I have our current disk tools use an INT2F function to get
information from the driver.  With 'SetROMVector' non-operational, I need a
new way to hook a interupt vector.  Please tell me there is a way.

As my code loads at ring ZERO, I have considered just going straight to
physical memory and hooking myself into INT2F.  While this is exceptable for
dos/win, it seems to be all wrong for OS/2.


ANSWER:
You cannot hook into interrupts as you do in DOS/WINOS2 Sessions. Applications
and PDD running in protected mode can not access BIOS thru the INT interface.

Ref: PDD reference in DevCon DDK 1, section on generic IOCtl commands -
       category 80h OEMHLP IOCtls.

What you can do is have an IOCtl interface between the application and PDD.
The application can issue DosDevIOCtl calls and pass data/parameters to the
PDD.  Since the PDD runs in R0 it has full freedom to access all the memory.
After the PDD is finished it can pass back the results to the application via
the data buffer of the IOCtl request packet.

Ref: For details regarding DosDevIOCtl call refer to Control Program
       Programming Reference.


FOLLOW-UP QUESTION:
As I read the first line of your response it is possable to hook inf2F for use
in an OS/2 (windows window/full screen and dos window/full screen) but not
under a OS/2 window/full screen or P.M.

Is this correct?

If this is correct that is All I need, the current tools/utilities are DOS and
windows 3.1 based.  I am putting a plan together to create P.M.  tools which
will not need the int2F interface.

The big problem that I am faced with is the P.M.  tools are not going to be
ready for some time and I need to provide Read/Write protect tools for use
with the new Iomega ZIP 100 drive before May 1995.  The quickest way for me to
get the required tools support is to fix my OAD for OS/2 driver to answer to
the DOS/WINDOWS tools we currently are shipping.


FOLLOW-UP ANSWER:
Dos and Windows applications running in the OS/2 Operating System environment
could use the Int2Fh interface for communicating with their corresponding OS/2
Physical Device Driver (PDD).  But to do so you need to develop a Virtual
Device Driver (VDD).  This VDD would do the following :-

- Install a Interrupt Hook routine for Int 2Fh ( Ref: VDD reference
VDHInstallIntHook Devhlp call).

- When any application ( DOS or Windows ) issues an Int 2Fh then control is
also given to the Interrupt Hook routine registered by the VDD.

- This routine depending on the service required could either

- Pass on the control to the next handler in the Int2Fh chain , if the service
is not supported by it.  or - Process the request by doing either of the
following:

- Issue an appropriate DevIOCTL call to the appropriate PDD and get the
required information which can then be passed on to the application.  (Ref:
VDD Reference VDHOpen and VDHDevIOCTL Devhlp calls)

- Use a PDD-VDD IDC interface to communicate with the _ appropriate PDD (Ref:
VDD Reference and PDD Reference for VDHOpenPDD Devhlp in VDD Ref and
RegisterPDD Devhlp in PDD Reference)

Also refer to following source codes reg details of PDD-VDD

Interface: ddkx86/MMOS2/Samples/Audiodd/*.* ddkx86/MMOS2/Sample/AudioVDD/*.*




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref: H36)
I'm seeing these messages when it is initializing the board (from the kernel
debugger)

NWD WARNING: a failsafe timeout was detected at cs:eip = 20c8:931
NWD WARNING: a failsafe timeout was detected at cs:eip = 20c8:931
NWD WARNING: a failsafe timeout was detected at cs:eip = 20c8:af2
NWD WARNING: a failsafe timeout was detected at cs:eip = 20c8:af2

These addresses are inside my interrupt handler routine.  I'm downloading code
to the board, and am wondering if perhaps I'm taking too long to download the
code.


ANSWER:
This warning is from the watchdog timer.  This means IRQ0 (timer) has not been
serviced.  Usually it is due to a device driver disabling interrupts too long.
The CS:IP values tell you what was executing at that time.

In OS/2 you cannot disable interrupts for more than 400 micro seconds.  This
is for performance reasons.




!STORAGE !PRINTER_______________________**********
May 03, 1995
QUESTION:  (Ref: H34)
Recently, scanner I/F TWAIN and enhanced IDE I/F ATAPI are very popular with
ISA machines.  Will OS/2 provide ATAPI and TWAIN .DMDs?


ANSWER:
The latest ST506 code which includes ATAPI Support for IDE is planned to be
available in the next release of the DevCon DDK product.  The current release
is DevCon DDK 1.0.  We have no plans to release sample code for TWAIN drivers
in our next product but will consider it for the future.




!MULTIMEDIA_____________________________**********
May 03, 1995
QUESTION: (Ref. H32)
I am developing a dd for a SCSI device (a video decoder).  My dd makes ioctl
requests to OS2SCSI.DMD (specific request is a TRANSFER SCB request) in order
to do SCSI WRITEs to the video decoder.

This works just fine except when the video decoder returns a SCSI STATUS of
BUSY (I check SCSI bus analyzer).  In this case I get a return code of 0x818A
from OS2SCSI.DMD.  Looking at the return code descriptions (documented on
pages 175-76 of the STORAGE DEVICE DRIVER REFERENCE FOR OS/2 -- document #
s71g-1897-01), this means the following:

        bit 15    -- ERROR
        bit  8    -- DONE
        bit  7    -- SCSI ERROR
        bits 0-6  -- REQUEST SENSE FAILED

This tells me nothing about the BUSY status that the video decoder returned!
How can my dd detect that the device was busy?


ANSWER:
We would like to know the value of Errorcode field in IORBH ?  Is it
IOERR_DEVICE_BUSY.  If yes, you will get a return code of 0x8189 (bit 0-6
imply SCSI_ERR_DEV_BUSY).

You could trace through CheckIORBError routine in ddkx86\src\dev\dasd\os2scsi\
scsubrs.c.  Relavent header files are ddkx86\src\dev\dasd\diskh\iorb.h, scsi.h


FOLLOW-UP QUESTION:
How can I determine the value of Errorcode?  My interface with OS2SCSI.DMD is
a standard ioctl request packet, which does not have the Errorcode field.  I
use the kernel debugger to trace through my own code, but I don't know how to
trace through OS2SCSI.DMD.  I would need at least a .SYM file and the listing
(I tried to compile to generate these files but was unsuccessful).  Any
suggestions on where to go from here???

(NOTE: the status being returned in the Ioctl Request Packet is definitely
0x818A when the SCSI target device returns BUSY)


FOLLOW-UP ANSWER:
1.The source code for OS2SCSI.DMD is available on DevCon DDK Version 1. The
'nmake' from the appropriate directory will generate the SYM & DMD files.

2. In order to see the value of 'ErrorCode' try the following.  In the routine
CheckIORBError() (in ddkx86\src\dev\dasd\os2scsi\scsubrs.c) include a
statement to return the variable 'ErrorCode' instead of the whatever is being
returned at present.  Then from the relavant IOCtl handler routine (in
ddkx86\src\dev\dasd\os2scsi\scgioctl.c) call CheckIORBError() routine.  Return
this 'ErrorCode' to the application, via the data buffer of the IOCtl request
packet, from the IOCtl handler routine.  From the application you can print
this value.




!NETWORK !OTHER_________________________**********
May 03, 1995
QUESTION (Ref. H31):
I have the installed the Kernel Debugger on a Notebook running OS/2 2.11.  I
would like to step through the NDIS device driver, specifically the code that
initializes the hardware adapter.  I have a null modem cable running from the
COM1 port of the notebook, to a second notebook's COM1 port.  I have assembled
the device driver with an INT 3 instruction at the place where I would like to
start debugging.

When I re-boot the notebook, the message appears "Presentation Manager
Debugging Output Enabled:  COM1", but no output is displaying to the second
notebook.  I have hit the Ctrl-C key several times but still not output to the
other notebook.

The NDIS device driver I'm trying to debug has already loaded, but the Kernel
Deugger did not stop at the INT 3 instruction.

Should nothing be running on the second terminal to have it to see the output?
What specifically do I need in the CONFIG.SYS file to start debugging?


ANSWER:
The second terminal would need a COM program with COM parameters the same as
the other system.  There is nothing specific required for the CONFIG.SYS to
run the kernel debugger.

Some things to consider:

- The kernel debugger defaults to COM2 output unless a switch is set forcing
it to COM1.  Please refer to the KDB reference manual on the DDK.  If there is
no COM2 it defaults to COM1.

- Check for a bad null modem cable.




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref: H15)
It was mentioned to me that the current version of PCMCIA.SYS does not "use" a
interrupt level for socket management functions.

I want to be able to have the device driver I am writing tell the socket
controller not to use an interrupt level, but to do that I need to know that
the card services is polling for status changes and not waiting for changes in
its interrupt handler.  Is there a way for the socket services driver to
obtain this information from the card services driver, (i.e.  version level,
etc)?


ANSWER:
Refer to the PCMCIA Card Services Specification - you could use the
GetCardServicesInfo Function from your Socket Services Driver.  This function
returns the number of logical sockets installed and information about Card
Services presence, vendor revision number and release compliance information.




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref. GZ7)
1. Are there any tricks you know of, where I can issue reads and writes to a
previously opened file from a ring 0 DD?  I know I can at Init time, and I
know I do not have the dynlink api calls available to me during task and
interrupt contexts.

2. On that same note, are the context hook calls a performance issue?)


ANSWER:
1) There is no provision to read/write to a file from R0.  However you could
try out the following workaround -

You could have a Ring 3 Daemon that talks to your driver via IOCtl to get/put
Messages to a File.

2) Context hook handlers will affect performance of time critical applications
as they are non-preemptible.

Ref :  PDD reference, Remarks section of AllocCtxHook


FOLLOW-UP QUESTION:
You mentioned using IOCTLs from a ring 3 daemon as an alternative.  Wouldn't
it be better to use Read/Write calls (standard file I/O)?  I had thought I had
seen somewhere that IOCTL's cause more drag because of ring transitions, than
the standard file I/O reads and writes!


FOLLOW-UP ANSWER:
 The scheme we suggested was -
                         DosDevIOCtl
      Device Driver  <---------------->  R3 Daemon
                                               *
                                   Write        Read
                                               
                                         *      
                                 ------------------
                                 |    F I L E     |
                                 ------------------

Data read by R3 daemon (via DosRead) from file is passed to DD in the data
buffer of the IOCtl request packet.

Data to be written to the file is passed in the data buffer of the IOCtl
request packet to the R3 daemon.  The R3 daemon then issues DosWrite.

Since DosRead/DosWrite cannot be issued from R0, we have this indirect
approach.  Extra drag is certainly present due to ring transitions (R0 <-->
R3).

Ref: For details of DosDevIOCtl call refer to Ch-2, Control Program
Programming Reference, section on DosDevIOCtl.




!I/O____________________________________**********
May 03, 1995
QUESTION: (Ref: GZ6)
I am developing an OS/2 ASYNC device driver for an intelligent adapter.  The
intelligent adapter has CPU and runs its own firmware.  The firmware is in a
binary format with name ACE.BIN.  The firmware should be downloaded to the
adapter from the OS/2 ASYNC device driver when the driver is initialized by
OS/2.

How do I do this firmware downloading?


ANSWER:
The firmware downloading to the intelligent can be done during INIT of your
ASYNC device driver.  To access the adapter during INIT, you will need to
create LDT access, since INIT runs at R3.  Call PhysToUVirt devhelp function
to get a selector to the adapter memory.  Then call DosOpen to open the binary
file, DosRead to read from the binary file and write to the adapter memory
using the virtual address returned by the PhysToUVirt call.

Ref: "Writing OS/2 2.1 device driver in C", by Steve J. Mastrianni, Ch - 17,
Tips and Techniques




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref: GY1)
I took my driver (PCMCIA I/O) up and running under 2.10 OS/2 and moved it and
the Card Services (PCMCIA.SYS), Socket Services (IBM2TOS1.SYS), and Resource
Manager (TOS2RMU1.SYS) to config.sys of the 3.0 WARP.

The message I get is :  Unable to load driver (IBM2TOS1.SYS) -- invaild
switch.  (Note:  no new switches or ANYTHING has been put into the config.sys
that was not in the config.sys of OS/2 2.10.....)

The only thing that has changed it the Operating System Version which I was
told would handle PCMCIA better than 2.10 OS/2.


ANSWER:
Your hardware is a Compaq LTE Elite.  According to the OS/2 Hardware
Compatibility List Socket Services requires files available on the IBM BBS:
(919) 517-0001.  For OS/2 2.1 download OS2P21.ZIP.  For WARP download
OS2P30.ZIP.




!STORAGE__________________________________**********
May 03, 1995
QUESTION: (Ref. GX6)
I need to find out what kind of support is supplied by IBM for enhanced IDE
drives.  I know that the IBMST506.ADD provides some IDE support, but I don't
know if it supports the features of enhanced IDE:

     1)  PIO mode 3 & 4
     2)  2 channel, 4 drives
     3)  PCI bus-master DMA with or without scatter/gather

I see some questions in the 03_96QA.TXT file regarding IDE PCI DMA-busmaster
controller driver development, so I suspect that one can't use the
out-of-the-box IBMST506.ADD for EIDE controller chips.  Basically, I am trying
to find out which EIDE features would necessitate the development of a new
ADD.


ANSWER:
1) The IBM1S506.ADD will use what ever timing model the BIOS sets up.  If the
BIOS sets up for mode 3 or 4, we will use it.

2) By default, the IBM1s506.add will support the industry standard primary and
secondary controllers at ports 0x1f0 and 0x170 with up to two devices each.
If the user specifies, you can use up to four channels with two devices each
for a total of 8 devices.  Please see the online docs on how this is
accomplished.

3) There is no DMA support in this driver - only PIO.

We also support translating geometry if the system BIOS supports this or if
there is a third party translating BIOS boot record (ie:  ONTRACK).

In most cases, the EIDE controllers work well with our driver except in cases
where special code is required, as in enabling a secondary controller.

In addition, we are investigating what it would take to include DMA support
for EIDE PCI controllers.  Note that this is an investigation and not a
commitment.


FOLLOW-UP QUESTION:
"A1)" of that response says that the ADD uses whatever timing mode
the BIOS sets up.

1) What is the ADD's interface to the BIOS for this (how does the ADD get this
information from the BIOS?).

In "A2)" of the response is a comment to "please see the online docs on how
[four channel, 2 devices per channel EIDE] is accomplished".

2) Could you please tell me where in the documentation this information is
found?  I did not see it in the DDK's Storage Device Driver Reference.


FOLLOW-UP ANSWER:
1) There is no communication between the ADD and the BIOS.  Whatever the
timing mode the hardware is set up for, is what the BIOS sets up.

2) As for the online doc's, do a HELP IBM1S506 at an OS/2 command prompt, not
in the DDK's Storage Device Driver Reference.





!STORAGE________________________________**********
May 03, 1995
QUESTION: (Ref: GX3)
I am trying to understand what the SET DEVICE TIMEOUT does.  This is one of
the OS/2 SCSI services for the SCSI driver (OS2SCSI.DMD).  It is documented on
page 170 of the STORAGE DEVICE DRIVER REFERENCE FOR OS/2 (document #
s71g-1897-01).

I am writing the OS/2 SCSI device driver for a SCSI target which is still in
development.  Sometimes the target fails in the middle of a data transfer.  At
this point the timeout is exceeded and I would expect the timeout to cause
something to happen and return to my device driver.  What is happening,
instead, is that when the target hangs, the host (including my device driver)
just sits there.

Am I expecting too much from the SET DEVICE TIMEOUT command?  What exactly
does it do?


ANSWER:
Set device timeout command sets the value of timeout field in the unit CB
structure.

Timeout field indicates the maximum number of milliseconds the driver will
permit for command completion before timing out.  If this field is set to 0,
the timeout value assigned is the default set by the driver.  If the field is
set to -1, timeout value assigned is infinite.  The timeout period is measured
from the last valid contact (interrupt) with the target device.  Therefore, if
the device interrupts periodically within the timeout interval, the interval
is reset after each interrupt.


FOLLOW-UP QUESTION:
Could you please elaborate on your answer?

In my environment, I have a SCSI fast/wide uchannel adapter.  To this adapter
I have a SCSI video card which is underdevelopment.  Sometimes the video card
holds the SCSI bus for prolongedperiods of time (over a minute).  I have set
the device timeout to about asecond.  If I understand your answer correctly,
the first adapter would do a SCSI reset or something to be able to return to
my device driver within thetimeout period.  This is not what is happening;
Instead, the adapterjust sits there and waits (over a minute).  Some
explanation please?


FOLLOW-UP ANSWER:
Timeout Ioctl goes to the Device Manager and is passed as an advisory value to
the ADD.  It MAY timeout the operation by using a timer tick routine from
start of I/O.  If there are multiple iterative contacts with the device during
one I/O request it is probably wise to reset the timer back to the initial
value after each contact.




!OTHER__________________________________**********
May 03, 1995
QUESTION: (Ref. GV3)
1. Can I Acquire More than ONE SPinLOCK (of course for a different critical
source) in my ADD Driver?.

2. Can you send me a sample code to create a SpinLock so that I can use it for
developing other calls in SMP.


ANSWER:
1. Each thread can own a maximum of 32 spinlocks when it blocks.  This assumes
these spinlocks have been created and acquired using the DevHelp provided for
that purpose.  Also, if the DD will not be blocking, then the 32 spinlock
limit can be exceeded.  One must also be aware that the kernel itself acquires
spinlocks that count as part of the 32 spinlock maximum.  So the DD itself
should acquire less than that.  How much less is difficult to give a precise
figure on, but I feel its safe to say, 16 should be a safe amount, which would
leave room for the OS to have the ability to acquire 16 itself.

Now keep in mind, the 32 spinlock limit only applies when the OS spinlock
manager is used to control the spinlocks.  If the DD writer chooses, a simple,
private, spinlock can be created.  We usually encourage the use of private
spinlocks for performance reasons.  The OS spinlock manager has to handle many
cases that are not necessary for a DD, and as such has long code path lengths.
Private or simple spinlocks are the way to achieve the highest level of
performance.

2. There is no template currently available for spinlocks, especially the types
we use inside the OS.  However, simple or private spinlocks are very
straight-forward.  I will include an example of a simple spinlock ACQUIRE and
RELEASE code fragments below:

GENERAL: (section name, not an actual label in the code)

SpinLockByte  db  0 ; actual variable used for spinlock
                    ;   0    means spinlock is unowned
                    ;   0ffh means spinlock is owned

***************************************************************
ACQUIRE: (section name, not an actual label in the code)

 mov al,0ffh           ; AL = ownership flag
 CheckLockAgain:
 cmp SpinLockByte,0    ; is spinlock currently owned?
 jne CheckLockAgain    ;  Yes, go back and check again
                       ;  No, spinlock is not owned so
                       ;   try to acquire ownership
 xchg SpinLockByte,al  ; attempt to acquire ownership
 or al,al              ; did we acquire the spinlock?
 jnz CheckLockAgain    ;  No, some one else got it, go
                       ;    back and try again.
                       ;  Yes, we now own the spinlock

*************************************************************
RELEASE: (section name, not an actual label in the code)

 mov SpinLockByte,0   ; Set the spinlock variable to
                      ;  not owned state.

*************************************************************




!NETWORK________________________________**********
May 03, 1995
QUESTION: (Ref: GR6)
I am writing an NDIS MAC driver for a parallel port attached TR device based
on the Texas TMS380 chip.

I have written NDIS protocol drivers and an ethernet MAC driver before, but TR
is significantly different to ethernet.

I have the DevCon LAN System disk with a skeleton ANDIS driver on it.
Skeleton drivers are easy!  I'm interested in an example Token Ring MAC
driver, it's the token ring bit I'm least familiar with (I've done ethernet
MAC and protocol drivers before, but never Token ring.

Are there (or will there be) an example token ring MAC driver (for any
chipset) available?  [I have DDK V1.2]


ANSWER:
At this time, there are no other samples available.




