.fo off
This is file: 08_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)
==============================================================================

!OTHER___________________________________**********
August 02, 1995
QUESTION: (Ref: HZ4)
We have an ISA bus add-on board with a 32k word FIFO memory on it.  The FIFO
fills from a serial data source.  It can be read over the ISA bus.  ISA bus
data is 16 bits long.  I am writing a device driver in C, using the Simple
OS/2 Serial Device Driver in DDK Appendix C as a model.

The application program calls the device driver with a DosRead to read 16k
words (one block) of data from the FIFO ( 1/2 the FIFO).  After the 1/2 full
interrupt occurs, the driver's strategy section should become unblocked and
transfer the data fron the FIFO to a buffer in the application program for
later processing.  This application buffer is declared in C as extern short
inbuf[32000], and stores 2 blocks.

I am getting confused about virtual, physical, and linear addresses.  What
kind of C routine do I need to move the data from the FIFO to the buffer
inbuf.  The FIFO board address is D0000 (strappable).  I know that DosRead
gives a 32 bit physical address in its request packet.

1. Do I have to convert this to a virtual address?

2. Does the board address have to be converted?

The sample programs in Appendix C use MoveData and MoveBytes functions.  There
is no copy of MoveData given.  But I think these functions always move data 8
bits in parallel, and I want to do 16 (for speed).  It seems like there should
be a simple solution.

3. Also the programming model for the PDD is a 16:16 model.  What makes it
16:16?

4. Does this mean that the 32 bit pointer from DosRead has to be converted?

So what I need is some guidance on how to move a block of data, in my strategy
section.

Right now the code I have in my program is the following, but I am almost
certain it is not correct:

int far *src;     //pointer to FIFO
int     *dst;    // pointer to destination buffer
unsigned int sizm, index;
dst = rp ->s.ReadWrite.buffer;  //Physical address from DosRead
sizm = 16000;   //Words to XFER

for( index = 0; index < sizm; index++)
    *dst++ = *src;       //xfer the words

ANSWER:
1,2 & 4) Yes, You have to convert these addresses to virtual address.  (
Selector:Offset) The sample programs are part of "Writting OS/2 2.1 Device
Drivers in C" by Steve.  J. Mastrianni.  In the sample programs he uses his
own DevHlp library which is not part of DevCon DDK.  The source code for
MoveBytes function is given in Appendix C, Section on "Data Transfer
Routine".This could be modified for 16 bits transfer.  Please refer Appendix D
in the same book for the C callable DevHlp library.

3) The PDD is still 16:16 model, this is to support the older OS/2 Device
Drivers.

Use the following sequence of calls in the INIT section of your driver to get
the virtual address of your FIFO board address

Use VMAlloc Devhelp to map the FIFO board address (D0000) into the system
memory and get the linear address.  This call needs the linear address of the
VARIABLE containg the physical address to be mapped, use the VirtToLin Devhelp
to get this.  Issue AllocGDTSelector devhelp to obtain a GDT selector.  Now
pass this selector along with the linear address of the board obtained from
the VMAlloc call to the LinToGDTSelector.  This call maps the linear address
into the given GDT selector.  Now this memory can be accessed in all context
using this selector.  You can use the MAKEP macro to make a pointer to this
memory by passing the GDT selector and 0 as offset.

In the READ section use PhysToVirt devhelp to get the virtual address of the
application buffer and make a pointer to this address using the MAKEP macro.

Now you can move the data from the FIFO buffer to the application buffer using
these two pointers.

Refer Physical Device Driver Reference, Chapter 9 "Device Helper Services".
For MAKEP macro refer to "Writing OS/2 2.1 Deivce Drivers in C", Appendix C
Section "Standard OS/2 Device Driver Include File

FOLLOWUP QUESTION:
I am implementing your suggestions in my driver.  When you talk about the INIT
section of my driver, you tell me to use the macro MAKEP to make a pointer.
This I understand because MAKEP requires a selector and offset as arguments,
and I have a GDT select or, and you tell me to use an offset of 0. In the READ
section you also tell me to use MAKEP to make a pointer.  But what do I use
for a selector and offset.  All I have is a virtual address given to me by the
PhysToVirt devhelp.  How do I get a selector and offset from this virtual
address?

FOLLOWUP ANSWER:
You could use macros SELECTOROF & OFFSETOF to get the selector and offset of
the virtual address.  Refer to section "Standard OS/2 Device Driver Include
File" in Appendix - C of "Writting OS/2 2.1 Device Driver in C" by Steve.J.
Mastrianni for these macro definitions.

Alternatively you could use the MoveBytes routine to move the data to the
application buffer.  The source code is given in section "Data Transfer
Routine" in Appendix - C. In this case you don't have to make a fabricated
pointer.

For sample code you could refer to the READ strategy call ( RPREAD ) in
"Simple OS/2 Parallel Device Driver" in Appendix - C of the same book.




!OTHER__________________________________***********
August 02, 1995
QUESTION:  (Ref: I26)
What particular callback event types are triggered by the completion of a
Request Configuration call if the Request Configuration call is being done in
the Init Complete portion of the device driver?

I'm trying to program the driver to process specific callback events but do
not know what Card Services calls trigger what type of event (i.e.  like a
REGISTRATION_COMPLETE vs a CARD_INSERTION).  The Card services manual
basically says that the driver can expect any event in any order.


ANSWER:
Card Services processes the Request Configuration function by calling the
Socket Services Set Socket to program the card to the configuration
information that has been locked for that socket.  There are no callback
events associated with the Request Configuration.




!OTHER___________________________________**********
August 02, 1995
QUESTION: (Ref: I34)
I need to read and enviremental variable i.e, SET XDSCFG=D:\AMTELCO during
init time in my driver.  Can you tell me a way to do this.?  I have seen a
routine DosGetEnv but can not find detailed info on it.

ANSWER:
DosGetEnv is a 1.x Call.  This call returns the address of the process
environment string for the current process.

DosGetEnv(PSEL EnvSegment , PUSHORT CmdOffset).

You should use DevHlp_GetDOSVar,Index - LocalInfoSeg has the following fields
defined in its structure -

EnvironmentSel (SEL)     -  Environment Selector
CmdLineOff (USHORT)      -  Command line offset in the segment addressed by
                            EnvironmentSel.

This is documented in the PDD Ref.



!OTHER__________________________________**********
August 03, 1995
QUESTION: (Ref: HZ8)
I am in the process of standardizing our Software Development Group on the
Watcom C/C++ compiler for both the compiler and linker.  The problem we are
encountering is that the linker does not generate a compatible .SYM file and
the MAPSYM utility does not work with the watcom generated MAP files.  My
question is this - Can I get a copy of the definition of the .SYM file format?
It would be very simple for me to coax one of my engineers to write a utility
to convert a watcom .MAP to an OS/2 .SYM as long as I have a file definition.



ANSWER:
The DUDE BBS has a utility for the conversion of the Watcom Map File to the
SYM file, to be used by the OS/2 Kernel Debugger.  Download WAT2MAP.EXE.




!OTHER__________________________________**********
August 03, 1995
QUESTION: (Ref: I41)
I am writing a resource-decompiler for my ColoradOS/2 presentation.  I am
almost done -- my only problem is that the "ITERDATA2" type of data page in an
*.EXE is referred too, but not documented, in exe386.h.

This type of resource data record is created when you use "rc -x2 foo.rc".

Can you point me in the right direction?

ANSWER:
This question can be best answered by the DEVCON group.  They are much more
familar with this area than the DDSC.  But, i was able to obtain the
information you are looking for and a file has been provided to me by the
DEVCON group.

 - COMPLIB.ZIP

Here is this .ZIP file that contains the .LIB, .H files, and brief
documentation.  Also, I think there is a problem with the Compress routine if
it is called from 32-bit code with ESP > 64K.  The work-around is to have your
32-bit code call a 16-bit wrap per routine that switches stacks and zero's out
the top half of ESP.

The documentation is meager, but it should be sufficient.




!NETWORK________________________________**********
August 03, 1995
QUESTION: (Ref: I50)
We currently purchased the IBM LAN SERVER 4.0 and running under OS/2 2.1.  We
are trying to do NetBios programming here and have problem with the API call
'NetBios32Submit()' or the NETBIOS() in the ACSNETB.DLL.  Please direct us to
the technical support group that can help us with these questions.


ANSWER:
Since you are developing from the DEVCON LAN cd, you need to contact the
DEVCON group for this problem.  But, the DEVCON group has informed us that
there is a problem with NetBios32Submitt API, and there is a fix.  You need to
call defect support ( 1-800-992-4777 ) and request the latest LS40REQ FixPak
that contains the fix for the NetBios32Submit problems.




!OTHER__________________________________**********
August 03, 1995
QUESTION: (Ref: I52)
We are just starting to look at developing an OS/2 device driver for a Network
device.  I was just wondering if anybody can point me to a place where I can
get a copy of MSC 6.0?  I currently have MSC 5.1 and I am ordering MSC 7.0 for
another project, but I am unable to find MSC 6.0 anywhere.


ANSWER:
MSC 6.0 is no longer available.  The vendors of MSC 6.0 stopped production on
this version.  You will not be able to use MSC 7.0 for OS/2 device drivers
because 7.0 does not support OS/2.  You may want to consider using the WATCOM
compiler v10.0B.




!DISPLAY________________________________**********
August 03, 1995
QUESTION: (Ref: I60)
Using the Dev Con DDK 2.0 there is a directory for the S3 source code.  But
there is nothing in the makefile about building a debug version of the S3
driver ( although there is for the XGA and 8514/a ). I tried sticking /DEBUG
into the link step but the IBMS332.DLL wouldn't load.  I understand that when
it builds there will be a map file by the same name and I can run mapsym on
that to create the sym for the debugger.  So, I'm really asking two different
areas of questions:

1. Concerning the S3 source code that is on the Dev Con DDK 2.0 is this
capable of building a DEBUG version.

2. When trying to use the kernal debugger and build a dll that will load is it
the same steps as to building a dll that will debug with IPMD.  ( in other
words just add DEBUG on to the link386 statement [and for the kernal debug
session - run the mapsym utility.]).


ANSWER:
1. The makefile provided on the \ddkx86\src\pmvideo\s3tiger directory on the
DevCon DDK 2.0 is not capable of building a DEBUG version.

To build the debug version of S3 driver you need to modify the makefile Below
the statement - "ifdef S3" change the statements -

        OBJ=S3RETAIL          to OBJ=S3DEBUG
and  BUILD=-DRETAIL ...   to BUILD=-DFIREWALL ...

 and generate using the command
            nmake s3

2. For debugging with kernel debugger, build dll with /map option on link386
command line.  You can use mapsym utility to generate the .SYM file from .MAP
file.  You can do symbolic debugging of S3 driver.




!I/O____________________________________**********
August 04, 1995
QUESTION: (Ref: I36)
I had the following macro code that worked under DOS environment, but I had
problem to convert it to OS/2 environment.  The code is trying to read and
write to a specified register.


#ifdef _32bit
    #define OUTB(reg,val)  _outb(reg,val);
    #define QOUTB(reg,val) _outb(reg,val);
    #define INB(reg)       _inb(reg)
#else
    #define OUTB(reg,val)   outportb(reg, val)
    #define QOUTB(reg,val)  { _AL = val; asm out reg,al; }
    #define INB(reg)        inportb(reg)

