This is file: 11_94QA.TXT

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

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

The following KEY WORDS are supported in this file.

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

!BASE__________________________________**********
November 29, 1994
QUESTION: (Ref: FO9)
When multiple threads may call DosDevIOCtl(), is it necessary to explicitly
semaphore protect the call, or is that taken care of by the operating system?


ANSWER:
It depends.  OS/2 kernel does not pre-empt threads when in IOCTL code, but a
user thread can be interrupted.  If your IOCTL dabbles in data structures that
are likely to be used/modified by interrupt routines, these ops will have to
be done with the interrupts held.  If the user thread does not block or yield
the CPU while manipulating critical regions then there is no need to use mutex
mechanisms.




!VIDEO__________________________________**********
November 29, 1994
QUESTION: (Ref: FO1)
We are looking at developing a double-byte driver for Matrox MGA.  The only
double-byte sample we found in the DDK is for VGA.  Since our driver is based
on the S3/XGA sample, is there a S3/XGA double-byte sample code available?
How can we get it?


ANSWER:
The 32-bit DBCS PMVIDEO Device Driver is available on DevCon DDK Version 1.
This is a Merged Version of S3,XGA & 8514 Drivers.  Part No. 83G9641.




!VIDEO__________________________________**********
November 29, 1994
QUESTION: (Ref: FN7)
I am experiencing similar errors when I generate either the VGA version or
SVGA versions of IBMDEV32.DLL as outlined in questions.zip.  In my case I am
using MASM 6.11 for DOS for the assembler.  Has there been any update in
understanding the problem?


ANSWER:
As stated in the DDK, MASM 6.0 is required, not MASM 6.11.  It is my
understanding that MASM 6.11 does not support OS/2.

CUSTOMER FOLLOW-UP:
My question was why MASM 6.11 failed to build IBMDEV32.DLL.  I thought you
might want to know what I found, since I did end up using it, with much pain.

The following quote from Microsoft's MASM 6.11 readme.txt says it all:

     Intersegment Near Jumps in Flat Model
     -------------------------------------
     Intersegment near jumps do not work across files (externs) in flat
     model. When programming in flat mode, make sure that all intersegment
     near jumps occur within the same file.

What it fails to mention is a CALL is as good as a JMP.  No errors are
generated by ML or LINK386.  The resulting code though is bad.  The result is
a insegment jump to a bogus offset.  The fix is to change all cross segment
external jumps or calls to a local entry in the referenced segment which then
jumps to the external routine.  An example follows:

ORIGNAL CODE:
        .386
        .model flat, syscall
        FARCODE SEGMENT DWORD PUBLIC FLAG 'CODE'
        farfunc PROTO SYSCALL
        FARCODE ENDS

        .CODE
        INVODE farfunc

FIXED CODE:
        .386
        .model flat, syscall
        FARCODE SEGMENT DWORD PUBLIC FLAG 'CODE'
        farfunc PROTO SYSCALL
        l_farfunc:      jmp farfunc
        FARCODE ENDS

        .CODE
        call l_farfunc




!MULTIMEDIA_____________________________**********
November 29, 1994
QUESTION: (Ref: FN6)
Why does an application sometimes receive an EVENT_ERROR message.

***************              ************     **********     ****************
*             *  Event_Error *  Sync    *     *        *     * Audio        *
* Application * <=========== *  Stream  * --- * ADSHDD * --- * Physical     *
*             *              *  Manager *     *        *     * Device Driver*
***************              ************     **********     ****************
                                     |        **********
                                     |--------*  FSSH  *
                                              **********


This message occurs during PLAY, without any visible problem.


ANSWER:
EVENT_ERROR is an Implicit Event and the Data Structure IMPL_EVCB is defined
in DDKX86\MMOS2\H\EVCB.H.  This Structure defines the Implicit Event Control
Block.  The EVENT_ERROR is notified when there is either an Error in the
Stream Handler or the Device Driver.  The Application could check for the
"ulStatus" field.  The Status Code could then be interpreted with the
MMOS2\H\MEERROR.H - Sync/Stream Manager Error Return Codes.




!PRINT__________________________________**********
November 29, 1994
QUESTION: (Ref: FM8)
My printer driver is a presentation printer driver based on the March 94
version of the OMNI code.  This driver uses the "Shadow DC" concept and all
actual drawing, except text, is passed on to the ShadowDC (display driver).
Some of the capabilities that I currently return to the application are those
of the Display driver.  My questions are:

1. Since I don't support any AVIO functions, should I return zero for
CAPS_SMALL_CHAR_HEIGHT/WIDTH and CAPS_CHAR_HEIGHT/WIDTH or are these somehow
connected to the size of the default printer font?  What about
CAPS_MARKER_HEIGHT/WIDTH?

2. Similarly, should I return zero for CAPS_VIO_LOADABLE_FONTS even if the DC
type is OD_MEMORY?  I don't draw any text to the ShadowDC.

3. Are CAPS_GRAPHICS_CHAR_HEIGHT/WIDTH supposed to reflect the DEFAULT printer
font or the font that is currently set?


ANSWER:
1. The CAPS_SMALL_CHAR, CAPS_CHAR & CAPS_MARKER are all related to the
parameters for the Font that is currently set.  These parameters are therefore
defined by the Font that is currently selected.

2. The value returned for CAPS_VIO_LOADABLE_FONTS should be the same as what
the Shadow DC would return.

3. CAPS_GRAPHICS parameters are to reflect the Font that is currently set.




!OTHER__________________________________**********
November 29, 1994
QUESTION: (Ref: FL5)
I'm trying to write a device driver that I believe requires the use of event
semaphores.  Multiple applications are to be blocked by the driver until
awakened by an interrupt.  I'm trying to understand how the various Semaphore
routines are tied together.

Is the following correct?

     Task Time                                Called By

A. DosCreateEventSem/DosOpenEventSem          - Application
     ("name", &EventSem);
B. DevHelp_SemHandle                          - DD
    (EventSem, IN_USE, &DDEventSem);
C. DevHelp_OpenEventSem (DDEventSem);         - DD
     Interrupt Time
D. DevHelp_PostEventSem (DDEventSem);         - DD
    Task Time
E. DevHelp_CloseEventSem (DDEventSem);        - DD
F. DevHelp_SemHandle                          - DD
    (DDEventSem, NOT_IN_USE, NULL);
G. DosCloseEventSem (EventSem);               - Application

If not, what is the proper usage of all these calls?  I received the following
system dump at DevHelp_PostEventSem during interrupt time.

