This is file: 12_93QA.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__________________________________**********
December 30, 1993
QUESTION: (Ref: 749)
I am trying to install a pre-reflection interrupt handler in a Virtual DOS
Session.  According to the DDK Documentation I need to use the
VDHInstallIntHook function to register my interrupt handler.  The FLAGS
parameter of VDHInstallIntHook accepts different options for the installed
interrupt handler.

According to the Documentation they are VDH_PRE_HOOK (the one I can't find)
and VDH_ASM_HOOK which I can find and have no problem with.  I can't compile
my driver without the VDH_PRE_HOOK since it doesn't seem to be defined in any
DDK include file that I have seen.

Can you provide either the name of the include file VDH_PRE_HOOK is in or the
defined value of VDH_PRE_HOOK.


ANSWER:
We intend to open a defect on this.

As a temporarily fix, you can include this code in v8086.inc

     VDH_PRE_HOOK      EQU     000000002H;




!STORAGE________________________________**********
December 30, 1993
QUESTION: (Ref: 625)
Q1. Do you have any ADD test utilities.  I have many code paths in my ADD
    driver that have not been executed by OS/2 2.1.  If you have a good test
    utility, please let me know how to get a hold of it.  We have tried your
    compatibility tests for OS/2 2.0, but they don't really test the ADD very
    extensively.  If you don't have a good utility, what is your schedule for
    creating one?

A1. Regarding test utilities for ADDs, I do not know of anything that exists.
    The developers here use their own testing methods.  The use of the kernel
    debugger would be the best way to test and debug ADDs.  The developer
    should be able to write test modules/applications to test different parts
    of the ADDs using DOSDevIOCtl calls.
==============================================================================

Q2. I am using the DevHlp_RegisterStackUsage() function in my ADD.  If I use
    four host adapters with four different IRQ levels in a system then the
    last call fails.  I noticed that none of your drivers which use interrupts
    make the RegisterStackUsage() calls.  Is it something I need to do?

A2. None of the developers here have used this call.  That makes it apparent
    that it is not required for a device driver to use the call.  However, the
    PDD reference says a maximum of 8KB is supported by OS/2 2.x for usage
    stack.  The failure of the last call in this case might have been due to
    the total size of the usage stack going beyond 8KB.




!BASE !VIDEO____________________________**********
December 30, 1993
QUESTION: (Ref: 590)
I try to alloc mem in PM driver, and then read a file into the allocated
buffer.  My DosAllocMem is called ok (returns 0), but the following DosRead
gives me DelayHardError SYS3175 4 string(s).  What did i do wrong?  DosOpen is
ok, so I got the filehandle.

Here is the relevant part of my code:
   DosSetFilePtr(hFileHandle, 0L, FILE_BEGIN, &ulFilePtr);
   DosAllocMem(&pBuffer, ulFileSize, PAG_READ | PAG_WRITE);
   \\  pBuffer was returned as 0x1D0000
   DosRead(hFileHandle, pBuffer, ulFileSize, &ulFileSize);
   \\  then it traps.


ANSWER:
The customer is not committing the memory that he has reserved with the
DosAllocMem function and hence is getting the fault.  He can do this by using
the PAG_COMMIT flag in the function call, as follows:

    DosAllocMem(&pBuffer, ulFileSize, PAG_READ | PAG_WRITE | PAG_COMMIT)

or he can use DosSetMem to commit the memory he reserved using DosAllocMem
just before he is actually ready to use it.




!BASE___________________________________**********
December 30, 1993
QUESTION: (Ref: 584)
Q1. Is it valid to issue software interrupts in a physical device driver?

Q2. Can you recommend any ways that I set up access to either the 16:16
    protected mode Bios interrupt handler or a way of mapping a linear address
    for the 32-Bit protected mode entry point?


A1. It is not valid to issue software interrupts in a physical device driver.

A2. Look at the OEMHELP IOCTL functions.  You might be able to get the
    information you want there.




!VIDEO__________________________________**********
December 30, 1993
QUESTION: (Ref: 555)
I'm currently trying to allocate a selector:offset address to 1 Mbyte of VRAM
memory at physical address=12 Mbytes (C00000h) by using the Device Helper
Services, but have run into some difficulties.

In the DDK Physical Device Driver reference (S10G6266) under the description
for VMAlloc, it describes how to do this using VMAlloc and then using the
FlatToSel macro to convert to a selector:offset.  But in doing this, the
selector I end up with is limited to 64k instead of the 1Mbyte specified.
(Actually, I end up with 16 selectors each of 64K for a total of 1Mbyte.  But
what I really want is one selector with addressability to the full 1Mbyte)

I looked in the XGA Ring0 driver (under the directory \xga32\xgasys20) in
module XGARING0.ASM to see what it was doing.  It implements a function called
flat_access, which uses the device helper service VMAlloc to map a physical
address to a linear address.  But it doesn't go on to create a selector:offset
address from this linear address.  (It doesn't seem to ever use this code
anyway).  If you know of any sample code that does this, or if I'm going about
this the wrong way, please let me know.


ANSWER:
If you are trying to write a 32-bit Ring 3 driver to talk to your physical
device driver (as in the case of the XGA driver), then there is no necessity
for you to convert the linear address that you obtain from the VMAlloc call to
a 16:16 format.  You can use DosDevIOCtl from your 32-bit driver to use the
memory using a flat address.  An example of this can be found in the way
src\xga32\32bit\matrox.c calls the function flat_access to get a linear
pointer to the VRAM memory (BTW, this also answers your query as to where the
flat_access function is actually used in the XGA driver).




!BASE___________________________________**********
December 30, 1993
QUESTION: (Ref: 543)
I located the source modules for the C Callable DevHelps , but noticed that
the assembly source code does not check for and return the result/error code
in AX!  Is this the same DevHelp Library used internally by IBM?

Further scanning of various files located several other DevHelp .ASM files
that do in fact check and return the correct error codes.

I would like to know if the C Callable DevHelp code provided in the DDK was
built with the various DHCALLx.ASM files provided on the DDK.


ANSWER:
There are no generic C interfaces for DEVHelps.  All the C Devhelp routines
that are in DASD and Multimedia are written by the respective developers for
their use.  So, they may not be complete.  They might have written just for
their own requirements.  With dhcalls*.asm the dhcalls.lib is built in DASD.
Customers can write their own C interfaces for DEVHelps using them as
examples.  We are trying to provide them with Generic DEVHelps in a future
version of the DDK.




!VIDEO__________________________________**********
December 30, 1993
QUESTION: (Ref: 525)
Q1. Is there a way to disable the caches in the XGA driver?  In particular,
    the font, blt, rectangle caches, etc....

A1. There is no way to disable the caches in the XGA driver.  The caches used
    here are just buffers in memory which are replicated in the video RAM if
    there is VRAM memory available on the adapter.
==============================================================================

Q2. Is it possible to place the cache in system memory, instead of VRAM?

A2. There is already a copy of the cache in system memory.  This gets copied
    to the VRAM whenever there is free memory available on the card.  In order
    to not have the cache get written to the VRAM, the customer will have to
    make modifications to the file eddevram.c under the \ddk\src\xga32\32bit
    directory.  The specific changes are as follows:

        -   Remove the if and else statements starting at line # 270 in
            eddevram.c and substitute it with the following:

                  pVRAMCacheStart = pSysCacheStartPhy;

    With this, the customer should effectively be able to disable the cache
    being written in video memory.




!OTHER !STORAGE_________________________**********
December 30, 1993
QUESTION: (Ref: 459)

Q1. We have several SCSI adapters for different types of buses (8bit AT, 16bit
    AT, EISA, MCA, and PCI).  All of these adapters use the same ADD under
    OS/2.  Our specific concern is with regard to the field AdapterHostBus in
    the data structure pADAPTORINFO.  This structure is returned from
    IOCC_CONFIGURATION major function, IOCM_Get_Device_Table subfunction call.
    Currently when the bus is PCI, we make this field EISA 16-bit.  This seems
    to work in the sense that nothing seems to go wrong, no error messages,
    etc.  Our questions are:  How is this information used by OS/2?  Is there
    any possibility that in the future something about this might cause them
    trouble?  He is also still interested in finding out what would occur if
    he registers the bus as an 8-bit AT bus.

A1. Currently the system/Device Manager does not use the information about the
    type of the bus.  That's why the customer does not have a problem, even
    when the ADD sets the field to EISA 16 bit for the PCI type.  But the
    parameter may be used in the future, and there is no guarantee of the
    effect of setting the wrong type.  If it's PCI, they should set
    AI_HOSTBUS_OTHER.
==============================================================================

Q2. I have a data segment which may be turned into a code segment by my
    program.  This code segment must have a known physical address and cannot
    be swapped to the disk (it contains the host adapter driver code).  Do I
    need to issue a lock segment call for this segment?  Do I need to issue a
    lock segment call for ANY of my segments in any cases (ie.  global shared
    data) ?

A2. Please refer to "Physical Device Driver Program Model" on page 3-2 of
    Physical Device Driver Reference.

    For the first two segments ( Data segment and Code segment ), the customer
    does not have to lock at all.  They are fixed all the time.  But for the
    other segment, before it is used, it should be locked.  If the customer
    wants to see a sample, IBM Floppy 1 adapter driver has this kind of code.
    It may be helpful.




!VIDEO__________________________________**********
December 30, 1993
QUESTION: (Ref: 449)
Is there a VGA driver help available to make a Portrait mode driver for OS/2?

ANSWER:
There is no portrait mode driver that we know of presently.




!PRINT__________________________________**********
December 30, 1993
QUESTION: (Ref: 372)
Does the Postscript driver on the DDK require OS/2 2.1?  We want to know if
this driver will work with OS/2 2.0 as well.


ANSWER:
The postscript driver will not work with OS/2 2.0 due to constraints placed on
the driver by the graphics engine (basically 16-bit), but it will work on OS/2
2.0+SP.




!STORAGE________________________________**********
December 30, 1993
QUESTION: (Ref: 357)
Q1. How is the LOCKDRIVE filter distributed to end users?  Is it available
    only through the BBS?

A1. LOCKDRV is not distributed directly to end users.  It is provided as a
    sample application.  Its use is permitted provided it is consistent with
    the DDK license agreement.
==============================================================================

Q2. The LOCKDRIVE documentation is old (6/3/92).  In the "Restrictions and
    Known Problems" section are several items that were being addressed at the
    time.  Will this be updated to show the current state of the filter?  For
    example, item 5 says:

         "The GA version of (IBM2SCSI.ADD) does not currently support the Lock
          IORB command code and will not work with the LOCKDRV filter.

          This is being addressed."

    And a more pressing item:

         "Certain devices (especially large optical devices) may timeout
          during a FAT format, which issues large Read Verify operations.
          This will be addressed by the DASD Manager by setting a non-default
          IORB timeout for these operations."

A2. The usage of LOCKDRV.FLT is documented a .DOC file in the LOCKDRV
    directory.  This is the only documentation that is available.

    The IBM2SCSI ADD driver was subsequently updated to support the
    Lock/Unlock IORBs.

    FORMAT (FAT) was updated in 2.1 to reduce the block counts being verified
    in a single operation.  A nominal timeout in a ADD driver of 30-45s should
    be sufficient for most devices.
==============================================================================

Q3. The documentation says that the LOCKDRV.FLT converts removable DASD and
    R/W Optical drives to fixed disks which are managed by the OS/2 DASD
    Manager.  I am trying to use LOCKDRV.FLT with a Sony R/W Optical device of
    SCSI type DISK, connected to an Olivetti SCSI adapter, using the
    IBMSCSI.DMD.  Is this a valid use of LOCKDRV.FLT?

A3. The SONY drive reports Type 0 Removable.  The LOCKDRV filter should change
    this to Type 0 Non-Removable.  We have not verified compatibility of this
    particular drive and the LOCKDRV filter.
==============================================================================

Q4. "Disks supported by the OS/2 DASD Manager may be partitioned and formatted
    with either FAT or HPFS file systems."  Is this true for the read/write
    optical cartridge?  Can FDISKPM be used with that device?  I didn't think
    they could ever be partitioned.

A4. LOCKDRV should allow partitioning of locked devices (at the loss of the
    removal feature).  That is its intended purpose.




!OTHER__________________________________**********
December 30, 1993
QUESTION: (Ref: 313)
I'm porting an application to OS/2, and I'd like to know about the
availability of Screen/Keyboard/Printer drivers in Arabic, specifically as
relates to database entry, etc.  Any ideas or leads?

We are aware of code page support, and it is not sufficient for our purposes.
Arabic is written from right to left, and the shape of a given letter -
ligatures, kerning, etc.  - can change dramatically depending on what letters
are its neighbors.  We are looking for a driver which incorporates all this
functionality.

ANSWER:
OS/2 2.0 has Arabic support for Full Screen sessions This includes Code Page,
collate sequence, uppercasing....etc in addition to orientation, shaping...and
other Arabic features.

OS/2 2.1 has recently been announced with support for Arabic in PM.  This will
add more features to PM Controls and classes.  The Arabic support should be
available 3Q93.




!BASE !OTHER____________________________**********
December 28, 1993
QUESTION: (Ref: 795)
If I'm doing a QueueWrite in the interrupt section of my device driver.  Do I
have to worry about the possibility of it conflicting with a QueueRead in the
strategy section of my device driver.  IE. Should I disable interrupts in the
strategy section while doing the QueueRead?


ANSWER:
Yes, to prevent any collison it is recommended  to disable interrupts to
protect QueueRead and QueueWrite's .




!OTHER !VIDEO___________________________**********
December 28, 1993
QUESTION: (Ref: 792)
How do You go about detecting which screen group the current process is
assigned to?  When an applications calls our driver, we would like our error
demon to be notified of the sceen type being used.  (ie:  FUll screen Windowed
Vo, or PM.)  By doing this we can have Pm Messages on a PM or VIO sesion and
Text based on a Full screen Dos , OS/2 or Windows session.


ANSWER:
The DevHelp_GetDOSVar will return the Global and Local info seg information
that has the process Id and the process type of the current process.  See the
PDD reference for this DevHelp.




!BASE___________________________________**********
December 28, 1993
QUESTION: (Ref: 742)
I am trying to allocate one or more buffers from inside the driver and then
allow access to it by both driver and the calling application.  Would you have
any source showing EXACTLY how to do it.


ANSWER:
You should be able to use DEVHLP_VMGLOBALTOPROCESS.  Look for examples in the
ddk in "ddk\src\xga32\xgasys20\xgaring0.asm" code.




!I/O____________________________________**********
December 28, 1993
QUESTION: (Ref: 460)
I am looking for the specification for communicating directly to a PS/2 style
mouse through the keyboard controller.  I know how the keyboard controller
passes commands to the mouse, but I need the byte commands that cause the
mouse to initialize, enable, set scaling, etc.


ANSWER:
The I/O Device Driver Reference has information for both the Keyboard driver
and the Mouse drivers.  Also, the DDK has both Keyboard and Mouse Device
drivers source.




!I/O____________________________________**********
December 28, 1993
QUESTION: (Ref: 434)
We wish to boot an OS/2 system without a mouse, and then add a PS/2 mouse
later and have the mouse function.  But, if OS/2 is forced to boot without a
mouse the support for the mouse is not provided.

Is there a command to tell mouse.sys to not check for a mouse and just load
PS/2 support?

We have considered loading a device driver before mouse.sys to lie to
mouse.sys about a mouse being present so that it will load properly, but we
are ignorant about what lies need to be told.  We don't know the interface
used to communicate with the mouse or where to intercept the calls (or
returned error codes).  Is there a way to intercept these errors?

We have also considered using the 'TYPE=' option of mouse.sys to specify
ourselves as a device-dependent mouse driver.  If we used this option we would
like to chain to the original default mouse driver to avoid writing a complete
mouse driver with all of the support already provided by mouse.sys.


ANSWER:
Check out \ddk\src\dev\mouse\familyg\pclogic.* . This is the code for a small
device-dependent driver that attaches to MOUSE.SYS using the 'TYPE=' option.
The IDC interface that this follows is also documented in the OS/2 Technical
Library volume 'Physical Device Driver Reference' (Document S10G-6266-00,
online version in \ddk\book directory on DDK)




!PRINT__________________________________**********
December 28, 1993
QUESTION: (Ref: 318)
There is a problem with our rasterizing OS/2 drivers when running under the
32-bit Service Pak for OS/2 2.0 and with OS/2 2.1.

The problem only occurs at resolutions less than the maximum and seems to be
connected to the way in which these drivers report page size in dots at low
resolutions.  These drivers, in common with the standard LaserJet driver,
"fake" low resolutions by always reporting page size at 300 dpi (or whatever
the maximum resolution is), and then scaling the graphics commands received in
order to achieve output at the desired reolution (150 dpi etc).  This approach
is used in order to simplify the reporting and handling of font metrics.

It is not entirely clear exactly what the problem is with the 32-bit Graphics
Engine, but the symptoms are that low resolution output does not appear to
have been scaled.  The effect of this is that objects are drawn at twice their
correct size, and also at x,y coordinates which are twice the correct
dimensions.  So, where with the 16-bit Graphics Engine, a four inch wide
bitmap drawn at 150 dpi would have been scaled from 1200 (4x300) dots to 600
dots wide, the output is still 1200 dots wide - which is twice the correct
size when working at 150 dpi.

With the 16-bit Engine, the drivers relied on hooking GreConvert and doing the
scaling there.  With the 32-bit Engine it looks as if we may not be receiving
some of the GreConvert calls which allowed us to work before, but it is
difficult to tell precisely what is going wrong.  I have found a partial fix
which involves un-hooking the GreConvert call and manipulating a flag within
BitBlt calls to detect when we have received a recursive BitBlt - if we are in
a recursive call we do not scale again.  Unfortunately, this is not a complete
solution, and it also has the unfortunate effect of breaking 150 dpi when
running under the 16-bit Graphics Engine.


ANSWER:
The main difference between OS/2 2.1 and earlier versions lies in the 32-bit
graphics engine.  The 32-bit engine generally uses device coordinates.
Earlier versions of the engine used application worldwide coordinates.
Because of this it is not necessary to hook the GRE transform functions
GreConvert, GreSetXformRect, and GreGetClipRects in the OS/2 2.1 printer
driver.

This has repercussions.  Code used to do bitblt's needs to pay attention to
the COM_TRANSFORM flag.  In the work here, they have associated a flag with
each bitmap.  The flag is used to keep track of whether the bitmap has been
converted so that extra conversions are not done.




!PRINT__________________________________**********
December 28, 1993
QUESTION: (Ref: 291)
Does there exist an OS/2 (16-bit) presentation sample driver which produces
BMP files as output rather than the usual device-oriented output to serial,
parallel, or file?  If so, how can I get one?  I'm trying to build a printer
presentation driver for a fax server (the server takes BMP files as input, one
per page).

I'm trying to work with the PMPRT driver that comes with the 1.3 DDK, but so
far it's been an uphill battle because of the driver's insistence on banding
and its lack of a hook for dumping a full page.


ANSWER:
No, There is no presentation driver which produces a BMP file currently in the
OS/2 device drivers.  Therefore, it is not included in the DDK.

I did talk with the person who developed the presentation device driver for
FaxPM.  The following comments are from the developer:

 1) Using the Epson printer driver as an example he generated a BMP file
    internally and in turn produced multiple TIF files for use by the
    fax.
 2) There is no problem using one bitmap per page, but there is no way
    to avoid the banding of the bitmap due to memory constraints.  Trying
    to use multiple bitmaps per page is a real hassle.
 3) There is a minor bug in the Epson printer drivers banding algorithm
    in that when you implement the banding it is journaling the commands
    using 60 passes rather than a smaller number of passes.  He used 4
    bands rather than the default of 60 in the printer driver code.
 4) The banding uses journaling of GPI as mentioned previously due to
    the memory restrictions also mentioned earlier.  This is how the
    presentation printer driver handles "dumping a full page."