Do you have any sample code that read or write directly to a specified
register under OS/2 environment.

ANSWER:
If you do not intend to use the multi-tasking capabilities of OS/2 for your
device, define the following in your .DEF file :

******************************************************************************
********
LIBRARY
PROTMODE
SEGMENTS
Your_Seg CLASS 'CODE' IOPL
******************************************************************************
********
Your_Seg is the Segment which has your code for the I/O.  The IOPL Attribute is essential for the I/O.




!VIDEO____________________________________**********
August 04, 1995
QUESTION: (Ref: I47)
We are working on video for Laptops and cannot find any information on native
DPMS support under OS/2.  We know that the Thinkpad 750c advertises DPMS
support and does come preloaded with OS/2.  Could you make it available the
details for hooking in the v arious levels of power management support under
OS/2 for desktop and laptop machines?

ANSWER:
APM (Advanced Power Management) Documentation is available in the I/O Device
Driver Ref.  There is also an article in the DevCon NewLetter Vol.5 about
Making your OS/2 Device Driver APM Aware.

The basic steps involved would be -

1. Attach to the APM Device Driver.  Use DevHlp_AttachDD from your Device
Driver.

2. Register your Power Management Event Notification Routine with the APM
Device Driver.




!STORAGE________________________________**********
August 07, 1995
QUESTION:  (Ref:  HZ6)
Q1.  Our PCI SCSI adapter & ADD driver needs to be tested for certification.
I need your help to guide me step by step through this process.  So far, I
have unsuccessfully ran DDTT tests from cdrom:\ddkx86\testcert\storage\
function\dasd\ioctl\*.  I have both DDTSCSI.DLL & SCSI.GRA in the same
directory as the ioctl files.  I have modified the config.sys to include the
correct path & libpath.  Upon running the tests, I keep getting this message:
"DDTT:ERROR:Failed to initialize input stream SYSINFO.TXT".  The bottom line
is that I need more detailed info to run these tests.

A1.  The error is due to improper installation of DDTT test programs and
script files.  Please follow the following procedure:

      -  For running SCSI ADD test, copy the files from

            \ddkx86\testcert\storage\function\scsi\add\*
            \ddkx86\testcert\general\ddtt\*

          into the directory c:\tscsiadd and add

            device=c:\tscsiadd\dasdadd.sys

          in the config.sys.

      -  For running SCSI IOCtl test, copy the files

           \ddkx86\testcert\storage\function\scsi\ioctl\*
           \ddkx86\testcert\general\ddtt\*

into the directory c:\tscsiio and add into the LIBPATH and PATH variables.

We followed the above procedure and did not find any error in running DDTT.

You are making a mistake in copying the files from

         \ddkx86\testcert\storage\function\dasd\ioctl\*

      You should change this to copy from the directory

         \ddkx86\testcert\storage\function\scsi\ioctl\*

Also, there is a documentation error in the storage device driver ref chapter
on SCSI IOCtl device driver test tool section installation.

The statement
 [c:\tscsiio]copy ddkx86\testcert\storage\function\dasd\ioctl\*
     should be read as
 [c:\tscsiio]copy ddkx86\testcert\storage\function\scsi\ioctl\*

======================================================================
Q2.  Your suggestion helped me in running the SCSI IOCtl test.  I do not
receive the error anymore.  However, I do want to confirm with you that the
IOCtl test is suitable for my PCI SCSI ADD driver?

A2.  The DDTT interacts with OS2SCSI.DMD and hence it does not really matter
what ADD driver is being used to control the device.  The DDTT should be
suitable for your PCI SCSI ADD Driver.

======================================================================
Q3.  There are two DDTT tests.  One of which requires DASDADD.SYS to be loaded
and the other is called IOctl.  I assume the IOctl test is the proper test?

A3.  You're right, there are two DDTT tests:

- The SCSI ADD functional verification test (FVT) excercises the IDC defined
for the SCSI Adapter Device Drivers.  This requires a test device driver
(dasdadd.sys) which communicates directly with the SCSI ADD under test.  This
basically tests the Ring 0 interfaces to your ADD.

- The SCSI IOCtl FVT excercises the APIs defined for the DosDevIOCtl inter-
face of the SCSI device driver.  This tests the Ring 3 Interface.

You should use both the tests for certification.



!VIDEO__________________________________**********
August 8, 1995
QUESTION:  (Ref:  I32)
Q1.  I have a question about the SVGA.EXE utility and a specific PMI file.  I'm
basing my SVGA.EXE code on the DDK 2.00 sample code (SVGAUTIL directory). 
My device uses the ProgramClock section commands provided in ChipData.C in
ICDesign1[0][0].  This is the code for programming the clock for the our chip.
This code contains some infinite loops.  However, a register16, used in the exit
test for the loop, is never incremented.

I also have an old VIPER.PMI file that I got from one of your developers when
I attended the Display Driver workshop in April this year.  This PMI file
includes code similar (but not identical) to the code that the DDK 2.00 code
would generate.  Besides some slightly different ordering of the commands,
there are some "Reg 16++" commands -- increment commands.  I would like to
know if these were added by-hand (AFTER running SVGA.EXE to generate the
PMI file), as I've seen no SVGAUTIL register command that would generate this
line.  If so, are there other undocumented commands?  Is there an updated
VIDEOPMI/SVGAUTIL coming that will include these commands?  Or have I simply
overlooked the command that would generate this?


A1.  We have a bug in svgautil.

The autoincrement operation has been left out not only from the regdata for the
ICDesign1 but the definition of the "+" operator has been left out from the list of
operator macros and the EmitCmd code which would format the expression.  We 
never shipped any code that includes the ProgramICD (we are calling IBMGPMI 
which does it for us) and that is why we never really found out about the bug. 
The sample PMI file that you received was written by hand to showcase the PMI 
language but there is no tool that could generate it.  We're not certain that your
PMI files need to be generated either, so much of the programming is common,
that an already written file can be distributed in its flat format.  But, if it is desirable
to generate the section, here is the fix that needs to be made:

svga.h line 460 (where register_ operators are defined)
Add #define REGISTER_ADD 0x1000

Don't forget to OR this define into REGISTER_ALL just below.

svga.c function EmitCmd, switch statement for (usOp & REGISTER_ALL).
Add  case REGISTER_ADD:
        RegChar = '+'; break;
chipdata.c regdata for ICDesign1, just before the PMICMD_ENDWHILE which
matches the WHILE on register 0x10, add an entry
{PMICMD_REGOP, NONE, NONE, 0x10, 0x10, REGISTER_OPEQUAL|REGISTER_ADD,b_1};

We plan to fix this in our next release.  However, it takes a long time for us to
make any code golden (available on the BBS) due to testing and certification
procedures, so your best bet is to fix your version locally.

By the way, if you do have a lot of code which already programs the ICD, why
don't you just call it from ibmgpmi, instead of struggling to format a complex PMI
file.  You could set the entire mode elsewhere and use PMI as a skeleton.


SOLUTION
---------
I followed your instructions to add the REGISTER_ADD command.  The SVGA.EXE
utility did not implement the correct command, however.  The CHIPDATA line:

    {PMICMD_REGOP, NONE, NONE, 0x10, 0x10, REGISTER_OPEQUAL|REGISTER_ADD,b_1};

                    generated the following line in SVGADATA.DOS:

                              r16 += 0x01234567;

I looked into SVGA.EXE, and saw that this was caused by the usBytes field
being set incorrectly.  I changed the CHIPDATA line to:


    {PMICMD_REGOP, NONE, NONE, 0x01, 0x10, REGISTER_OPEQUAL|REGISTER_ADD,b_1};

and the correct SVGADATA.DOS line was created.

========================================================================
Q2.  I'd also like very much to get whatever source I can that generated a working
ProgramClock section for the Viper PMI file, as I am writing for a device (on Intel)
whose clock is programmed the same way.  Note:  We did not provide this code; IBM
did.  Our drivers did not use the PMI file interface.  I don't have the original code that
was used to generate that VIPER.PMI file.  I suspect what I'm looking for would be an
updated CHIPDATA.C file, and perhaps an updated SVGA.C source file.

A2.  We have no public version of svga.exe that runs Weitek since your driver was 
never shipped by us and we just used it to prototype/showcase the new language 
extensions.




!NETWORK________________________________**********
August 8, 1995
QUESTION:  (Ref: I43)
Q1.  We are building an NDIS driver for OS/2 Warp.  I belive OS/2 Warp only
supports 16 bit NDIS drivers.  Is this true?

A1.  The NDIS interface is 16 bit but that does not mean that all the driver
code is 16 bits too.

=================================================================
Q2.  Since I'm writing a driver for our PCI FDDI Card, how would I communicate
to the PCI card?  I have tried to use the "outp" function but it is just 16 bit.
How would I output 32 bit data and input 32 bit data from and to my PCI card?
(Using the 16 bit ndis driver)

A2.  We do input and output to 32 bit ports in assembler so when we want to
switch to 386 instructions, in your case, it would look like:
   
     .386p                                                                      
     in  eax,dx                                                                 
     .386p 

=================================================================
Q3.  FDDI supports SNAP and 802.2 frame types, how would I change or do I need
to change the config.sys file so LANS 4.0 (or whatever version) would understand
802.2 or SNAP?
                                                
A3.  Configuring with LAPs or MPTS will automatically modify your config.sys so
there is no need to modify it manually.




!I/O__________________________________**********
August 10, 1995
QUESTION: (Ref: I31)
My problem is how could I pass information to the Keyboard buffer.  I know
about named pipes but I don't know how a Keyboard Driver works let alone send
information to it.

The reason I want to pass information to the Keyboard Driver because I want
OS/2 to know that the data I received from the COM port is a keystroke so that
it could process it like it was coming from the local keyboard.

ANSWER:
You cannot use Named Pipes to pass information to the Keyboard driver.  You
can modify your COM port device driver to pass information to the keyboard
driver in the following manner:

1. Call AttachDD DevHelp call to obtain the address of the IDC entry point
(Device Name = KBD$ , Driver Name = KBDBASE.SYS - device independent keyboard
driver )

2. Store the data from the COM port as the first and second scan code in the
Data Segment.

3. Call KbdIDC function with the following four variables on the stack.
     a) Function to be executed. The functions could be CMD_Open, CMD_Close
        or CMD_Keystroke.
     b) Offset of the data packet buffer.
     c) Data Segment.
     d) Handle or Code Segment.
        Refer kbdidc.asm in ddkx86\src\dev\kbd\kbdbase.

FOLLOWUP QUESTION:
First I would like to repeat my problem, I would like to pass information
coming from the COM port to the Keyboard driver.  My objective for doing this
is for OS/2 to process the information coming from the COM port as keystrokes
and do the appropriate processing/execution that keystroke represents.

1.What is the syntax of DevHelp_AttachDD and what does it return?

2.I am not very familiar with assembly, so is there another way of placing the 
scan code in the Data Segment preferably C?

3.How exactly do I pass information to the Keyboard Driver?  What are the
exact function call that I need and what are their syntax (e.g.  CMD_Open, and
CMD_Close)?

4.What Header, LIB, and DLL files do I need to be able to compile the program?

If you could also give me sample codes for theese functions I would greatly
appreciate it.  If the items I mentioned above are found in the DDK CD-ROM
just tell me what files I need to access.  By the way the compiler I am using
is IBM C/Set++.