The system detected an internal processing
error at location ##1100:0e11 - 0002:0e11.
line 60000, in file 2008 @(#)dhrouter.asm       6.11 91/11/16
DevHlp Usage Error
048600b4 - 11/03 15:03:10.53
Internal revision 6.617, 94/01/28
The system is stopped.  Record the location number
of the error and contact your service representative.


ANSWER:
1. The sequence of operations being followed is correct.  Something similar is
also contained in the DDK v1.2 in the SRC\PEN\PENTKT\UTIL\PENCAL directory.
Refer to the file ALIGN.C.  The application threads here wait on the event
semaphore (with DosWaitEventSem).


2. The call DevHelp_PostEventSem cannot be issued from the interrupt context.
This is the reason as to why you get system dump at that call.  (Ref:  P-122,
Physical Device Driver Reference).

If the semaphore being handed down is a 32 bit semaphore then there is no way
that the semaphore can be dealt with during interrupt time.  Semhandle and
SemClear are for RAM semaphores which are 16 bit entities.  So, the solution
is to allocate a context hook at task time (AllocateCtxHook) that performs the
posting of the semaphore (PostEventSem).  Now, during your interrupt routine,
arm the context hook (ArmCtxHook) instead of directly trying to post the
semaphore.  The context hook routine will run on the next task-time thread
that is scheduled.




!OTHER__________________________________**********
November 17, 1994
QUESTION: (Ref: FK9)
I have the document SMP.INF from the DUDE BBS, but I cannot find out how to
determine whether your device driver is running under OS/2 SMP or not.  Is
there a way that this can be done?


ANSWER:
Issue a Devhlp_GetDosVar with an index of 18.  Returns 1 if OS has SMP support
and error is returned if the OS has uniprocessor support.

Index 17 returns the number of processors.  A value of 1 is returned if only 1
processor is running SMP.  > 1 is the number of processors running on SMP.  An
error is returned if the system does not support SMP.




!OTHER__________________________________**********
November 17, 1994
QUESTION: (Ref: FK4)
We are trying to find what changes we have to make in our ADD driver for our
HBA to support OS/2 2.11 SMP and OS/2 Warp.  Is there any DDK available for
either of them?


ANSWER:
There is a SMP.INF file that has been made available in the Main file area on
DUDE bbs and is named SMPDOC.ZIP.  This document includes information on SMP
device drivers; and is the only document available from IBM at this time.
Currently there is no source code available for SMP.  However, in our next
release of DDK, there will be WARP source code.




!OTHER__________________________________**********
November 17, 1994
QUESTION: (Ref: FJ2)
Here are some questions that I need help on.

Q1. In what product (developer toolkit...)  does one get the C libraries and
    header files to access the devHelp routines (all the device driver
    interfaces)?

Q2. Can I write a device driver in C or C++ (through IBM's C Set++ 2.1 -->
    32bit)?  Are there any limitations?  Is Assembler necessary for
    development in any way?

Q3. What memory model is used for development of device drivers?  Are there
    any limitations to using the 32bit flat model?  Are there any situations
    where I must use the 16:16 model?

Q4. Are any of the device driver interfaces still 16-bit?  If so, are there
    any performance or mixed-mode development considerations that I should be
    aware of?

Q5. I've heard of ADD32.  Is this a new DD model?  Can you give a short
    overview of this new model?  When will it be available?

Q6. What is in the Device Driver Source Kit?  Is it necessary for DD
    development?

Q7. Does IBM sell a 32-bit Assembler product?  If not, where does one get the
    proper header files and link libraries to work with a 3rd party 32-bit
    OS/2 Assembler product?


ANSWER:
The following answers are based upon the assumption that you are referring to
a Physical Device Driver (PDD).  At this time, there are no 32-bit PDDs, only
16-bit PDDs.  There are 32-bit device drivers such as Virtual Device Drivers
(VDDs) for Dos and Presentation Manager (PM) device drivers.

A1. The IBM Device Driver Source Kit for OS/2 (DDK).  To order the DDK, call
    1-800-633-8266.

A2. Use this compiler for 32-bit device drivers only, If you plan to write a
    16-bit device driver then use a 16-bit compiler.  Examples of 16-bit
    compilers are MS 6.0, IBM C/2, Watcom C16, and Borland 3.5.

A3. Small Memory Model (64k code & 64k data) is used for PDDs.  Do not use the
    32-bit flat model with PDDs.  You must use the 16:16 model with PDDs.

A4. All PDDs are 16-bit.

A5. ADD32 is not available yet and there is no scheduled release.  No further
    information is available at this time.

A6. The DDK contains Source Code, Tools & Reference Material for development
    of Physical, Virtual & Presentation Device Drivers.  The C Callable
    Library is also a part of the DDK.  This is called DHCALLS.LIB and is
    contained in \DDK\LIB subdirectory.  The source code is also included in
    the DDK.  The DDK is not necessary for device driver development but may
    save you time because the source code provided in the DDK may be modified
    to comply with your development needs thus eliminating the need for you to
    write your device driver from scratch.

A7. IBM does not sell a 32-bit Assembler product.  I am not aware of a 32-bit
    OS/2 Assembler product or where to obtain the proper header files and link
    libraries to work with such a product.




!I/O____________________________________**********
November 17, 1994
QUESTION: (Ref: FI5)
Sending mouse events off to OS/2, I have some acceleration tables that are
being used.  In Presentation Manager, it's fine.  In a DOS full-screen it is
fine.  Under Win-OS/2 full screen & seamless it is fine.  But under a
full-screen OS/2 session it is WAY WAY to quick.  The acceleration seems much
too much.  What's different?


ANSWER:
1. This problem pertains to an application if you are using the mouse drivers
   which are provided by IBM.  Please contact the Developers Assistance Program
   (DAP) at 407-982-6408 for assistance with application development.

2. If you are using your own Mouse Driver, the Source Code in the  DDK could
   serve as general guidelines. A modified mouse driver is used for Seamless
   applications. The source code is available as a seperate option diskette with
   DDK. DDK\SRC\DEV\MOUSE contains the device independent source code for MOUSE.SYS.





!OTHER__________________________________**********
November 16, 1994
QUESTION: (Ref: FI8)
Q1. Can I use "VDHPushFarCall" to call into a windows driver (protected
    mode)?

    I tested running a .COM program from a DOS box (v86 mode) and it works!!
    as expected.

    The scenario is as follows:
      1) I use "VDHRegisterAPI" to have the VM call into the VDD and report a
         callback entry point in it's ES:BX (segment:offset for v86 mode,
         selector:offset for protected mode).

      2) I use "VDHArmContextHook" to wait for the VM to be in context for the
         callback.

      3) Then, I use "VDHPushFarCall" to do the callback, and I also use
         "VDHArmReturnHook" to trap the VM's retf.

    As I mentioned, it all works for v86 mode.  What do I need to do to make
    it work in protected mode??

A1. I assume that the reference to windows driver (protected mode) means a
    Windows 3.x device driver.

    OS/2 provides a Windows kernel (WIN-OS/2) capable of running as a DPMI
    client within a VDM.  Whereas the retail version of Windows 3.x can only
    function as a DPMI host.  The WIN-OS/2 is a virtual environment to support
    both Windows 2.x applications (real mode) and Windows 3.x applications
    (standard mode).

    Hence a Windows 3.x device driver cannot be loaded with WIN-OS/2.  Instead
    a VDD must be developed to emulate the required Windows 3.x device driver
    thru IDC calls to corresponding PDD.

    The procedure you have explained holds good in both protected mode and v86
    mode.  Only difference is, the address returned in ES:BX in step (1) is to
    be interpreted differently.
==============================================================================

Q2. I'm trying to set-up a callback into a windows RING-3 driver (.DRV file),
    not a VxD (.386 file).  These drivers are the Crystal Semiconductor
    drivers in the current OS/2 release (WARP) used for the IBM ThinkPad:

           CS31BA11.DRV (WIN-OS/2)
           VCS4231.SYS (VDD)

    I'd like to add some enhanced features (ie, Power Management) by being
    able to make callbacks from the VDD into the WIN-OS/2 driver.

    Should I be using VDHPushFarCall?

A2. Confirm if VDM is in the Protected Mode.  This could be done by checking
    on the Global Variable "flVdmStatus" which is exported to all VDDs.  Check
    the flag VDM_STATUS_VPM_EXEC, if this flag is set, it is in the Protected
    Mode.  If VDM is not in the Protected Mode, switch to it with the
    VDHSwitchToVPM (switches current DOS Session into Protected Mode).

    Once in the Protected Mode, you could use VDHPushFarCall.  In the Return
    Hook, if it was switched to the Protected Mode, you could switch back to
    the V86 Mode with the VDHSwitchToV86 Call to get you back in the V86 Mode,
    if neccessary.  You could also browse through the VMOUSE Driver Source
    Code in the DDK - DDK\SRC\VDEV\VMOUSE Directory.
==============================================================================

Q3. Do I need to make conversions to entry point in ES:BX?

A3. Conversion of Entry Point is not necessary.  DOS or DPMI applications
    issue INT 2F calls to determine if they are running under OS/2, and then
    get the virtual device driver API Entry Point.

    In the VDHRegisterAPI, the parameter pfnV86Hook should be NULL and
    pfnVPMHook will be the VPM-Mode Hook Routine Address.




!I/O____________________________________**********
November 17, 1994
QUESTION: (Ref: FJ1)
How would I go about detecting if the mouse cursor is in a seamless Win-OS/2
session?  I want to do this before sending a click.  It's all in screen
group 1; both PM and Seamless Win-OS/2. Is there something I am missing
to differentiate?  It seems like it should be a simple thing.  Any short
snippets of code for this?


ANSWER:
This problem is related to an application.  The mouse DD cannot detect, on its
own, which window the cursor is currently positioned in.  From the X,Y
coordinates of the mouse event, PM determines to which window the notification
is to be sent.




!OTHER__________________________________**********
November 17, 1994
QUESTION: (Ref: FI0)
We are writing OS/2 32-bit display driver.  The source of display testing
program, DTT32, is included in DDK package but the binary is not.  I tried to
build the binaries with C/Set++ (version 2.0).

I must change 4 of the source file in order to pass the compilation.  First is
that ICC didn't recognize the huge keyword, so I deleted them (2 files).  The
second is that ICC didn't accept the prototype like xxx(a, b, ...)  in one
header file, I deleted it too.  In linking time, there was a warning told me
to enter path spec of dde4mbm, I just press <enter>, no error.

After all binaries were generated, I modified the config.sys to include the
run-time libraries path included in LIBPATH and reboot.  But I always got an
error message when I run the dtt.exe with all possible parameters in the DDK
manual.

That's all my problem - I cannot build a runnable dtt32, to test my display
driver.


ANSWER:
Build of DTT32 requires CSet/2 & not C/Set++ v2.0.

Build Requirements for the  32-bit Display Test Tool:
        IBM C Set/2 (ICC Compiler)

Build Instructions:

1. Make sure that you have the IBM C Set/2 compiler installed.

2. Before the FIRST build is attempted, run (only once) the COPYCSET.CMD REXX
command file in the DDK directory.  This command copies the set of needed
files from your installed copy of the IBM C Set/2 compiler to the proper
directories under the DDK base directory.

3. Set the PATH environment variable from the commandline as follows:

   SET PATH=C:\'ddkdirectory'\Tools;%PATH%

   Where 'ddkdirectory' represents the DDK installed directory and C:
   represents the drive letter on which the DDK is installed.  On CD-ROM, the
   TOOLS directory path is DDK\TOOLS.

4. Set the TMP environment variable to a work directory,

      e.g., SET TMP=C:\MYTMP

5. In order to build all the testcase DLL's and DTT.EXE, change directories
   to \'ddkdirectory'\TESTTOOL\DTT32 and type in the following command:

   NMAKE /f DTT32.MAK