Note:  The developer will have to come up with a programmatic way of handling
the naming of multiple journaling files.

Another suggestion that I got was that the handling of the memory context in
the postscript printer driver (release in DDK 1 and 2) would be an excellent
example of handling the bitmaps using brute force printing.

Both of these methods do not entail an alteration of the PMPRT queue
processor.  This means that the output is always handled as STD or RAW rather
than trying to alter it for a BMP file.  Reverse clipping is still not handled
by the queue processor.  In short, only metafiles and raw data are handle by
the queue processor.

Altering PMPRT to handle private formats is possible, but will require a lot
of the PMPRT code to be duplicated to achieve the results.  Most of these
functions are handle at an application level for FaxPM from the information I
was able to gather.  I still have some questions out to different people and
will let you know if anyone has any further comments on the subject.  I know
this probably isn't the answer this person had in mind, but it is the best we
have for now.

A note to the person altering PMPRT.  Remember that a private queue processor
must support PM_Q_STD and PM_Q_RAW; be compiled at ring 3 (for 16-bit); Code
segments must be defined as PRELOAD; must run in protect mode only; must
support the following six functions as the assigned ordinal values:

                       SplQpOpen           @1
                       SplQpClose          @2
                       SplQpPrint          @3
                       SplQpControl        @4
                       SplQpInstall        @5
                       SplQpQueryDt        @6




!VIDEO__________________________________**********
December 28, 1993
QUESTION: (Ref: 268)
Q1. For each test in the DTT, what are the criteria for PASS/FAIL?
    Specifically, the GreAttributes2->GreSetCursorRc test fails with 4 errors
    with the VGA display driver shipped with OS/2 2.1 March beta.  Our driver
    also fails with 4 errors.  They are:

         PMERR_INV_CURSOR_BITMAP
         PMERR_FUNC_NOT_INSTALLED
         PMERR_INV_COORDINATE
         PMERR_INV_COORDINATE

    We need to know exactly what the test expects.

Q2. We have noticed that sometimes the screen does not refresh properly when a
    dialog box is closed.  Is there a general mechanism available for the
    display driver to tell OS/2 to refresh the screen?


A1. The logging level should be up (i.e should be in low trace or Debug
    level).  This will cause DTT to write information to the log file
    regarding what API was exercised, what the API expected, and what actually
    happened.  From this information it should be easy to find out both the
    criteria for Pass and Fail for each test, and also the information that
    the test expects.

A2. The answer is No.  Actually DDT is working as designed.  DTT doesn't
    repaint because in order to repaint, it would have to rerun the test.  In
    some cases the test would take extremely long, so DDT basically ignores
    the repaint message and leaves a hole.




!OTHER__________________________________**********
December 27, 1993
QUESTION: (Ref: 780)
I am trying to locate a library file named SLIPCEP.  It is used to link a
sample driver that's in Steve Mastrianni's book "Writing OS/2 2.1 Device
Drivers in C."  Is this file part of the DDK perhaps?  Can I download it from
the DUDE?


ANSWER:
The latest SLIBCEP is included with Microsoft C 6.0.  That is the best source
of that file.




!VIDEO__________________________________**********
December 27, 1993
QUESTION: (Ref: 765)
I'm developing a XGA compatible display driver.  After I install the XGA
driver from OS2 2.1, the CONFIG.SYS installs the driver XGARING0.SYS.  There's
no source code for XGARING0.SYS from the device source kit 1.1.

I wonder what is XGARING0.SYS?  I will guess it is a PDD.  But I thought
XGA.SYS is the PDD.

What's the difference of XGA.SYS and XGARING0.SYS?

How can I get the source code for XGARING0.SYS?


ANSWER:
Both XGA.SYS and XGARING0.SYS are Ring 0 PDD's for XGA.  XGARING0.SYS is
installed because it is required to run 1.3 level code on 2.0+.  Also, some
2.0 level code requires that XGARING0.SYS be present.  However, the main XGA
PDD is XGA.SYS which also gets installed when XGA is installed on a 2.1 system
and the source for this is included in the DDK.




!PRINT__________________________________**********
December 27, 1993
QUESTION: (Ref: 761)
Q1. Compiling of the IBM 42xx source code - how do I compile this code with
    all its modules to generate the DRV file?  Which MAKE file and compiler do
    I use to compile the modules?

A1. Here are the steps to build the 42xx driver:

       - Install the IBM C/Set 2 compiler.  C/Set++ is also acceptable.
       - Install the DDK
       - Make sure that the \DDK\TOOLS directory on the DDK is on your path
       - Run the REXX command script COPYCSET.CMD located in the \DDK
         directory on the DDK.  This will set up your system so that the
         make files on the DDK will work correctly.
       - Go to \ddk\src\prntdd\42xx directory on the DDK
       - Run nmake

    This will create the retail version of the driver in the
    \ddk\mri\prntdd\42xx_src\retail directory of your hard disk where you
    installed the ddk.  The driver will be named DDK42XX.DRV.  If you wish to
    create the debug version of the driver, create an environment variable
    DEBUG and set it to 1 ("Set DEBUG=1").  This will cause the make file to
    create the debug version of the driver with the same name in the
    \ddk\mri\prmtdd\42xx_src\debug directory in your ddk install directory
    tree.
==============================================================================

Q2. After proper compilation, what kind of driver do I have?

        a.   Will it have the job and printer properties dialog
             boxes displayed?

        b.   Will it generate output? if not, what do I need to do
             exactly to make it generate output for a PCL laser
             printer? Another words, which module contains the codes
              or the table for printer escape commands?

A2. After a successful build, you will have a full scale OS/2 printer driver
    complete with job and printer dialog box support.  This driver supports
    the IBM Proprinter family.  It does not support PCL printers.  There is a
    file on the DDK which contains a list of all printers supported by this
    driver.  The file is \DDK\SRC\PRNTDD\42XX\DOC\42XXREAD.DOC




!BASE !I/O______________________________**********
December 27, 1993
QUESTION: (Ref: 760)
We don't have the DDK yet, but we would like to know if the standard OS/2
asynch driver provides a standardized IDC interface.  If so, is that standard
followed by any other vendors (for X.25, ISDN, etc)?  If there is such a
standard, is it documented, and can we get a copy of it?


ANSWER:
The standard OS/2 async driver does provide IDC support via Attach_DD devhelp.
I am not sure if other vendors follow standard IDC interface to X.25 and ISDN.
I would think that the X.25 and ISDN will NOT support IDC because they are not
ring 0. I know that the TCP/IP does not support IDC because it has no ring 0.
The IDC interface is used by physical device drivers that run in ring 0. The
Net BIOS driver and the COM drivers do support IDC.

There is documentation on IDC interface in the PDD reference.  Any PDD can
communicate with another PDD using this routine.  A VDD also can communicate
with a PDD using the IDC interface.  This interface is used by communication
drivers in ring 0. The X.25 support as in TCP/IP is in the net working layer
which is not ring 0.

If you are looking for sample code that uses IDC, we may send you the ATCOM
source code from the DDK.  ATCOM is the async driver COM.SYS that supports
IDC.




!MULTIMEDIA_______________________________________********
December 27, 1993
QUESTION: (Ref: 743)
Q1. We encounter a problem in MIDI / FM driver.  We need to get system timer
    to increase the system timer tick because there is not built-in timer
    clock on our sound board, like Sound Blaster, and we need to get PC timer
    click from the OS/2 system.  The MIDI/FM driver needs a faster timer tick
    than normal PC timer tick.  I think that timer control is very important
    resource for OS/2 system and it is not suitable for us to change the
    system clock.  For Windows / Windows NT, FM / MIDI tempo is controled by
    MMSYSTEM.DLL and the FM / MIDI driver only translates MIDI information and
    sends it to hardware.  Would you like providing some sample code or some
    solutions as soon as possible.