FOLLOWUP ANSWER:
1. The 'AttachDD' function returns to you the code segment, offset, and data
segment.  You use the code segment and offset as a function call.  If you have
questions refer to the example in the KBDINIT.C code.  This function can then
be called like any other function.

DevHlp_AttachDD returns the the following - DS of the target drivers IDC entry
point, CS:IP of the IDC entry point of the targer driver.  (Ref :  PDD ref,
AttachDD DevHlp).

The steps to be followed would be :

- Call AttachDD with driver name and pass address of 12 byte structure into
  which system returns DS,CS,IP values of the IDC entry point.

- When you want to call IDC entry point, load DS with IDC entry point DS,
  make far call to CS:IP.

IDC entry point can be called only from R0.

2. Sample code on how to use IDC from your driver is available in OEMHLP.ZIP
on the BBS.This also shows how to pass parameters in 'C' to the Attached
Device Driver.

3. Before you invoke the Keyboard Driver there should be four variables on the
stack:

    1- Function to be executed.
    2- Data Offset
    3- Data Segment
    4- Handle or Code Segment
  Parameters 2,3 & 4 are obtained from the AttachDD Call.
  Parameter 1 would depend on the function invoked -
  0 - Cmd_Open
  1 - Cmd_Close
  2 - Cmd_Keystroke / Cmd_ScanCode ( kbddd.h )

4. For the DevHlp calls - DHCALLS.LIB

You would also have to compile your code on Microsoft C v6.0 / Watcom 10.
These compilers are used for the 16 bit OS/2 Device Driver Development.  The
IBM CSet++ cannot be used for the development of your PDD.




!OTHER__________________________________**********
August 10, 1995
QUESTION: (Ref: I51)
The DDK 2.00 PMI file documentation (DISPLAY.INF) recommends defining a
minimum PMI version of 2.2.  The DDK source code (SVGAUTIL file SVGA.H) does
not define anything greater than 2.15, however.

This is a note to you that the documentation (DISPLAY.INF and/or source code
needs updating.  But I'd also like to know the answer...

I'm currently using what the source code sets:  2.15.  Should I change this?
What would SVGA.H list as the requirements for versions > 2.15?

ANSWER:
Any version > 2.0 has the same level of support within the VIDEOPMI (the
parser).  SVGA.EXE doesn't have capability to format all of the valid language
expressions, so I believe that was the reason to give it 2.15 version.  The
parser will not behave any differently if the version is up-versioned.  It
will only behave differen tly if the version is < 2.0.




!OTHER__________________________________**********
August 10, 1995
QUESTION: (Ref: I91)
I need to do a selector to physical address conversion during an interrupt
routine.  DevHlp_VirttoPhys returns 'DevHlp usage error' whenever I try it
during the IRQ.  Do you have any suggestions?

ANSWER:
VirttoPhys is not valid at IRQ time.  Do a VirtToLin and then LinToPageList.
Both these DevHlps are valid at Interrupt time.





!NETWORK__________________________________**********
August 11, 1995
QUESTION: (Ref: I21)
I understand that there is a NetBIOS spec (v2.2, I think) that has new
features, eg.  including acknowledgements with datagrams.

I wish to obtain this spec. Do you have this, or know where I can get it from?

ANSWER:
There is no new spec, but the latest tech ref has some new Netbios
information such as tracing enhancements.  There are no acks for
datagrams.  The latest LAN Tech Reference is #SC30-3587-00.

FOLLOWUP QUESTION:
I have that tech ref, and it references netbios 2.2, and on Tx there is a bit
indicating whether you can accept piggybacked acks or not.

However, it would be extremely useful to have state tables for these
transitions, to understand how they work.  Any ideas you have would be
appreciated.

FOLLOWUP ANSWER:
The piggyback ack is in the frame header in frames like Data_Only_Last in the
Data1 field.  They are called Acknowledge_With_Data_Allowed and Acknow-
ledge_Included, rather than piggybacks in the description.  This is described in 
chapter 5 of the Tech Ref.  For performance, this type of Acking was disabled 
for ring 3 Netbios apps and is only available for the ring 0 DD interface, as ex-
plained on page 6-6 in the tech ref.




!OTHER__________________________________**********
August 11, 1995
QUESTION: (Ref: I64)
1. I need to initialize whole bunch of variables inside of the strategy routine.
Some of these variables also will be used in the interrpt service routine.  How
do I map the address of these variables that are shared in both ring0 and ring3
operations?  Do I need two different addresses for these shared variables in two
rings.  ie a virtual address and a GDT address?

2. How do I allocate a piece of physical memory that can be used in both ring 0
and ring 3?

3. How do I lock down different segments of my code, (large model) so they
will stay in memory after the init routine?  Do I need to call dev_help to
lock segments down?

4. What happends when a interrpt occures and my ISR routine gets called?  Dos
the system disable interrupts?

5. What's the difference between kernel mode, init mode and interrupt mode?
which ring they correspond to?

ANSWER:
1) You don't need to have two different address for the variables defined in
the device driver.  You can access the variables in all routines i.e.,
strategy & interrupt service routine.

2) The purpose of memory allocation and the usage is not mentioned.  The
general guidelines as follows:

Use AllocPhys DevHelp to allocate memory.  To get Ring0 access you could use
the DevHelp PhysToGDTSelector, and Ring3 access can be obtained using the
DevHelp PhysToUVirt.

If the application need to access the allocated memory the VMGlobalToProcess
DevHelp can be used.

3) Use the SEGMENTS directive and its IOPL option in the module definition
file (.DEF) to mark those segments that are to be kept after initialisation.
A PDD can lock a permanent segment using a DevHlp.,if it is necessary to
prevent it from being swapped out or moved.Refer to "Physical Device Driver
Reference", Chapter 3, Section on "Physical Device Driver Programming Model". 
Use VMLock to lock the memory region into physical memory.

4) If the device driver is running on an ISA bus machine, OS/2 calls the
device driver's Interrupt handler with interrupts disabled, since interrupts
cannot be shared.  On an EISA or MicroChannel machine, interrupt remain
enabled when the interrupt handler is entered.  Refer to "Writting OS/2 2.1
Device Drivers in C" by Steve.J.Mastrianni, Section on "Interrupt Section".
This book is available online in DevCon DDK.

5) Kernel & Interrupt mode runs at Ring0.  The Init mode runs at Ring3 with
IOPL privilege.  Refer to PDD Reference, Chapter 3, Section on "OS/2 evice
Driver Execution Contexts".




!OTHER__________________________________**********
August 11, 1995
QUESTION: (Ref: I67)
We are trying to use the PDD I have written with OS/2 WARP Version 3. Our
application program is a multithreaded program.  We have a Visual Age C++
compiler, Version 3.0.  We are using this for our application programs.  We
tried this with the device driver examples, but got errors.  Then we
discovered that the DDK comes with a compiler and assembler, namely cl386
and masm.  So can we use these for the device driver and the Visual Age
compiler for OS/2 and our application programs?

The PDD is still a 16:16 model.  Do I have to compile this differently than my 
application programs?

In addition to the DOSREAD I asked about in the previous questions, my device
driver uses DosDevIOctl calls.  These are copied from the Simple OS/2 Parallel
Physical Device Driver in Appendix C of the DDK.  They are used to write a 
control byte to my add on board, and also to read a status byte.

In Appendix C the DosDevIOctl call from the application program to the kernel
has 5 parameters, of which the device handle is the last one.  In the OS/2 WARP
Control Programing Reference manual this call has 9 parameters, of which the
device handle is the first one.  Which one should I use and why the difference?
Is one a 16 bit call and the other a 32 bit call?  In the DDK section, Providing a
Low Level Interface, they describe a small assembly language stub that is linked
in with the driver to suppress C start up code.  The sample programs use a label
called __acrtused.  Does OS/2 know about the name?  What does this label mean
and where is it defined?

In the function MoveBytes in Appendix C, there is an include file called
drvlib.inc.  We cannot find a copy of it in the DDK.  Can you supply a copy?

ANSWER:
1) You have to compile your driver using a 16 bit compiler.  The Simple OS/2
Parallel Physical Deivce Driver example driver in DDK uses MicroSoft C 6.0
compiler.You could also use Watcom C v10.You cannot use Visual Age C++ for
your PDD Development.

2) Yes, the 16 bit call has 5 parameters and the 32 bit call has 9 parameters. 
You have to use one of them depending on the compiler which you are using to
create the application i.e., if you are are using a 32 bit compiler use the call
which has 9 parameters.

3) The driver loader looks into the beginning of the FIRST segment in the .SYS
file to get the header.  This segment has to be the DATA segment with the device
header in the beginning (i.e., 0001:0000).  This is done with the startup assembler
code in which the data segment is defined before the code segment.  THe default
startup code of the runtime library is not used.  This is done in the MicroSoft C
compiler ver 6.0 by using the dummy label "_acrtused".  This is only for the com-
piler not for OS/2.

4) Sorry, we do not own this component.  The MoveBytes function is part of the
book "Writting OS/2 2.1 Device Drivers in C" by Steve.J.  Mastrianni.  In the
sample program he uses his own DevHlp library which is not part of DevCon DDK.
Please refer to Appendix - D in the same book for the C callable DevHlp library.




!I/O____________________________________**********
August 14, 1995
QUESTION: (Ref: I04)
I am Interested in using my VC compiler to produce OS/2 keyboard drivers.  I do
not have C 6.0 available, but I do also have C 5.1.  I need assistance in deter-
mining the appropriate compile and link parameters for either of these compilers.

ANSWER:
When writing and compiling Keyboard device drivers we recommend the following:

 (1) Microsoft MASM 5.1   (3) Microsoft C 6.0     (4) Microsoft CL386

Note:  The numbers in parentheses (below) refer to the numbers in the table
(above).

  Keyboard Device Drivers (16-Bit)

         -  Keyboard (Device Independent) (1)
         -  Keyboard (Device Dependent) (1), (3)
         -  Virtual Keyboard (1), (4)

We cannot guarantee that your driver will build and complie properly when
using any other compliers.



!BASE__________________________________**********
August 14, 1995
QUESTION: (Ref: I56)
Using DevHlp_SetIRQ, we are registering for 4 of the 8259 PIC generated
interrupts.

The application we are porting from DOS to OS/2 occasionally needs to mask
one of the above mentioned 4 interrupts.  Since there is no DevHlp service to 
do this, and since we were advised against directly manipulating the 8259 in
OSDD101 workshop, we are considering the following alternatives to achieve
functionality similar to masking:

Implement an "ignore flag" mechanism in the ISR such that interrupts that
occur during the "mask period" are not processed normally.

Invoke DevHlp_UnSetIRQ to simulate masking, and then re-invoke DevHlp_SetIRQ
to simulate unmasking.  Questions:

Do you envision any race conditions using this strategy?

Does OS/2 ever "pend" interrupts and pass them to a DD's ISR "after the
fact"?

What processing does OS/2 perform when an interrupt from the 8259 is
asserted and no DD ISR has been registered for that particular IRQ?  Does 
OS/2 mask interrupts associated with an IRQ until some device driver invokes
DevHlp_SetIRQ?

If no DD ISR's have been registered for any IRQ's (ie., NONE of the device
drivers identified in CONFIG.SYS invoked DevHlp_SetIRQ), what processing takes
place when an interrupt from the 8259 is asserted?  (I'm wondering if OS/2 masks
all interrupts in THIS case.)