!BASE___________________________________**********
November 17, 1994
QUESTION: (Ref: FH8)
We are using SSAllocMem to allocate memory which can be accessed by multiple
processes (without explicitly using DosGet/Give).

Problem is that after a while, during which many SSAllocMem calls are
successfully made, we are returned an error code of 0x12345678.

What does this mean?


ANSWER:
The returned code 0x12345678 is not a documented error code.  The valid error
codes are:

NO_ERROR                       -  0
ERROR_INVALID_PARAMETER        - 87
ERROR_NOT_ENOUGH_MEMORY        -  8

You should also be using SSFreeMem to free the shared memory that was
allocated by a call to SSAllocMem.

In SSAllocMem, when size parameter becomes zero an error is returned.  Instead
you can use SafeSSAllocMem, which is a wraparound for SSAllocMem.  This
function allocates a 64K segment when size parameter is zero.

If your aim is to create a shared segment between processes then we suggest
that you use DosAllocShrdSeg/DosGetShrd.




!BASE !OTHER____________________________**********
November 17, 1994
QUESTION: (Ref: FH5)
An application is supplying a buffer to our PDD.  Our PDD has no problem
accessing the first 4096 bytes in the buffer.  After the 4096th byte we
sometimes run in to trouble.  Our PDD is accessing the buffer at task time and
we have not locked the buffer.

1) Does a application supplied buffer need to be locked down for a PDD to
   access the buffer at task time?  With interrupts off?

2) Will OS/2 page in pages for a PDD at task time?

3) Where is there a good descriptions of how OS/2 memory management and paging
   system work?  With special concern for PDDs?


ANSWER:
I assume you are sending an application buffer to a PDD thru data/ parameter
packet of a user defined IOCTL function call.  I do not know whether your
application is 16/32 bit using DosDevIOCtl/DosDevIOCtl2.

For 32-bit applications this problem may not occur unless you are accessing
more than the buffer size defined by DataLengthMax or ParamLengthMax of
DosDevIOCtl.

For 16-bit applications using DosDevIOCtl the PDD must do a verify access on
data or param buffers before accessing.  The DosDevIOCtl2 call is better
suited for variable length packets.


1) There is no need to lock application supplied buffers, as long as they are
   accessed in application context. You must do a verify access as explained
   before.

2) YES

3) THE DESIGN OF OS/2 by Deitel & Kogan




!BASE !OTHER____________________________**********
November 17, 1994
QUESTION: (Ref: FH4)
We currently have VMAlloc working.  The value of the Flag that works for us is
0x30, (i.e.  bit 5 is on and bit 4 is on, which is process space and obtains a
linear address for the given physical address).

1)  Is the returned linear address locked and fixed?

2) Is the returned linear address contiguous throughout the physical address
   space?

3) Will BaseLinearAddress + 4097 be the same location as BasePhysicalAddress +
   4097?

4)  Are there any alignement issues?

5)  Are there any paging issues?


Our problem only shows up on byte access on the first byte access in the
second 4K area.


ANSWER:
The flags used will result in mapping a physical region into the private
region of the process space.  Normally, this is used only to get access to
adapters or adapter buffers from the user process.  It should not be used to
map user RAM into process space.

1. A fixed memory region is also locked.  If the VMDHA_FIXED option is not
used, then the page goes into the swappable page pool.  If the physical
address corresponds to adapter buffer then this can cause problems.

2. If the physical region is more than 4K long, you will have to explicitly
use the VMDHA_CONTIG|VMDHA_FIXED flag.  Note that you cannot have a swappable
contiguous region.

3. None.  The physical address need not be on a page boundary.  However, the
mapping entries allocated by VMAlloc, use only pages.  If the phys addr is of
the form 4096*A+b then the value A is entered into the mapping table and the
offset b is added to the resulting linear address.

4. You have not given the size of the physical region.  This is true only for
fixed+contiguous mapping.  For a page aligned address P, P and P+4097 access
different page table entries.  The physical addresses in these two entries
need not be 4K apart.

5. Yes.  Remember that VMAlloc deals only with pages and mappings.  Therefore,
it always maps the page that contains the physical address that you pass.  If
this address does not begin on a page boundary, then you will still be able to
access the memory below the physical address without causing a page fault.
So, if your regions are not page aligned, then don't expect the paging
mechanism to catch all out of bounds accesses.  Try allocating with
VMDHA_FIXED|VMDHA_CONTIG|VMDHA_PROCESS|VMDHA_PHYS flags.  This should map in
your multi-page region in full.




!BASE !OTHER____________________________**********
November 17, 1994
QUESTION: (Ref: FH3)
I am developing a VDD under the 1.2 DDK in C and having some difficulty.

I have a DLL that calls the VDD entry point by issuing a DosRequestVDD.
During this call, there is a chunk of memory allocated, using VDHAllocMem, in
the VDD context but under the processing of the DLL.  When the call finishes,
a pointer is returned to the DLL of the location of this memory.

My problem is, I can't get access to this piece of memory.  Is this because
the memory is allocated in a RING-0 context, and cannot be accessed from a
RING-3 app?


ANSWER:
The purpose for the allocated memory is not mentioned.  I can give only
general guidelines on this question :

1. VMAllocMem allocates memory from the kernel heap area which is accessible
from all processes in all contexts.  It is also a precious resource.  Since it
comes off a heap, the allocation can be on a long/dword boundary and not
necessarily on a page boundary.

2. This memory is R0 because it comes from the system heap.  The selector will
be xxxx x100 (GDT, R0).  It cannot be accessed from the app in user mode.

3. THe DLL can allocate memory and pass it to DosRequestVDD instead of
allocating memory from the system heap in the VDD.


If the discussion about the memory areas is confusing and you have access to
the book The Design of OS/2, look up the section 10.4 "80386 DOS
compatibility" for a detailed discussion on multiple VDMs, VDDs and memory
regions.




!NETWORK !PRINT_________________________**********
November 17, 1994
QUESTION: (Ref: FG7)
Our problem is with OS/2 1.3, but we will probably see the problem with OS/2
2.1.  To give you some background, Jetlan is device attached to printer,
either via MIO or serial/parallel, providing multi-protocol network support.

For OS/2, rather than add another stack for print server SMB dialog etc., we
install a driver on the machine providing print queue service.  This
character-mode driver is invoked via a line in config.sys.  It reads lines in
protocol.ini (placed there by our install and human-interface utilities) and
initializes the appropriate number of linked device-headers, with user-defined
names e.g.  LPT46, etc., and communicates with protocol mgr as an NDIS driver,
providing access to the network devices assigned to each character device
name.

At present this is a "vanilla" character device, not specifically a printer
device.  Later we may modify, to allow status checking etc.

This works fine, for example, when we do a copy to lpt46:  it comes out as
expected.  In assigning a printer to a queue, all works IF we use a device
name such as LPT5, LPT6, LPT7, LPT8, LPT9.  These devices get assigned
properly, and can be selected from Print Manager's drop-down list for
"Device".

The problem:  Trying to assign a printer device for a queue, for higher LPT
numbers, or arbitrary names.

If we use a device name e.g.  LPT5 it works, as described.  However, if the
name is LPTnn, where nn is greater than 9, or if the name is some other
string, the device does not show up in the printmanager device list.  Further,
Print Manager does not allow typing in arbitrary device names.  We were told
by a consultant that any character device would show up here, but this does
not seem to be the case.

The question:  Is there some way to get arbitrary character device names to
show up in this list?  Alternately, is there some other way to assign these
"ports" to printers attached to a queue?


ANSWER:
This problem does not exist in OS/2 2.1. For OS/2 1.3, try out the following
code:

PrfWriteProfileString(HINI_SYSTEMPROFILE,"PM_SPOOLER_PORT","LPT46",";");

This function call will update the INI to include LPT46 and it should show up
on the Print Manager list box.




!OTHER__________________________________**********
November 17, 1994
QUESTION:  (Ref: FG4)
How much does Warp change the way I write device drivers?  Can I just drop my
code into the new OS, compile, etc., and run?  Is there a new device run?  Is
there a new device driver pardigm involved?


ANSWER:
Drivers for OS/2 2.x are compatible with OS/2 Warp and do not require
additional modifications.

OS/2 Warp introduces a centralized Resource Management Architecture to
facilitate the coexistence & cooperation of the increasing number of device
drivers.  With the introduction of this architecture, a functional line has
been drawn separating previous device driver capabilities and those of the
OS/2 device drivers written to use the Resource Manager Services.  Device
drivers written to use the Resource Manager Services are referred to as
RM-Aware drivers.  Existing OS/2 2.x device drivers are referred to as legacy
drivers.  Both types of drivers are supported on OS/2 Warp.  The Resource
Manager services identifies resources (I/O Ports,DMA Channels & IRQ Levels)
that are already claimed by drivers and have been initialized previously.  A
driver using the Resource Management calls avoid inadvertently corrupting the
state of Adapters that were initialized by previously loaded drivers.




!OTHER__________________________________**********
November 11, 1994
QUESTION: (Ref: FL3)
1. What is the plan for OS/2 2.x to provide support for PCI.  Are there
additional commands available to take care of PCI dependent information?

2. Does OS/2 map PCI resources into EISA space or make use of the larger PCI
space to take advantage of more interrupts available?

3. Does OS/2 support peer PCI buses as defined in the PCI 2.0 Spec?