A1. Use the DMA device to transfer 5 ms (or whatever granularity you desire)
    of garbage data.  When the transfer is complete you will be interrupted,
    thus this is your timing clock.  You will have to experiment with the size
    of the data block, to achieve your desired timing.
==============================================================================

Q2. I like to know if there are any MIXER control software standard in IBM
    MMOS/2 because we shall develop a MIXER control utility on MMPM and we
    need to select the communication method between audio PDD driver and the
    utility.  If there is any MIXER standard in MMOS/2, we shall follow it.

A2. IBM development is currently working on a standard mixer API set and
    control applet.  It is structured after Media Vision's, but not identical.
==============================================================================

Q3. There are some problems on playing MIDI and Wave concurrently.  We cannot
    switch between MIDI player and WAVE player when the one is playing because
    the DMA is occupied.  In Windows it is possible to play wave file and midi
    file concurrently, Why does not OS/2?.

A3. Unfortunately this is true for all soundcards that do not generate thier
    own timimg.  It is possible to play MIDI and WAVE files concurently in
    Windows, because Windows takes the DOS system timer and reprogramms it.
    This is not possible under OS/2.  The timer stays fixed at 32ms.  The OS/2
    scheduler is based on it.  As a result threre is no other known way of
    getting fast timing out of OS/2.
==============================================================================

Q4. We found that there is only one media player in MMPM/2 with Sound Blaster
    SBP2D2.SYS driver.  I think that it should be good for user to open
    multiple media player in MMOS/2 and we try to allow it in our driver.
    Could you provide some advise on it.

A4. You should look at the PAS16 source code or the DDK sample templete data
    structure Stream Table.  The name of the process is called Multiple
    instances, and if you implement it in your driver, you should be able to
    open multiple sessions.

       File #1==> x:\ddk\mmos2\mmtoolkt\samples\audiodd\AUDIODD.C <==
       * FUNCTION:         Initializes the stream table at device init time.
               /* alloc memory for stream table, */
               // Initialize stream table
               // Map to GDT selector to address of stream table

       File #2==> x:\ddk\mmos2\mmtoolkt\samples\audiodd\MMDDCMDS.C <==
           PSTREAM pStream;    // pointer to Stream table
           // Search stream table for matching stream handle
           // Search stream table for matching stream handle
       * DESCRIPTIVE NAME: Get the stream table entry.
       * FUNCTION: To search the stream table finding a match with the given
                   parm.
       * INPUT: pointer to stream table, stream handle to find




!STORAGE________________________________**********
December 27, 1993
QUESTION: (Ref: 669)
I currently have a Photoshop Plug-In which contains a scanner driver written
for ASPI for Windows.  Photoshop and my driver migrates into OS/2 through the
Migration software, no problem.  However, my driver cannot find ASPI for
Windows.  Can I migrate the winaspi.dll and vaspid.386, also?  or do I need to
rewrite the ASPI level for OS/2?  If the latter is true, will I have to
compile that layer in OS/2 as I will need to use a Device Attach help to find
the entry point of ASPI in OS/2?  Will I need to recompile all the other
layers in OS/2 also?  Will they compile?  How should I link?  Please help.

ANSWER:
Adaptech is writing the Winos2 ASPI interface, so there will be no effort
required on your part.




!BASE !OTHER____________________________**********
December 27, 1993
QUESTION: (Ref: 455)
Q1. I'm looking for the best way to switch sessions.  I need to switch a
    session to the foreground, even if I'm not the current foreground session.
    The Session Manager obviously does this (like when using Alt-Esc).  Is
    there a command or IOCTL that can be sent to switch to a given session?

    The only alternative that I've come up with so far is to generate CTRL-ESC
    programmatically, send it to my keyboard driver, flip into PM, then have
    my PM process use WinSetActiveWindow to make itself the foreground, then
    use DosSelectSession.  Seems kludgy.

A1. What this customer wants to do is precluded by the design of OS/2.  The
    internal interfaces between components of OS/2 that the session manager
    uses in switching sessions are private.  They are not published and will
    not be published.  Part of the design of OS/2 is that individual processes
    are protected, so no one process can have the ability to switch itself
    into the foreground.
==============================================================================

Q2. The following is a list of things that we would like to get additional
    documentation for.  These are all mentioned in the private headers
    available with the DDK.


        typedef struct _LSISTRUCT       /* lsis */
             {
                USHORT  cb;                 /* Size of this structure */
                PID     pidNewSession;
                SGID    sgidNewSession;
                PID     pidStarter;
                TID     tidStarter;
                SGID    sgidStarter;
                USHORT  usProgramType;
                BOOL    fForeground;
             } LSISTRUCT;
             typedef LSISTRUCT *PLSISTRUCT;

        BOOL    APIENTRY WinLockStartInput(PLSISTRUCT plsis);
        BOOL    APIENTRY WinProcessHotKey(PQMSG pqmsg,BOOL fProcess,ULONG
                         fHotkeys);
        BOOL    APIENTRY WinQueryHungProcess(PQHPSTRUCT);
        BOOL    APIENTRY WinScreenSwitch(BOOL fSwitchOut,
                                              BOOL fDebugger,
                                              USHORT usUnused,
                                              ULONG cbDirty,
                                              PVOID pbUnused);

A2. The DDK does have some references to internal APIs.  These are
    undocumented internal private interfaces between components.  So We do not
    support these APIs.  The APIs in question WinLockStartInput,
    WinProcessHotKey WinQueryHungProcess, WinScreenSwitch, and InputReadEvent
    are internal function calls.  However you may still use them as used in
    DDK.  Here is a very brief description of what some of these internal APIs
    are intended for.

    WinLockStartInput:  This call is used to prevent mouse or keyboard input
    processing during application startup.  The same call is also used to
    reenable input processing.

    WinProcessHotKey:  Process hot keys primarily during process termination.
    (for example, ALT F4).

    WinQueryHungProcess:  Tracks a hung process, it's message queue, fills in
    *lppid with it's process ID, *lptid with it's TID, and the return value is
    a code identifying the type of hang.

    WinScreenSwitch:  This routine is used to notify USER when a screen switch
    is about to occur.  If fswitchout is true we are about to switch out of
    user's screen group.  If so all screen output must be halted.  If
    fswitchout is false we are about to switch in to USER's screen group.




!BASE !I/O______________________________**********
December 27, 1993
QUESTION:  (Ref: 319)
Q1. We need to open the floppy device in the VDD and send an IOCTL to shut
    down the floppy driver so we can use the floppy disk controller.  The open
    works great in the VDD (we are opening "A:") but a floppy must be in the
    drive before the open is successful.  Is there a set of access bits to
    allow us to open the floppy driver without a floppy in the drive?

A1. In OS/2 2.1 you can issue a number of IOCTL calls without first obtaining
    a valid handle to the drive.  This is explained in the Physical Device
    Driver reference in the OS/2 tech reference books ( It's documented in the
    2.0 books but the function is actually not available in OS/2 2.0)

    All they need to do is call the IOCTL function with a file handle equal to
    -1 and set the drive field to the drive number they want to send the IOCTL
    to.
==============================================================================

Q2. I searched the "OS/2 2.0 Technical Library Physical Device Driver
    Reference", the hard copy and online versions, and could not find anything
    about making IOCtl calls without obtaining a valid handle.

    I tried doing a DosDevIOCtl() using a file handle of -1, a category of 8,
    and a function of 0x5D to suspend control of the floppy controller.  It
    always returns an error code of 15 (ERROR_INVALID_DRIVE).  As far as I can
    tell there is no way to set the drive number.

    Is there a page number or section in the PDD reference where it explains
    how to do this?

    Is category 8 function 0x5D one of the IOCTL calls that can be made using
    a handle of -1?

    Is it even possible to do this from a ring 3 application or DLL?

A2. Page 18-150 in the OS/2 2.0 Technical Library Physical Device Driver
    Reference explains how to issue, and what fields to set, an IOCTL call
    without using a previously allocated file handle.

    Example :
       Parameter.DriveUnit =(toupper(DriveLetter) - 'A');
       DevHandle = -1;
       DosDevIOCTL (DevHandle, 0x8,0x5D, Parameter, ParamLength, ParamLinOut,
                                      NULL,      NULL,        NULL   );
==============================================================================