ANSWER:
The architecturally correct method that should be used to mask an interrupt at
the 8259 PIC is to issue DevHlp_UnSetIRQ.

1) There is always the potential that a device will generate an interrupt
right before you issue the UnSetIRQ.  Then the driver may redrive the device, 
complete the ISR processing, and then the UnSetIRQ is issued.  The result is that
the interrupt from the redrive will never occur because the UnSetIRQ was issued.

2) OS/2 does not queue interrupts.  Interrupts are serviced real time in
priority order.  Queueing of interrupts may occur in DOS and/or Windows
sessions.

3) OS/2 masks off a particular IRQ until a device driver issues SetIRQ.  Then, 
when an interrupt occurs, the interrupt manager calls all device drivers 
registered to service that interrupt until a driver claims the interrupt.

4) No, OS/2 does not mask all interrupts in this case.  As long as no device
drivers have registered for the interrupt level, the level is masked off at
the 8259 and the system is not affected by the interrupting device.  If a
device driver is registered for an interrupt level, the device continuously
interrupts on that level, but the device driver does not claim the interrupt
level or cannot clear the interrupt at the device, that is when there is a
problem and OS/2 performance is affected.  There is no case where all
interrupts are masked.




!MULTIMEDIA_____________________________**********
August 15, 1995
QUESTION: (Ref: I11)
I am attempting to alter the environment variables for a DOS session from our
VDD.  The purpose is to ensure all DOS sessions have the BLASTER= setting
correct so that games that use this will run OK.

To do this I am going to alter the DOS session's Program Segment Prefix (PSP)
pointer to the environment block (offset 2Ch in the PSP).  I have hooked the
DOS PDBChange event.  This will give me, according to the DOCs, a V86 segment
of the session's PDB in EAX.  I believe PDB is same as PSP.  OK.

I get 3 DOS change events for every DOS window I open.  NOTE:  there are no
commands run from the autoexec.bat, only SET commands.  I expect the data at
the segment in EAX to have the same format as a DOS standard PSP.  All DOS
PSP's start with a CDh, 20h (this is INT 20h instruction).  All PSP's have the
environment block's segment address at offset 2Ch.


Here is what I find :

1) The first DOS PDBChange event points me to a block that looks nothing like
a PSP at all.

2) The second DOS PDBChange event points me to a block that looks like a PSP.
However, the value at offset 2Ch (which is supposed to point me to the
environment block) is 0000.

3) The third DOS PDBChange event is just like the second.

4) When I launch an app in the DOS window (debug), I get a DOSChangePDB event.
The block pointed to by the V86 segment address is a valid PSP.  However, the
environment pointer does not point to the environment block used by the
application.  This appears to be the one that is used by command.com for all
subsequent sessions.  There is a bug here somewhere in the DOS manager.  The
one used by the app is 210h bytes away.  See dump.  I know because I dumped
the the PSP and environment block from the DOS session and it points to the
other envronment block.  I also altered the values and they get reflected in
subsequent apps but not in the one that was launched.  (debug log removed)

Questions :
Following the first 3 DOSChangePDB events on a DOS window opening (all of
these events provide no valid pointers to environment block).  I get a DOS
prompt and can do the SET command and see environment variables.  Where are
these settings stored?  How can I get to them?

Is the PDB the same as a PSP?

ANSWER:
PDB (Process Data Block) == PSP (Program Segment Prefix) == PID (Process ID)
in the DOS world.  Why does DOS have 3 names for the same thing.  We can not
determine this.

The miscellaneous ChangePDB notifications appear to be a minor "bug" that
could be fixed.  After OS/2 2.0 went out the door it was noticed that some
ill-behaved DOS apps would fail 2-48 hours into operations.  It turns out the
problem was that the bad apps were "poking" values into the DOSKRNL data area,
deliberately overwriting the "CurrentPDB" value.  As long as they repaired the
CurrentPDB value before the next timer tick that performed file I/O they were
fine.  Since the CurrentPDB identifies the current process's JFT, changing the
CurrentPDB changes the JFT.  File I/O then goes to someone else's open handle.
In the source code of the DOSKRNL we have a macro called "SVC" which is used
to make a pseudo-call from V86 mode to ring 0 OS2KRNL mode.  "DemDispatch" is
the SVC dispatcher in the OS2KRNL.  On entry of every SVC we check the DOSKRNL
data segment's CurrentPDB against what we believe to be the current PDB value.
If they differ, we change the value in the OS2KRNL and notify all who have
registered for notification.  There are a couple of miscellaneous SVC calls in
the DOSKRNL init code before the 1st PDB is setup.  That's why you are seeing
the strange calls during VDM initialization.  To get rid of these bogus
notifications, a flag could be set to ignore the CurrentPDB check until it is
established for real.  The number of bogus notifications will depend on the
number of SVCs before the 1st PDB is established.  This will be highly version
dependent and not easily predictable.

The next problem appears to be related to the environment segment.  In the DOS
world the environment segment has traditionally been owned and controlled by
the user shell (COMMAND.COM) and not the base OS (i.e.  IBMDOS.COM or
MSDOS.SYS).  Only recent versions of DOS have any cognizance of an environment
at all.  The second problem with DOS environments are they tend to be highly
space constrained.  The 32K limit isn't a factor as much as a DOS child
process is only allocated just enough room for an environment.  The only safe
and secure environment altering means in the DOS world is the user shell "SET"
command.  Obviously DOS apps aren't going to issue a SET command.  But it is
almost impossible to come up with a 100% foolproof environment alteration
scheme in the DOS world (99% yes, but not 100%).  To add confusion a user
doesn't have to use COMMAND.COM.  They could use 4DOS or even their own home
grown shell.

Having a VDD poke values into the DOS environment is a mistake.  That will
cause as many problems as it solves.  When DOS Execs a child process it
allocates just enough space for the child's environment, plus 2 bytes, plus
the asciiz name of the child program.  If no "SET BLASTER=" statement exists,
there isn't room to add it.  Adding to the end of the environment will overlay
the asciiz child program name.  C programs that want to use argv[0] will now
fail; because that's were argv[0] comes from.




!NETWORK !OTHER_________________________**********
August 15, 1995
QUESTION: (Ref: I73)
I am currently adding National Language Support for error and status messages
to an existing NDIS driver.  This driver is written in assembly language.  I
have already added this support to the DOS version.  What I need to find out
is how to read the country code in OS/2 from within a physical device driver
at INIT time.  In the DOS version I use Int 21, Function 65h (Get Extended
Country Information).  The Developer Connection CD-ROM that I looked at states
that this call is only supported in a DOS session under OS/2.  What function
is the equivalent of this for OS/2 and can I call it at initialization time
from a physical device driver written in assembly language?  The DOS version
of NDIS National Language Support is works like this:

    read country code
    build message file name from country code
    open message file
    read message file, overlaying default message table
    close message file.


ANSWER:
You can get the country code information at INIT time by using " Query
Keyboard Code Page Information" Keyboard IOCtl command( Category = 04h,
Function = 7bh).  Refer chapter 10 "Generic IOCtl commands", section "Keyboard
IOCtl Commands" in PDD reference.

For the calling sequence of DosDevIOCtl in assemnly refer chapter 10 "Generic
IOCtl Commands", section "Generic IOCtl example" in PDD reference.  view.




!OTHER___________________________________**********
August 15, 1995
QUESTION: (Ref: I81)
Our transient utility program used for the control/query of our 3270/5250
PCMCIA cards requires access to the Card Services platform for basic query and
control.  This DOS program typically calls the Card Services CSS functions via
Interrupt 1A.  This technicque is not supported directly under OS/2.  We
understand that a system driver accesses CSS via the address provided via
AttachDD - DeviceHelp.

How does a transient utility program gain access to the Card Services entry
point?  Is there a system function that may be used by a transient program to
gain access to DeviceHelp?

For protected mode clients that have access to the Device Help entry the
AttachDD function is used.  But for transient programs, how does the utility
gain this entry point?  It would seem that the this entry would have to be
used as the basic control point to gain access to the various devices and
drivers within the system.  What are the binding requirement differences if
any for DeviceHelp?

ANSWER:
There are no documented IOCtls for the PCMCIA Card Services Driver and hence
it wouldn't be possible to access the Card Services from a Ring 3 Application.
You are required to develop a client PDD to access card services through
AttachDD DevHelp call.




!VIDEO__________________________________**********
August 15, 1995
QUESTION: (Ref: I97)
I am trying to find documentation on the VioSetState call, which is used by
the SVGA sample driver.  I've looked in DDK references, DevCon, etc.  and
haven't yet been able to find it (nor much information on other VIO calls).
Could you direct me to the right place to look?

ANSWER:
The VIO calls (INF file) are available in the OS/2 1.3 toolkit.





!BASE___________________________________**********
August 16, 1995
QUESTION: (Ref: I57)
This project is a one-off, so I have not been able to gather many resources.
I am using the Watcom 10.0a C++ compiler with a library by David Bollo, and
further guidance from Steven Mastrianni's book.

I need to accomplish two things:
 a) transfer data between the board's memory-mapped buffer at 0D8000h and
    an application program, and

 b) retrieve the current time and date from the global information
    segment and place them in the driver's data space.

So far I have not found the correct method for setting up addressing for these
accesses.

Transfers a) are needed at both initialization and task times.
Transfers b) are only needed at task time. Neither is needed by
either the interrupt or the timer handlers.

I have attempted to use the PhysToVirt device helper function, but without
success.

ANSWER:
a. You could transfer the data between board's memory mapped buffer and an
application program in the following manner:

  1. Use AllocGDTSelector devhelp function to obtain a GDT selector at INIT
  time.

  2. Make PhysToGDTSel DevHelp call to map the GDT selector to physical
  address of the board's memory.

  3. Use the MAKEP macro to make a far pointer from the Sel:Off value You   
  can access this memory at initialization and task time.  Your application
  through DosRead and DosDevIOCtl can call drivers strategy routines for
  transferring data.

  Ref:  Steve Mastrianni's book "Writing OS/2 Device Drivers in C" chapter              
  on memory mapped adapter and source code listing for this in appendix c.

  You could also refer the source code:
  ddkx86\src\dev\dasd\ibm\ibm2flpy\fl2trace.c

b. You can retrieve current time and date from Global Information Segment
using GetDosVar DevHelp call with index = 1.  Please Ref:  GetDosVar DevHelp
function in PDD Reference.




!BASE___________________________________**********
August 16, 1995
QUESTION: (Ref: I59)
Why is it that OS/2 limits you to 64 meg of RAM and video RAM that the system
can see?

Also, why is it that the system will default to a video aperture size of 64k
if you have more than 4 meg of VRAM.

ANSWER:
I don't know of any limitations that sound even close to what is described
in your note.

We do have drivers which use linear apertures and there are no limitations on
the size of such linear apertures, when mapped properly!

There is no limitation of 64 Mega Bytes of RAM as System RAM.  In fact OS2
supports up to 4GB of System RAM and 512 MB of RAM per process.

In the Video display adapters the VRAM mapping would be done below 64 MB
memory space for non-ISA Bus system and below 16 MB for ISA Bus system.

Non-ISA Bus
        System RAM         VRAM Aperture     Mapped Addr
          60 MB              4 MB           3c00000
          62 MB              2 MB           3e00000
          63 MB              1 MB           3f00000
       >= 64MB               64KB           A0000