ANSWER:
1. PCI Support is available with OS/2 Warp Version 3. OS/2 v2.1 does not
include PCI Support. However for testing purposes, OS2LDR with PCI Support
could be obtained from OS/2 Development. OS/2 Support has an APAR PJ14230
and some method of distribution for OS2LDR for 2.1 Systems.

2. OS/2 does no moving around of PCI resources itself.  It is totally
dependant on the PCI BIOS and/or Setup utilities to have configured the PCI
devices.

3. Yes, OS/2 Warp  supports peer PCI Buses as defined in the PCI 2.0 Spec.




!MULTIMEDIA_____________________________**********
November 11, 1994
QUESTION: (Ref: FE9)
Several questions to help me in developing my MMPM video capture driver.
1)  I have been advised to use the VIDVCI VSD to reduce my work and
    to 'tap into future technology'.  This requires some more information
    than is in the MMPM/2 DD Ref, PC Video sample or the Online docs.

    For the INI files that the VSD reads,
        1) how is it read, what are the keywords/valid values
        2) into what structure
        3) if I need additional elements that are not currently in
           existance, how would I add them?

2)  Comments
    NOWHERE is the data format for the images documented.  Is it from
    top to bottom or bottom to top.  Is it packed, or is it padded like
    BMP files?  Is there a header for the images?  This is for
    function 140:6C.
    If you want me to abide by the 'terms' of hooking into the general
    VCI interface, why do you not document the structure for function
    140:60?

3)  Verify:  I should use the System Timer to setup to capture images.

4)  Question:   My video board directly supports 24 bit image capture.
    When will the VIDVCI VSD/MCD support 24 bit images?

5)  After looking at the Video IN installation program, It looks like the
    installation program supports unpacking 'pack' files.  (PACK*.PK1)

    1)  How is that done?
    2)  How do I tap into that power for my driver installation?
        (My final product will have about 4-5 Meg of files with different
         parts allowed to be installed.)
    3)  It looks like it is part of the standard installation, at least
        if you use the GENIN.DLL.  Why is it not documented with the
        reset of it's interface.  (You tell me that I can use it to
        prompt for interupt/IO ports/anything.  Why can't you tell me
        about this 'secret' that would be SO GREAT for such a large
        system as mine.)


ANSWER:
These responses are based on the assumption that you already have DDK v1.2
and the OS/2 2.1 PCVIDEO Source Code dtd.4/13/94.

1.The INI file could be text or binary.
   a. In the given sample source,the INI File is text and is contained in
      DDK\MMOS2\MMTOOLKT\SAMPLES\PCVIDEO\VIDVBC1.INI.
   b. The Entries in the INI file are parsed by-
      DDK\MMOS2\MMTOOLKT\SAMPLES\IBMVIDT\PCV.C.  Going through this code would
      give an idea about the structure initialisation.
   c. You can always add additional elements.  In the 140:60 IOCtls the Data
      Packet Format and the Data Structure is device specific.

2. The data format of the image could either be YUV411 or RGB565.  The image
is stored from top to bottom.  Structures for 140:60 & 140:6C are defined in:

         DDK\MMOS2\MMTOOLKT\SAMPLES\PCVIDEO\VIDVCI.H.

3. Your own card interrupts are recommended.  However,there should be no
problems using the system timer to capture images.

4. Currently support 16 bit image capture.  We are working towards 24 bit,but
cannot give any time commitments at this stage.

5. Refer to the Ultimotion Video IN Programming Reference.
   DDK\MMOS2\MMTOOLKT\SAMPLES\VIDINST\CONTROL.SCR
                                      VIDFILES.SCR
These Script Files are the master control file and the File List Control File
for the generic video install sample which is a part of DDKv1.2




!DISPLAY________________________________**********
November 11 1994
QUESTION: (Ref: FB3)
I am having trouble initializing OS/2 with a newly created display driver
based on the S3/8514/XGA PM driver in the DDK v1.2.  I had previously been
able to install my driver on a different machine and I believe this to be an
installation or configuration problem.  Here are the steps taken.

   1) Installed OS/2 v 2.1
   2) Installed Debug Kernel
   3) Rebooted OS/2  (testing Debug Kernel .. OK)
   4) Ran dspinstl.exe using modified versions of pss3.dsc
      and pss3b.dsp from the DDK along with my driver DLL
      and SYM files.
   5) After dspinstl ran OK, rebooted the system.
   6) I got as far as having the driver initialze the board
      and the device structures.
   7) A message then came up on the debug monitor as follows
        Symbols linked (pmmle)
        DelayHardError SYS3175: 4 strings(s):
        Pid 003   Tid 0001   Slot 0008   HobMte 0108
        C:\OS2\PMSHELL.EXE
        H
        Symbols unlinked (pmmle)
        Symbols unlinked (ibms332)
        Symbols unlinked (som)
        Symbols unlinked (pmdrag)
        Symbols unlinked (pmmctls
        Symbols unlinked (pmwp)
   8) I was able to set a breakpoint in the board init
      code and set the debugger trap flag. I then got
      Trap 13 (0DH) GP Fault 0000
      with the registers as follows:

      eax=0000d137 ebx=00000000 ecx=00008e27 edx=00000000
      esi=00008e27 edi=00008e27 eip=00007644 esp=0000f9e6
      cs=d0ff  ss=001f  ds=d14f  es=0000  fs=150b  gs=0000
      iopl=2

      d0ff:00007644  mov  ax,word ptr es:[ebx+08]  es:0008=invalid

   9) No symbols were available so I navigated around the
      faults till I came to
      "doscall1:CODE16_GROUP:DOSR3EXITADDR:"
      referenced from      "DOSISIGDISPATCH + f"
      and       "DOSCOPY - 65"


ANSWER:
1.Could you try the same DLL/SYM/DSC/DSP files and use DSPINSTL on the
Previous System, in which you had no problems earlier?  If it goes through,
then the problem is Hardware related.  If it fails, it's probably because of
the modifications you made in the original source.

2.You could also try to use the original source with your DSC & DSP files and
try to eliminate errors in DSC/DSP Files, if any.  If there are no problems
with your DSC/DSP File, then that leaves the modifications you have made in
the original source.




!STORAGE________________________________**********
November 11, 1994
QUESTION: (Ref: FB0)
1. I am using PhysToVirt to access data buffers passed to my IFS during READ
   and WRITE while in the context of my ring 3 daemon process.  I am of course
   locking down the memory first and using VirtToPhys in the context of the
   IFS request before calling PhysToVirt in the context of the ring 3 daemon.
   All this seems to work for 1 application but with a heavier load I start
   encountering error 8 (out of memory).  I have heard that OS/2 has a "locked
   memory area" but cannot find any documentation on it.  If there is such a
   thing as a locked memory area I am probably running out of it.  What can I
   do to alleviate this problem ?  What are the various OS/2 memory areas and
   how do they work ?

2. I am also using PhysToUVirt to support network RAW data transfers.  It
   seems to work fine while copying files but if I try to run a application
   from a network drive (thru my IFS) I get error # 176.  Why would
   PhysToUVirt work fine except when running applications?


ANSWER:
1. IFS is not supported by DDK, but I will try to answer this as best as I
   can.  The buffers passed via READ/WRITE will be locked into memory and
   converted into physical address by the kernel before it is passed to the
   drivers.  It is only the non-parameter pointers (like pointers passed in
   user structures in IOCTL calls) that need attention.

   The PhysToVirt function picks up selectors from a limited pool of temporary
   selectors.  Therefore, it is possible to run out of memory if these are not
   freed quickly.  Refer to \ddk\src\dev\mouse\ioget.asm for a sample usage of
   PhysToVirt.

   The various memory areas in OS/2 2.x are explained in detail in the book
   "The Design of OS/2" by H. M. Deital and M. Kogan.  Refer to the redbook
   vol 0:  Control Program Reference for a broad introduction.  If you are
   using OS/2 2.x, there are 32-bit memory management DevHelps which are
   described in the latter book that may be worth taking a look at.  You may
   also want to see if you can use shared memory rather than pinned memory to
   transfer data.  With 32-bit paged memory, you dont have to lock an entire
   segment at a time; you can do it 4K pages at a time.

   PhysToVirt yields a GDT Based Pointer which is not usable from a Ring 3
   Thread.  Ring 3 Threads do not have GDT Access,they only have LDT Access.
   PhysToUVirt yields a virtual address mapped to the Application's LDT.

2. The error #176 (in decimal) is Reserved by the System and is not
   documented.

   PhysToUVirt returns a fabricated segment for private use between a Physical
   Device Driver & an Application.  Data within such a segment cannot be
   passed on system calls and can be used by the receiving application only to
   return data variables.




!MULTIMEDIA_____________________________**********
November 11, 1994
QUESTION: (Ref: F99)
The following code doesn't work.  It is called whenever an strategy OPEN
request comes in.  (Irrelevant parts have been deleted)

PID pid=0;

void StrategyOpen (PREQPACKET prp)
{
  PLINFOSEG plin;

  DevHelp_GetDOSVar(DHGETDOSV_LOCINFOSEG,0,&plin);    // save our PID
  pid=plin->pidCurrent;
}