Q3. We have a VDD API that returns a linear address back to the application
    (windows).  Our windows app then allocates a selector (AllocSelector())
    and sets the selector base to the linear address from the VDD.  The result
    of this operation is a DIFFERENT memory area (if I dump the LDT for the
    selector, the linear address that was passed to SetSelectorBase (win 3.0
    call) is not what the LDT's base is set to).  I beleve this is becaues a
    VDD linear address is NOT a Win OS/2 Linear address.  Please tell me how I
    can make this work (accessing the same memory (the memory is a DMA buffer)
    allocated in the VDD).

A3. The best method is to use DPMI calls.  DPMI (Dos Protect Mode Interface)
    allows applications to run in Protect Mode.  DPMI is used for different
    services - functions like convert linear address.  Developer(Customer)
    needs the following functions:

     Allocate LDT descriptor
         in  INT 31  the  fc(function code) is 0
         and in ZX = number of the descriptor wanted.

    Then he needs to use

        Set Seg Base Address - specify linear address related to that segment.
             fc = 7

    The customer needs DPMI spec to do this.
==============================================================================

Q4. We need to have a better resolution system time (accurate to +- one
    milliseconds).  We are currently using the SysQueryVal() to get time in
    mseconds since system boot.  This value apparently only gets updated once
    every 50 milliseconds or so.

A4. There is a 838 nanosecond ( less than 1 millisecond) timer available.
    However, this is used by PERFVIEW and everybody else that knows about it.
    The API's to access this high resolution timer are NOT published.  We use
    the timer inside the operating system for timer services.  The problem
    that you get into is that when there are multiple reader/writers to the
    same timer (there is only one), the data is garbled.

    More clock information:
    The original PC design did not provide for very accurate or reliable
    timing.  Sometimes I am concerned about people who are trying to use the
    PC as a highly accurate timing device.  The original PC design provided
    one timing device:  the Programmable Interval Timer, or PIT.  The PIT had
    3 timers.  Only one of these three is usable by software programs.  The
    other two were used for internal hardware purposes.  Many games used the
    one timer available for software.  The PC-AT added a second timing device,
    to keep date and time of day.  I call this the Real time clock or RTC.  So
    there is the PIT with 3 timers, and the RTC with 1 timer.  Any operating
    system for a PC can only use PIT 0 (one of the three timers on the PIT) or
    the RTC.  OS/2 uses the RTC for its timing, and leaves PIT 0 alone for DOS
    compatibility purposes.  PIT 0 can provide for intervals down to
    nanoseconds, and is the most accurate timing device for short intervals.
    The RTC is better for date and time operations, where longer term accuracy
    is desired.  OS/2 uses the RTC for its time, which is updated every 32
    milliseconds.  There have been several requests for 1 millisecond
    accuracy.  This enhancement is possible, and has been seriously
    considered, especially as multimedia puts more demands on timing.
    However, there has not been a sufficiently strong enough case made (to
    date) for OS/2 to commit to providing 1 millisecond timer accuracy.  Thus
    it has not been implemented.  If your customer has a good justification
    for 1ms timers, I'd be happy to forward that on to OS/2 planning.  As a
    matter of fact, I'm interested in uses for 1ms timers, and ways to
    convince OS/2 planning to give this capability a greater focus.  Until
    then, I suggest your customer look into specialty add-on cards for the PC
    which provide external, very accurate clocks for timing.  I believe that
    such cards have been created for scientific/research measurement purposes.




!I/O____________________________________**********
December 22, 1993
QUESTION: (Ref: 759)
Our OS/2 application is a multi-thread program.  The communication thread is
sending and receiving a data thread from the DOS base system.  This thread
should be activated only when an interrupt occurs at COM3 by RTS=1 at DOS
machine (which is CTS=1 at OS2).  Is there a way that I can initialize COM.SYS
to handle this interrupt and wake up the OS/2 application?  I know that I can
fulfill this task by polling the CTS line (function 67 hex in ASYNC IOCtl
functions), but this is not interrupt driven and will affect system
performance.  If there is any other way to do this?


ANSWER:
There is no way to enable an event callback in COM.SYS at this time.  It might
be possible in your application to poll while doing sleeps in between the
queries.  This is covered in the Physical Device Driver Reference.




!VIDEO__________________________________**********
December 22, 1993
QUESTION: (Ref: 714)
How does the OS/2 for Windows affect our current OS/2 2.1 display drivers?  Do
we have to have different drivers, particularly the support of Windows?


ANSWER:
You don't have to modify your OS/2 2.1 base display drivers at all for OS/2
for Windows, and your Windows 3.1 drivers will be sufficient for Windows
support.




!I/O____________________________________**********
December 22, 1993
QUESTION: (Ref: 610)
We have developed OS/2 COM Port drivers for the IBM ARTIC adapter and would
like to have DosDevConfig report the addition of our COM ports.  I cannot find
any information in the PDD manual regarding updating information reported by
DosDevConfig.

The problem is that after we install the Arctic card with the 16 ports and
install the device drivers, DOSDevConfig still only reports 2 ports.  We would
like it to report 18, not 2. We have referred to the control programming
reference, which states that calling DOSDevConfig with the parameter
DEVINFO_RS232 will return the number of attached ports.

So our questions are:

   - Is there a way that we can update the information
        returned by DOSDevConfig so that it returns the correct number?

   - If the answer to the above question is yes, how do we do it?

   - If the answer is no, then why?  Is it because DOSDevConfig queries
        the bios and the bios only knows about the original com ports?


ANSWER:
No, I dont think they can return the proper number of COM ports using
DOSDevConfig.  He has to write code to get this information from the CPP.
Yes, it is because DOSDevConfig queries the BIOS.nform




!VIDEO__________________________________**********
December 20, 1993
QUESTION: (Ref: 770)
Why are two VGA TEXT modes supported by the BVHSVGA in addition to the S3
chips' SVGA modes?  After all, the BVHVGA is capable of setting these modes
and is chained to the BVHSVGA for just such a purpose.


ANSWER:
A customer can go about coding the BVHSVGA's VGA text modes in either way:
chain into the BVHVGA or let the SVGA.EXE generate the mode and BVHSVGA (2.1
version supplied by IBM) will know how to use them.  If the modes are chained
into BVHVGA, Cleanup function has to be executed prior to chaining.  However,
the cleanup is not all too powerful, it takes a lot of trial-error to find the
perfect cleanup sequence which works for all mode combinations.  So, adding
the VGA modes into the SVGADATA.PMI is a faster and cleaner solution.  There
are also some adapters which are programming extended registers even for the
VGA modes, which makes usage of BVHVGA virtually impossible.

Once we decided to stop chaining these modes, we made BVHSVGA more flexible in
terms of which text modes can be issued.  For example, BVHVGA will be able to
set only a subset of text modes that BVHSVGA can (almost any number of columns
< horizontal resolution capability of the card can be issued).  So, because we
don't believe that cleanup is cost-effective and elegant and BVHSVGA offers
more mode flexibility, we encourage developers to stick with our architecture.




!OTHER !STORAGE_________________________**********
December 20, 1993
QUESTION: (Ref: 751)
The IFS.ZIP documentation implies that filename handling must of necessity be
case insensitive (docs state to force upper case before parses and matches),
yet the IFS I wish to develop must be case sensitive, Would it be acceptable
for me to merely not uppercase the relevant strings?


ANSWER:
The 'current' OS/2 file system rules, ALL existing file systems PRESERVE case,
but are case INSENSITIVE..  In clearer words, the user may ENTER a mixed case
file name, but ALL file compares are done regardless of case.

If you WISH to develop a case SENSITIVE file system you must understand that
the SYSTEM does compares in a case INSENSITIVE way ABOVE you, and you have NO
control of this...

There is currently no plan to provide a CASE sensitive file system mechanism..




!VIDEO__________________________________**********
December 20, 1993
QUESTION: (Ref: 738)
I heard that the IBM XGA driver supports multiple instances such that the OS2
desktop is split across 2 or more monitors.  Is it true?

If so, does that mean MCA XGA or ISA XGA hardware?


ANSWER:
The XGA driver can be built with controls which will support the use of the
IBM product DCAF which can be used to control and monitor keyboard or display
input of remote workstations.  Other than that, there is no functionality
built in to split the display across two physical displays.




!OTHER__________________________________**********
December 20, 1993
QUESTION: (Ref: 735)
There is a problem in the CDINST.CMD under the OS2 2.1 DDK 1.1.  The directory
is \DDK\MISCTOOL\KDEBUG\DEBUG.  If you run

    CDINST D C

You get "Invalid drive letter specified ...  (D)".  This is caused by:

Start from line 15 which the execution gets to

 :default
 if exist %1:\OS2TK20\debug\debuginst.exe goto install
 echo CDINST Error! - Invalid drive letter specified... (%1)
 goto err_exit
 :install
 echo
 echo
 pause
 %1:
 if not "%3"="" goto specified
 cd \os2tk20\debug
 debuginst.exe %2 /s%1:\os2tk20\debug
 goto exit

NOTE that from the above code, the execution will fail in several places
because of no \os2tk20 directory in the DDK 1.1 CDROM.


ANSWER:
Yes, this is a bug in the current DDK which will be fixed in the next release.
In the meantime, there are two temporary fixes.  Either one will work:

1.  Issue the CDINST command as follows:

        CDINST D C \DDK\MISCTOOL\KDEBUG\DEBUG

2.  Edit the CDINST.CMD file and change the default directory path in 3
    places to \ddk\misctool\kdebug\debug.




!BASE___________________________________**********
December 20, 1993
QUESTION: (Ref: 616)
I am looking for a way to allocate large, fixed blocks of PS/2 memory for
access by both the system 486 processor and other Z180 processors in the
system.

From what I have read, it seems like only a physical device driver can
allocate non-swappable memory.  This memory needs to be contiguous and greater
than 64K.  The Z180 processor boards need a fixed physical address in order to
access the memory, and the PS/2 needs a virtual address for my C++ application
to access the same memory.

It would be nice if the physical memory address and the virtual address used
by the os/2 application were the same, but it doesn't seem like this is
possible.


ANSWER:
Ask the customer to refer to Pg.  17-56 in PDD . Function PhysToUVirt.




!OTHER__________________________________**********
December 20, 1993
QUESTION: (Ref: 356)
There are several references to the file bsedosp.h in the DDK, but the file,
which I assume is the private version of bsedos.h, is nowhere to be found.  Is
this file meant to be available on the DDK?


ANSWER:
This file is a precompiled header file and is included in a library file on
the DDK.  The 'p' indicates that the file is private.  It is not included in
header form for legal or proprietary reasons.




!I/O____________________________________**********
December 20, 1993
QUESTION: (Ref: 342)
Q1. The documentation for keyboard IOCTLs states that 16 hotkeys can be set.
    However, upon examining the sample KBD driver that comes with the DDK, I
    see that upon receiving these "additional" hotkeys, the KBD just sends an
    event to the session manager.  Nowhere does it say what the session
    manager does with them.

    My need is to assign arbitrary hotkeys to sessions or programs, and I'm
    looking for the best ways to do this.

A1. The currently defined hotkeys are as follows:

       Ctrl-Esc - switch the tasklist to the foreground
       Alt-Esc  - switch between the running sessions
       Alt-Tab  - switch between the running PM sessions
       Alt-Home - switch a fullscreen VDM to a windowed VDM and vice versa

    The session manager uses an IOCTL to tell the keyboard to notify session
    manager whenever that key-combo is pressed.  It's up to session manager to
    decide what to do based on what key-combo was pressed.  The session
    manager is the only system that gets notified of hot-key events.  But a
    keyboard monitor should work.  Keyboard monitors are documented in the 1.3
    and 2.0 physical device driver guides, though I think the 1.3 docs are
    more complete on this point.
==============================================================================

Q2. I have noticed that there are two keyboard drivers with OS/2, one for
    PS/2's and one for other machines.  Could you either let me know what the
    differences are, or point me toward some documentation that I can refer to
    that will provide this information?

A2. The only difference between KBD01.SYS and KBD02.SYS is that KBD02 uses
    ABIOS while KBD01 talks directly to the hardware.  The interfaces they
    present to the outside world are identical.




!PRINT__________________________________**********
December 15, 1993
QUESTION: (Ref: 713)
From any text editor or word processor, if I select my Presentation Device
Driver as the default printer, then my driver will be loaded, and it will
remain in memory until I reboot the computer.  As long as I don't reboot my
computer, the driver will somehow be still running, even if I have exited out
of the text editor or word processor that selected the driver.


ANSWER:
Once the process that loaded the DLL exits, it should be possible to delete or
rename the DLL, as long as the exiting process cleaned up properly and as long
as no other process is using this DLL.  The problem in the case of printer
drivers is that the Graphics Engine is not freeing the driver handle once the
application finished the printing and quit.  Due to this, when you try to
delete the DRV file, the kernel thinks that the driver is still in use by GRE
and doesn't let you delete it.




!OTHER__________________________________**********
December 15, 1993
QUESTION: (Ref: 713)
Can I debug a Presentation Device Driver (which is actually just a DLL) using
IMPD?


ANSWER:
You should be able to debug presentation drivers using IPMD provided you have
a debug version of the application that is going to invoke the (debug version)
printer driver.




!VIDEO__________________________________**********
December 15, 1993
QUESTION: (Ref: 725)
I want to develope an OS2 2.1 display driver with seemless windows 3.1
support.  I wonder, is there any Xga seemless windows driver source available?
Also, where can I get more information or documentation on that subject other
than the VGA seemless windows source code?


ANSWER:
There is no XGA seamless windows driver source available at this time.

Regarding documentation:
There is some documentation on the subject of seamless windows drivers in the
Display Device Driver Reference Manual.  If you have our DDK, this same
documentation can be found in the Display Device Driver Reference section on
the DDK.

Also, the WinOS2 3.1 compliment of the DDK might be useful since it contains
source code for a seamless VGA driver which might be of some use.




!OTHER__________________________________**********
December 15, 1993
QUESTION: (Ref: 722)
I would like to get a copy of the debug kernel for OS/2 2.1.  I thought that
it would be on this BBS, but I can't find it.  Could you leave directions on
how to get a copy?  Also, is there an Internet node from which this BBS's info
is mirrored?


ANSWER:
The Kernel Debugger can be found on the DDK.  If you don't have one, you can
order the IBM Device Driver Source Kit for OS/2 (part number 71G3703) by phone
thru 800-633-8266.

There is no Internet node which mirrors our BBS inforation at this time.  We
handle only this one communications vehicle.




!OTHER__________________________________**********
December 15, 1993
QUESTION: (Ref: 708)
Are audio tapes available from your last Device Driver Conference in San Jose,
California.  I am interested to know how I can go about obtaining these audio
tapes.


ANSWER:
Yes, the tapes are still available.  They can be ordered by calling Convention
Recorders at 800-487-8273.




!STORAGE________________________________**********
December 15, 1993
QUESTION: (Ref: 696)
I looking for an MMPM capable device driver for the Philips CM-205 CDROM
drive.  I have one from V.C.S.  that works for data and music CD with V.C.S.'s
player but won't do dual mode cd's and is quite slow.  Do you know of any
other drivers for this drive?


ANSWER:
We understand that Laser Magnetics subsidiary of Philips is working on a
driver.  Please conact them at 800-777-5674.




!I/O !OTHER_____________________________**********
December 15, 1993
QUESTION: (Ref: 693)
Is there some example code and/or additional explanation of how to use the
VDHPushFarCall to simulate a FAR call to V86 code?

Specifically, I'm looking for restrictions and example code that works.


ANSWER:
There is no example code that we know of except that the call is used in the
Virtual Touch Device Driver.  It is in ddk\src\vdev\vtouch\vthook.c.




!STORAGE________________________________**********
December 15, 1993
QUESTION: (Ref: 671)
I would like a copy of OS2SCSI.SYM to debug a problem.  I'd use it and the
source on the DDK to check the IORB to and from the ADD.


ANSWER:
The symbol file (.SYM) gets created when you build the driver.  Please build
the OS2SCSI driver from the DDK.  It is better to use the driver that matches
the symbol file for debugging and therefore it would be better for you to
build the driver and use it along with the symbol file.




!BASE !OTHER____________________________**********
December 15, 1993
QUESTION: (Ref: 670)
Is there a way to send a device driver data without using an IOCTL?

Can I send data to my client program by putting something in shared memory and
using a semaphore.  How would I accomplish the communication going the other
way?  In other words, I'd like to put something in shared memory, and somehow
signal the device driver to read it, without using an IOCTL


ANSWER:
An application can share RAM semaphores with a device driver(PDD).  The PDD
must convert the semaphore handle passed by application to a system semaphore.
(see Devhelp SemHandle).  The application can create a semaphore and will
still need to do IOCTL to pass the semapnore handle to the driver.

Alternatively, the application can allocate memory and have the device driver
lock the memory and map it to the processess address space.  This also will
involve at least one IOCTL to the PDD.




!PRINT__________________________________**********
December 15, 1993
QUESTION: (Ref: 666)
This question regards the PM hard copy driver.

The sample code for the mini raster printer under the directory
\ddk\src\prntdd\mdriver of the DDK version 1.1 uses two different methods for
calling the graphic engine modules.

The first method is to use the original functions that were passed to the PM
driver via the Dispatch Table.

The second method is to use the "inner" functions.  Both of these methods can
be found in procedure 'CharStringPos' in source file 'text.c' located in the
above directory.  These two lines from the procedure are the two methods that
I am talking about:

  1st method:
    pfnCharStringPos = globals.ppfnDispatchTableCopy[ NGreCharStringPos &
    0x00FF ];

  2nd method:
    lrc = InnerGreCharStringPos( pddc->hdcShadow, pptlStart, prclRect, flOptions, cChars, pchString, paDX, pAttrs,
    ulFunction );

My questions are:
1. What are the differences between these two methods?

2. Can we use these two methods interchangably, or if not, when can we use
   which method?


ANSWER:
The customer can find the differences between the two types of calls in the
readme file located in \ddk\src\prntdd\mdriver\doc directory on the DDK.




!PRINT__________________________________**********
December 15, 1993
QUESTION: (Ref: 663)
When a user installs one of the standard in-box OS/2 PM Printer drivers they
are prompted "if they want to install the equivalent WIN-OS/2 printer driver".
AS a writer of 3rd -party printer drivers for OS/2, how can we put together a
device driver diskette that will give the user a similar prompt when our
custom OEM printer OS/2 driver is installed?

Q1. Are there specials EA's that we need to set?

Q2. What should the contents of our disk be and do we need an OEMSETUP.INF
    file as under Windows.  If not, how do we identify the WIN-OS/2 files that
    are required?


ANSWER:
A1. You don't have to set any EA's for OS/2 to WinOS/2 printer matching.

A2. Printer matching can be done using the file drvmap.inf which resides under
    the \os2\mdos\winos2\system directory.  The printer install diskette could
    contain the OS/2 driver and the corresponding WinOS2 driver and an install
    program which goes in and modifies the drvmap.inf file to insert an entry
    for matching the two drivers.




!PRINT__________________________________**********
December 15, 1993
QUESTION: (Ref: 662)
Printer Driver Failure

I have done extensive tracing in EPM with my driver.  EPM does a DevOpenDC
followed by a GpiCreatePS(hab, hdc, pSizel, PU_TWIPS | GPIT_MICRO |
GPIA_ASSOC).  Inside of GPI32CREATEPS, the failure occurs at GPI32CREATEPS +
1C5.  The call at this location returns a 'FALSE'.  All other tests in this
area return TRUE.  If I modify the return code of this call to be TRUE
(00000001), the printer driver works correctly.

What is the test being performed at GPI32CREATEPS+1C5?


ANSWER:
The customer needs to make two changes to his MDRIVER code to fix the EPM
problem.  In the function DeviceSetAttributes in attrib.c, insert line

                 lrc = TRUE;

before the break statement in cases PRIM_IMAGE and PRIM_LINE.

In both cases, the function InnerGreSetAttributes() returns successfully, but
the Minidriver function DeviceSetAttributes() returns FALSE since the value of
lrc is not set after the InnerGre call.




!BASE !PRINT____________________________**********
December 15, 1993
QUESTION: (Ref: 647)
I have the responsibility to add new function to an existing Printer PM Device
Driver.  The Driver is 16-bit.

According to the Presentation Driver Reference Exit List processing occurs
when the "current process ends, normally or abnormally.  I've traced through
the code and I don't really understand when the ExitList is being processed.

Can I depend on the Exit List being processed when the driver is finished
printing whatever the application asked it to print?

Or is the Exit List only called when the application is terminated?

I don't see any consistency in when the Exit List is processed.  If I can't
depend on it being called then should I only include those things that I know
must be cleaned up when the driver is abnormally terminated?


ANSWER:
The exit list gets processed at the end of each process, whether the process
terminates normally or abnormally.

If the application spawns a new process each time it sends a print job, then
the exit list will get processed when the driver has finished printing.
Otherwise the exit list processing will be done when the application
terminates.




!STORAGE________________________________**********
December 15, 1993
QUESTION: (Ref: 644)
I would like advice on writing an IFS.  I have your sample (IBM's) of DBFS
with DBCTL.  I would like to write DBCTL in 32-bit manner for our project and
let DBFS as 16-bit as it should be and have special answers.

A sample for FS_FINDFROMNAME would also be very helpful.

And I would like to know how to convert a 16:16 bit GDT pointer from
FSH_SEGALLOC to a 32-bit flat pointer for my 32-bit app (changed DBCTL for
32-bit).


ANSWER:
There is no sample FS_FINDFROMNAME, but it is identical to findfirst/next
except that you MUST follow the spec for the returned data format for 32 bit
client requests, as the format is DIFFERENT between the two.  There is a bit
in the flags that says the caller is 32 bit..

If you are writing a phsyical IFS, then the first field in the returned info
allows you to save some info where the NEXT call is done.

Note that under 2.x the, sequence for 32 bit apps is
FS_FindFirst/FS_FindFromName and for 16 bit apps its FS_FindFirst/FS_FindNext




!BASE !OTHER____________________________**********
December 15, 1993
QUESTION: (Ref: 627)
I'm writing a simple timer device driver that receives every timer tick
interrupt and increments a counter.  This is done in the driver's interrupt
routine.

What I want to do is post a semaphore when the driver reaches a certain count.
The driver takes a semaphore handle from an application through a generic
DevIOCtrl call after the application opens the device.

The PDD reference says that DevHlp_PostEventSem can't be called at interrupt
time.  I looked at the Context Hook routines, but I couldn't allocate a
Context Hook.

Do you have any suggestions as to how I might be able to signal my application
when to wake up?


ANSWER:
DevHelp- SemHandle will allow the PDD to convert the semaphore handle passed
by the application to a system semaphore handle.  The PDD can then use this
system semaphore handle during interrupt time.

See PDD reference on DevHlp-SemHandle page 17-81.




!PRINT__________________________________**********
December 15, 1993
QUESTION: (Ref: 683)
I need to write a 'pseudo' printer device driver. This printer device driver,
if selected by a word processor, will create an image of a page to a disk file
every time the word processor prints that page.

I read from the DDK's presentation device driver reference that a printer
device driver can make use of the 'DISPLAY.DLL' when the DC's type is
OD_MEMORY.  Then everytime the hardcopy device driver receives the NEW_FRAME
escape, my printer device driver can try to write whatever in the bitmap
created by DISPLAY.DLL to a file.

My questions are:

Q1. When does a hard copy device driver receives a DC that is of type
    OD_MEMORY?

Q2. What is the correct way to have the dispatch table set up so that all
    requests from the applications be routed to the DISPLAY.DLL?


ANSWER:
A1. The presentation driver creates a DC of type OD_MEMORY when the
    application issues a DevOpenDC call.  The corresponding GreOpenDC call
    made by the driver can create a DISPLAY DC.

    Please look at the code for the Minidriver provided with DDK Version 1.1.
    The file newframe.c contains example code on how to write bitmaps to the
    display when the NEWFRAME escape is invoked, when invoked in the DEBUG
    mode.  This should be pretty helpful for your requirement.

A2. You don't have to concern yourself with the dispatch table.  This is only
    for the GRE to presentation driver interface.




!OTHER__________________________________**********
December 15, 1993
QUESTION: (Ref: 618)
Q1. Let's assume I have my driver written (a file called abc.sys).  How do I
    install that driver on my OS/2 system so that applications can start
    selecting it?

Q2. I tried to use "Device Driver Install" from the "OS/2 System" folder.
    This asked me for the source and destination of my driver.  The source is
    defaulted to 'A:\' which is exactly where I have my my driver (abc.sys).
    When I clicked on the 'Install' button, I get the following message:

         A profile control file could not be found in the source directory.

    What is this "profile control file" and how do I find information about
    creating it?


ANSWER:
A1. If you want to install the driver on your own system, you can edit the
    CONFIG.SYS file to say:

       DEVICE=C:\xxx\yyy\abc.sys

    where xxx\yyy is the path where you are installing the device driver.

    Then, copy the device driver to that appropriate directory.

A2. If you want to use the profile control file, this is documented in three
    places:

    a. Hardcopy documentation - Chapter 7 of the OS/2 2.0 Technical Library,
       Physical Device Driver Reference Manual, form number S10G-6266.

    b. DDK 1.0 on line documentation - view file DDK\BOOK\S10G6266 (Reference
       manual, section "Installation of External Loadable Device Drivers")

    c. DDK 1.1 - PDD (Physical Device Driver) Reference Manual, section
       "Installation of External Loadable Device Drivers".




!OTHER !STORAGE_________________________**********
December 15, 1993
QUESTION: (Ref: 711)
I was recently testing some new stress tests which I created for my OS/2 2.1
SCSI ADD driver and I ran across some error messages that I would like to have
explained to me.

I am running some memory eating programs in DOS windows and some disk stress
tests in OS/2 windows.  The DOS program simply allocates up to 1,000 buffers
of random size ranging from 1,000 to 10,000 bytes.  It will allocate memory
until there is no more memory to allocate and uses the Borland C compiler
function _farmalloc() to get memory.  After memory has been allocated, it
constantly touches every byte in every buffer to force the O/S to keep the
buffers in memory.  There were four DOS boxes running, each with one of these
programs running in it.  The programs would allocate a total of about 530MB
each, so the total memory usage was about 2.5-3.0 MB plus the memory needed
for the DOS O/S emulation, etc.

The disk stress tests were four OS/2 batch files in which each had a different
copy pattern (drive letter arrangement) and each had a different set of files
to copy from.  There were four of these command files running in the system,
one each in its own OS/2 window.

Now for the problem description:  I was running OS/2 2.1 with the Kernel
debugger installed and all of the above tests were running at the time of
failure.  Two of my disk stress windows halted and all other processes were
still running.  The Kernel debugger screen dump follows:

 Symbols linked (pmshapi)
 Symbols linked (pmgpi)
 Symbols linked (pmspl)
 Symbols linked (pmctls)
 Symbols linked (pmdrag)
 Symbols linked (som)
 Symbols linked (pmmle)
 DelayHardError SYS3175: 4 string(s):
  Pid 003c  Tid 0001  Slot 0032  HobMte 03da
  C:\OS2\XCOPY.EXE
 H
 DelayHardError SYS3175: 4 string(s):
  Pid 003c  Tid 0001  Slot 0032  HobMte 03da
  C:\OS2\XCOPY.EXE
 H
 DelayHardError SYS3175: 4 string(s):
  Pid 0070  Tid 0001  Slot 0030  HobMte 03b1
  C:\OS2\COMP.COM
 H
 DelayHardError SYS3175: 4 string(s):
  Pid 0070  Tid 0001  Slot 0030  HobMte 03b1
  C:\OS2\COMP.COM
 H

The second and third disk stress windows were the ones which halted.  The
second window was running an XCOPY and printed the following message:

 SYS 1808:
 The process has stopped.  The software diagnostic
 code (exception code) is  0005.

The third windows was running a COMP command and printed the exact same
message.  OS/2 put up a dialog which explained that there was some sort of
error in these windows and it told me that the programs would be halted.

What I would like to know is:

    1) What does the following Kernel debugger message mean?

       "DelayHardError SYS3175: 4 string(s)"

    2) What does the SYS 1808: software diagnostic exception code 0005
       message mean?

    3) Could this have something to do with my ADD driver??

    4) What else can I do to help you help me?