ISA Bus System
        System RAM          VRAM Aperture    Mapped Addr
          12 MB              4 MB            C00000
          14 MB              2 MB            E00000
          15 MB              1 MB            F00000
       >= 16 MB              64KB            A0000

The reason for having video aperture 64KB for more than 4MB of VRAM is due to
the hardware memory access of the S3 display adapter depending on the System
Bus.  Please Ref:  \ddkx86\src\pmvideo\s3tiger\s3qesc.c, function FindS3Aperture.

FOLLOWUP QUESTION:
Here's where things stand concerning getting the correct aperture size with
FindS3Aperture.  If you use the DDK 1.2 pmvideo\32bit\s3qesc.c code you will
see that there is a #define ISA_BUS 2. This causes a problem because the S3
chip when asked what kind of bus is being used will return 1 for vlb and 2 for
pci.  Therefore when the check is done to see if it is not an isa bus the compare
will be equal and they shouldn't be.  I do realize that on the 2.0 ddk the code is
fixed and ISA_BUS is defined as 3 (which it should).  The reason we didn't see
this is because the 2.52 driver that was downloaded from S3 for the 964 S3 chip
has this bug in it.

Could you please explain why if the system can see up to 4 gig of system
memory (which you stated in your answer to me) that the card will tell you an
address which is entirely based on 64 meg of RAM (for non isa).  Isn't it actually
a limit of 4 gig for linear addressing (virtual memory).

FOLLOWUP ANSWER:
How is the card configured is not determined by the "system", but by the
handler which is performing the setmode functions.  As far as I know, the S3
driver shipped by S3 is setting the mode by issuing VioSetMode and their
BVHSVGA is executing a VESA BIOS call (or an equivalent) which could explain
why the aperture is programmed for 0xA0000.  S3 driver from our DDK is also a
banked (not a linear frame buffer) driver, so our setmode (provided by PMI
subsystem) is setting the aperture to 0xA0000.  When a driver wishes to use
linear aperture, it has two choices.  Either change the BVHSVGA to set such
aperture (if PMI used, then change the PMI setmode) or add code to the driver 
to make aperture changes after the BVHSVGA setmode has completed.  Once the
card is configured for the correct aperture, a linear mapping for such physical
address has to be obtained before referring to it.  You do this either by calling
PMDD ioctl or SCREENDD ioctl (function B) to do so.  There are a bunch of OEMHLP
IOCTl's which also allow you to read the PCI configuration space state (applies
only to Warp though) and also sample codeof how screendd uses these ioctl at
its init time to get to the configuration space.  The ioctl's can be used by ring 3 
components, although I don't know if they reflect the state of the space at the 
boot time or the actual state at the moment.


There should be more information in the latest DDK PDD reference You may find 
them useful to determine the base addresses, although since video is not confor-
ming to any device management, you are also free to make your pick (risk  of 
contention included then).  As for the references to the bus type, I don't really
know what the issue is all about.  Too little information as to the actual symptom
is given.  So, if you need to make code changes to the S3 driver that is in DDK,
you will that it is a banked driver, and that its setmode is also banked.




!VIDEO__________________________________**********
August 16, 1995
QUESTION: (Ref: I68)
On the DDK 2.0 CD ROM there is the PMVIDEO 32bit directory which contains the
code for the XGA 8514a and S3.  Well, I built it and It will not work.  when I
copy the file over to the os2\dll directory (ofcourse after rebooting) and reboot
again the presentation manager comes up but without any icons on it. Another
machine I tried it on the shell would not initialize.  The S3 chip is a 968, any 
ideas?  I need to be able to build this so I can debug the size of the aperture 
being given.

ANSWER:
The supported chips for S3 display driver is listed in OEMLIST.INF.  But S3
Chip 968 is not supported in the existing source code in the DDK.  S3 968
Driver is however available from the Vendor - MIROBBS.  You are required to
modify the hardware dependent code in the palette.asm, hwaccess.asm.

Ref:  Display Device Driver Reference for OS/2, on DevCon DDK 2.0 CDROM,
Section "s3 displaydriver", section "strategies for Adapting the Driver to
other chipsets" and s3.DSP (sample file for installation & configuration).




!OTHER__________________________________**********
August 16, 1995
QUESTION: (Ref: I71)
Can you suggest methods of APP->SCSI communication?  I do need to send CDBs
to the device so generic IOCTLs do not have the ability (I think?)

ANSWER:
You can either use the OS2SCSI (SCB) interface or the OS2ASPI (ASPI SRB)
interface.  Both are documented in the DDK. The ASPI interface is also
documented on the Adaptec BBS.

The ASPI SRB interface is identical to the DOS interface except for the
requirement to write a PDD to handle the SRB completeion callback.

The generic Disk IOCtls are documented in the Physical Device Driver Ref. and do
not have any IOCtls for CDBs.  You could also refer to the Appendix - "OS/2 SCSI
Device Driver Interface Specification" for the SCB Interface & "Advanced SCSI
Programming Interface(ASPI) OS/2 Specification" for the SRB Interface. (Both are
available in the Storage Device Driver Ref on Devcon DDK V2.0 as well).




!OTHER__________________________________**********
August 16, 1995
QUESTION: (Ref: I88)
CCFG.EXE Capstone 3270/5250 PCMCIA card manager utility - DOS Erratic DOS
program behaviour under DOS

A portion of this program is used to read and write various Flash memory
devices that are used on the Capstone MicroLink 3270/5250 PC Card.

We experience extremely erratic behaviour, including total or partial loss of 
data integrity (during a write flash phase) if we use the following macro to 
force a cycle delay:

        CYCLE_DELAY     macro
              push    ax
              in      al, 61h
              pop     ax
              endm

In actual use, the CYCLE_DELAY instruction may be repeated from 1 to
3 times.

Workaround/Change:
Changed I/O port address from 0x61 to 0x80 - now program functions!

Why is the system failing?  I expect that port 0x61 is trapped by the kernal, but
it is also trapped by Windows and this does not cause any erratic behaviour un-
der DOS/Windows or Netroom Cloaker.

ANSWER:
When Virtual DOS Machine (VDM) is created and once DOS emulation is complete, 
VDM Manager installs default I/O hooks, page fault hooks or INT hooks. Control is
passed to the DOS emulation kernel.  The virtual device drivers virtualize all
standard features to maintain a separate hardware state for each VDM, including
direct programming of I/O ports.  Some of the ports are claimed by VDD's.  The 
port 61h (speaker port) used in your CYCLE_DELAY macro is already claimed and
may cause erratic gram.  I/O port address 80h is not claimed, (although all ports
are trapped by DOS kernel) so it gives expected cycle delay in VDM on OS/2.

Refer chapter 3, 8086 Emulation, section 3.3 I/O Port Trapping of OS/2 V 2.0 
-DOS and Windows Environments.




!OTHER__________________________________**********
August 16, 1995
QUESTION: (Ref: I89)
CCFG.EXE Capstone 3270/5250 PCMCIA card manager utility - DOS Spurious program
"stalls" under DOS - continues if key or mouse activity

During the diagnostic tests of the adapter, the system often times just STALLS 
during some of the tests.  Execution continues if any keys are touched or if mouse
is moved.

In this case, a program loop (attached) calls out to CheckEscape to see if the 
escape key has been depressed (to end a looping diagnostic).  Depending on the
actual test phase (testing memory, I/O, IRQ or host system activity) the rate at
which CheckEscape is called changes.

Temporary workaround:
A workaround as indicated in the code stub below, is used to PREVENT calls to
CheckEscape while operating under OS/2.  This also causes unacceptable
behavior in our program since it is very difficult for the user to end a looping
test.  But, at least the program continues...

What is the correct manner to do this under OS/2 and maintain DOS compliance?

ANSWER:
In the DOS session the Virtual Keyboard Device Driver supports Idle Detection so
that DOS applications must not waste execssive CPU time when in input peek 
loops.  The following two settings determine the way in which the OS detects
that an application in the VDM is currently idle.

IDLE_SECONDS
IDLE_SENSITIVITY

The application using CPU time depends on the other OS/2 processes.  If the
application receives input while running and seems to run slower than expected,
the idle sensivity should be set to a higher value.  You can adjust these two
parameters via DOS Settings pop up menu.  It is also possible to develop a VDD 
which will detect ication by VDHWakeIdle VDD DevHelp function.

However, we have tried out your test case ( it checks for Escape Key and
outputs a '*' on the display) and found that DOS application runs smoothly.
Whenver any other application is executed on OS/2 window, the DOS application
is slowed down.

Ref:
1.  Chapter 11, DosSettings, section 11.2.6 Idle Detection, OS/2 V 2.0 Vol
    2 Dos and Windows Environments.
2. Chapter 3, Base Virtual Drivers, section Idle Detection Support in VDD
    Reference.




!OTHER !STORAGE_________________________**********
August 16, 1995
QUESTION: (Ref: IA0)
I intend to experiment with an extension (IOCTL) to the driver OS2DASD.  I set
out to write a small C program which would OPEN the driver, issue an IOCTL,
then CLOSE the driver.

I'm not having any luck opening the driver.  Could you provide me with some
sample source code (or a pointer to same) showing the proper way to open this
driver?


ANSWER:
1. The OS2DASD driver can be opened by specifying the drive letter in DosOpen
call.  You can make the DosOpen call with the following parameters :

    DosOpen( "C:",   // Drive_Letter:
                 &FileHandle,
                 &ulAction,
                 0L,
                 FILE_SYSTEM,
                 OPEN_ACTION_OPEN_IF_EXISTS,
                 OPEN_FLAGS_DASD | OPEN_SHARE_DENYNONE | OPEN_ACCESS_READWRITE
                 0L ) ;
Refer chapter 2,Control Program Function, section DosOpen in "Control Program
Programming Reference".  After getting the handle, you can use Generic IOCtl
Category 08h.
***********************************************************************
#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("C:",&handle,&action,0L,0,1,0x80c2,0L);    /* use Hard Disk Drive
   Letter */ 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);
}



2. You can also use some of the functions in the Category 08h without doing
DosOpen.  in this case, use -1 as the file handle.  Refer chapter 10 Generic
IOCtl Commands, section Category 08h Logical Disk Control IOCtl commands in
"Physical Device Driver reference".

3. In case of Generic IOCtl category 09h, the handle used must be returned by
DosPhysicalDisk.  You can make DosPhysicalDisk call with the following
parameters :

DosPhysicalDisk( INFO_GETIOCTLHANDLE,
      &Data,
      sizeof(USHORT),
      "1:",    //Disk_Number:ASCIIZ -partitionable disk
      3 ) ;    //sizeof ASCIIZ string that specifies the partitionable disk.
Refer
1. Chapter 2, Control Program Function, section DosPhysicalDisk of "Control
Program Programming Reference".

2. Chapter 10, Generic IOCtl Commands, section Category 09h Physical Disk
Control IOCtl commands in "Physical Device Driver reference".