The value assigned to pid is zero.  My driver is given the name "MPU401",
and from the OS/2 command prompt, I issue "copy mpu401 con", at which point
StrategyOpen() is called.  Should the PID be zero?


ANSWER:
1.Please try the DevHlp in the following manner :

PLINFOSEG plin,LocalInfoSeg_Ptr;

DevHelp_GetDOSVar(DHGETDOSV_LOCINFOSEG,0,&plin);
LocalInfoSeg_Ptr = *( ( PLINFOSEG far * ) plin );
pid = LocalInfoSeg_Ptr -> pidCurrent ;

2.For the User Process the PID is normally non-zero.




!MULTIMEDIA_____________________________**********
November 11, 1994
QUESTION: (Ref: F93)
I only want to allow one process to open my device driver.  When the second
process calls DosOpen, it's translated to a function 0xD strategy call.
Assuming I know how to GetDOSVar to determine if a different process is
attempting a DosOpen, what values in the Request Packet do I set to tell the
process that the device is not currently available?


ANSWER:
Depending on your application,the Request Packet Status could be either Busy &
Done (0x0300) or Error,Error Not Ready & Done (0x8102).  The open request is
rejected by sending the BUSY status back to the kernel.  The kernel maps the
return to a standard return code and sends that code to the application as a
failure.  In all cases whether errors,occured or not the driver must return
with the DONE status.




!OTHER__________________________________**********
November 09, 1994
QUESTION: (Ref: FK3)
In the past, I have posted questions to you guys, and you've responded by
saying "just goto this section of the DDK", and I could add some functionality
to the already existing driver.  This is great, but is it legal?  I mean what
if I wrote and sold a product that used a piece from the DDK that I added to.
Is that fair?  It seems like that would be an infringement on copyright
material within the DDK.  Or is the DDK provided to help do things exactly
like this, and selling it as a product then is also not an issue.


ANSWER:
Basically, you can do what you are asking.  See the DDK licensing agreement,
which accompanies the DDK, for details.




!OTHER__________________________________**********
November 09, 1994
QUESTION: (Ref: FJ7)
I am writing an ADD and would like to read a configuration file in the
root directory during initialization.  Is this possible?  If so, how?


ANSWER:
ADDs are base device drivers and initialize at ring 0, therefore they have no
access to the file API necessary to read a file.  Also, be aware that while
ADDs are initializing the file system really isn't in existence yet.  If your
ADD is non-critical to system boot up, then what some people do is run a ring
three thread (via the config) that calls to the ADD through an IOCTL and
completes the initialization with the ring three thread doing the file IO.




!I/O____________________________________**********
November 09, 1994
QUESTION: (Ref: FJ4)
Is there a way to reliably "stuff" characters into ANY kind of session under
OS/2 as if they had been issued from the keyboard?

I need to cover VDMs, PM apps, Full screen and/or Windows OS/2 sessions as
well.  Could I somehow call the KBD driver and make him "think" he's got a
scan code/key combination?


ANSWER:
There is no documented way to stuff characters into sessions under OS/2.  But,
you could try out the following procedure to extend the KBD driver.

Implement a new user defined IOCtl function under category 4. This function
can be called from an application with the scan code in the parameter block.
From the user defined IOCtl function call 'ProcessScanCode' with the scan code
in AL This function puts the scan code in the appropriate place.  You will
have to modify the KBDIOCT.ASM to include the User defined IOCtl Function.

Ref : \DDK\SRC\DEV\KBD\KBDSCAN.ASM for 'ProcessScanCode' function.
          \DDL\SRC\DEV\KBD\KBDIOCT.ASM ,which is the Generic IOCtl Request
           Processor
Ref : Physical Device Driver Reference, Ch - 10, P-323 for IOCtl extensions.




!STORAGE________________________________**********
November 09, 1994
QUESTION: (Ref: FI9)
What IFS does/will a SCSI based WORM drive be using?  Which device manager
will be used?  Is it the DASD Manager or the SCSI Manager?


ANSWER:
OS/2 v2.x does not have an IFS for a WORM device.  Due to the special device
characteristics of WORM, a random access file system on this device may be
entirely different from DASD file system.  This calls for a new IFS and DMD
for WORM devices.  In case the WORM device is used like an archieval media, a
new device class driver to call SCSI DMD may be sufficient to do the job.




!BASE___________________________________**********
November 09, 1994
QUESTION: (Ref: FE4)
1. What is the best way to locate the cause of a TRAP 8- Double Exception?
The problem with stepping through code is that it won't happen when tracing
through code.

2. How do I do a Post Mortem to determine the CS:EIP when the TRAP 8 was
issued?


ANSWER:
1. TRAP 0008 - The processor detected an exception while processing an
exception. It could be caused by either hardware or software. If TRAP 0002 is
also being experienced contact hardware support.

2. Use the Krnl Debugger Command:  VSF * VS does not however interrupt Ring 0
Interrupts.  The F(Fatal) option causes the kernel to route the faults that
are fatal to a process to the debugger instead of displaying the PopUp
Message.  Executing G after VSF * will bring you to the CS:EIP which is
causing the Trap.




!BASE___________________________________**********
November 09, 1994
QUESTION: (Ref: FD7)
My PDD returns a pointer to the 32 bit app, this pointer was created by
PhysToUVirt so as to access the memory on the card.  I have no problem
accessing the memory on the card.  Now the 32 bit app needs to send the PDD 2
pointers one from the memory local to the app and the other is possible the
one returned to the app by the PDD.  Since these pointers are flat and I have
no idea which pointer is which, how do I get the virtual address from theses
flat address?  All I want is to beable to convert ANY linear address to a
VIRTUAL address, even fabricated addresses by PhysToUVirt.


ANSWER:
1. You can try converting the address to physical and check against the
adapter memory region.

2. If your application is passing you linear (flat) addresses.  The VM*
mapping functions may be a better option.  Since they work in flat space, you
do not have to handle any fabricated addresses.  The pointers mapped by
VMGlobalToProcess and VMProcessToGlobal are like any other user pointers.  3.
If the user's buffer is in the tiled region (OBJ_TILE),you can use the
SelToFlat() macro to convert the virtual address to a linear address.


FOLLOW-UP QUESTIONS
1) I have memory mapped hardware in the address range of 0x10000000 to
0xEFFFFFFF and its size is > 64K.  I need to allow 32 bit apps to have access
to this area.  I need to do this from a physical device driver(PDD).  How do I
map physical addesses in this area to a linear addresses for application use?
The size needs to be > 64K.

2) I need to let apps have access to the memory mapped hardware in question
#1.  Also the app may need to give me back a pointer to the memory mapped
hardware.  I am using IOCtls to talk to the PDD and these pointers are inside
a structure that is passed during the IOCtl call.  How do I convert the linear
pointer back to being a virtual pointer?  If I were using PhysToUVirt I get a
fabricated segment back, I can convert it to a linear address.  But if I get
that fabricated linear address back how can I get a virtual address?

3) Does VMAlloc only alloc in the area of 0x0 to max RAM found in the system?
Or can I use it to solve question #1?  I have tried to use VMAlloc to solve
quesion #1 but I always get an error.

4) Can the MAKEP macro be use in a PDD?  Or is an app only macro?  Basicly can
I take a virtual address and get a linear address with MAKEP in a PDD and pass
the linear address back to the app?

5) Where are the simple easy to use memory mapping and pointer conversion
functions for PDD?


FOLLOW-UP ANSWERS
1. Since your physical address requires more than 24bits and is larger than
64K, I assume you will be running your app in 80386 prot-mode.  It is possible
to map a linear user address to this region using VMAlloc.  However 512MB -
4GB (0x20000000-0xFFFFFFFF) Region is called the System Region and is reserved
for the operating system use.

2. It is not necessary to go thru PhysToUVirt, because the pointer returned by
VMAlloc can be used like any other user space linear pointer in your 32-bit
app.  The virtual mapping is required only for device driver which still use
16-bit model.  You could use the FlatToSel Macro (if the address is < 512MB).
This Macro is defined in DDK\INC\DEVHLP.INC

3. No.  VMAlloc creates a mapping between the VM space and the physically
addressable region.  Since the memory mapped h/w is not allocatable RAM, be
sure to use VMDHA_FIXED, VMDHA_CONTIG VMDHA_PHYS and VMDHA_PROCESS flags to
get the regions mapped into the process space.  The error in VMAlloc could be
because of the fact you are trying to map memory beyond the 512MB region.

4. MAKEP can be used even in PDD.  In your case, you dont need any fabricated
pointers.  You can pass the linear address obtained from VMAlloc directly to
your app.

5. Please refer to the following for examples and usage :
     (a) PDD Reference
     (b) OS/2 2.0 Vol 1: Control Program (Redbook),
         section 6.1
     (c) \ddk\src\pmvideo\xgasys20\xgaring0.asm
     (d) Writing OS/2 2.1 Device Drivers in C, by Steven
         J. Mastrianni, II edition. sections on VM*
         devhelps.

Note that DDs still use 16-bit model.  & operator on DD variables will give
you a virtual 16:16 pointer.  Where a linear address is called for you may
have to convert this to Linear (32-bit offset) using VirtToLin devhelp.  You
will find an example in (d) cited above.