ANSWER:
1. The system saves the hard error information until the process's exit list
routines are called and its resources are gone away.  This is done because the
process that id dieing due to a GP fault may own resources that are needed to
display the hard error popup.  This is what the DelayHardError means.  This is
usually caused by some invalid string pointer(s) to the replacement strings
while XCOPY and COMP are trying to process the strings.

2. SYS1808 with exception code 0005.  This exception code indicates an access
violation.  This occurs when an attempt is made to load or store data in an
inaccessible location or to execute an inaccessible instruction.  This
exception corresponds to a TRAP-D (General Protection fault) or TRAP-E (a Page
Fault) caused by an attempt to access an uncommitted page or a page with
incorrect attributes for the desired operation.

3. This problem is not likely to do with the ADD.

4. You may use the Interrupt and Trap Vector command (VSF *) to list the trap
vectors that the kernel debugger intercepts.  This will show you the
instruction that causes the error.

Note:
DelayHardError is known to occur due to non re-entrant string functions.  I am
not sure if this is caused by string functions in XCOPY and COMP that are non
re-entrant.




!STORAGE________________________________**********
December 15, 1993
QUESTION: (Ref: 409)
We are developing an ADD SCSI driver for OS/2 2.x for a proprietary SCSI disk
controller.  We wish to modify the order in which drive letters are assigned
to disk drives by modifying the information returned for the
IORB_CONFIGURATION command.

In order to do this, it is necessary to understand the algorithm used by the
file system to assign drive letters to disk drives.  Could you specify the
method used for drive letter assignment?

Is the assignment based on the UnitHandle value returned by the ADD driver?
Are several UnitInfo fields used?  What is the effect of having more than one
SCSI Adapter in the system?


ANSWER:
I took a look at OS2DASD code.  The order of the drive letters seems to be
decided by the order of the BPB array which OS2DASD returns at INIT command.
The order of the BPB array is decided by the order of the UNITINFOs which the
ADDs return.  So I thought that possibly the ADDs could change the order of
the drive letters by changing the order of the UNITINFOs that they return.
But actually the ADDs do not know their order.  So it means that ADDs can not
completely control the order of the UNITINFOs which OS2DASD gets.  It seems to
be impossible to modify the order of the drive letters by ADDs, so thus there
is no way to modify drive letter assignments on a global basis.

The drive letter assignment mechanisms are a throw-back to DOS.  I don't think
there is much planned to make the assignments more flexible, at least in the
short term.




!VIDEO__________________________________**********
December 15, 1993
QUESTION: (Ref: 337)
We have experienced a problem with DOS graphics applications running in a DOS
window on top of the OS/2 desktop.  When an application tries to use a
standard VGA mode (640x480x16) in a window, a dialog box appears indicating
that the mode requested is not supported.  The application will run properly
when switched to full screen.  If the application is allowed to run full
screen and then switched back to a window, the application is stalled, but the
contents of the last full screen is rendered properly in the window.


ANSWER:
The scenario you have presented is working as designed, since you are running
the desktop at a 256 color depth.  If this is the case then when you switch
your planar video mode application (16 color) from full screen to a window
then the desktop mode is mutually exclusive of the emulated window mode.  In
simpler terms the video adapter is no longer in a mode which will allow the
hardware virtualization to take place.  We therefore freeze any planar
graphics modes when they are in the background or windowed when the desktop is
running in a 256 color mode.




!STORAGE________________________________**********
December 15, 1993
QUESTION: (Ref: 310)
We are developing an ADD SCSI driver for OS/2 2.0 (and 2.1) for a proprietary
SCSI disk controller.  A problem has occured when using the Hitachi CDR-3750
CDROM drive.  The operating system used for this test was OS/2 2.1.  During
initialization of the CDROM drive, 2 Mode Select commands failed with a Check
Condition.  These errors do not occur when using the Toshiba XM-3401B CDROM
drive.


ANSWER:
According to OS/2 development, this is not a problem because this MODE SELECT
command is asking for audio capability.  When the device returns ILLEGAL
REQUEST, it means that the device does not have the capability being queried.

The reason that Toshiba XM-3401B CDROM does not return this error is that it
has the capability to support it.

The format of CD-ROM Audio Control Parameter Page is in table 13-13 in Chapter
13, CD-ROM Devices, of SCSI-2 specification.  ( 9/1/1991 version )