!VIDEO__________________________________**********
August 16, 1995
QUESTION: (Ref: IB3)
I am making VGA.DLL and VGA.SYM from DDKX86\SRC\PMDISP\EGAFAM\EGAVGA\DEBUG, I
copy them over to OS2\DEBUG\DLL\DISPLAY.DLL and DISPLAY.SYM.  Deleting
OS2\DLL\ DISPLAY.DLL.  Reboot system.  PM still comes up, but not my VGA.DLL
(I put a INT 3 inside my VGA.DLL, I expect the display driver stop).  This
tells me OS/2 didn't go to OS2\DEBUG\DLL subdirectory looking for my
DISPLAY.DLL driver.  Where did it go?  What file name it looking for?

Making VGA.DLL and VGA.SYM from DDKX86\SRC\PMDISP\EGAFAM\EGAVGA\RETAIL, copy
them over to OS2\DLL\DISPLAY.DLL and DISPLAY.SYM.  Reboot system.  PM comes
up, stop at my break point, INT 3, of my VGA.DLL.  Symbols are working.

I did install Debug PM in Debug Kernel.

Should I use RETAIL version instead of DEBUG version?

ANSWER:
When you install the debug kernel, just select the options for - Install
utilities/symbols, install debug kernel.  Do not install the Debug PM at this
stage.

Get to src\pmdisp\egafam\egavga directory and invoke - nmake VGADEB.  This
will create the debug version of VGA.DLL.  Rename this to DISPLAY.DLL in
OS2\DLL directory (NOT in the OS2\DEBUG\DLL directory)

You should be using the DEBUG Version.






!I/O______________________________________**********
August 17, 1995
QUESTION: (Ref: I92)
We develope a serial keypad that passes scan codes to the IBMKBD.SYS driver in
OS/2 Warp.

We have a customer that has a Thinkpad 350c running OS/2 2.10.  This machine
(or OS/2 version) does not have the IBMKBD.SYS driver in the CONFIG.SYS (or
even on the drive).  What is available to pass scan codes to the system in
this version of OS/2?

If there is a diferent method for 2.1x of OS/2, how can I detect, in the
driver, what version of OS/2 is running so I can make the appropriate calls to
setup the IDD communications, and correct call to pass the key codes.

ANSWER:
In OS/2 2.1, Keyboard Device Driver will either communicate directly with the
hardware( ISA/ EISA bus) or with ABIOS (PS/2 Microchannel Bus).  OS/2 will load
kbd01.sys for ISA/EISA machines and will load kbd02.sys for Microchannel machines.

You can perform IDC with the Keyboard Device Driver in the following manner: 
1. Call AttachDD DevHelp call to obtain the address of IDC entry point.
(Device name = "KBD$ ").

2. Call DD_Cmd_Entry, the keyboard device dependent IDC Entry point and
request router routine( \ddk\src\dev\kbd\kbd02\kbdhwdd.asm ) with the
following four parameters on stack:

 a. Return Address.

 b. Function Code ( described in ddk\src\dev\kbd\kbdddr.inc).
       For strategy time execution, function code has MSB = 0.
       For interrupt time execution, function code has MSB = 1.

 c. Variable 1, which is the pointer to Output data structure for most
       commands.

 d. Variable 2, which is the pointer to Input data structure.

For eg.  of IDC communication refer to sample code in:
\ddk\src\dev\kbd\kbdfilt.asm

You could detect the version of OS/2 running by using GetDosVar DevHelp call
with and Index =1.  You can get the Major and Minor version number based on
whichyou could make appropriate calls to set up IDC.

Refer chapter 9 Device Helper Services, section GetDosVar in PDD reference.

FOLLOWUP QUESTION:
I don't have the directory 'kbd02' on my ddk, so I am looking for some
clarification on the procedure you describe.

I don't see kbd01.sys (or kbd02.sys) loading in an OS/2 2.10 config.sys file. Are
these loaded automatically?

For Warp, I currently attach to IBMKBD.SYS through Attach_DD call during init. 
Key scan codes are passed by:

pushword ptr 2      ; function #
push   offset KeyBuffer
pushds
pushIDC_handle
calldword ptr Kbdaddr+6   ; returned by attach_dd

The method you describe in #2 of your response, is that for 2.1x of OS/2?

FOLLOWUP ANSWER:
kbd01 and kbd02 directories are available in \ddk\src\dev\kbd in DDK Ver 1.2.
Since keyboard is a base device driver, it will be loaded automatically via Int 
13h from the root or \OS2 directory.  Keyboard device driver (KBD0x) is not
loaded through config.sys file.

The method suggested for IDC in our previous response is for OS/2 Ver 2.1x.
IBMKBD is for Warp,where we moved to the two layer architecture - device
dependent & the device independent layers.

The method of getting the version of OS/2 running by using GetDOSVar DevHelp
call is applicable for both OS/2 V 2.x and OS/2 Warp.




!VIDEO__________________________________**********
August 18, 1995
QUESTION:  (Ref: I77)
The MONITOR.DIF file supplied with Warp leaves something to be desired, from our
point of view:

1.  The entries for some monitors are far too conservative.
2.  Entries for the resolution 1152x864 are not supplied.

So my question is, does IBM have an updated MONITOR.DIF that we can ship and/or
use as a base for our own modifications?



ANSWER:
MONITOR.DIF can be updated by anyone who could get their hands to it.  It took con-
siderable effort to come up with the database that includes most commonly used 
monitors with their most commonly used resolutions, as a way of handling the legacy 
monitors until the DDC enabled monitors arrive and become a common place.  The 
refresh rate values were picked from manufacturer's specs, so if they are conserva-
tive, then the spec must have been either misread or incorrect to begin with.

We do take official requests from monitor manufacturers and update the monitor.dif
entries.  However, there is no vehicle for the update distribution other than a set of 
display drivers which are placed on our bulletin boards.  So, the bottom line is, two
things can be done.  The manufacturer can send their list of updates to us and we 
will build the monitor.dif and give it back to them for distribution.  Or they can bypass
us and ship their own version of monitor.dif with their drivers.  The first choice
ensures that the next release of OS/2 will have their updates in the monitor.dif 
(altough it may not have their drivers).





!I/0____________________________________**********
August 18, 1995
QUESTION:  (Ref: I83)
I am trying to call KbdIDC from C.  When I look at the data structure returned
from DevHelp_AttachDD, I find a structure with PVOID Rmode, USHORT Rds,
PVOID Pmode, USHORT Pds.  Which of these structure elements correspond
to the parameters Data Offset, Data Segment, and Handle (code Segment) for 
the call to KbdIDC?

ANSWER:
The parameters to be passed to KbdIdc are:

1. Data Offset, which should be set to 0.
2. Data Segment, which should be set to Pds obtained from AttachDD
   DevHelp call.
3. Handle, which should be set to Pmode obtained from AttachDD DevHelp
   call.  Please refer to Chapter 9 " Device Helper Services", section 
   "AttachDD" of the PDD Reference.



!OTHER__________________________________**********
August 18, 1995
QUESTION:  (Ref: I95)
I am devloping a 16 bit device driver for a memory mapped ISA board for OS2.
The driver was written using Microsoft 5.1.  I am having a problem interfacing
to my driver from a 32 bit sample application I have developed.  The problem
has to do with 32 bit pointers being passed within a private structure through
an IOCTL.  I am attempting to use VMProcessToGlobal to map the 32 bit callers
buffer into my address space, my problem is that the DevHelp service keeps 
returning 0x57 (87) INVALID PARAMETER.  My code fragment looks as follows:

typedef struct
{
        void far *pBuffer;
}PRIVATE_BUFFER;

DeviceIoctlHandler(PRIVATE_BUFFER *pPrivateBuffer)
{
void far *pMem;

VMProcessToGlobal(pPrivateBuffer->pBuffer,0x1000,1,&pMem);
}

The PRIVATE_BUFFER structure is passed through the parameter field in the
Ioctl request and the kernel translates the structure pointer fine.  But the
private pointer 'pBuffer' is set by the 32 bit application to 0x4D3A0.  I have
also tried to call VirtToLin before calling VMProcessGlobal, VirtToLin just
turns the buffer address from 0x4D3A0 to 0xD3A0 and my return from
VMProcessToGlobal is still 0x57.


ANSWER:
Refer to DevHlp_VMProcessToGlobal in the PDD Ref. - the address range
pBuffer must be on a page boundary and must not cross object boundaries.
The address you pass - 0x4D3A0 is'nt on a page boundary and hence the
error - INVALID_PARAMETER.




!MULTIMEDIA_____________________________**********
August 18, 1995
QUESTION: (Ref: IA3)
.AVI plays over Win/OS2 fullscreen and wipes out DOS fullscreen.  We have seen
this problem with other SVGA adapters/drivers we have tried.  Our quick and dirty
solution is to check the foregroundsession flag set by GreDeath/GreResurrection
when AcquireFB is called, and return DEVESC_ERROR to the calling application if
PM is not in the forground.  Is there a problem with this approach?  If so, what
is the correct way to be handling this case.  Any ideas?

ANSWER:
The display driver supporting software motion video (such as playing .AVI
files), must support multimedia hook functions:

    DEVESC_ACQUIREFB
    DEVESC_DEACQUIREFB
    DEVESC_SWITCHBANK

Death and Resurrection functions are used when switching to and from full
screen windows, DOS or OS/2 sessions.  Death function handles the switching of 
PM into the background and Resurrection function performs the inverse task. You
are required to implement these functions in your PM display driver.

Ref: Chapter on "S3 Display driver", section "Multimedia hooks" in "Display
     Device Driver Reference for OS/2" on DevCon DDK V2.0.

You can also refer to software motion video Dev Escapes functions in the
source code:

    \ddkx86\src\pmvideo\s3tiger\s3qesc.c in DevCon DDK V2.0
    or
    \ddk\src\pmvideo\32bit\eddqesc.c in DDK V1.2




!I/O_____________________________________**********
August 18, 1995
QUESTION: (Ref: IA7)
I am trying to compile a keyboard device driver.  I get an error on the
following statement in kbddd.h:  USHORT FAR _loadds IDC_Entry_Point(USHORT
Req, USHORT Req_off, USHORT Req_Seg); It says the function declaration is
invalid.  and points to _loadds.  I have considered the various #ifdef but
there are no #ifdef in effect before this function declaration.  Please
advise.

ANSWER:
The keyboard device driver must be compiled using 16 bit compiler.  You cannot
use ICC compiler (32 bit ) to compile the driver.  The recommended compiler for
this driver is Microsoft C 6.0.

Refer chapter " DDK Roadmap", section Device Drivers and Build Structure
(Keyboard Drivers ) in "Using Your DDK".



!OTHER__________________________________**********
August 23, 1995
QUESTION: (Ref: I02)
My company wants to support its new Plug & Play card (not PCMCIA) on OS/2 and
I want to know if, otherwise then just PnP for PCMCIA, OS/2 is supporting
Plug & Play. If not, I would like to know if and when this (PnP hardware on
ISA) will be supported on OS/2?

ANSWER:
Our future OS/2 plans call for full Plug and Play support, ie., automatic
recognition, installation, and configuration of PnP devices, dynamic loading
and unloading of device drivers, and a graphical user interface to assist with
installation and configuration of legacy devices.  IBM will provide code
samples in the OS/2 DDK, will hold PnP workshops to show IHVs how to develop
PnP drivers (along with necessary tools), and we will include PnP drivers in
future OS/2 products.



!STORAGE !PCMCIA________________________**********
August 23, 1995
QUESTION:  (Ref: I94)
Q1.  How do I modify the IBMIDECD.FLT quickly so as to initialize itself after
the client driver is loaded or how can I fake the IBMIDECD.FLT initialization
to reserve at least one unit?  How can we do the initialization later (after
the card is inserted)?