FOLLOW-UP QUESTIONS
We are running 386 Protected mode 32 bit applications only.

1) The 512MB - 4GB (0x20000000-0xFFFFFFFF) Region you speak of as being the
system memory.  Are you talking linear (flat) or physical address space?  My
hardware is in the physical address space of 0x10000000 to 0xEFFFFFFF and that
cannot be changed.  I do not care where it maps to in linear space.  The
largest single space I need to map a on time is from 0x40000000 to 7FFFFFFF or
0x80000000 to 0xBFFFFFFF.

2) Is it a problem having memory mapped hardware in the range of 0x10000000 to
0xEFFFFFFF for OS/2?  If so what are the problem?  And how do we get around
them?


FOLLOW-UP ANSWERS
Some background info before I answer the questions raised.  The virtual space
(in OS/2) is the 4GB space addressable by 32-bit offset.  It ranges from
0x0...0xffff ffff (strictly speaking the low 64KB is not mapped deliberately
to catch null pointers).  Out of this total 4GB space, the lower 512MB (0x0
...  0x1fff ffff) is addressable in user mode.  This range contains a private
region (exclusive to this process) in the lower area (0x0 ....)  and a shared
region (common to two or more processes) in the upper area (....  0x1fff
ffff).  These regions grow towards each other and the boundary is dynamic.

The virtual space above 512MB (0x2000 0000 ...  0xffff ffff) is reserved by
the kernel for process-specific tables and other information.

The physical space is the memory range addressable thru the 32-bit address
lines of the 80386 chip.  If the bus you use is able to make use of the
A24..A32 address lines then you should not have any problem addressing your
hardware.  Treat your adapter as a memory object beginning at address
ADAP_ADDR and spanning a range ADAP_RANGE.

VMAlloc allows you to map ADAP_ADDR to LIN_ADAP_ADDR.  This is possible only
if ADAP_RANGE is less than (512MB-shared region size - existing private region
size - overheads).  You may specify whether you want the flat address in the
private region or global (shared) region while VMAllocing.  If you allocate in
the shared region the object will eat up shared virtual space in every process
in the system for possible access.

Now for the answers:
1. The linear range 0x4000 0000 is not available to processes for mapping
memory objects.  The upper limit is 0x1fff ffff.  The physical addresses
0x1000 0000 should not pose any problems.

2. The linear range need not be same as the physical range.  You can map to
any region below 0x2000 0000 as long as the object can be fitted within the
private/shared region of the virtual space.  You have not given the size of
the memory object to be mapped.




!STORAGE________________________________**********
November 09, 1994
QUESTION: (Ref: FD0)
We have a PDD for tape drives attached to the floppy disk controller.  We
noticed there is a IOCTL (Cat 8, Func 5d) to obtain access to the fdc
hardware.  We would like to issue this IOCTL from the PDD instead of from the
high level application.  How can this be done?  Thanks in advance.


ANSWER:
The DosDevIOCTL() can be issued by the PDD at INIT time.  The file handle can
be obtained by DosOpen on the Drive.

If you want to invoke IOCTL functions at TASK time, you cannot use this
call.Instead, you will have to AttachDD to the floppy driver and then put
across an IDC call to invoke the IOCTL operation.

The source code for Adapter Device Driver for ABIOS Diskette is contained in
the DDK directory :  DDK\SRC\DEV\DASD\IBM\IBM2FLPY IDC is available on this
Adapter Device Driver and the commands are given through the IORB with the
Entry Point obtained from DevHlp_AttachDD (to IBM2FLP$).IOCM_SUSPEND &
IOCM_RESUME is used to obtain the DosDevIOCtl (Cat.8,Func.5d)
Functionality.This is also documented in the Storage Device Driver Reference.




!MULTIMEDIA_____________________________**********
November 09, 1994
QUESTION: (Ref: F87)
I am having difficulty running the PMADDE audio utility as provided in the
DDK.  It gives an error box:

         Unable to Load Device Specific Info
                        87

I remember this question was posted by someone else in one of the quest.zip
files.  The answer to him was his mmpm2.ini file was not correct and mmpm2 was
not recognizing his audio driver.

My driver is currently working under mmpm2, it makes the proper window
open/close noises, and bells, and applause, etc..  So, I don't think mmpm2 has
a problem recogizing my driver.  My base OS/2 version is 2.1, current CSD XR02010.  My MMPM/2 is version 1.01.2, current CSD XR06200, prior CSD UN09407.
My driver and mmpm2 install stuff is based on the AD1848 sample source.  The
driver is for the ICS2002 audio codec and is intended for use in the IBM
Thinkpad 230.  The boys in Yamato are requesting me to run the PMADDE utility
to verify functionality.

Here is my mmpm2.ini:(DELETED FOR SECURITY REASONS)


ANSWER:
You are using the Resource ID = 8 without updating the PMADDE.H & PMADDEVS.RC
Files.

The following comments are with reference to DDKv1.2 :
Add the following line in DDK\MMOS2\MMTOOLKT\NEATSTUF\PMADDE\PMADDE.H
#define BUSAUDIO  8
Then update the corresponding entries in PMADDEVS.RC (same directory)
RCDATA BUSAUDIO
BEGIN
<User Specified Data>
END
Rebuild with these changes and it should work.




!STORAGE________________________________**********
November 09, 1994
QUESTION: (Ref: F80)
I am building a filter driver that sits between the DASD.DMD and any DASD
.ADD drivers.  Is there any reason why I shouldn't use IOCTL calls to
my filter driver to modify it's functionality?  The only other option I
might have is to use a .SYS device driver and IDC to control it but, I would
prefer not to have 2 components to my software.


ANSWER:
The filter DD interface is identical to that of ADD.  There are two ways of
modifying the functionality.

One way is to define a set of command line parameters and access them during
driver initialization.  To have uniformity in command line syntax a
parser/tokenizer is supplied in \ddk\src\dev\dasd\cmdparse.  As the filter
device driver is a BASEDEV, the parameters set thru command line are unchanged
till subsequent reboot.

Like ADD, the Filter DD has a character device name, which ends with a $
(dollar).  This character device name may be used to open the FDD and invoke
IOCTL commands.  Obviously, these IOCTL codes will be vendor- defined and
implemented in the strategy routine of the driver.




!OTHER__________________________________**********
November 04, 1994
QUESTION: (Ref: FI2)

I have a requirement for communication between an OS/2 application and Windows
apps that I am writing.  I need both synchronous and asynchronous
communications.

The Developer Connection for OS/2 has articles by David Kenner discussing
using VDDs in volumes 2-4 but the articles raise several questions and the
CD-ROM shipped with DevCon does not contain complete source code.
Specifically I wonder if anyone can help with the following questions.

Q1. How does a Windows application call into the VDD?

Q2. How does the VDD make callbacks into the windows application?

Q3. The VDHRegisterApi function is undocumented - how does it work?

Q4. Can the VDD force the DOS (win-os2) application to wait for some
    processing the OS/2 side carries out - by using VDHSemaphores?

Q5. What contexts does the VDD run in?


ANSWER:
                                         <--------          <--------
WIN-OS/2 Process     -------->   VDD  -------->   OS/2 Process


The VDD acts as an intermediary between WIN-OS/2 process and OS/2 process.

INITIALIZATION OF VDD :
The VDD is initialized during OS/2 system loading.  During initialization the
VDD cannot call VDHRegisterAPI.  So, register user hooks for creation and
termination of DOS/WIN-OS/2 sessions using VDHInstallUserHook calls (Ref:
sample code - 1, DEVCON-4).  The creation hook is called VddCreate.

WIN-OS/2 Session Creation :
When a WIN-OS/2 session is created, the creation hook VddCreate is invoked,
which in turn calls VDHRegisterAPI to register VDD protect-mode entry point
(Ref:  sample code-2, DEVCON-4).  This process takes place per WIN-OS/2
session creation.

OS/2 process:
OS/2 process opens VDD with DosOpenVDD, initializes a queue handler with
DosRequestVDD (Ref:  sample code -1, DEVCON-2).  DosRequestVDD (POST_MESSAGE)
writes message into VDD internal queue which in turn is sent to WIN-OS/2
process.  This is explained later (Ref:  sample code - 2, DEVCON-2).
DosRequestVDD(READ_QUEUE) waits for a message from the WIN-OS/2 process and
returns when a message is ready (Ref:  sample code - 3, DEVCON-2).

WIN-OS/2 process:
In WIN-OS/2 process first determine the environment by issuing INT 2Fh with
AX=4010h (Ref:  sample code - 4, DEVCON-4).  Next get the entry point into VDD
by issuing INT 2Fh with AX=4011h (Ref:  sample code - 5, DEVCON-4).  With this
entry point WIN-OS/2 process can call VDD to initialize/register callback/post
message/terminate.  First, the initialization is to be done.  The register
call back option registers a function within WIN-OS/2 process.  This is the
function called by the VDD to pass on the message received from OS/2 process
to the WIN-OS/2 process.

The WIN-OS/2 process sends messages to VDD thru post message option.  The
ReadVirtQueue function (Ref:  sample code - 3, DEVCON-2) retrieves the message
from the VDD.

A1. Issue INT 2Fh, AX=4011 to get VDD entry point.  Use this to call VDD.