!PRINT__________________________________**********
December 14, 1993
QUESTION: (Ref: 691)
How can I install a printer driver and create a printer object on the desktop
without operator intervention.


ANSWER:
Here are the steps that need to be taken in order to install a printer driver
and create a printer object on the desktop without operator intervention:

1.  Make the following entries in your ini files:

        PM_SPOOLER_DD in os2sys.ini - device name
        PM_DEVICE_DRIVERS in os2.ini - driver location

2. Set up your PRDINFO3 structure and call SplCreateDevice to create
   the print destination.

3.  Finally,  a print queue needs to be created using SplCreateQueue(),
    after setting up your PRQINFO3 structure.  This will cause a print
    object to be created on the desktop.




!OTHER__________________________________**********
December 14, 1993
QUESTION: (Ref: 617)
There are a number of APIs in the toolkit or the DDK which are undocumented.
What is the danger in using an undocumented API?


ANSWER:
The most significant reason for undocumented API's is the operating system
itself.  This undocumented code is designed for use by OS/2 itself, and is not
meant to be used by anyone else.  It is IBM interal use code for the OS/2
developers, where these developers can control both the use of the code and
the environment that the code works in.  IBM reserves the right to change the
code or environment, and the function or the implementation may change in
future releases.

Use of undocumented API's in an uncontrolled environment can easily result of
timing problems and can potentially bring down the entire system.
Undocumented code that works now may work differently in the future.  IBM
strongly recommends that users not use any undocumented API's.  It is very
dangerous to do so.




!BASE___________________________________**********
December 14, 1993
QUESTION: (Ref: 606)
A device driver has a direct entry point into my device driver.  It sets the
ds register to a common data area that we share before calling the entry
point.  How can I find my device driver's original data segment once the other
device driver has called my device driver?

The DD I'm writing:  Controls multiple devices, each device has its own data
segment and shares info in the dd data segment with other devices.

DD that calls my DD:  Calls just one of the devices (and sets up its data
segment).

I need to find the global info in the dd ds.


ANSWER:
A device driver can have multiple devices.  The Device header must contain the
link pointer to the next device that the driver supports and the header for
the last device must have this pointer to the next device set to 0xFFFFFFFF.
The strategy routine must contain the entry for each device.

The device header must be the first item that appears in the data segment.
Additionally a method of detecting which device is being requested needs to be
provided for drivers that support multiple devices.

This can be accomplished using an assembler stub for startup.  The following
is the example:

              EXTERN _main:near
              PUBLIC _STRAT1
              PUBLIC _STRAT2
              PUBLIC _acrtused

   _DATA      segment word public 'DATA'
   _DATA      ends

   CONST      segment word public 'CONST'
   CONST      ends

    _BSS        segment word public 'BSS'
    _BSS        ends

    DGROUP      group CONST,_BSS,_DATA

    _TEXT       segment word public 'CODE'
                assume cs:_TEXT,ds:DGROUP,es:NOTHING,ss:NOTHING
                .286P

    _STRAT1     proc far
    _acrtused:

         push   0
         jmp    start     ; signal device 0

    _STRTA1     endp

    _STRAT2     proc far

         push   1
         jmp    start    ; signal device 1

    start:

       push     es        ; send address
       push     bx
       call     _main     ; call driver main line
       pop      bx        ; restore es:bx
       pop      es
       add      sp,2      ; cleanup stack
       mov      word ptr es:[bx+3],ax ;send completion status
       ret

    _STRAT2     endp      ; endp should be on the last device

 _TEXT          ends
                end

There are examples of device headers in the PDD reference and also in "WRITING
OS/2 2.1 DEVICE DRIVERS IN C" by Steven J Mastrianni.




!OTHER__________________________________**********
December 14, 1993
QUESTION: (Ref: 589)
We're looking for a way to get the extended attributes from a Windows
application running in a Win-OS2 session.


ANSWER:
One way of doing this would be to have an OS/2 program do DosQueryFileInfo and
create a named pipe for the DOS program to get the info via the named pipe.
There is sample code that creates OS/2 named pipe in "OS/2 Version 2.0 -
Volume 2:  DOS and Windows Environment" manual in Appendix E.




!BASE___________________________________**********
December 14, 1993
QUESTION: (Ref: 588)
Is there a way to allocate a DMA buffer in a PDD that is aligned on a 32K or
64K address boundary?


ANSWER:
Example code to allocDMAbuffer is in Multimedia source.  The file to look for
is "DDK\MMOS2\MMTOOLKT\SAMPLES\AUDIODD\AUDIODD.C" and the function is
allocDMAbuffer.  Also there in one more example in
"DDK\SRC\DEV\DASD\IBM\IBM2FLPY\FL2ENTRY.C"

The example will tell you to use DevHelp_AllocPhys for DMA buffers.

The sequence will be:
    DevHelp_AllocPhys
    DevHelp_PhysToGDTSelector
    DevHelp_FreePhys

The physical memory is always allocated below 16 MB.  AllocPhys only requires
that you specify if the memory is to be allocated below 1MB or above 1MB.




!STORAGE________________________________**********
December 10, 1993
QUESTION: (Ref: 053)
These questions regard OS/2 Adapter Device Drivers.

Q1. Does OS/2 ever request byte counts in a scatter/gather entry which are not
    multiples of 512?

Q2. If MaxHWSGList defines the boundary in a scatter/gather list where a
    sector will not be split across entries, how does OS/2 handle the case
    where a device driver returns a value of 1 for MaxHWSGList?

The reason for these questions is that we have an adapter which only performs
sector level scatter/gather in the hardware, so byte level scatter/gather
operations haved to be emulated in software.


ANSWER:
A1. S/G entries which span sector boundaries are not common but definitely do
    occur.  If the adapter's S/G support is broken or limited, then the ADD
    should maintain a 64KB buffer to emulate S/G support for lists which are
    not acceptable to the adapter's S/G support.  It is up to the ADD to scan
    the received S/G lists to detect when a transfer to the buffer is
    necessary.  The ADD must also maintain appropriate controls to insure
    usage of the buffer is serialized in a multitasking environment.

A2. From my understanding setting MaxHWSGList to < 16 would either result in
    severe performance degradation or cause the OS/2 filesystems not to work
    at all.  Our layer just passes this information back to the filesystems.
    You would need to discuss how the OS/2 filesystems handle particular
    parameter values with the owners of those components.




!BASE !OTHER____________________________**********
December 10, 1993
QUESTION: (Ref: C04)
We are working on a project where we wish to have our OS/2 application talk
with our priopriatery I/O card.  We are new to OS/2 and we are not sure what
paths are available to us for setting up communication between our program and
our card.  Note that only our program will be communicating with the card.


ANSWER:
There are two basic paths that can be considered to implement the I/O:
Alternative 1:  Place the I/O code in the application and give that code I/O
privlege level.  Alternative 2:  Write a device driver to implement the I/O.
Both methods are possible, but method #2 is probably better since under
alternative #1 the application code will need to poll the hardware, resulting
in a slower less responsive implementation.

To implement alternative #1, though, the application code should be divided
into two basic modules.  Module one (Main) should contain all the basic
program code and module two should contain all the I/O code.  Now all calls
from module one to the I/O routines contained in module two should be done as
far calls.  When compiling, the DEF file should give module two I/O privilege
level.  (IOPL "module two name").  As far as the problem with parameter
passing - in the main program, use the pragma 'SYSLINK' to define the
parameter passing protocol to the I/O subroutine.  This will make sure that
the parameters are passed via the stack.  (By the way, the default parameter
protocol is 'optlink', which uses register protocol) See the C set/2 reference
for further details.

To implement alternative #2:
It is best that OS/2 2.0 device drivers (Non-VDD) be written in 16 bit
assembler.  The DDK (Device Driver Kit) would be the best, if not only, source
for device driver example code.  The best tool set for developing device
drivers for OS/2 are MASM 5.1 (MASM 6.0 will work also but is harder to use)
and MicroSoft C 6.0.  The C set/2 compiler is only good for 32 bit code
development, as for device driver development it is only useful for 32 bit VDD
development.  Linkers for putting together all these various object sources
can be found in base OS/2, the OS/2 toolkit, and in the DDK.  The best linker
for physical device driver development would be the one found in the DDK.




!STORAGE________________________________**********
December 10, 1993
QUESTION: (Ref: 052)
Would you tell me the relation between OS2SCSI.DMD and OS2ASPI.DMD?  If I want
to write a Host adapter driver to support both DMDs, do I need to support both
interfaces in the HA driver?


ANSWER:
The interface below the DMDs and to the ADDs (HAs) is the same for both
OS2SCSI and OS2ASPI.  The difference between the two DMDs is in what they
provide upward to the application level.  OS2ASPI provides support for the
ASPI specification for applications to use.  OS2SCSI provides support for
IBM's "OS2SCSI" specification for applications.  Bottom line is that you are
able to write one ADD that will support both DMDs.




!BASE !I/O !PRINT_______________________**********
December 10, 1993
QUESTION: (Ref: 719)
Q1. I need to write an OS/2 Physical Device Driver for an ISA/EISA enhanced
    parallel port adapter.  I have and have read Mastrianni's "Writing OS/2
    2.1 Device Drivers in C" and IBM's "Physical Device Driver Reference"
    (Version 2.00), and I've reviewed the sources for both the base (physical)
    and virtual parallel port device drivers provided with the DDK.

    Among other design issues, this particular adapter is built around "soft
    configurable" logic:  Prior to initialization, the parallel port will not
    exist in the system; Afterwards, the enhanced port is hardware-compatible
    with the "standard" PC parallel port.  Up to three such enhanced ports
    could be installed in a single system.  However, the number of installed
    ports cannot be detected by the system until my initialization code is
    executed.  Multiple ports should be handled by the same driver.  Lastly
    (of course), these enhanced ports need to be assigned to the standard
    device names (LPT1, LPT2, and/or LPT3).

    I'm trying to come up with ways to make all this work, while retaining
    IBM's "base" device driver for all the "standard" ports installed in the
    system, and the existing VDD for DOS app support.  I have most of the
    information I need, but I still have several questions not answered by
    either the documentation or DDK sources.

    Are the device names in the Device Header "fixed" at install time?  That
    is, can I build the driver with some arbitrary name (such as "FOO1xxxx")
    in the device header; then, at install time, when I've determined that
    this port should be (for example) LPT2, explicitly de-install the existing
    LPT2 driver (by calling DosOpen, then invoking the deinstall function),
    then dynamically change the name in the device header to "LPT2"?

A1. System Initialization (sys init) needs to know the name of the device
    prior to calling the device driver to initialize that device.  This info
    is needed to determine whether the device already exists.  If the device
    exists, then sys init calls the first occurrence of the device to
    deinstall.  If the first occurrence fails to deinstall, the second
    occurrence is never called to initialize.  It is very important that the
    device name be correct in the device driver header.  If your device driver
    changes the device name to an already existing device name, unpredicable
    results may occur.  There isn't an api that software can call to deinstall
    device drivers.
==============================================================================

Q2. Are the number of devices in the Device Header fixed at install time?  I
    may need to support up to three cards in a given system.  It would be
    "clean" to support all such devices with a single instance of the driver
    code.  Can I define three (or four, allowing for the "PRN" device) device
    headers in the driver; then, at install time when I know how many devices
    I actually need, dynamically "mark" the last active header by setting the
    "link" address = -1?  (Or "zero out" the unused Device Header data
    structures?  Or something else?)

A2. A device driver can add/delete device driver headers at init time.  For
    example, a device driver can determine it only supports 2 devices (lpt1,
    2) when it is called to initialize the first device (lpt1).  It can then
    put a -1 into the pointer to next device driver header for the lpt2 device
    header so that sys init does not call the lpt3 device driver header.
    However, a device driver cannot put a -1 into the lpt1 device driver
    header during lpt3 initialization.  The method you describe (move -1 into
    the link field) is the recommended method of dynamically changing the
    number of devices supported by a device driver.
==============================================================================

Q3. Is it possible to "hook Into" the VDD-PDD chain between the existing
    virtual and physical parallel port drivers?  I'd like to leave your
    existing VDD and PDD drivers intact, but intercept all VDD service
    requests for the parallel ports I've installed.  As far as I can tell, the
    string "LPT" is used for all parallel ports by the existing PDD.  If I
    register a second driver with same string, OS/2 will either:  1) refuse to
    register a second driver with the same string; or 2) replace the first
    registration with the second call.  Can you tell me which of these two
    will occur?

    In the first case, I can't use this method to get your VDD to call my PPD
    for services.  How can I then support your VDD for DOS apps?

    In the second case, my driver will receive all VDD service requests for
    all parallel ports.  Is these some way my new PDD can pass the VDD service
    requests for the "standard" ports to the VDD service routines in the
    existing PDD?

A3. It is not possible to hook into the VDD-PDD chain.  If a second driver
    issues a dh_RegisterPDD call with the same name as another device driver
    the system will halt (unfriendly).  When the OS/2 parallel port device
    driver is called to deinstall (all of its devices), it deregisters its
    PDD-VDD IDC.

    The VDD only uses the PDD when it is installed.  It uses defaults
    otherwise.  The VDD does not send data through the IDC interface, only
    control info.  DOS apps are supported without using the IDC interface
    (with some restrictions like, no direct hardware support from a DOS
    session).  DOS session data enters the device driver through the strategy
    entry point.

    There is no way for your device driver to pass IDC requests to the
    existing OS/2 parallel port device driver.  You must support all parallel
    ports in order to get full DOS session support.
==============================================================================