A1.  At the present time, there is no way to reinitialize an OS/2 DD that con-
trols DASD after the system has booted.  You are on the right track with the
"Device Faking" approach.  We have developed, with Communica Inc., Bourne,
MA, a set of drivers that fake the presence of certain devices regardless of the
actual HW present.  The faking is controlled by device driver config.sys para-
meters.

We are in the process of writing a "How To" document which should provide
sufficient information for an IHV to implement this type of Faking logic.  This
is planned to be available to IHVs, for no-cost, within 90 days.

You can also contact Communica directly for technical assistance in designing
such an interface.  Communica is free to release this information however they
are not under contract with IBM to supply consulting services to IHVs seeking
such assistance.  As such, they will likely charge you for their service.  The
correct people to contact at Communica are:

             Matt Trask or Barry Kasindorf
             508-759-6714


Q2.  Will the IBMIDECD.FLT be suitable for HD, MO and CDR?

A2.  No, IBMIDECD.FLT is specific to CD-ROMs and will not attempt to communicate
to any other type of ATAPI device.


Q3.  Will it be possible to modify the CIS information on the PCMCIA/eIDE card
so as to use the PCM2ATA.SYS to open the Secondary IO from 170-177, 376-377 and
RQ15?  If it is possible, we don't have to have the client driver.  Is it possible?
If so, how do I modify the CIS?

A3.  This sounds like a HW manufacturer issue.




!BASE___________________________________**********
August 23, 1995
QUESTION: (Ref: I96)
1) Can a BASEDEV .FLT do real mode INTp 13h calls during the initialization
processing?  If so, how?

2) Can any function number be used, including those not currently used by IBM?

3) During the message that indicates the BASEDEVs will be used for all I/O
from now on, can any real mode interrupts be done?

4) Does any software, including OS/2, bypass the filters that have registered
and directly access the drive?

5) How does FDISK read the master boot record when doing a display function?
It is seeing something I don't think it should.

6) Does OS/2 cache the master boot record?

ANSWER:
1) A BASEDEV .FLT cannot call INT 13h during initialization.

2) None of INT 13h functions can be used.

3) No real mode interrupts can be done, since it is running in protected mode.

4) Normally no software calling through OS/2 can bypass the filter that have
    registered.

5) FDISK util reads the MBR from the drive using DosDevioctl() call to read the
    MBR sector.  The Device Driver "decodes" what it think is the MBR.  (The first
    sector of the drive).  What does the user mean by "seeing something that it
    should not"?  Need more info.  (Is there a Bios translation/ disk compression
    utility in play?  etc..)

6) DosDevIOCTL category 9.

FOLLOWUP QUESTION:
1) Would capturing the UNITs prevent even some abnormal program from
bypassing us?  No only do we have encryption to handle, we need to limit
access also.

FOLLOWUP ANSWER:
1) A filter device driver can allocate permanent ownership of the target unit
from the downstream driver and present a device table containing the new
representation of the unit to any upstream drivers.  Since the filter device
driver retains the ownership of the downstream resource it can construct a new
UNITINFO table to contain the approriate information for presenting a logical
view.  This effectively hides the target units allocated by the filter device
driver.  By hiding the unit the customer can limit the access.

Refer to "Storage Device Driver Reference", chapter on "Using Filter Device
Drivers".




!OTHER__________________________________**********
August 23, 1995
QUESTION: (Ref: IB4)
My Driver Allocates an "extra context" at init time and later this extra
context is armed, and basically sits in an endless loop of calling another
driver via IDC entry point for data.  I appears that some parts of OS/2 eg.
PULSE, believe that the CPU usage is absolutely pegged whenever the extra
context does a ProcBlock.

Am I not allowed to Block in an Allocated Context or is PULSE sick?

ANSWER:
You cannot use ProcBlock in an allocated context since the Hook_Handler cannot
be preempted.  Refer the Remarks section of AllocateCtxHook, chapter Device
Helper Services in PDD reference.

Context hook processing is stealed to ring 3 processes & threads so if you
block in a context hook you'll block the thread which should be dispatched
after the context hook , thread which was the next dispatchable and so may
belong to any running application.  Try to generate a trap with a verify access
in a context hook and you'll see random applications trapping in ring 3.




!OTHER__________________________________**********
August 25, 1995
QUESTION: (Ref: IA8)
I am working on OS/2 WARP DDK.  I have installed the "compiler and Runtime
libraries" components of VisualAge C++ and tried to rebuild "ibmgpmi.dll".
The makefile cannot find "dde4mbs.lib" and "dde4mbso.lib".  Where can I get
those two libraries?  Do I install other components to get those two
libraries?


ANSWER:
These libraries have been replaced in VAC++ with CPPOM30 and CPPOM30I.
However, you should *avoid* explicitly linking in runtime libraries if at all
possible, and let the compiler select them via the /Gm, /Gd, and /R compile
switches.  This insures that the runtime and code match, as there are some
subtle differences in the compiler header files for single and multithreading.
It also insulates you from compiler library name changes, like this.

You should also link via ICC if you want the make file to be compatible with
both C Set++ and VAC++, as VAC++ is incompatible with LINK386....




!VIDEO__________________________________**********
August 25, 1995
QUESTION:(Ref: IB2)
1. How can a fullscreen windows driver determine, if it is running under
Win-OS/2 or under Win3.1 started from DOS?

The fullscreen windows driver is used with standard Windows 3.1 (booting DOS
and typing "win") or it is used as a fullscreen Win-OS/2 driver (booting
OS/2).  How can I determine the difference?  Perhaps there are some escapes
available under Win-OS/2, but not under Win3.1.

2. How can I start a fullscreen DOS session from an OS/2 application?



ANSWER:
There is no API to do this, but what you can do is issue an INT2F Function
4010.  Then look in the AX register and review the value:

If AX = 0, then you are under OS/2 2.0 or higher
If AX is not equal to zero, then you are running under DOS or OS/2 1.X.

If BX = 1400, then you are using OS/2 2.0
If BX = 140A, then you are using OS/2 2.1 or newer.

You can refer to the VDD reference guide under VDHRegister API (2F)
for furthur details.

You can start a full screen DOS session from OS/2 application using
DosStartSession call.  Refer chapter "Control Program Functions", section
DosStartSession in Control Program Guide and Reference.




!VIDEO__________________________________**********
August 25, 1995
QUESTION: (Ref: IC1)
I am unable to build the VGA32 drivers.  I get assembler errors, all related
to macros and INVOKE.  I am using MASM 6.00B.

Is MASM 6.00B the problem?

I have not modified any of the code, except the MAKEFILEs to alter the
directory structures defined in them.  Problem occurs whenever INVOKE is
called, either in a macro, or directly.


ANSWER:
The Build Requirement for the 32 bit VGA Display Driver is MASM Version 6.00
and not MASM 6.0B.  The code in the DDK is the Production Code and as stated
in DDK documentation requires Microsoft Macro Assembler Version 6.00




!VIDEO________________________________________**********
August 25, 1995
QUESTION: (Ref: IC5)
Based on 640x480x16 color driver, I want to create an 800x600x16 color driver.
I modified SCAN_CNT=600 (was 480) inside of MAKEFILE under DDKX86\SRC\PMDISP\
EGAFAM\EGAVGA subdirectory.  And changed SCREEN_CX=800 (was 640) in
EGAMEMD.ASM.  SCREEN_CBSCAN=100 (was 80), SCREEN_DSCAN=100 (was 80).  It
didn't work.  I couldn't recall whatelse I did before.  800x600x16 color
driver should be pretty simple.  Would you me know?

There are four modes support in DDKX86\SRC\PMDISP\PPXY\8514\8514INIT.ASM:
                640x480x4 mode (16 color)
                640x480x8 mode (256 color or 16 color ????)
                1024x768x4 mode (16 color)
                1024x768x8 mode (256 color or 16 color ????)


Our hardware does support 800x600 mode.


Windows call BIOS doing mode set.  OS/2 through Video Device Handler setting
different mode.  Would you give me a little bit more information how to do it?
(Because kernel debugger can not set break point on I/O, it's hard for me to
trap where PM doing mode set).  DDKX86\SRC\VDH generates BVHVGA.DLL,
DDKX86\SRC\ SVDH makes BVHSVGA.DLL.  For SuperVGA mode, should I use both
of them?  Or just one of them?  Which one?  What's different between them?

ANSWER:
1. The Base Video Handler ( BVH ) display driver handles all OS/2 full screen
operations.  When PM opens an OS/2 full screen on the desktop, a call is made
by the kernel to DevEnable through the DDI interface.  The DevEnable function
( resides in IDHMAIN.ASM ) loads all the VDHs entry points of all base video
handler routines into a call vector table.  At this point, initialization
occurs, hardware handling routines are called and the OS/2 full screen is
displayed.  BVH includes a set of function to access the adapter interface.
SetMode is one of them, and it sets the video mode.

    Refer 1: "Base Video Handler Display Driver" in Display Device Driver
             Reference for OS/2 online DDK 2.0 CD.
          2: You could refer to the following source codes:
             \ddkx86\src\vdh\idhmain.asm
             \ddkx86\src\vdh\idhmode.asm

2. For Super VGA mode, you should use both of them.  The SVGA Base Video
Handler provides support for a super set of the VGA base video handler and
therefore relies on the VGA base video handler to be loaded in order to work.
Base Video Handler are used to access video devices and provides two
additional DLLs.

    BVHINIT.DLL    - minimum function for system installation and reporting
                     errors.
    BVHWNDW.DLL    - supports VIO window sessions.

    Refer section"SVGA Base Video Handler" chapter -DDKRoadmap in Using Your
    DDK.

3. Look for the "VGA132" keyword in the EGAVGA directory.The corresponding
entries could be modified if you were to increase the horizontal resolution,in
this case to 664.


The four modes supported in display driver directory
\ddkx86\src\pmdisp\ppxy\8514

    640x480x4    -  16 color ( 4bpp, bits per pixel )
    640x480x8    - 256 color ( 8bpp )
  1024x768x4    -  16 color ( 4bpp )
  1024x768x8    - 256 color ( 8bpp )




!OTHER__________________________________**********
August 25, 1995
QUESTION: (Ref: IC6)
I can no longer use the kernel debugger on the above-mentioned machine.

The retail kernel runs fine, but when I install the debug kernel the following
IPE message appears BEFORE the logo is displayed.