A2. Using VDD entry point the WIN-OS/2 process registers a call back function
    (this function is present within the WIN-OS/2 process) with the VDD.  The
    VDD calls this callback function to send messages to the WIN-OS/2 process.

A3. Please refer to p-203,391 of Virtual Device Driver Reference for 'C' &
    assembly calling conventions respectively.

A4. Yes. Please refer to p-241,432 of Virtual Device Driver Reference.
    VDHWaitEventSem is used to wait on an event semaphore.  If the semaphore
    is posted, it will return immediately.

A5. a) Initialization context
    b) DOS session creation context
    c) DOS session task context
    d) OS/2 task context




!STORAGE________________________________**********
November 04, 1994
QUESTION: (Ref: FH9)
Q1. I have not been able to get the NEC CDR 260 to work on IDE using 2.1 or
    Warp beta.  Is this or any IDE CDROM supported?  If not when could I get
    the beta or source code for IBM IBM1S506.ADD that works with CDROM's?

Q2. The problem seems to be that the system does not see the CD present in the
    drive even though it is there.  Perhaps the IBM1S506.ADD does not handle
    removable media in general?


ANSWER:
A1. There is a beta OS/2 device driver for the NEC CDR 260 cdrom.  The name of
    the driver is NEC260.ZIP and it is on the NEC BBS at 1-508-635-4706.

A2. You are correct, IBM1S506.ADD does not handle removable media.




!OTHER__________________________________**********
November 04, 1994
QUESTION: (Ref: FH1)
I am writing an Adapter Device Driver (ADD) for a parallel port based IDE hard
disk.  I was using the IBM1S506 ADD that is provided on the DDK as a template
for my ADD.

On my machine, I have a SCSI drive and a CDROM drive.  The SCSI drive is
partitioned as C:, D:  and E:.

Q1. To be able to load the driver successfully and allow OS/2 to boot
    successfully, I have to set the UF_REMOVABLE bit in the UnitFlags field of
    the UNITINFO sturcture.  If I do not set this bit, OS/2 fails to boot and
    hangs up giving the message "Unable to load C:\os2\country.sys.".  Is this
    expected ?

A1. An ADD should be loaded using BASEDEV= config command without path prefix.
    The following bits in UnitFlag UNITINFO must be cleared.

       a) UF_NODASD_SUPT
       b) UF_DEFECTIVE
       c) UF_REMOVABLE
    The UnitType must be set to UIB_TYPE_DISK.

    If the above conditions are satisfied and the system is still unable to
    load the ADD, the problem may be elsewhere.  The possible area may be one
    or more of the following -

       a) This ADD interfaces thru printer port. You may have to
           disable adapter initialization thru command line
           parameters.
           Ref : ST506/IDE specific parameters in "Storage Device
           Driver Ref"
       b) INIT request packet command code for base device driver is
           1BH instead of 0H.
       c) ADD must be defined as level 3 character device
           driver with capabilities bit strip indicating alternate
           INIT request packet.
       d) ADD must have a valid character device name ending with a $
           sign.
==============================================================================

Q2. My disk is formatted under DOS and works in the DOS environment.  Under
    OS/2, when I set the bit mentioned in Ques 1, my disk comes up as drive
    F:.  When I type F:  at the OS/2 prompt I am able to get the F:  prompt.
    When I issue a DIR command, the following appears:

        Volume in drive F has no label.
        The Volume Serial Number is 534E:4A52
        Directory of F:\
        SYS0026: The specified disk or diskette cannot be accessed.

    When I type HELP SYS0026 from drive C:, I get the following info:

        The disk or diskette is not properly formatted for the
        operating system.  Action: Format the disk for the
        operating system.

    However the IBM1S506 ADD does *** NOT *** support the Format command.  So
    the question is, how does formatting occur on a regular IDE disk, if the
    ADD does not support the Format command?  Do I have to write a separate
    formatting program to format my disk?

A2. The system does not recognize this ADD as a partitioned fixed disk.
    Instead it's assumed as a removable FAT file system.  This problem may
    disappear when Q1 is resolved.

    IBM1S506 ADD does not implement IOCC_FORMAT command.  You have to
    implement relevent command modifiers in IOCC_GEOMETRY and IOCC_FORMAT
    commands.  You can still use OS/2 FORMAT utility.




!OTHER__________________________________**********
November 04, 1994
QUESTION: (Ref: FH0)
Q1. Why must the driver version field in the device caps be 2.00?  That is
    what the display driver documention says.  Can I change the version
    number?  What is the meaning of this number?

Q2. At which OS/2 verion is the OEMHLP support for PCI valid?


ANSWER:
A1. CAPS_DRIVER_VERSION field gives version of presentation driver.  The
    higher order word of Version ID.  is zero, low order word of Version ID.
    identifies release.  Example:

                  for OS/2 v2.0 it is 0x0000 0200.
                  for OS/2 v2.1 it is 0x0000 0210.

    Each version of OS/2 has its unique corresponding id.

    This Version ID could be useful depending upon your Application and the
    Driver.  GreQueryDeviceCaps supports DevQueryCaps at the API.  The
    handling routine returns the required information in the Device
    Capabilities Buffer.  This function must be supported by the driver.

    The CAPS_DRIVER_VERSION is sometimes used during driver loading to prevent
    version mismatch with the operating system.  There are certain drivers
    which work with only particular OS/2 Versions.  This could prevent such a
    situation by giving out the Error Message that the Driver is not supported
    on this Version of OS/2.  If you are not particular about the OS/2
    Version, you could ignore this field.

A2. The OEMHLP.ZIP file on the DUDE bbs is only a preliminary document.  OS/2
    2.11 has little to no PCI support, we are still working on it.  Some
    adapters, such as Adaptec 2940, work but can be problematic.  Full PCI
    support requires configuration utilities that will not be released until a
    future version of the operating system.  This will not be in WARP either,
    although some PCI adapters may work fine under WARP.




!VIDEO__________________________________**********
November 04, 1994
QUESTION: (Ref: FG8)
I've got a question for you.  In OS/2 you've got a Base Video Handler as
specified in your CONFIG.SYS, i.e.  SET VIO_VGA=DEVICE(BVHVGA).  Depending on
what your CONFIG.SYS says, you can chain BVH's together just as described in
the Video PDD section of the Physical Device Driver Reference.

Ok - here's my question.  OS/2 also uses a DLL called BVHWNDW.DLL, that
supports windowed VIO sessions.  Is there any way to chain to that DLL in the
same way that you can chain to the normal BVH?  What I'm after is some way to
get a crack at what BVHWNDW.DLL is going to see or do before it does it.  Is
this possible?

I did look at Registering a VIO subsystem, and was hoping instead that I could
do device chaining to the BVHWNDW just like you can with the normal BVHVGA.


ANSWER:
The DEVICE() Keyword defines the list of names of the DLLs & PDDs which are
combined to create the Video Device Handler.  The BVDHWNDW.DLL is not like
other device drivers, it provides VIO functions for windowed sessions and
appears like a video driver to the Presentation manager.  Also, it gets loaded
only for VIO window sessions unlike other BVDH that get loaded during start
up.  This DLL cannot be added to the DEVICE() statement.  The name of this DLL
is fixed and the Base Video Subsystem loads it automatically as it is needed.
BVHWNDW.DLL is the module called from BVSCALLS.DLL when a VioXXX API is called
in AVIO and the Window Session(OS/2 Window).  It emulates the Vio API Call to
the GPI API Call on the PM Desktop.

The source for BVHWNDW.DLL is contained in the DDK.  You could modify the
source in \ddk\src\vdh to monitor calls to BVDHWNDW.DLL.




!OTHER__________________________________**********
November 04, 1994
QUESTION: (Ref: FE0)
I would like to be able to use fonts similar to the VIO and System Proportional
fonts in my application, but with some changes to tailor the character set
slightly.  I was trying to reverse engineer the fonts that are in the
DSPRES.DLL dll to get a copy of them.  I discovered that there is a resource
type RT_xxx defined of 0x3e8 (1000b10).  After dumping them out in hex format,
I discovered the format of these fonts is very similar to, but slightly
different from, the normal font record layout.

Q1. I was wondering where the layout/docs of these font's are located. The file
    PMFONT.H has a define for the resource type, but no indication of the
    record layout.

Q2. Is this some type of "legacy" situation, that is, an obsolete, held-over
    format?  Or is there another specific reason?

Q3. How would the developer of a presentation driver access them anyway?  I've
    noticed that the DSPRES.DLL is always supplied with all the different
    drivers coming from various video driver vendors.


ANSWER:
DSPRES.DLL has the OS/2 Display Driver Fonts: Normal Text Fonts, Old System
Proportional Fonts and AVIO Fonts.

A1. The font file formats are described in PM Prog. Ref. Vol - 3 Appendix E,F.

A2. To design new fonts font editor utility may be used. This is available as
    part of developers toolkit for OS/2.