Q4. After configuring the enhanced parallel ports, I'd like to "register" them
    by putting the base I/O address(es) in the BIOS data area (at RAM address
    0x400).  Since these are "hardware compatible" ports, I'd like to update
    the system's BIOS equipment list.  (This is primarily for the benefit of
    DOS programs that detect installed ports by inspecting this memory.)

    Please confirm:  I cannot update the BIOS data area at Init time (since
    I'm running at Ring 3), but if I support the InitComplete strategy
    command, I can update BIOS data at that time (since I'm running at Ring
    0).

A4. Your device driver can update the bios data area while processing the
    InitComplete strategy command but not while processing the Init command
    (ring 0 versus ring 3).

    OS/2 uses the equipment flag and the parallel port base port address list
    in the bios data area (see DosDevConfig API and/or VLPT).  The sooner this
    info is updated the better.  If the OS/2 parallel port device driver is
    initialized and thinks there is one parallel port, and then your device
    driver is loaded and updates the bios data area with additional ports,
    there may be confusion between the OS/2 parallel port device driver and
    your device driver.  VLPT also looks at this info to configure itself.  If
    VLPT thinks there is a different number of parallel port than the OS/2
    parallel port device driver, there will be trouble.




!BASE___________________________________**********
December 10, 1993
QUESTION: (Ref: 702)
Q1. Our device driver gets a pointer to an application buffer through a
    DosDevIOCtl() call and uses this buffer to either read or write data.  Is
    it possible, if the application buffer is not accessible due to swapping
    or any other reasons and that this might lead to a page fault or trap in
    the PDD ?

A1. If the address and/or the buffer pointers are not valid, then the driver
    would trap.  It is a good idea for the application to verify that the
    selector/offset and the pointer to the buffer area are valid before making
    the IOCtl call.  Besides, the application may also swap out if several
    start running at the same time.
==============================================================================

Q2. If this is possible, what can we do to prevent such a situation?  Do we
    have to lock the memory buffer (DevLock) before accessing it, or do we
    have to convert it from linear to virt.  or vice versa or are there any
    other things to do?

A2. If the application is a 32 bit application, it will be better to pass the
    physical address of the applications buffer area and have the driver lock
    it in memory.  Additionally, the application should use a semaphore to
    co-ordinate the access to this memory area.  The application could pass a
    semaphore to the driver.  The driver then issues the devhelp_SemHandle
    with an IN USE flag set.  The driver could then do what it is expected to
    do with the buffer and then issue another devhelp_SemHandle with NOT IN
    USE flag so that the application now can access the buffer.  For a 32 bit
    application, the driver will return a linear address pointer when a
    physical address pointer is passed (see VMAlloc devhelp ). The application
    can then access the memory area using the linear address returned by the
    driver.
==============================================================================

Q3. Should we use DosRead() or DosWrite() to get around a possible problem
    with DosDevIOCtl()?

A3. Use of DosDevIOCtl is the best way to go.




!VIDEO__________________________________**********
December 10, 1993
QUESTION: (Ref: 695)
I am developing WinOS2 Seamless driver for our proprietery chipset.  The base
driver I am using is our Windows 3.1 driver.  I am modifying it exactly as is
done in your Seamless driver sample code supplied with the OS/2 DDK ver 1.1.

My problem is in requesting a semaphore.  I am using the functions
"request_semaphore" and "clear_semaphore" in the file "IPC.ASM" but they are
not working.  I have found that even after doing request_semaphore the
semaphore locations fs_ProcID and fs_ThrdID are being written over by some
other threads in the system.  In other words, I do not really own the
semaphore even after a successful request_semaphore.

We also call "init_struct.pfvwin".  Does this function return any error code
that we can check?  In the manual "Display Device Driver Reference" chapter 7
("Seamless Windows Support") pgs 148-153, a code example for requesting and
clearing semaphores has been given.  This example is based on cli-sti logic.
However, this has not been used in the IPC.ASM code; rather
"init_struct.pfvwin"has been used.  Which logic is better?


ANSWER:
One possible reason the request semaphore is failing might be because the PM
driver is releasing the semaphore that you just obtained.  Please check the
heartbeat processing between the seamless and PM drivers.

Second init_struct.pfvwin is a pointer to the INT66 interrupt handler.  The
process just blocks on it pending release of the controller.  So you don't
need to bother about its return codes at all.  As soon as it returns, you can
grab ownership of the controller.

Finally, CLI's and STI's are not needed in IPC.ASM.  These instructions were
intended to be used around the semaphore code to ensure that we would not be
preempted.  But DPMI is trapping these instructions to have an effect just in
that VDM.




!OTHER !STORAGE_________________________**********
December 10, 1993
QUESTION: (Ref: 753)
How can a get a copy of the ASPI interface spec.


ANSWER:
The ASPI interface spec is not available through IBM, only through ADAPTEC.
ADAPTEC can be reached by calling 800-934-2766




!VIDEO__________________________________**********
December 10, 1993
QUESTION: (Ref: 756)
I heard a rumor that there would be OS/2 2.1 drivers for the S3 chipsets using
the 2061 clock chip.


ANSWER:
The only cards that the S3 drivers currently support, that have the 2061 clock
chip, are the Diamond card and the Number Nine card.




!I/O____________________________________**********
December 10, 1993
QUESTION: (Ref: 395)
How does the Winos2 mouse process the RELATIVE and ABSOLUTE mouse events?


ANSWER:
The problem is that MOUSE.DRV doesn't know if the points it receives from its
'C' hook are relative or absolute when not in a seamless VDM.  For seamless,
MOUSE.DRV assumes all points are absolute, so it does not do accelleration and
passes the absolute flag (ax has 8000h on) to windows.  For full screen, it
doesn't know, so it treats all points as relative.  Absolute points get all
screwed up from the accelleration.

The fix is for MOUSE.DRV to be informed if points are relative or absolute.
In Mouse.drv, module int33h at enable time, obtains the VMOUSE entry point
using Int 2f function 4011 get VDHRegisterAPI entry point stuff.  Mouse.drv
calls VMOUSE to indicate that it would like to be informed whether points are
relative or absolute.  VMOUSE also calculates the scaling factors based on the
video mode needed to scale screen coordinates to windows 0 to 64k absolute
coordinate system.

VMOUSE was changed to handle the new case in its VMDosLink routine as
previously described, and to pass 8000h in the event flags if (and only if)
the caller has requested for absolute event notification.

This scheme maintains compatibility for normal int 33 apps.  Video mode is not
a problem for windows, which is the only case that MOUSE.DRV (and us) care
about.  Any video mode problems are problems independent for this fix and will
mess up MOUSE.SYS since it dependents on VMOUSE and VVID to keep it informed
in order to translate device coordinates to screen coordinates.




!PRINT__________________________________**********
December 08, 1993
QUESTION: (Ref: 560)
How does PRINT01.SYS get the command line parameters from CONFIG.SYS; i.e.  if
you have the CONFIG.SYS statement:  BASEDEV=PRINT01.SYS Parameter list

How does PRINTO1 retrieve this the parameter list?  (By the way, the include
file \ddk\dos\dosinc\*.inc include the strucs for the init request packet, but
don't refer at all to the CONFIG.SYS params)


ANSWER:
Command line parsing of the BASEDEV=PRINT01.SYS statement is not currently
supported.  In order to insert this functionality, the customer will have to
look at the INIT function description in the Physical Device Driver Reference.
The parameter Pointer_2 can be used to get the command line parameters.




!BASE___________________________________**********
December 08, 1993
QUESTION: (Ref: 588)
Is there a way to allocate a DMA buffer in a PDD that is aligned on a 32K or
64K address boundary?


ANSWER:
Example code to allocDMAbuffer is in Multimedia source.  The file to look for
is "DDK\MMOS2\MMTOOLKT\SAMPLES\AUDIODD\AUDIODD.C" and the function is
allocDMAbuffer.  Also there in one more example in
"DDK\SRC\DEV\DASD\IBM\IBM2FLPY\FL2ENTRY.C"

The example will tell you to use DevHelp_AllocPhys for DMA buffers.

The sequence will be:

    DevHelp_AllocPhys
    DevHelp_PhysToGDTSelector
    DevHelp_FreePhys

The physical memory is always allocated below 16 MB.  AllocPhys only requires
that you specify if the memory is to be allocated below 1MB or above 1MB.




!BASE !STORAGE__________________________**********
December 08, 1993
QUESTION: (Ref: 585)
I am writing a 16-bit scanner SCSI physical device driver for OS/2 2.1.  The
ONLY applications which will call this driver are 32-bit apps.

I wish to dynamically allocate memory in my 32-bit application and have the
scanner send data to this memory region via my device driver.  In order to
accomplish this I need the driver to translate the linear address of the
memory buffer to a physical address.

What is the proper procedure?


ANSWER:
After the application allocates the mememory and has the linear address to
pass to the driver, follow these steps:

1. Call VMLock to verify access and to lock the range of memory into physical
   memory.

2. Call VMProcessToGlobal to map the private address of the process to global
   address space.

3. Access the memory using the flat selector and its linear address (offset)
   as returned by VMProcessToGlobal.

4. Call VMFree to remove global mapping to process address space.

5. Call VMUnlock to unlock the object.




!BASE !VIDEO____________________________**********
December 08, 1993
QUESTION: (Ref: 626)
Q1. We are porting a new graphics accelerator chip to OS/2 2.1 with Seamless
    Windows.  We have memory mapped I/O registers when performing accelerated
    functions such as BitBlt, Text, etc.  This chip is optimized to be used on
    PCI and VESA local bus video cards.

    How can we find the first available unmapped physical memory address.  For
    example, if a computer has 16 Meg of memory, wouldn't the first address be
    (16 Meg + (6 * 64K))?  (The 6 * 64K being for rom, video, etc.)

    If the computer also contains a local bus disk controller that has 4 Meg
    of memory for disk caching on the local bus card, and this also has the
    ability to be linearly mapped above system memory, will the OS or kernel
    make sure that we are not mapped at the same physical location?  I assume
    we need ring 0 access to do this.  In which driver would this be done?
    Screen01.sys, Screen02.sys, or a separate physical driver?

Q2. Assuming we now know the physical address to map our video adapter, do we
    just call PhysToUVirt to get a selector and a linear address?  Will this
    also lock the memory down so that it will not be swapped out?  Do we need
    to do anything else to accomplish this?

Q3. Which sub-version of Masm 5.1 and Masm 6.0 should be used for the display
    drivers?


A1. There is no way to determine the first unmapped physical address for the
    adapter.  In order to map a physical address to system memory, you need to
    use DosDevIoctl to access the kernel DevHlp services.  Please look at the
    VMALLOC Dev Hlp in the PDD reference and the SCREENDD support IOCTLs
    section in the DDK display reference.

    As long as the linear mapped memory is locked by the drivers, the kernel
    will make sure that you cannot map another linear address to the same
    physical memory.  Refer to the Display driver reference for the IOCTLS
    supported by SCREENDD.  If you need kernel services beyond what is
    supported by SCREENDD, then you need to write your own Ring 0 driver.

A2. SCREENDD IOCTLs provide support for obtaining linear address mapping for a
    given physical address.

A3. MASM 5.1 is actually 5.10A.15 and ships with the DDK.  The sub-version for
    MASM 6.0 is MASM 6.00A.




!BASE !VIDEO____________________________**********
December 08, 1993
QUESTION: (Ref: 621)
Q1. I'm having trouble getting access to 1Mb of VRAM using the DeviceHelper
    Services (in the XGA Ring0 driver).

    In the XGA PM driver source, the function AccessVRAMBitmap() in MATROX.C
    makes a call to the RING0 driver, which calls the FLAT_ACCESS function.
    This function uses the Device Helper Service VMALLOC to get a linear
    address for the CURRENT process.  That is, after this function gets
    executed, I can write to VRAM using DS:<returned_linear_address>.

    However, this linear address ONLY seems to be valid for the current
    process.  If another process comes through in the PM driver, then that
    linear address will no longer be valid.  The function ACCESSVRAMBITMAP in
    MATROX.C seems to try to create a linear address for each process that
    occurrs, but it never gets called.

    Is this the correct way/method of accessing 1Mb of flat memory?  That is,
    does the PM driver have to determine what the current process ID is, and
    then use a corresponding linear address?  (Please refer to the
    UpdateVRAMBitmap function in MATROX.C for clarification).


A1. Yes, if you allocate linear addresses on a per-process basis as is done by
    function flat_access (by setting bit 5), then you will have a different
    linear address for each process (using either AccessVRAMBitmap() or
    UpdateVRAMBitmap() functions).  I don't know why bit 5 is set in this
    particular case since there are already mechanisms in place to ensure
    proper access to the VRAM memory among the processes.

    You should note that you might not have to get the linear address at all
    if the card has hardware draw implemented.  In the 32-bit XGA driver, the
    linear address is used only for a particular type of monitor (MATROX)
    which doesn't have hardware drawing enabled.  For all other cards, it
    seems to suffice to use the physical address directly.
==============================================================================

Q2. The previous answer stated that:

    '...  there are already mechanisms in place to ensure proper access to
    VRAM memory among the processes'.

    Could you expand on that?  Does this mean that the driver only needs to
    use VMALLOC once and does not have to check for other processes coming
    thru?  Or does the driver have to use a different linear address for each
    process that comes thru?


A2. I was actually talking about the call to global_access() function from
    eddefpdb.c and meant that there are semaphores guarding against access to
    multiple processes at the same time.  The driver will have to check for
    serialized access, especially if you use a global address for VRAM.
==============================================================================

Q3. If this (See Question 1) is the correct method, where should the function
    UpdateVRAMBitmap be called?  Should it be called in the function
    XGA_Enterdriver?


A3. The function UpdateVRAMBitmap() is not being invoked anywhere in the XGA
    driver currently.  But the proper place would be to call it inside
    AccessVRAMBitmap() itself to ensure that the process hasn't already
    acquired a linear address to the VRAM memory through a previous call to
    AccessVRAMBitmap().
==============================================================================

Q4. I tried using VMALLOC with bit <5> set so that the linear mapping would be
    done in the global address range, instead of the current process range.
    However, which segment register/selector value am I suppose to use to
    address the VRAM then?  I've got the linear address, but then what value
    should I use for the selector?

    If I can map the 1Mb of VRAM globally, then I wouldn't have to worry about
    the UpdateVRAMBitMap function problems described up above.


A4. Bit 5 should actually be clear for the linear address mapping to be done
    in global address range.  There is already a function called
    global_access() in xgaring0.asm in the Ring 0 driver which does this.  If
    this were to be used, the linear address could still be accessed in the
    same way as before by making a DosDevIoctl call from the 32-bit driver and
    obtaining the flat address to the memory.
==============================================================================

Q5. The answer to question 4 says to use the global_access function from the
    Ring0 driver.  I've used that without much success.  The question still
    remains:

    If I use VMALLOC with bit <5> set (process address range), then I CAN
    write to my VRAM frame buffer using the current DS value as follows:

          mov   ax,55
          mov   ds:<linear_address_returned_from_VMALLOC>,ax

    where DS is the current process data selector, usually value 53h on my
    system.

    If I use VMALLOC with bit <5> clear (global address range), then I CAN'T
    do the above.  Which selector value do I need to use?  Using the current
    DS doesn't work because the returned linear address is beyond the limits
    of the current DS selector value.

    Is there a designated selector value that I need to use whenever I get a
    linear address mapped in the Global Address range?

    The PDD Driver reference seems to hint at this.  In the description for
    VMProcessToGlobal (on the second page), it says to 'access the memory
    using the FLAT selector and its linear address as returned by
    VMProcessToGlobal.  Is there a designated FLAT selector?  If so, where do
    I get it from?


A5. There is a designated FLAT selector and it is FLAT itself.  So the
    customer would access his address as FLAT:<linear_address_returned>

    In response to the questions related to using VMAlloc...  The approach the
    customer is taking, to map a physical address to process space in a
    VMAlloc call, is fine.  An alternative might be to call VMAlloc against
    global address space and then use VMGlobalToProcess to bring it down into
    each process's space.

    There is no way to provide Ring 3 addressability to System (global) space
    via a Ring 3 selector.vide




!VIDEO__________________________________**********
December 08, 1993
QUESTION: (Ref: 602)
Q1. Using the source code from your Device Driver Source Kit Version 1.1, and
    using Macro Assembler 6.00, I built a dll from ddk\src\vga32\svga256.  I
    get no errors or warnings, and get the file

      10-07-93  11:29a    124157         333  SV600256.DLL

    This matches in size with the GA version I am using, namely,

        Directory of C:\os2\dll
        IBMDEV32 DLL   124157   5-08-93  10:06p

    But when I use comp to compare the two files, they don't compare:

        Compare file C:IBMDEV32.DLL and file
        v:\ddk\src\vga32\svga256\600\retail\SV600256.DLL

        A COMPARE error occurred at OFFSET B0
        Mismatching byte of file 1 = DD
        Mismatching byte of file 2 = BB

        A COMPARE error occurred at OFFSET F0
        Mismatching byte of file 1 = DA
        Mismatching byte of file 2 = B8

        A COMPARE error occurred at OFFSET F8
        Mismatching byte of file 1 = FB
        Mismatching byte of file 2 = D9

        A COMPARE error occurred at OFFSET 144
        Mismatching byte of file 1 = 64
        Mismatching byte of file 2 = 84

        A COMPARE error occurred at OFFSET 1A4
        Mismatching byte of file 1 = 71
        Mismatching byte of file 2 = D1

        A COMPARE error occurred at OFFSET 1EC
        Mismatching byte of file 1 = BE
        Mismatching byte of file 2 = D2

        A COMPARE error occurred at OFFSET 6FB
        Mismatching byte of file 1 = BC
        Mismatching byte of file 2 = C0

        A COMPARE error occurred at OFFSET 70F
        Mismatching byte of file 1 = 6F
        Mismatching byte of file 2 = 77

         etc.

    Worse, when I boot DOS, and do

        cd \os2\dll
        copy sv600256.dll ibmdev32.dll

    then when I reboot OS/2, I get to where the PM screen is first drawn,
    i.e., filled with gray, and the mouse cursor appears, shows the "busy"
    clock, and then the system gets no farther, although mouse moves are
    handled.  The kernel debugger shows

        DelayHardError SYS3170: 4 string(s)
         Pid 0006  Tid 0001  Slot 0008  HobMte 01b1
         C:\OS2\PMSHELL.EXE
        d0ef39ad
        f200d0e7
        P1=b1b71450  P2=f116002b  P3=f2007b1e  P4=d0ef39ad

    Breaking in the Kernel debugger shows that the system is hung waiting for
    _ptbcPriQReady to go nonzero.

    So, obviously, the question is what's wrong?  H ave I missed something in
    the process of trying to use SV600256.DLL.  I assume that I just have to
    copy it into the boot drive as

        \OS2\DLL\IBMDEV32.DLL

    Is there something more to it?

    Should the SV600256.DLL that the DDK source makes exactly match the one
    that installs off the GA release disks?


A1. The sv600256.dll that the DDK source builds need not match the one that
    shipped with OS/2 2.1.  We get the latest buildable and tested source code
    that exists for each driver and put it in the DDK.  Since this testing
    might not be as comprehensive as pre-ship testing, there is a chance that
    the driver might have problems in it.  The customer seems to be using the
    right MASM and he is also installing the DLL correctly.
==============================================================================

Q2. If it's any help in figuring this out, I've made the following versions of
    the svga256 dll:

        600.ret     800 by 600 "retail"
        600.deb     800 by 600 "debug"
        768.ret    1024 by 768 "retail"

    and have run them on three different systems, two with Trident 8900CL
    chips and one with Tseng 4000.  The results are system independent--

        the "retail" versions paint the PM screen gray, put
            up the clock cursor and hang, letting you move the mouse
        the "debug" version hangs earlier, with a blank screen.

    In all cases, the Kernel debugger reports DelayHardError (which means??)
    and references C:\OS2\PMSHELL.EXE

    I've also tried to use the DSPINSTL utility to install these drivers, by
    PACKing them and putting them on disk 2 replacing SV600256.DL_ and
    SV768256.DL_.  Everything seems to go OK, with no error messages, but
    these drivers are just copied into \OS2\DLL, and don't replace
    IBMDEV32.DLL, so when you reboot, you're in 640 by 480 mode.

    I test-built the SV600256.DLL from the DDK and compared it to the one that
    shipped with OS/2 2.1 and got exactly the same results as the customer is
    getting.


A2. Please ask the customer to also build IBMVGA32.DLL (src\vga32\ibmvga32
    directory) and replace that DLL on the system as well.  I built both
    ibmvga32.dll and sv600256.dll and tested them out on a DELL system with a
    Tseng 4000 card and the system booted up fine in SVGA (800x600) mode.

    Also, the reason his DSPINSTL was not working is that he needs to pack the
    directory and filename information while using pack.exe.  Ask him to look
    at pack/unpack documentation for that info.




!VIDEO__________________________________**********
December 08, 1993
QUESTION: (Ref: 516)
Q1. We have image processing hardware that works in conjunction with a Trident
    S-VGA chip that OS/2 is controlling to provide screen output.  We use the
    standard OS/2 device drivers for the SVGA portion, and add code that
    controls the imaging portion.  Our application runs in PM, but needs to
    tidy up if the user does anything that could change to an SVGA mode other
    than the one used by the PM.  For instance, if the user switches to a full
    screen prompt of any kind, we need to be notified and have a chance to
    change register settings in our hardware.

    Can you point me to what I need to do?  Is there something analogous to
    the Windows DD Notify Background Switch that a PM app or DLL can use?

    Is there some place in the PM display driver that I can register the fact
    that I want to be called if PM is switching in or out?


A1. The answer to this is to define a global Extern variable "fGrimReaper".
    This is the variable used by the OS/2 session manager.  When an
    application is in full screen mode (foreground) this variable is set to
    -1.  Otherwise it is set to 0. (It may be vice versa - please check the
    display driver code as to how this is used whether -1 or 0. I have seen
    all the display drivers including the PM driver use this variable to see
    if the session belongs to the driver.
==============================================================================

Q2. This is along the right track, but not quite.  This is a way to check
    after the screen has switched.  He needs to know before the screen
    switches because he has some housekeeping he needs to do before the
    switch.  His question is, how can he do this?  He sees two possibilities:

       - Some way to hook into the session manager so that it will notify
          him.
       - Write his own presentation driver.

    Obviously, the first would be simpler.  Or, is there some other way to do
    this?


A2. During screen switches, every display driver is notified of the screen
    switch with Death() and Resurrection() calls.  The Gre engine calls
    Death() when the screen switches from a PM to non PM screen group.
    Similarly the Resurrection is called when the screen switches back to the
    PM screen group.  All the drivers hook to the entry table that the gre
    function calls.  See DISPATCH.ASM in DDK\SRC\VGA32\IBMVGA32.  The display
    drivers upon Death() call perform the required functions like
    Save_TextVram etc.

    There will be no need for him to write a PM driver.  If he is modifying
    the SVGA driver, the driver already hooks to these calls and do get
    notified of the screen switches.  He can look at the code where it saves
    the VRAM upon the Death call for later use upon the Resurrection call.  He
    should be able to modify this part of the code to set any particular
    register values.  The Death and Resurrection functions are
    DDK\SRC\VGA32\IBMVGA32\ WINATTRS.ASM.




!PRINT__________________________________**********
December 08, 1993
QUESTION: (Ref: 630)
How do I realize a font outline or bitmap from the ATM engine?


ANSWER:
The PostScript driver can download PostScript Soft Fonts, and it does
not generally need to realize ATM fonts because they are width
matched to equivalent PS fonts.

The algorithm for getting the scalled bitmaps of each ATM character is
as follows:

* The GRE calls the drivers CharStringPos() function

* The driver determines it is an engine font

* The driver then returns a zero to the engine to indicate the CharStringPos()
  was not handled

* The Engine will call DevQueryCaps to determine if the driver has set
  CAPS_RASTER_CAPS ie.  Raster device

* The engine will create the images of all character glyphs needed to produce
  the character string including codepage trans.

* The engine will then call the drivers DeviceSetAttributes().  The new
  charbundle.cdef.defset field will be pointer to the FOCAFONT structure which
  has the character definitions and image data

* Next the engine will call the drivers CharStringPos() again with the
  COM_DEVICE com flag bit set.  The driver must handle the call.  Note:
  CharStringPos may be called more than once to output portions of the string.
  (I think 8 chars at a time???)

* When the driver gets a CharStringPos call with COM_DEVICE set should look in
  the FOCAFONT structure for each char glyph by using by using each char as an
  offset into the glyph table.

* Note:  If you are going to cache the glyphs you should copy them to your own
  memory at this point.




!BASE !OTHER____________________________**********
December 08, 1993
QUESTION: (Ref: 046)
Does anyone know how to create a custom message (and message number) for
VDHPopUp to use?


ANSWER
You can't.  User defined .MSG files are not supported by VDHPopUp at this
time.  This is a know requirement.  All the VDHPopUp text is taken from the
\os2\osomsg* files.




!OTHER__________________________________**********
December 01, 1993
QUESTION: (Ref: 423)
Could you point me in the right direction with respect to documentation about
the actual text of the error messages referred to in header files such as
BASEMID.INC, UTIL*.INC, etc (\DDK\INC)?  I need to report some errors in my
device driver and would like to use the existing error messages.

Although the symbolic name of the error (EQU) gives me some indication what
the actual text will say, it is not really all that obvious.  To avoid having
to try out all the message IDs it would be a lot easier if I could have look
at the text table representing the error messages.  Therefore, my question is:
is the error text table documented anywhere?

ANSWER:
Most of the drivers in the DDK use an error message file contained in
DDK\MRI\TXT\OSO001.MSG in the DDK.  This is a binary file, so it's not
possible to edit it unless you use a binary editor.  If you look at the
MAKEFILE in the VMOUSE driver, you can get an idea of one way of extracting
the error messages with tools provided in the DDK.  Of course, you may use any
method that suits your needs, but the technique used in VMOUSE should get you
going.




!I/O____________________________________**********
December 01, 1993
QUESTION: (Ref: 369)
In the keyboard driver source files, located on the Device Driver Source Kit
CD, I saw that the keyboard driver interacts with the SINGLEQ$ (Single Queue)
driver when keystrokes need to passed to a Presentation Manager screen group.

I would like to get more information on the SINGLEQ$ driver, more exact the
specifications on how to interface with it.


ANSWER:
We have never documented how to talk to SINGLEQ$ at least to my knowledge.
This is not something we want people to do.  This is an internal interface
that WILL change over time (very soon in fact).  If you absolutely need to
know how to do this, then we can provide pointers to the source.  SINGLEQ$ is
a device driver, like any other, and as such can be opened with DosOpen etc.




!OTHER !STORAGE_________________________**********
December 01, 1993
QUESTION: (Ref: 402)
I have developed a SCSI character device driver for OS/2 which acts as both
initiator and target.  It is working, but if I try to specify a buffer size of
greater than 32768 on a DosRead or DosWrite, the Request Packet comes to me
with 44941 in the buffer size field of the packet.  It seems odd that
DosRead/Write both have ULONG parameters for size but the Request Packet has
only a USHORT to hold the size.


ANSWER:
A possible workaround is to use DosDev IOCTl.  64K (65,536 bytes) still could
not be reached, however, this device driver could now go up to 64,000 bytes.



=================== Administrative Stuff ===================
________________________________________**********
December 30, 1993