The system detected an internal processing error at
location ##1100:ba14 - 0002:ba14.
line 60008, in file 6015 @(#)inisifs.asm        6.7 92/03/08
SIFS: Init: can not allocate memory for tmp file
05860521 - 00/00 00:00:00.00
Internal revision 8.200, 94/11/09
The system is stopped.  Record all of the above information and
contact your service representative.
eax=00000008 ebx=ffe39f18 ecx=fec50890 edx=aba47000 esi=00000009 edi=0000ff77
eip=0000ba14 esp=00005f3a ebp=00000000 iopl=3 -- -- -- nv up di pl zr na pe nc
cs=1100 ss=0030 ds=0400 es=0168 fs=0000 gs=0000  cr2=ffe51000  cr3=001d6000
1100:0000ba14 891eed64       mov     word ptr [64ed],bx            ds:64ed=0000

The madness here is that the kernel debugger ran fine on this machine for more
than a year.  I _have_ recently updated the BIOS from Dell's A03 to its A05,
but even after the update the kernel debugger ran fine.  Then, for no
reason(!), the IPE appeared.

Has anybody seen this IPE before?  What's it signify?  Can it be fixed or
worked around?


ANSWER:
This error is due to insufficient memory below 1 MB.  Check to see what the
machine returns when you issue an INT 12h.  Sounds like the new BIOS is taking
up some extra memory in the Extended BIOS Data Area.




!VIDEO__________________________________**********
August 25, 1995
QUESTION: (Ref: ID3)
How can I determine, if I run under a german or english OS/2 version in order
to display different text strings in an OS/2 app?


ANSWER:
I'm not sure if you are doing this from app level or device driver level but,
you could use the DosDevIoctl KBD_QUERYKBDCODEPAGESUPPORT Catagory 04H,
Function 7BH in your app/driver.

For further details on this, you could consult the OS/2 Control Program
Reference Guide.





!STORAGE________________________________**********
August 28, 1995
QUESTION: (Ref: IB1)
Using a BASEDEV (type .ADD) to control a Character Device, in this case a
CDROM, how can the driver discover the currently assigned Drive Letter?

PROBLEM DETAILS (PLEASE INCLUDE SOLUTIONS YOU HAVE CONSIDERED):

While the driver functions have no need to know the system Drive Letter that
has been assigned (such as C, D, E etc) it is desirable to be able to extract
this information for service, maintenance or testing.  This is especially true
when a system has multiple drives, and/or, includes drivers for SRAM and FLASH
drives as well.

Why is this important?  In most cases, a user may have only one CDROM, and so
will not have as much confusion.  But what about a system where multiple
drives are concerned.  In the case of the Kodak Photo CD Version 2.0.1, the
software only supports the FIRST cdrom.  This means that the user has to do
things such as DIR of each device to see where the drive got assigned.  This
will also require that the user manipulate the CONFIG.SYS to re-orient the
order of the drivers.  (this limitation is Kodaks's problem)

We have a CE utility that is used to report the current status of the CDROM
with info such as card not installed; card rejected-drive cable unattached and
so on.  When we use this facility on a standard DOS platform we also emit the
current drive letter (this is easy, it's in our Device Header).  Users find
this information very usable, especially when doing an initial installation.

Question - how can the PDD base driver extract this drive letter information?
If not via the PDD, how can a DOS utility get the correlation from a Device
Handle (assuming a standard OPEN function) to the drive letter?

ANSWER:
1. To find out the drive letter where your CDROM drive is installed , try the
following code -

#define CDType            0x8000
#define FirstDrive             0
#define Binary_to_Printable 0x41
#define LastDrive             26

// used for CD number of units Ioctl
struct {
        USHORT count;
        USHORT first;
        } cdinfo;

// array of device info to be collected
BIOSPARAMETERBLOCK devices[LastDrive];

ULONG Action;
HFILE handle;
ULONG datasize;
UCHAR DriveIndex=1;

// check for CD drives
  if(!DosOpen("\\DEV\\CD-ROM2$",&handle,&Action,0,
             FILE_NORMAL,OPEN_ACTION_OPEN_IF_EXISTS,
             OPEN_SHARE_DENYNONE|OPEN_ACCESS_READONLY,
             NULL))
     {
     datasize=sizeof(cdinfo);
     if(!(rc=DosDevIOCtl(handle,0x82,0x60,
       NULL, 0, NULL,(PVOID)&cdinfo,
       sizeof(cdinfo), &datasize)))
       {
       // mark those devices as CDs
       while(cdinfo.count--)
         {
         devices[cdinfo.first+cdinfo.count].fsDeviceAttr|=CDType;     // say
                        its a CD device
         } /* end while */
       } /* end if */
     DosClose(handle);
     } /* end if */

for(DriveIndex=FirstDrive; DriveIndex<LastDrive; DriveIndex++)
    {
    if(devices[DriveIndex].bDeviceType)
      {
      printf("Device %c is ", DriveIndex+Binary_to_Printable);
      if(devices[DriveIndex].fsDeviceAttr & CDType)
        {
        printf("a  CDROM drive");
        }
      printf("\n");
      } /* end if */
    } /* end for
*/

2. Also there is a file on the DUDE BBS - TESTDEV.ZIP which shows how to
determine what drives are what type.

3. You could implement a special IOCtl command and check for a certain return
code.  From your application open the drive and call the IOCtl to confirm that
it is your driver.

From DOS you could get the CDROM drive letter using the INT 2fh calls.  To get
the CDROM drive letters use the following set of instructions:

    mov    ax, 150dh
    int    2fh

    15h in AH -- CDROM Functions
    0dh in AL -- Command Code

This gives the drive letter list buffer in ES:BX

For further information about the Function Descriptions refer to "Virtual
Device Driver Reference", chapter on "Installable Virtual Device Drivers",
Section "Virtual CDROM Device Driver".



!I/O____________________________________**********
August 29, 1995
QUESTION: (Ref: IC2)
I'm developing a touchs screen driver.  To provide mouse emulation, I send 
absolute mouse events to the MOUSE$ driver.  For a touch or drag, I send a
MOUSE_MOTION_WITH_BN1_DOWN message with the touch coordinates.  For an 
untouch I send a MOUSE_MOTION message with the touch coordinates.  This 
works fine in OS/2 applications.  However, in a Win-OS/2 session, two touches
in the same location are required to emulate a mouse button down event, and
a mouse button up event is never generated.  I've tried sending a MOUSE_MOTION
message on the first touch and setting a timer for one tick, then sending a 
MOUSE_BN1_DOWN message; I've tried sending an event with value 0 for an un-
touch.  I've tried looking at the MOUSE and VMOUSE code to determine what 
translation is being done, but I can't figure it out.  I've been trying to acquire the 
Win-OS/2 modified code for a month, and I still haven't received it.

What sequence of absolute mouse event messages are required to emulate a
mouse correctly for OS/2 and Win-OS/2?  What other modifications are required?

ANSWER:
An optional disk is available  - MS windows v3.1 DDK modified code
which contains sources for WIN-OS/2 Mouse, WIN-OS/2 Serial & WIN-OS/2 seamless
VGA. The Mouse Code has the modifications that were made to the Windows
Mouse Driver for its adaptibility in an WIN-OS/2 Session.


FOLLOWUP QUESTION:
I'll keep trying to acquire the modified Win-OS/2 code.  However, I understand
that these modifications were included in 'OS/2 Warp With Windows'.  I have
tested my driver on the copy which was included in the DevCon 6 CD, and it had
the same problem, so I'm not convinced that the Win-OS/2 code will solve my
problem.  I'd like more specific help about how absolute mouse events are
translated into windows mouse events.  The MOUSE$ IDC does not have an event
type for BUTTON UP.  How is a BUTTON UP event generated for Windows?  What
message sequence is required from a device dependent mouse driver? 

FOLLOWUP ANSWER:
"Some devices may not work correctly with generic mouse driver ( MOUSE.DRV ).
If this is the case, you should write a WIN-OS/2 mouse driver to support the new 
device type".

Refer Building the WIN-OS/2 Mouse device driver in Input/Output Device Driver
Reference.

The IDC provided by MOUSE.SYS supports the function Process_Absolute.  This
request is issued by the device dependent driver to pass an absolute-point
device event,usually from touch sensitive screen.  This function is non-reentrant.
It is the responsibility of device dependent device driver.

Refer to chapter on Mouse Device Driver, section MOUSE.SYS IDC Interface -
Process_Absolute in Input/Output Device Driver Reference.




!OTHER__________________________________**********
August 29, 1995
QUESTION: (Ref: IB6)
I cannot find the subroutines DevHelp_AttachDD and KbdIDC.  Where are they?

ANSWER:
Refer to DevCon DDK Version 2.
DevHlp_AttachDD Routine is defined in -
DDKX86\SRC\DEV\DASD\DEVHELP\DHCALL5A.ASM

The KbdIDC routine is defined in -
DDKX86\SRC\DEV\KBD\KBDBASE\KBDIDC.ASM




!NETWORK________________________________**********
August 30, 1995
QUESTION:  (Ref: IB5)
I was trying to install our LAN driver into the OS/2 WARP Connect Box and the
install failed because our microcode did not get copied to the D:\IBMCOM\MACS
directory.

When I did the first time install, our LAN driver, installation file and the
microcode were copied to the D:\GRPWARE\CLIENTS\LADCLT\ MACS\ directory. 
But later on, only the LAN driver and the installation file got copied to the
D:\IBMCOM\MACS directory; and our driver needs the microcode file to be in the
same directory to function.

We use the same installation file on the OS/2 Warp system and it seems okay. 
Also,  after the first install fails, if we use MPTS to install our driver, it will
work.


ANSWER:
This is bug in the Warp Connect installation code.   APAR IC11004 has been
created to address this problem.  The Warp Connect developers are looking
into it and hopefully it will be fixed for the next release/csd.   You may
contact OS/2 Warp Connect technical support at 1-800-992-4777 to check the
status of this defect.




!OTHER__________________________________**********
August 31, 1995
QUESTION: (Ref: ID4)
I am looking into Plug and Play feature and Object linking/embedding
in OS/2 platform The following below is a list of questions regarding these
issues. 

Does OS/2 operating system supports Plug and Play?  If no, then what is
needed so as to support PnP?  What does device drivers need to do
if the adaptor is a PnP card?

ANSWER:
Currently we have not released any PnP drivers or documentation.

Our future OS/2 plans call for full Plug and Play support, ie., automatic
recognition, installation, and configuration of PnP devices, dynamic loading
and unloading of device drivers, and a graphical user interface to assist with
installation and configuration of legacy devices.  IBM will provide code
samples in the OS/2 DDK, will hold PnP workshops to show IHVs how to develop
PnP drivers (along with necessary tools), and we will include PnP drivers in
future OS/2 products.




!OTHER__________________________________**********
August 31, 1995
QUESTION: (Ref: IE6)
I need to find out what time it is in my interrupt service routine.
You know, what time is it, man?

I was tripping along nicely, planning to use DevHlp_GetDOSVar, when I
fell flat on my face.  You can't call that service in interrupt context?
What??

So how do I get hold of a millisec clock in my ISR?  It's a reasonable
request, n'est pas?

ANSWER:
Yes, it is true that DevHlp_GetDOSVar cannot be called in the interrupt
context To get hold of millisec clock in the ISR you adapt the following
procedure:

1) At INIT time call the DevHlp_GetDOSVar with index GlobalInfoSeg = 1.

2) If you are using Assembly language, AX:BX points to the index on return.
In 'C' language, the requested variable is returned in KernelVar on successful
return.  Save this address in a variable in the device driver.

The address of this selector is global and valid in interrupt context also.
"GlobalInfoSeg word valid at tasktime and interrupt time, but not at INIT
time", Refer Page 170 in PDD Reference.

3) In the ISR you can use this variable to access millisecs field.

Ref:  Ch-9, "Deivce Helper Services", Section on "DevHelp_GetDOSVar", in
"Physical Device Driver Reference".

You could also refer to the following source code:

\ddkx86\src\dev\touchdd\didd\tdicinit.c
\ddkx86\src\dev\mouse\init.asm

in DevCon DDK Ver.  2.0