A3. Several font functions are described in PM Device Driver Reference Manual
    (see 'font functions' in index). When Presentation Manager is initialized,
    the engine is responsible for establishing the default image and outline
    fonts, and the default pattern and marker sets.

    The presentation driver can supply device fonts as default fonts. If this
    is done, the driver can request the graphics engine to manage the device
    fonts by setting the CAPS_FONT_OUTLINE_MANAGE or CAPS_FONT_IMAGE_MANAGE
    flag in the array of device capabilities (see GreQueryDeviceCaps).  When
    these flags are set, the engine performs any mapping and transforms that
    might be necessary.  To use a default font belonging to the presentation
    driver, the font handle is passed to the engine in response to
    GreQueryDevResource. This has been documented in the Presentation Device
    Driver Reference.




!STORAGE________________________________**********
November 04, 1994
QUESTION: (Ref: FD5)
Q1. Always on the lookout for enhancements, I've been looking at EDDI so I can
    enable S/G for the xfer.  Can you confirm that EDDI is supported for
    character devices?  I'm a bit confused about what to do with BlockCount
    and BlocksXferred (page 16-11 of the OS/2 2.0 PDD Reference) and how they
    apply to character devices.  Is there sample code anywhere of a character
    mode EDDI implementation?

Q2. I'm uncertain whether I really want S/G anyway.  My machine supports it
    (or at least the controller does) but most of my customers' machines
    probably won't.

Q3. The XferBuflen in the CDB is set to Buffer Length of *each* S/G element.
    This field is the same as the System Buffer Byte Count in the SCB.  This
    seems to imply that I'd have to break up the xfer into 4K chunks and thus
    lose the advantage of large xfer size above.  Since I reuse the same 64K
    buffer for each call maybe S/G won't buy me much.  I'd appreciate your
    comments.


ANSWER
A1. The EDDI (introduced in OS/2 2.1) is specifically targetted at HD drivers.
    The interface parameters and functions are meant for IFS and FSD access to
    HD drivers, as evident from the descriptions of BlockCount and
    BlockXferred.  Therefore, there is no sample code for character mode EDDI.

A2. It is the ADD that provides S/G capability, either in controller hardware
    or thru emulation.  The performance with even emulated S/G will be better
    than that with no S/G (cf.  pg 137, SDD Ref).

A3. If you have a fixed contiguous buffer of 64K, you dont have to depend on
    s/g.  Even if the buffer is not contiguous, use PT (bit 12) of the SCB
    enable word to break up your buffer into 16 pages and send them in one go
    with the number of entries (i.e.  16) in System Buffer Byte Count.  The
    System Buffer Address will contain the address to a list of 16-pairs (page
    address, byte count in page).  (cf.  pg 180, SDD Ref for details)




!VIDEO__________________________________**********
November 04, 1994
QUESTION: (Ref: FC8)
Whenever a Windows program calls 'RealizePalette' an error occurs in GDI.EXE.
The error message displayed in the PM dialog box looks like the following:

        Application Error
        'myapp' caused a General Protection Fault in module
        GDI.EXE at 0016:160C    ...

The basic problem is that the VGA sample driver code doesn't implement palette
management.  (The file SEAMLESS.TIP has been very useful to fix the problems
with the default palette).

Q1. The best thing would be to have all the sample code for the 256 color
    seamless windows driver.

Q2. If this is too much, at least a sample of how to handle the
    'RealizePalette' request in the seamless windows driver.

Q3.  Another sample about how to use the counter accessible to the presentation
     driver and the seamless windows driver and Windows kernel would be very
     useful.

     The counter (ULONG 'ulLastPalUpdate' in SEAMLESSDATA shared structure) is
     incremented in the PM driver and it should allow the seamless windows
     driver and kernel to determine when their internal palette mappings are
     invalid, but we don't know how.

Q4.  Running a simple program which creates and realizes a new palette, copying
     the default palette, we saw that for GDI palette realization PM Shield
     calls the PM 'GREQueryPaletteRealization' but our PM driver returns a
     mapping from the logical table to the hardware palette of 256 zeros before
     or after the GDI error occurrence.

     This should be related to the problem in some way, but we don't know how.


A1. Microsoft Windows 3.1 DDK Modified Code for WINOS/2 Seamless VGA is
    available as an optional diskette.

A2. If the Presentation Space being used is associated with a Direct Device
    Context (DC) such as the screen, then the application must call
    WinRealizePalette, passing the palette handle obtained in the
    GpiCreatePalette call, before drawing/using the palette.  It is the
    WinRealizePalette function call that filters to the presentation driver to
    update the colors in the devices hardware palette.  At this time, any
    palette/color conflicts that occur should be resolved.

A3. After Windows driver initialization, the GDI issues a Driver Control() call
    requesting the address of the data described above. (A Control() call is
    really the end result of an application device escape.  The GDI is
    responsible for translating Escape() calls to Windows Driver Control()
    functions.)  After this call, the GDI has addressability to all the
    necessary PM palette information.

    The format of the Control() function is:

    rc = Control ( lpDevice, SEAMLESS_PAL_INIT, lpInDate, lpOutData)

    where

    lpDevice = a long pointer to a data structure of type PDEVICE, the
    destination device bit map

    SEAMLESS_PAL_INIT = a word of value 6010
    lpInData = NULL
    lpOut Data = a long pointer to a structure that contains:
                 bfPaletteIsfixed
                 ulLastPalUpdate
                 pHWPalette

    (These are the palette-related entries in the PM/Windows shared
    data/code area).

4.Refer to the Display Device Driver Reference - Realizing Palette.




!OTHER__________________________________**********
November 04, 1994
QUESTION: (Ref: FC2)
OS/2 does not recognize my device driver as being a device driver.  Below is
some info on the situation.  What am I missing or doing wrong?

I'm using the DDK in conjunction with Mastrianni's book on writing device
drivers in C. I'm using the Watcom C compiler, and the masm that was shipped
on the ddk.

Steve's sample serial driver has only five segments, _DATA, CONST, _BSS,
c_common, and _TEXT; and they are in that order.  Using the Watcom compiler, I
have several other segments in addition to the ones that the serial example
had.

The _DATA segment starts at 0002:0044, and the _NULL segment starts at
0002:0000 (with the _TEXT segment starting at 0001:0000).  In Steve's code,
the _DATA segment starts at 0001:0000, and the _TEXT segment starts at
0002:0000 (and no _NULL segment).

I've tried putting the device header in the _NULL segment explicitly, which
mapped the device header to 0002:0000, and I also have a copy at the start of
the _DATA segment at 0002:0044.  I have also tried putting the assembly
version of the device header at the head of the data segment explicitly.

Nothing seems to work.


ANSWER:
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.  at 0001:0000).

This is done with the start up assembler code in which the Data Segment is
defined before the Code Segment.  The default StartUp Code of the Compiler is
not used.  This is done in the Microsoft C Compiler v6.0 by using the dummy
label "__acrtused".

Please contact Watcom Support for help in Calling a C - program from the start
up Assembly Code, without using the Compiler's StartUp Code.

Compile with the Small Memory Model option.  While linking, ensure that the
Start Up Assembly Code is the first Object Module.




!I/O____________________________________**********
November 04, 1994
QUESTION: (Ref: FC0)
I know how to get the mouse pointer location in screen group 1 (Presentation
Manager.)  But I do not know, or see, what is needed to get it (or screen
dimensions) from a full screen DOS or OS/2 session (especially full-screen DOS
session, since the virtual mouse driver is used.)  Is there a way to do this?
For the VMOUSE.SYS driver, I see the OS/2 driver passing to it a packet
(structure) of information consisting of which session gets the movement, the
button change information, mickey delta movement, etc...  but do not see a way
for the OS/2 driver to get the VMOUSE.SYS driver to tell it what the cursor
location is.  I would appreciate any help.


ANSWER:
For DOS apps, the virtual mouse driver supports INT 15H and INT 33H
interfaces.  Check out the notes in chapter 5 of VDD Reference (DDK v1.2) and
in \ddk\src\vdev\vmouse\mouse.doc for details.  For non-PM OS/2 apps, the
MOUSE$ driver provides ioctl functions to get the mouse pointer position.
Refer to Category 07h functions in Chapter 10, PDD Reference for details.

In OS/2 2.x, it is the OS/2 driver that handles the device directly and the
VMOUSE is just a Virtual driver that emulates the device in DOS sessions.  The
cursor location should be available with this driver itself.




!VIDEO__________________________________**********
November 04, 1994
QUESTION: (Ref: FDB2)
Q1. Is the DOS network API (int 2f) supported in a DOS VDM and if not is
    there a VDD which does ?

Q2. Is there a VDD which supports NETBIOS in a VDM?


ANSWER:
A1. There is no support for DOS network API in OS/2 VDM.  Int 2f is actually
    used for time-slicing (see VDD Reference,pg 19) during busy wait loops.
    In OS/2, network layer support is usually implemented as a R3 daemon.
    VDDs for these services are supplied along with the Networking software
    (e.g LAPS, NTS/2).  No VDD in the DDK supports the DOS Network API.
    However,you could always hook this interrupt and have your own Interrupt
    Handler.

A2. The base release of OS/2 does not contain any VDD for NETBIOS support.
    However, NETBIOS support for DOS apps is provided by products like LAPS,
    NTS/2 and so on.  Note here that if a NETBIOS support is installed on
    OS/2, the DOS VDM apps will be able to make use of these services
    transparently.  Also,the virtual machine boot facility in OS/2 permits
    loading any session/ version specific software.The DDK does not have any
    VDD which supports NETBIOS.
