This is file: 05_94QA.TXT

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

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

The following KEY WORDS are supported in this file.

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


!NETWORK________________________________**********
May 27, 1994
QUESTION: (Ref: C18)
I have been unable to locate any sample source code for a network interface
card on the DDK or elsewhere.  We are interested in any code as an example,
but would prefer Ethernet.  Can you point us in the right direction?


ANSWER:
Please download a file called LANINFO.TXT from the Main file area on the DUDE.
It contains the information you are looking for.




!NETWORK________________________________**********
May 27, 1994
QUESTION: (Ref: C16)
The IBM OS/2 NDIS Driver Implementation Package mentions that there is a
program for verifying the syntax of a NIF file called SNIFFLE.EXE.  Where
could I find this file or where might I download it from ?  Thanks.


ANSWER
SNIFFLE.EXE is now provided in NTS/2 in the latest CSD (WR07045).




!NETWORK________________________________**********
May 27, 1994
QUESTION: (Ref: B86)
I'm looking for help to write an OS/2 driver to support the standard IBM PC
SDLC Communications Adapter.  It seems to be a pretty straightforward request,
but it's hard to get any information regarding the hardware parameters I need
to write the driver.  I know Communications Manager/2 exists so I shouldn't
have to write the driver -- but I want to be able to get to the SDLC frames
myself.

In the IBM BBS there's a downloadable file which claims to be an OS/2 driver
for SDLC.  But it's just an .EXE (no sources), it looks more like a DOS driver
to me, and in any case it doesn't work.

So can anybody give me a tip how to continue in this search (there isn't a
clue about SDLC driver in the DDK CD)?


ANSWER:
As of this date there isn't an API through CM to get into the SDLC protocol
driver and bypass SNA.

There isn't a user friendly document that describes how to program to the
SDLC/MPA adapter interface.

The only document available is the IBM Multiprotocol Adapter/A Technical
Reference (S85F-1643-00).




!NETWORK________________________________**********
May 27, 1994
QUESTION: (Ref: B79)
We are considering developing a NetBOIS application to support LAN Server with
a new server application.  We are having trouble finding information on how to
develop a protocol specific application.  We also would like help on sample
applications, header files, tool kits for development and testing.  We have
the LAN Technical Reference SC30-3383 and LAN Server application development
reference.  But neither of these have a disk with sample C code or header
files specific to NetBois.  Where can I find this?


ANSWER:
We offer primarily the LAN Technical Reference.  I also have a package called
the NDIS Driver Implementation Package.  This is primarily for MAC developers,
but may have some material useful to you.  This is free.  To order, please
send a request by writing directly to:

         IBM Corporation
         NDIS, Dept 483
         ATTN: Michael Ward, M/S 9131
         11501 Burnet Road
         Austin, Texas 78758

The header files for netbios are now included with NTS/2 and LAN Server 3.0.
These are included in the recent CSD and refresh versions:  LAN Server 3.0
refresh (7040) and NTS/2 CSD 7045.  I believe that these files were previously
included with the Technical Reference.

You might also want to call the Develper Assistance Program number
(407-982-6408).  They should be able to provide the OS/2 toolkits, etc.  There
is an NDIS toolkit from Austin, but this is primarily for MAC Developers.




!VIDEO__________________________________**********
May 27, 1994
QUESTION: (Ref: A64)
We need to display on a flat panel display in portrait mode.  I have access to
a DDK and have examined the source code for the files IBMVGA32.DLL and
IBMDRV32.DLL to determine what needs to be done to create portrait mode
versions of the drivers.  I find that I will need to modify a large number of
the files and will need to restructure much of the driver because physical
display and memory display buffer code is intermixed.  AM I taking the right
approach?

Is there a less costly or time consuming alternative to get to where I want to
go, such as using graphics engine transforms?

Are there any device specific transforms that would allow for rotating the
display 90 or 270 degrees?  Do you have any suggestions?


ANSWER:
It sounds like a correct approach, however, it is always difficult to find
more than one expert that agrees on any one approach.  Now, assuming that you
always want to display in portrait mode, not just in a session, it may be
better to perform the transformation in the presentation driver itself,
although I don't believe we have a device specific transform API that would
directly transform the display fron 90 or 270 degrees.  I am intrepreting
device specfic to mean "something in device coordinates".  For example,if we
have a bitmap that is defined directly in physical device cordinates of the
target device, transformations in current state are not possible.  See the
GPI/GRE reference.




!OTHER__________________________________**********
May 27, 1994
QUESTION: (Ref: A58)
Does IBM have plans to provide a conversion tool for XGS to Dumb Frame Buffer?


ANSWER:
At present, IBM has no plans for such a conversion tool.




!STORAGE________________________________**********
May 27, 1994
QUESTION: (Ref: A55)
The Storage Device Driver reference manaual states that a command-line
paramater parser is provided to make passing parm to a .ADD more consistent
and easy.  Where is this parser in the DDK?  I cannot find it anywhere or in
the sample .ADDs in the DDK.


ANSWER:
The CMDPARSE.C and related files are located in DDK\SRC\DEV\DASD\CMDPARSE .




!OTHER__________________________________**********
May 27, 1994
QUESTION: (Ref: A49)
We have an application which must be awaked in critical priority every 80ms or
40ms.  With the OS/2 1.31, we wrote a driver that took control of the "Channel
0-System Timer" on PS/2 Computer (We didn't need the DOS session).

We tried the same driver on OS/2 2.1 but the driver didn't start.  Do you have
a nice solution hard or software (nice=not expensive) for us?

The XGA-2 device drivers for the OS/2 1.31 traps regulary at boot
(on PS/2).  We installed some applications over the world (~40) and now our
clients ask us to correct the problem.  Is there a way to do it without
uploading the 2.1 version?


ANSWER:
OS/2 1.x only provides a 32ms granularity of timer service.  Whether used by
device drivers or applications, 32ms "chunks" are all that is available.  This
is a design restriction.  So a user asking for 40ms will get 64ms.

This was improved in OS/2 2.x.  Time critical priority threads will get 8ms
granularity timers.  This permits the 40ms timers requested.  This granularity
is available to applications (via threads) NOT device drivers.

Do this:
  DosSetPriority ... to time critical
  DosStartTimer ... to 40 ms

The semaphore passed in DosStartTimer will now be posted every 40ms (or very
close to that number.  Actually, it is 7.8125ms x 4) This is only available in
OS/2 versions 2.0 or higher.




!STORAGE________________________________**********
May 25, 1994
QUESTION: (Ref: C21)
At one time I was able to use OPTICAL.SYS to use my Pioneer optical drive as a
hard drive.  I can't find OPTICAL.SYS on my system anymore.  Did it go away
with 2.1?

I have the original 2.0 diskettes, but don't know where or which disk
OPTICAL.SYS is on, or if I should even try to use it.  SYTOS PLUS does not
provide a PIONEER optical SCSI driver, so I want to use my drive as a hard
drive.


ANSWER:
Optical.sys is not shipped with OS/2 2.X.  This driver is shipped with the
hardware product.  But, a driver can be downloaded from the IBM BBS
(919-517-0001).  The file is called 21optcl.com and is a self-extracting file.




!BASE___________________________________**********
May 25, 1994
QUESTION: (Ref: B98)
We have developed an OS/2 1.x driver for our data acquisition board, using the
old MS toolkit.  It works fine but we are now porting some of our system
(EXEs) to 32-bit, and running into some problems (running OS/2 2.1).

We have a "Level 1" 16-bit device driver.  In the driver's READ strategy
routine, it attempts to return driver-specific errors by setting the ERROR bit
(15) and the DEV ERROR bit (14) and inserting our error code in bits 0-7.
This has always worked fine -- we get the error as a return value from
DosRead.  However, now I am in the process of updating the DLL which accesses
the driver, from 16-bit to 32-bit.

The 32-bit DosRead always returns error 5 (Access Denied) wherever we
previously got the driver-specific errors.

Does the 32-bit DosRead not pass back driver-specific errors from a Level 1
driver?

Is this true of any non-IOCtl calls (the IOCtl calls seem to work the same as
before)?


ANSWER:
Taken from the on line PDD reference on the DDK:

 Bit 15

    The Error bit.  If this bit is set, the low 8 bits of the status
    WORD (7-0) indicate the error code, which is processed by the
    operating system in one of the following ways:

     If the IOCtl category is User Defined, (refer to the Category
    Code under Generic IOCtl Commands), FF00H is ORed with the
    byte-wide error code.

     If not User Defined and bit 14 (device driver defined error
    code) is set, FE00H is ORed with the byte-wide error code.

     Otherwise, the error code must be one of those shown in the
    table below, and is mapped into one of the standard OS/2 API
    return codes.
    (ie. if this is NOT an IOCTL request)




!VIDEO__________________________**********
May 25, 1994
QUESTION: (Ref: B85)
The Presentation Driver Reference (pdrbase.inf) on the latest Developer
Connection CD (7 Mar 1994) does not document the following functions, defined
in pmddim.h:

        GreDevicePolygonSet
        GreFrameRegion
        GreOpenScreenChangeArea
        GreGetScreenChangeArea
        GreCloseScreenChangeArea.

Where are these functions documented and how do I get hold of it?


ANSWER:
These are internal function that have to be exposed in the DDK due to their
use by Presentation driver source code.  These are some of the InnerGre
functions So the answer here would be that these functions are not documented
since they are for internal use only.  Further, these functions are also
subject to change at any time in the future and hence should be avoided if
possible.




!OTHER__________________________________**********
May 25, 1994
QUESTION: (Ref: B80)
We are using the CDROM (DDK) to install/restore the debug/retail kernel in
the lab.  However, we have to go to a customer site to debug, and the customer
does not have a CDROM installed.  How can I re-build the Debugging Tool
Diskettes from the DDK (CDROM) so that I can install/restore the kernel from
floppy diskettes?


ANSWER:
Be sure that you have the right level debugger before you start.  You need to
match the level of OS/2 on your dustomers system.

You should be able to copy whatever release level of the debugger you want
onto two or three diskettes, and then copy they to your users machine with the
exact same tree structure as is on the DDK.

You should then be able to install from there.

It would be advisable for you to test this before you go to your user.




!BASE___________________________________**********
May 25, 1994
QUESTION: (Ref: B62)
What's the recommended procedure for resolving a virtual address to a physical
address while the system does interrupt handling.  To make it clear let me say
it again in the following manner.  After an interrupt signal was sent, how
should they compute a physical address from a given virtual address.
One thing that makes it more complicate is that the corresponding memory area
could be swapped at this time.


ANSWER:
To convert a virtual address to a physical address at interrupt time, The
virtual address, however, must be a "global" virtual address, and not a
process virtual address.  The reason is that the thread context of the
interrupt handler is not known.

The way to do it if its a global virtual address is
1) call DevHelp_VirtToLin on the virtual address.  This will give you
   a linear address
2) call DevHelp_LinToPageList.  This will give you a page list structure
   of the physical addresses that back the virtual address.

This sequence works at interrupt time as I have used it in the SCSI ADD code.
You will need a linear address for the pagelist on the LinToPageList call.  If
the address is a process virtual address then you must calculate the physical
address at task time and save it.




!VIDEO_______________________________**********
MAY 25, 1994
QUESTION: (Ref: B39)
I have my seamless windows driver mostly working at this time.  I have
executed all of the standard windows applications that are available in the
WIN-OS/2 Accessories group, and they all work fine except for one BIG problem.
When I click on a Control-Menu box to get the Control Menu, the Control-Menu
box is re-drawn as active, and then the following error message is displayed:

                           CLOCK

                An error has occurred in your
                application.
                If you choose to ignore, you should save
                your work in a new file.
                If you choose close, your application
                will terminate.

If I click on the CLOSE option, the following message is displayed:

                      Application Error

                CLOCK caused a General Protection
                Fault in
                module GDI.EXE at 0016:1320
                Choose OK. CLOCK will close.
This same error also occurs when selecting an item from the Menu bar of the
application.


ANSWER:
The Seamless DEV ESC 6010, SEAMLESS_PAL_INIT must be implemented.  This DEV
ESC is documented in the PM Display Driver Reference manual.  RC_PALETTE is
required for Windows to recognize the driver as palette capable ( 256 color )
so it should not be removed.  WINShield depends on valid data from the
SEAMLESS_PAL_INIT DEV ESC to understand this also, and intercept SetPalette
functions correctly.  It uses a flag in the returned data structure (
bfPaletteIsFixed ) for this.  It also gets a pointer to the PM HWPalette....
rather important since both seamless windows and PM are sharing the same
palette.

          These were implemented in VGA code example:

                6000  SEAMLESS_ESC_INIT
                6001  SEAMLESS_ESC_EXIT
                6002  SEAMLESS_ESC_ENABLE
                6010  SEAMLESS_PAL_INIT




!STORAGE________________________________**********
May 25, 1994
QUESTION: (Ref: B10)
How can I get the document that was referenced by Sam Detweiler in his talk on
IFS's at the PSP TI in San Fransisco last week?  Also he mentioned a shell IFS
source on CompuServe.  Is that available on the DUDE also?


ANSWER:
The shell IFS file, which is called IFSSRC.ZIP, is now out on the DUDE Mail
File area.  You can download it from there.  This is different from the
IFS.ZIP file that was already out on the DUDE, and is the same file that is
out on CompuServe.

The other document that Sam referenced is all part of the IFS.ZIP file that is
already out on the DUDE.




!VIDEO__________________________________**********
May 25, 1994
QUESTION: (Ref: B08)
In testing our seamless driver, we have found that color bitmaps tend to crash
Windows when the bitmap is copied via the Clipboard between a seamless session
and WINOS2.

We suspect that the reason for this may be related to the fact that our full
screen Windows driver is palette managed but the PM and Seamless drivers are
not.  We are forced to have the Seamless driver NOT palette managed because
the PM driver isn't palette managed.

When we tried to use a palette managed Seamless driver, it crashed with weird
problems which we were never able to track down.  We concluded that the
seamless driver must behave the same way as PM due to limitations in VWIN.  It
was a big job turning the Windows driver into a non-managed version, but it
would have been harder to turn PM into a palette managed driver.

My questions are:

1. Is the Clipboard problem a limitation in Windows?

2. Has this issue been addressed by IBM, and has it been tested?

3. And, finally, has OS/2 2.1 seamless support been tested with palette
   managed display drivers, and has it been tested with a mismatch between the
   two?


ANSWER:
1) I talked to the developer who implemented the Clipboard feature. There is no
   limitation between seamless Windows and fullscreen WinOs2. There is only one
   clipboard limitation which is copy metafile from PM application to
   fullscreen or seamless application. Furthermore the clipboard
   implementation is independent of Drivers capability, specifically regardless
   of whether the Windows driver support palette manager. This is because
   clipboard deals with Device Independent Bitmap format.

2) Yes IBM has tested coping bitmap between Seamless application and WinOS2
   fullscreen application.

3) We certainly tested Seamless drivers that have palette manager support. XGA
   seamless driver is one example. Regarding the testing of mismatch in the
   sense that fullscreen WinOS2 has palette manager support whereas Seamless
   driver does not we have no idea.

Here is additional information on clipboard.  I happen to come across a defect
against OS/2 2.1 on GP fault in Excel 4.0 using clipboard.  The defect # is
74318.  This defect has been fixed and the problem is in VWIN.SYS.

Let me also mention that if in future if you experience additional problems
you should report the problems with your machine configuration to IBM via the
OS/2 helpline (800-465-2222).  Development can work with you to fix the
problem via this vehicle.




!VIDEO__________________________________**********
May 25, 1994
QUESTION: (Ref: A85)
We are developing a seamless Windows driver and have encountered a problem
that we would like to ask you about.

When moving a seamless window on the OS/2 desktop to an overlapping location,
we sometimes get items (the frame, for example) drawn in the overlapping areas
of the window before the window is copied.  The only thing that we have been
able to determine about this problem is that we are apparently drawing at the
new window position before OS/2 executes the screen-to-screen BitBlt to move
the window.  As a result, we draw in the overlapping region and then the
incorrect data is copied to the new window location by the BitBlt.

Our assumption is that there may be some flag we are supposed to check before
we perform any drawing operations.  Theoretically, this would force us to
synchronize with OS/2 in this operation.  If so, could you tell us how to
check it?  Alternatively, is there some flag WE should set in order to force
the Windows and OS/2 graphics engines to call our Windows driver to do the
copy (probably moving the problem to our OS/2 PM driver then...).


ANSWER:
As you point out you are drawing at the new window position before OS/2
executes the screen to screen BitBlt to move the window.  Further you are
correct in assuming that a synchronization mechanism is needed between the two
drivers.  A semaphore can be added to synchronize and resolve this problem.
Seamless windows driver would wait on the PMDD_SCREEN_BUSY RAM semaphore.
Examples can be found on the latest DDK under DBCS code.  (IPC.INC and
SEAMLESS.INC).




!MULTIMEDIA_____________________________**********
May 25, 1994
QUESTION: (Ref: A21)
How many buffers will the stream handler send to the audio dd.  How can I
prevent overflow of data from the stream handler to the audiodd during
playback.


ANSWER:
Audio stream handler at most will give you 2 buffers at any given time.  There
will be no overflow situation as long as your dd handles 2 buffers at any time.

So, during playback your dd initially receives two buffers.  When the first
buffer has completed playback you start playing the second buffer.  You then
return the first buffer back to audiostream handler and he sends you the third
buffer.  The cycle then repeats.




!PRINT__________________________________**********
May 25, 1994
QUESTION: (Ref: 913)
We need to know how to do the following:

 - Install a printer object totally under program control, NO user
   intervention.

   I have played with changing the spooler settings in the OS2SYS.INI with very
   little luck.  It seems to be order dependent and I do not know the correct
   order.

 - Remove a printer object totally under program control.  We, at times, require
   our installation to delete our existing printer objects and printer driver
   before installing the new printer driver and creating printer objects.


ANSWER:
Here are the steps needed to install a printer object automatically:

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.


Similarly, removing a printer object can be accomplished by executing the
corresponding spooler delete functions (SplDeleteQueue and SplDeleteDevice)
and deleting the INI file entries.  However, if the printer driver has been
loaded since the last reboot of the system, then currently, the system needs
to be shutdown and rebooted before the file can be deleted.




!VIDEO__________________________________**********
May 25, 1994
QUESTION: (Ref: 869)
I would like some information on writing device drivers for the intel smart
video recorder  it's a little frustrating having the hardware and the only
driver will only run as windows virtual device drivers, and my machine is
OS/2 all the way.  I would really appreciate any help or direction to take.


ANSWER:
This is a request we have heard before.  No, Intel does not have an SVR driver
for OS/2.  However, IBM is sensitive to requests like yours and is seeking a
solution to the problem.  I also asked about the possibility of you developing
your own driver.  The following information was forwarded from our planning
organization.

**This is not a simple driver, since SVR has an onboard video processor (i750
chip) that runs microcode and does real time capture/compression of Indeo
bitsteam.  Writing a driver [for OS/2] would mean licensing Intel's Litening
SW architecture, which manages the download and execution of microcode for
i750.***

We also want to make you aware of the Action Media II product from IBM that
works with OS/2.  We appreciate your support of OS/2.




!NETWORK________________________________**********
May 25, 1994
QUESTION: (Ref: 842)
I am searching for information on MPTS/MPTN, which I understand is part of
IBM's LAN transport future directions.  MPTS is a layer that sits above the
network protocols in LAN Server transports.

In a presentation Mark Simpson gave at the driver conference in San Jose, he
indicated an OS/2 32 bit distributed API would be available to enable
application access to many transports using a common interface.  I am
searching for information on this API and related development tools.


ANSWER:
MPTS (MultiProtocol Transport Services) focusses on the socket API.  The
intent is to provide access to "any" protocol via the 32-bit socket API.  As a
result, you may develop all your applications by writing to one standard
transport interface namely the socket API and with MPTS, these applications
can be made to run over any other protocol.  This is what we refer to as the
transport independence since the transport is now transparent to the
applications.  This is is the main problem that the MPTN architecture provides
solution for.

MPTS code was shipped with the OS/2 DCE product last September and it supports
socket API over TCP/IP and NetBIOS protocols.  RTP's AnyNET/2- sockets over
SNA product is being migrated to the Austin's MPTS transport framework.  As a
result, MPTS could then support sockets over SNA, in addition to NetBIOS and
TCP/IP.

Currently we are working on providing sockets API over IPX/SPX protocol so
that when it is all done, you get sockets over NetBIOS, SNA, IPX/SPX, and of
course, TCP/IP.

With respect to transport independence, we currently support TCP/IP
applications ( such as DCE, FTP, NFS ) run on top of NetBIOS ( note that this
function is made available as BETA only ). When RTP goes with the next release
of AnyNET/2, you should be able to run DCE on top of SNA.




!OTHER__________________________________**********
May 25, 1994
QUESTION: (Ref: 801)
What ring does a context hook run at?  Does it run at ring 0, since it is part
of the device driver code; or does it run at ring 3 since it is at task time?
It would make sense to me to run at ring 0. The documentation is not specific.
Also, how much scheduler overhead/task switching is involved?  Is this a
tremendous amount or fairly negligable?


ANSWER:
Context Hook runs at ring 0. Context hooks should never block.  The overhead
is fairly negligible.

Context hooks run right before the current thread of execution is about to
exit from the kernel back to application (user) space.  The thread the context
hook is running on (probably) doesn't belong to the process the context hook
is actually doing services for so it should NOT be blocked.  In some cases,
the OS's IDLE thread is used to run the context hooks and blocking this thread
causes an immediate hang.  If you need control back after some period of time
or on some furure event, use a timer hook or some other interrupt handler
along with another context hook or one smart context hook and a list of
"things to do next".




!VIDEO__________________________________**********
May 25, 1994
QUESTION: (Ref: 790)
I am looking for drivers for the intel smart video recorder for OS2. If there
are none available can someone aid me in developing device drivers for them.


ANSWER:
We contacted INTEL and found that they do not currently have an
OS/2 DD available for their Smart Video Recorder.  They had no additional
information, as to status/target dates for such a driver, from their
developers.  As for developing you own, we provide the DDK, DEVCON and ADS
(from private developers).  To learn more, browse the DUDE.




!VIDEO__________________________________**********
May 25, 1994
QUESTION: (Ref: 754)
I'm trying to write a full screen app that runs at 640 480 256 colors.  I've
already got this working for XGA, but unfornately XGA is going away.  I've now
got to get it working for SVGA.  I want to take advantage of the SVGA device
drvier as much as possible, since there are so many SVGA chip sets.  I don't
care if I only support the SVGA device drivers supplied with os/2 2.1.

Right know using the vio calls I've got the mode set to work, but the
VioSetState for setting the color regs does not appear to work.  Is this call
supported by the XGA and SVGA device drivers?  If not, can I use SCREEN$
calls?

In any case, is there documentation on the SCREEN$ calls, AND are there PMDD$
calls? I heard a rumor there were, and could I use those calls in full screen
mode?  I tried opening SCREEN$ and it works, but I have no idea about the
IOCTL format.  All I need to make this work is the set mode call, the load
color palette call, the set bank call.  Everything else I can do with the get
physical buffer call just like I do in XGA.


ANSWER:
You can get more information about video functions in the Physical
device driver reference under the chapter titled "Video PDD".  Also,  if
you have the DDK, you can look at the SCREEN$ source code under
\src\dev\screendd.


1. Q- VioSetState for setting the color regs does not appear to work.
   A- This is an old, 16 bit call. It is suggested to use IOCTL's.

2. Q- Can SCREEN$ calls be used and if so, where is documentation?
   A- Yes, SOURCE/DEV/SCREENDD directory for SCREENDD source and
      IOCTL format can be found there also.

3. Q- PMDD$ ?
   A- Proprietary to IBM.....




!OTHER !STORAGE_________________________**********
May 25, 1994
QUESTION: (Ref: 740)
I am trying to build the CDROM filter drivers which are part of the DDK.  The
USEDDK manual says that I need to use the Microsoft 6.0 C compiler.  I have
installed Microsoft C 7.0, but am not able to run the compiler in a OS2 shell.
I get the error 1059, cannot execute this program.

My question is can I use the 7.0 compiler and if so do I have to do something
different during installation ?


ANSWER:
Microsoft C 7.0 does not support OS/2.  The last microsoft compiler that
supports OS/2 is C 6.0.  Alternatively IBM CSET/2 may be used to build the
drivers in DDK if the customer can not get hold of MS C 6.0.  The makefile in
DDK will need to be modified to use CSET/2.




!OTHER__________________________________**********
May 25, 1994
QUESTION: (Ref: 721)
I'm working on a video improvement and need some entry points into the IBM
OS/2 Multimedia development system.  I'd like to support OS/2, Ultimedia and
any emerging video software you're offering.

Question:  What parts of the system/driver or application/decompressors (like
Indeo) can be upgraded to use hardware functions?

What SDK, DDK, etc. should I obtain to start programming the speed-up?


ANSWER:
The Developer's Toolkit for OS/2 Version 2.1 contains both diskettes and
CD-ROM.  The CD-ROM contains Multimedia Presentation Manager/2.  The product
number is P61G1416.

IBM's most recent offering and a more complete package is The Developer
Connection for OS/2 (DEVCON).  It is a CD-ROM that can be ordered by calling
1-800-6DEVCON (1-800-633-8266).  The product number is 82G1500.

The IBM Device Driver Source Kit for OS/2 (DDK) is the product that we support
and can be ordered through the 800# list above.  As a DDK subscriber you are
eligible to attend, at no charge, our workshops.  You may also be interested
in offering your device driver development skills to those companies that are
looking to offer an OS/2 device driver with their product.  If so, then
inquirer about our DUDE ADS.




!PRINTER________________________________**********
May 25, 1994
QUESTION: (Ref: 717)
I found a problem with the way printer sharing is currently implemented.  When
the printer driver receives a request for exclusive access to the printer it
saves the current PID (of the requesting program).  When a request to
relinquish exclusive access is received, the printer driver authenticates this
requesting by verifing that the current PID matched the one saved earlier.

However, a device driver may relinquish use of the printer port during an
interrupt thread, i.e.  when the curernt PID is not the same a the PID at time
time of the request for exclusive use.

This is particularly true for an audio device driver which does not block
processes which request its services.

I have, therefore, found it necessary to modify functions checkdirectaccess
and releasedirectaccess in file prtplpt.asm

I use register BX to pass the DS of the driver as an authentication key.  I
save this key when exclusive access is requested and use it to verify a
request to relinquish.

I currently have to distribute my own version of printer01.sys, printer02.sys
and I hope that eventually IBM will include a similar fix in its code.


ANSWER:
The original intent of the parallel port IDC for sharing of the parallel port
between multiple device driver was for use at task time, not interrupt time.
The fact that audio device drivers return the request thread prior to
completion of interrupt time processing, prevents them from being able to
issue the release exclusive access at task time.  I have reworked the parallel
port device driver to use the device driver data selector as the key to verify
the caller of the release exclusive access is the same as the caller of the
request exclusive access.  This has changed the IDC interface to require the
es register to be set to the callers primary data segment.  The audio device
driver developer is correct that the process id is unavailable at interrupt
time.

I have updated the document describing this along with the parallel port
device driver and have sent it to the SYSOP.  He will be updating the DUDE
server with this information (The IDC is still in beta form).  I am working on
getting it to OS/2 Service for OS/2 2.1 (which the next DDK will be based) and
into the OS/2 2.1 manufacturing refresh.  I'm not sure that it will make it
into the manufacturing refresh.




!STORAGE________________________________**********
May 25, 1994
QUESTION: (Ref: 709)
I am writing a block device driver that loads as a DEVICE=.SYS driver.  It
appears that the DISKCACHE line in the CONFIG.SYS is processed before my
driver loads.  I have found this by forcing a syntax error on the DISKCACHE
line.  This error is reported before my sign-on message.  It appears that
there is no caching for my devices -- I always get the request packets for
reads even when I read the same file multiple times in a row.  My questions
are:

Q1. When is the DISKCACHE statement actually processed during the boot
    process?

Q2. How is the allocated memory divided among the devices?  As one large
    cache or as a section per block device?

Q3. I am using the Strategy1 interface as opposed to the EDDI/Strategy2
    interface.  Is this part of the problem?


ANSWER:
A1. The DISKCACHE line gets processed during bootup before any of the drivers
    are loaded.  This information is passed to the OS2 kernel by the loader.

A2. The allocated memory is not devided among devices. The kernel notifies
    the drivers during init time. IBM SCSI driver supports cache and gets
    notified by the kernel during init time. See OS2SCSI.DMD that supports
    cache.

A3. The EDDI/Strategy2 needs to be used only if the driver needs to support
    the scatter/gather interface (nothing with DISKCACHE).




!BASE___________________________________**********
May 25, 1994
QUESTION: (Ref: 657)
RE: How to keep the STACK of a thread permanently in memory ?
1. When calling 'DosDevIOCtl', the thread is switched from USER to KERNEL mode
and a kernel stack is allocated and assigned to the thread.  The stack is
found to be 8K (2 pages of 4K) and I also found out that only the first page
is committed in memory.  The problem is when the stack usage exceeds 4K in the
driver, a SEGMENT NOT PRESENT will occur and the system will stop.  In other
words, the actual stack size of the thread inside the kernel is only 4K but
not 8K even though a system stack of 8K is allocated.  Is there way of
committing the second page of the stack inside the device driver ?  It seems
to me that it is a system design flaw or am I missing part of the whole
picture ?

2. When the thread is asleep and when there is memory overcommitment in the
sytem, I found that even the first page of the stack is temporarily swapped
out.  That will create a problem when the ISR needs to put some information in
the stack.  I have try locking the stack in memory by calling DEVHELP but the
system stopped with an internal processing error after a while.

I know the ISR can put the information into the data segment of the device
driver and the data segment will never be swapped out.  But I prefer storing
the information in the stack.

3. Further to question 2, there is also another reason for keeping the stack
in memory.  Because after the ISR wakes the thread up, the stack has to be
loaded from SWAPPER.DAT before the thread can run.  There will be a
considerable amount of delay between ISR calling Devhlp_ProcRun and the thread
starting to run.  If this delay is not desirable, the stack and all other
structures needed by the thread (e.g.  the TSD) has to be resident in memory
all the time.


ANSWER:
When the application sends the address of the stack via IOCtl to the driver,
the driver must call VMProcessToGlobal to get a pointer to the stack and then
VMLock the buffer to prevent from being paged.  The driver then can transfer
data freely.




!OTHER_________________________________**********
May 25, 1994
QUESTION: (Ref: 643)
PM Drivers are DLL's running at ring 3. I compiled a "skeleton" PM device
driver using the one that came with the DDK 1.1, under
\ddk\src\prntdd\mdriver.  It is only slightly modified.  My ICC's options
include "-Ti+", and my link386's options include "/DEBUG".  When I run a
program that calls my PM driver, I can load the source code for my driver, but
I cannot set a break point anywhere in my driver.


ANSWER:
Do you have the debug kernel loaded when you are trying to debug the driver?
Also, please see the README file under \ddk\src\prntdd\mdriver\doc directory
for more information on debugging.




!STORAGE________________________________**********
May 25, 1994
QUESTION: (Ref: 642)
Reference is made in the DDK documentations for CD-ROM Manager Interface
Specification, to the ADAPTERDEVBUS field of the ADAPTERINFO structure being
set to AI_DEVBUS_NONSCSI_CDROM.  This seems to imply that perhaps a higher
level driver uses this flag to determine which device manager to use to
service I/O requests.  What I would like to know is, how does the kernel
determine which file system driver (HPFS or CDFS) to use to service those
requests?

It may be that I will have to modify both the DASD and CDROM device managers
as well as the file system drivers in order to implement the IDE CDROM device.
I hope that at most mods will only be need to the device managers, but in any
event a clarification on the device manager selection process would be very
helpful.


ANSWER:
There is a IFS= statement in the config.sys that tells the system which file
system to use. The file system for CD-ROM is CDFS. The config.sys will have
a statement like:

IFS=C:\OS2\CDFS.IFS

There will be no need to modify either any of the file system drivers or the
.DMD. The non-SCSI CD-ROM driver is an ADD and the OS2DASD manager will
support the ADD. Once the customer receives the MITSUMI CD-ROM driver diskette
things will clear up.




!PRINT__________________________________**********
May 25, 1994
QUESTION: (Ref: 640)
We are trying to interface our scanners to our application.  We can retrieve
data from the scanner but after a fixed number of blocks the device driver we
are using seems to Hang....  We downloaded a general purpose device driver
called GENSCSI.SYS from Compuserve.  It works basically as advertised except
for the above problem.


ANSWER:
That driver was put out for educational purposes only.  The idea was to show
how to program to the published interface for OS2SCSI.DMD, not to provide a
bullet proof driver.  It was never intended for real world use and has not
been tested for that type of use.  The complete source is provided in the
package that others could use as a starting point for making their own driver




!OTHER__________________________________**********
May 17, 1994
QUESTION: (Ref: B77)
I am interested in the OS/2 for PowerPC beta program that was outlined at the
OS/2 PSP in San Francisco April 25-29.


ANSWER:
A file called OS24PPC.TXT has been placed in the main file area on the DUDE.
This should give you the information you need regarding the PowerPC beta
program.




!OTHER__________________________________**********
May 17, 1994
QUESTION: (Ref: B96)
I am a developer in Germany.  We need the following OS/2 books very urgently.
Can you tell us the addresses of where we can get these books?

N0.                      Book Name             Publisher         Author
1       Writing OS/2 Device Drivers in C.    VNR Comp. Library  Steven J.
                                                                 Mastriani
2       OS/@ Techn Library Physical Device     IBM
        Driver Ref. Public. No. 10G266

3       OS/2 SCSI Device Driver                 Dept. 6G9        D.T. Feriozi
        Interface Spec.                         IBM Boca Raton   R.B. Tegart.

4       The Design of OS/2 1992                 Addison Wesley   H. Deitel,


ANSWER:
There are several sources for the books you have asked about.  I will list
those that I know of, and let you decide which is the best for you.

1. Writing OS/2 Device Drivers (Mastrianni):
This is available in the US through IBM under the document number SR28-4392. I
don't know if it is available through IBM in Germany.

It is available on CompuServe from Compubooks (GO CBK).

It is also available from Van Nostrand Reinhold (VNR) in the US by calling
800-842-3636. VNR is an International Thomson Publishing (ITP) company. The
book gives an address of ITP in Bonn, Germany. It is:

                International Thomson Publishing GmbH
                Konigswinteror Str. 518
                5300 Bonn 3
                Germany

2. Physical Device Driver Reference:
This documentation is also available in several places. It is available in
soft-copy on the DDK V1.2.

Hard-copy can be ordered through the same phone number that the DDK can be
ordered through. For EMEA, the phone numbers I have are all in Copenhagen.
The German language number is +45-4810-1000. The document number is
S10G-6266-01.

3. OS/2 SCSI Device Driver Interface Spec (Feriozi, Tegart):
This document is no longer available in it's original form or title. You are
apparently looking at some outdated information. The document has evolved to
become the Storage Device Driver Reference manual.

The answer supplied in number 2 above also applies here, with the exception of
the hard-copy document number. For this manual, it is S71G-1897-xx.

4. The Design of OS/2 (Deitel, Kogan):
This is available through IBM under the document number S325-4005.

I do not have an address or phone number for the publisher, Addison-Wesley.
However, in the front of the book, it indicates that they also have an office
in Bonn, Germany.

I hope this information provides you with the assistance you need.




!OTHER__________________________________**********
May 17, 1994
QUESTION: (Ref: B68)
I have made some modifications to the H files in order to get allow
ADD's to be built with WATCOM C16.  This compiler is very strict about ANSI
compliance, and several parts of the toolkit do not meet the requirements.

The changes are relatively minor-- I have sent all the files so you can diff
them and see the changes.

I would appreciate if future versions of the DDK could be ANSI compliant.

By the way, WATCOM C16 produces better code than the MSC v6.0 you are using
now, and is a native OS/2 compiler.


ANSWER:
There is an OS/2 development effort to consolidate compilers/tools currently
being used to build various products.  We believe the short list for compilers
includes Watcom as a 16 bit replacement for MS C.

The DDK team does not support the use of tools (compilers/assembers) other
than the ones indicated by the Build Requiremenst in "Using Your DDK" on the
DDK.  Drivers can be built with other compilers providing the user fully
understands what he/she is dealing with, perhaps with some modification as
needed.

Part of the problem with the non-ANSI header files is that some/most of the
headers that ship with the DDK are not the headers that are shipped with the
OS/2 Toolkit.  Rather, they are headers that are used by OS/2 development in
order to use the Microsoft (16-bit) compiler.  The headers shipped with the
Toolkit are intended to be used with the IBM (Toronto 32-bit) C/C++ compilers.
(Yes, we have two -- or more -- sets of "Toolkit" headers internally.)

A little information on the Watcom compiler -- Watcom is the 16-bit "compiler
of choice" for future OS/2 development.  Most of development is still using
various Microsoft compilers for their components.  There is a task force
driving the convergence of OS/2 development to the Watcom compiler.  The goal
is to move away from dependence on Microsoft, particularly for the compilers
that are no longer available commercially.




!OTHER__________________________________**********
May 17, 1994
QUESTION: (Ref: B65)
Last week I attended the PSP conference.  At the Hang Trap booth, they were
handing out literature and indicated that there would be several class
offerings coming up.  Can you tell me the schedule for the classes please.


ANSWER:
As of 4/28/94:

                  OS/2 HANG/TRAP ANALYSIS WORKSHOP
                       Duration:  4.5 days

COURSE #  SECT  CLASS DATE  STATUS     LOCATION     INSTRUC  STAT/REVNUE
--------  ----  ----------- ------    ------------  --------------------

   P1082  ----  05/09 - 13  PUBLIC   Boca Raton      MARIE
   P1082  5725  05/09 - 13  PUBLIC   Dallas SD       PETE

   P1082  ZZ02  06/06 - 10  PUBLIC   Boca Raton      MARIE
   P1082  ----  06/06 - 10  PUBLIC   Winnepeg        PETE
   P1082  5844  06/13 - 17  PUBLIC   Atlanta SD      DENNIS
   P1082  W650  06/27 - 01  PUBLIC   Somers SD       DENNIS

   P1082  ZZ03  07/18 - 22  PUBLIC   Boca Raton      MARIE
   P1082  W347  07/18 - 22  PUBLIC   San Jose SD     PETE
   P1082  IW05  07/25 - 29  PUBLIC   Dallas SD       PETE
   P1082  W397  07/25 - 29  PUBLIC   Phoenix SD      DENNIS

   P1082  ZZ04  08/08 - 12  PUBLIC   Boca Raton      MARIE
   P1082  W383  08/15 - 19  PUBLIC   Seattle SD      PETE

   P1082  ZZ05  09/19 - 23  PUBLIC   Boca Raton      MARIE
   P1082  IW22  09/19 - 23  PUBLIC   Atlanta SD      DENNIS
   P1082  XXXX  09/26 - 30  PUBLIC   Endicott SD     DENNIS

   P1082  ZZ06  10/17 - 21  PUBLIC   Boca Raton      MARIE
   P1082  ----  10/17 - 21  EUROPE   Mainz, Germany  PETE
   P1082  ----  10/24 - 28  EUROPE   Mainz, Germany  PETE

   P1082  IW56  11/07 - 11  PUBLIC   Dallas SD       PETE
   P1082  ZZ07  11/14 - 18  PUBLIC   Boca Raton      MARIE

   P1082  ZZ08  12/12 - 16  PUBLIC   Boca Raton      MARIE

****    Dept RG1/Int Zip 1026/Bldg 001-3   ****
****          1000 NW 51st Street          ****
****         Boca Raton, FL   33431        ****




!STORAGE________________________________**********
May 17, 1994
QUESTION: (Ref: B43)
I have a question about SCSI timeout.  One of our IHVs developed a removable
HDD for SCSI.

This device will be waiting some time before being ready to read.  Perhaps the
disconect time needs more than 45 sec.

Now structure as follows.
   Application program
     OS/2 Kernel
          |
     OS2DASD.DMD
          |
     OS2SCSI.DMD
          |
     IBM2SCSI.ADD
          |
      SCSI CARD
          |
     Removable DISK  <--- Data Transfer --CARD reader

Application program used DosDevIOCtl(Category 8 logical DISK) to Removable
disk, and so read/write can do by DosDevIOCtl.

When removable disk send disconect to SCSI for card reader transfer.  And when
disconect time over 45 sec, trouble could occur (disconect time less than 45
sec, trouble could not occur.)

Perhaps, I think OS2 kernel (FAT manager) or OS2DASD.DMD control timeout to
read/write to OS2DASD.  In the case of OS2DASD or DDK's modules, we can fix.

Our environment:OS/2 J2.1/DDK v1.1

Can you suggest a way to solve the disconect problems.


ANSWER:
There are two ways to talk to the hardware.  DosDevIOCtL or go through the
OS2DASD.DMD manager.

  Path for the OS2DASD.DMD manager is

  Method 1      Application
                Kernel
                OS2DASD.DMD
                IBM2SCS2.ADD
                HardwareCARD


  Method 2    DosDevIOCtL
              Kernel
              xxx.add
              Hardware Card



The Timeout in the I/O Request Block Header can be set to a -1 that will give
an infinite time to wait for a response, If this timeout is set to a 0 the
xxx.add driver can set the value.  Please see page 21 of the OS/2 Storage
Device Driver Reference manual or in the DDK.




!OTHER__________________________________**********
May 17, 1994
QUESTION: (Ref: B30)
I have developed an OS/2 2.1 driver for our PCMCIA network card.  It is based
on our earlier non-PCMCIA NDIS driver.  I have only, just now, ordered the DDK
and am hoping it may answer some of my questions, but for now I have based my
PCMCIA methods on Mastrianni's 2.1 DD book with some guesswork to fill in
blanks and errors.  The driver uses both Init and CMDInitComplete strategy
handlers.  For the most part it is working fine.

As I see it, under OS/2, I can't call Card Services to find and configure my
card until CMDInitComplete time or later.  In the old scheme of things I would
communicate with my card at Init time and if something was not as expected, I
could print a message to the default console that described the problem to the
user (I used DOSPUTMESSAGE).  I would like to do something similar when I find
my PCMCIA card at CMDInitComplete time.

Is there a way for me to do a simple console message at this time in the
driver?

If there is no simple way, is there any dependable way?  If this is covered in
the DDK, just tell me where to look when I get it.

Another nice feature might be if my driver could present some kind of pop-up
message window on insertion or removal events.  Do you have any suggestions on
how this might be implemented from my driver?

Is there any other PCMCIA related documentation, besides the DDK and I/O DDR,
that may be useful to me?  I already have the PCMCIA specs from PCMCIA.


ANSWER:
-  How to display the message when the client driver detects unexpected
   configuration from the card services driver  ?

   As the customer already knows, the PDD can communicate the other PDD
   through IDC entry only after INIT COMP command, not at INIT time.  Also at
   ring 0, there is no way to display the error message from the PDD.

   The only things which a PDD can do is to make the resident segment within
   4K bytes and make the others into swappable segments.  When the application
   starts communicating to PDD the application can pop up the meesage.

 - How to popup the message box when PC card is inserted ?

   If the application is not running at this point, there is no way to do it.
   When the application is running, it can create another thread which calls
   to PDD and waits, for insertion and removal events, and displays the popup
   message.  The PDD can block this thread, and when the PDD gets the event,
   it can run this thread.

 - Currently, the only books I know are the PCMCIA specifications and the
   Input and Output Device Driver Reference in DDK.




!I/O____________________________________**********
May 17, 1994
QUESTION: (Ref: A72)
I am having a problem with the Keyboard device driver.  In using the Xlate
scan code Cat.  4 Function 0x79 I am not able to correctly cook extended keys.
That is, for keys like Right Control, Numeric Enter and any other key with an
E0 (or E1) prefix, the resulting CHARDATA structure is not filled out
correctly.  For, example, if I Translate an E0 and then a 1D I do not get back
a flags status register that indicates a Right control is depressed.  Instead
it indicates that a left control was depressed.

I looked in the DDK and it seems that the KbdXlate should do what I want, but
that there are some checks for extended extended scan codes in XlatSC before
it is called!  What are those?  Are those 3270 keyboard scan codes?

What I have is a stream of Scan codes that exactly represent a series of
keystrokes (extended and not).  What I need to do is to translate these into a
set of monitor packets to be inserted into a Keyboard DD monitor chain.  It
sounds like Cat.  4 Func 79 is made to order for this purpose.  What am I
doing wrong?

I am just using that IOCtl in a monitor application.  I need to be able to
"cook" a steady stream of scan codes into monitor packets for insertion into
the monitor device chain.


ANSWER:
The reference to "extended extended" is related to the IBM 122 Key and the
addititional keys that are used by that keyboard.  There were not enough scan
codes available after the hardware group assigned them to all requestors
including the Japanese for their DBCS keyboards.

In the CharData record defined in the Physical Device driver book under
Category 4, Function 79, make sure the field "Status" has bit 1 ON.  This
signifies that the scan code is a extended key code.  Also load 'E0' in the
"ScanCode" field before calling the IOCTL for the first time.  After the
return form the call, reload the "ScanCode" field with the scan code of the
actual key and reset the "Status" field to zero.  After this call to the
keyboard, the CharData field should show the correct information.




!OTHER__________________________________**********
May 17, 1994
QUESTION: (Ref: A15)
Q1. I need to set the system time from an interface card to a GPS satellite
    receiver.  This hardware provides microsecond timing accuracy.  I would
    like to obtain the system clock source code so I can modify it to utilize
    timing information from this board.  I would also like to run the system
    timer from an interrupt generated by this board.  Can the timer period be
    changed?  Possibly this may be in clock01.sys?

Q2. I would like information on how to modify the OS/2 startup bitmap.


A1. It looks like you don't have the DDK.  CLOCK0x.SYS source is distributed
    on the DDK.  You are on the right track:  the timer period is in
    CLOCK0x.SYS and it can be changed.  Presently OS/2 gets its timing from
    the CMOS clock.  You should be able to change the timing source, too.

A2. The OS/2 startup logo cannot be easily modified.  The logo is put up by
    OS2KRNL.  It is not a bitmap and cannot easily be changed.  It can,
    however be disabled by patching the kernel.  Instead of getting the OS/2
    logo and copyright statement, you would get a blank screen with the
    copyright statement.  Not really an improvement.

    Another alternative is to write a device driver that would clear the
    screen and put up a logo.  The OS/2 logo would already be up for a while
    before the device driver gets loaded, so the user would already see it.
    There is such a device driver on the preloaded PS/1 and PS/VP machines.




!BASE !OTHER____________________________**********
May 17, 1994
QUESTION: (Ref: 932)
Q1. I am having a problem with a Windows 16 bit application running under OS/2
    2.1 accessing a OS/2 PDD through the DOS 0x440C Generic IOCtl function.
    When performing the DOS IOCtl request, I set both the parameter and data
    buffer pointers to the same parameter packet address.  When the OS/2
    driver receives the IOCtl request the parameter packet pointer seems valid
    (I can lock it and verify read/write access) but it is not the original
    data.  However, the IOCtl data buffer pointer looks like my data but it
    fails on a DEVHLP_LOCK request (result AX=5).

    I do not have this problem when using the DOS or OS/2 IOCtl functions from
    either a DOS real mode app or OS/2 16 bit app.

    Could you please answer the following questions:

    - Does OS/2 support IOCtl requests to an OS/2 PDD from a Windows session?

    - If not, how can a Windows app running under OS/2 2.x get access to a
      PDD?

    - Can this be done without writing a VDD?

    - Are the parameter and data buffer pointers within a OS/2 IOCtl packet
      already converted and locked when the PDD gets control?

A1. The Windows app calls the Generic Ioctl and is intercepted by DOS which
    then transfers control to DPMI which is the weak link in the chain.  The
    communication between DPMI and the VDMM doesn't work.

    The easiest solution is to write a VDD to create the IDC to the PDD.
==============================================================================

Q2. This does not seem to follow what is documented within the Physical Device
    Driver Reference for version 2.00.  It states (page 5-6, Converting DOS
    session Addresses Within IOCtl Request):

    "In OS/2 2.0, INT 21 IOCtl (AH= 44h) functions are passed to the OS/2
    physical device driver in protected mode.  Notice that the IOCtl packet
    contains pointers.  The addresses of the IOCtl packets are translated by
    the kernel since they are pointers."

    Is this not true?  If so, for what sessions does the OS/2 kernel convert
    the IOCtl pointers?

A2. Yes, OS/2 supporst IOCTL requests to an OS/2 PDD from a windows session.

    To handle INT21H Generic IOCTL's from the windows session the following
    steps are to be followed.

    1. Allocate GDT selectors at INIT time.

    2. When request comes in determine if the request is from a MVDM via
       GetDosVar.

    3. If request from MVDM, convert segment:offset to linear address via
       shifting segment 4 bits left and adding to offset.

    4. Use LinToGDTSelector to map linear address to a GDT selector

    5. Use the GDT selector for accessing the memory.

    You should lock the segment before doing the LinToGDTSelector.  Use Vmlock
    to lock before LinToGDTSelector .

    First you have to convert the V86 address to a linear address (16*seg +
    offset).  VMLock uses the linear address as an argument; then
    LinToGDTSelector uses the same linear address(now locked if all went well)
    to give you a selector:offset(16:16) address that you can use to address
    the V86 data area while executing in your driver.

    There is example code in "ddk\src\dev\atcom\ATCOM.ASM", lines 798-852,
    which does what the customer is trying to do.  This code is in assembly
    language.  This should help you to understand the problem.
==============================================================================

Q3. In supporting DOS apps under OS/2 2.x, I would like to be able to detect
    that OS/2 is running so that I may re-direct our request our OS/2 PDD.  I
    can successfully detect that OS/2 is running by using the DOS get version
    function 0x3306.  However, this only works when the DOS session is not a
    boot image.  If I create a boot image of DOS and boot it, the DOS get
    version function 0x3306 returns the version of DOS that was booted.  Is
    there a way to reliable detect OS/2 2.x from a booted image of DOS?

A3. There is one way that he should be able to code fairly easily.  Have him
    walk the device driver header chain backwards, looking for the device
    driver FSFILTER.  This will tell him if he is in a booted VMB - MAYBE.

    The reason for the "MAYBE" is that there is NO guarantee that the end user
    added that statement to his environment even though it is documented that
    he should.  In other words, the VMB will work without it.




!I/O____________________________________**********
May 10, 1994
QUESTION: (Ref: B47)
We're looking to develop a device driver for Pen Input.  We're a little
confused between the difference in PenPM and Pen for OS/2.  Which do we
develop for?


ANSWER:
They are one and the same.  PenPM was really a code name that got wide usage
and became generally known.  Pen for OS/2 is the real name of the product.




!STORAGE________________________________**********
May 10, 1994
QUESTION: (Ref: B34)
We are developing a SCSI ADD device driver.  When we install OS/2 from CD-ROM
sitting on our SCSI adapter card, we are OK if we use HPFS format, but we
crash the system when we use FAT to format the disk during installation, the
message we saw is:

    TRAP 000d, the system detected an internal processing error at
    location ##0160:fff5fbd5 - 000d:9bd5
    60000,9084  048600b4  internal version 6.514 ,93/04/12

We use the same ADD driver, same hardware when we installing, the only
difference is the FAT/HPFS choice Do you have any idea what could cause this
problem ?


ANSWER:
The device driver must determine the media type in the device in order to
return the pointer to the BPB table With the varying media layouts OS/2 needs
to be aware of the location of the FAT's and directories before it reads them.
The device driver should read the boot sector from the specified buffer.  A
good ref that may help is Steve Mastrianni book page 77 (Writing OS/2 2.1
Device Drivers in C ).




!OTHER__________________________________**********
May 10, 1994
QUESTION: (Ref: B33)
I have a question RE:  how to determine what the names of the OS2 device
drivers that I have loaded on my system.  I have a card and a DLL from a mfg.
but the DLL doesn't work properly.  I want to open/read+write/close the device
myself.  However I need to know the device name.

Is there an easy way, or a utility around that can tell me this info??


ANSWER:
Use DosQueryFSAttach(using the Ordinal) approach (devicename=0,1,2,3,4,5...)
and it will return the device names.. installed.




!OTHER !VIDEO___________________________**********
May 10, 1994
QUESTION: (Ref: B03)
I am having trouble getting debug output to my debug terminal via my IBMXGA32
driver.  When I build the debug version of this code it inserts calls to
DebugOutput.  This macro is resolved to make a call to Debug32Output.

I have stepped through the call in the the KDebugger to verify that the call
is being made but nothing appears on the Debug Terminal's screen.  I tried
installing the debug version of PMDD.sys but all this does for me is beep
during processing.

I have been able to get output from the debug version of the vxga.sys VDD and
my debug terminal works so I must be missing a set some where.  What else is
required to be able to get output from my video driver DLL?


ANSWER:
If we look at the debug routine code (defined in edddebug.c) the routines dump
output to the debug terminal only if the variable DebugOn is defined.  We need
some minor changes in the makefile.  Define EDD_DEBUG and XGADEBUG in the
makefile under the debug section.  When you do the debug build you should see
these variables defined for the compiler.  After building this version you may
verify the presence of the variable _debugOn in the map file.  This should
enable the output if everything else is fine.




!OTHER__________________________________**********
May 10, 1994
QUESTION: (Ref: A87)
The list of interrupt numbers and I/O address that the PCMCIA card will
support can be read from the card.  In order to do this my Client Services
driver needs some buffer space to read in the tuples.

In my "connect" subroutine I used the DevHlp_AllocPhys & DevHlp_PhystoUVirt to
get the scratch area I needed.  This works fine when the "connect" routine is
called during the Init Complete time, but when it's called from my Call Back
entry (Card Insertion) it bombs.  My guess is the Call Back occurs during
interrupt time.

The short term solution was to put the buffer into the code which is wasteful.
Is there a way to allocate the memory, use it, and then deallocte.


ANSWER:
It is true that the client services driver is always called back from the
current card services driver (PCMCIA.SYS) at interrupt time.  This is a known
problem.  Especially if the customer's client driver is a fax/modem driver and
the machine has only 4-8 MB memory, it causes a swap problem as well.

There is a new PCMCIA.SYS which fixes the above problem that may be available
by request.  Last month, we sent the new one to the customer who had a swap
problem.  The new version always calls the Call Back entry in the client
driver at task time.  If the customer can run his/her driver with this new
version of PCMCIA.SYS, the problem he is having will not happen.  But the new
PCMCIA.SYS may have dependencies on other socket services drivers.  A beta
version of this should be available on the IBM bulletin board in April -
(919)517-0001.

If the customer does not want to get this new version, he can fix the problem
inside of his own code.  There is another solution using the DevHelp,
AllocateCtxHook and ArmCtxHook functions.  The customer can put the function
or procedure to be at task time in to one subroutine.  and call it through
ArmCtxHook at interrupt time.  The subroutine will be called at task time.
Also, when the allocated memory is used beyond the context, I suggest to use a
GDT selector, not LDT.  In the customer's case, Devhelp, allocGDTSelector and
PhysToGDTSel are used.




!OTHER__________________________________**********
May 10, 1994
QUESTION: (Ref: A36)
I have a question on my VDD.  I allocate an event semaphore in
much the same way as is described in the Question and Answer file. That
is, it blocks waiting for a sem posting from the DOS side, then copies some
info and continues.

Problem is, that if the DOS session is closed, the semaphore is released
and the data that I wish to copy is no longer committed.  Most of the time
it is adequate to test whether or not the VDHWaitEventSem returns TRUE to
see if the data can be touched without a system page fault halt.  BUT,
there are times when the semaphore has returned TRUE and I still fault when
touching the data.

Question .. Is there any way, given the HVDM to tell whether the session
is active at task time.  That is, that dereferencing data via the
*(DATA *)(PBYTE(xxx) + hvdm) will not fault?  Thanks.

Here is more description of the scenario.  I hook notification at create and
terminate of VDD.  I also have a registered entry point that I call from an
OS2 side application.  The OS2 side makes a call into the VDD for service.
The particular DOS VDM that needs to respond to the request is out of context,
so the call originating from the OS2 side dos a VDHWaitEventSem to hold for
the VDM response.

In the meantime, the VDM is killed by the user.  During this process the
event sem is cleared, releasing the OS2 thread.  BUT .. it doesn't know that
none of the data it has access to (biased by the HVDM handle) is no longer
valid.  The Event sem can actually return success under these
conditions.  So ... what I need to be able to do, is to dynamically determine
if the particular vdm handle is still valid, or alternatively whether its
allocated data is committed before I try to access it.
Im not sure what the ref number of the QA file is.  I downloaded all
QA files on this BB and concatinated them into one file for searching.
All I can say is that the info I have comes from this BB.

The Semaphore is allocated within and associated with a particular VDM.
There may be more than one VDM active each with its own blocking semaphore.


ANSWER:
During VDM termination the VDDs termination handler could set some flag
in VDD global memory, one per vdm, signifying that the vdm has terminated.
Now, each time the semaphore is posted the thread returns to the OS/2 app
which immediately calls back into the VDD to see if the VDM is still
there before trying to access the data based on the HVDM. The VDDs termination
handler will get called before the normal process termination causes the
semaphore to be posted.




!OTHER__________________________________**********
May 10, 1994
QUESTION: (Ref: A33)
We would like to provide (in our video driver) information that the SYSLEVEL
command can display so that we can easily determine the installed driver
version.  What is the right way to do this?


ANSWER:
The Application would create an SYSLEVEL.XXX file probably through the Prf
APIs and would embed for example the application name, the version, the
component ID, type, current CSD level, and prior CSD level into the
SYSLEVEL.XXX file.  The Syslevel command will pick it up and display the
level.  Please note that the intended usage of this facility is towards
PRODUCTS and not individual components or drivers.  The Prf APIs I am
talking about are for example PrfOpenProfile(), PrfWriteProfileString() and
so on.




!BASE !OTHER____________________________**********
MAY 10, 1994
QUESTION: (Ref: 583)
I am trying to write a VDD which generates an interrupt 2 in a DOS session
whenever certain ports are written to.  So far, I am able to trap I/O calls
properly and generate an interrupt 2. My problem is that while the DOS
interrupt is active I do not want I/O calls to generate further interrupts
until the DOS interrupt handler returns.  I tried hooking IRET, but it crashes
the system when the interrupt is called.  Is there anything special I need to
do besides VDHArmReturnHook after VDHPushInt?


ANSWER:
He can use CLI,STI & RET assembly instructions to stop generating further
interrupts.  NMI-Disable portion of the address latch can be set or reset by a
DOS application.  However, changes to enable or disable NMI are otherwise
ignored.  He can look into vvideo\vvmode.c for an example of how to disable
and reset NMI .




!OTHER_________________________________**********
May 10, 1994
QUESTION: (Ref: 450)
I am having a strange problem with the code fragment below.  I am trying to
pass a pointer to an array in my test program to the device driver for my A/D
Subsystem.  It will work as long as I return up to but not more the first 3
Array values ( [0] [1] [2] ). If I try to send any more I get an Operating
System Crash.  I call the Device Driver via the API IOCTL but I also have the
same results if I call the Device Driver via a API DosRead.

In my Device Driver code I have tried with and without locking the memory, I
have tried filling the array in through assignments in a for loop (*p++ = val
[i] ), and I have used _fmemcpy and a assembly language MoveBytes routine all
give the same results 3 array values and no more.

 THIS IS THE CODE FROM THE TEST PROGRAM ...............

    HFILE   DevHandle;       /* Device handle specifies the device */
    ULONG   Category;        /* Device category */
    ULONG   Function;        /* Device function */
    PVOID   ParmList , DataList;  /* Command-specific argument list */
    ULONG   ParmLengthMax;   /* Command arguments list max length */
    ULONG   ParmLengthInOut; /* Command arguments length (returned) */
    ULONG   DataLengthMax;   /* Data area maximum length */
    ULONG   DataLengthInOut; /* Data area length (returned) */
    APIRET  rc;              /* Return code */

    short        ival [4000];

    Category = 0x83;
    Function = 0x1;
    DataList = ParmList = ( PVOID ) ival;
    ParmLengthInOut = 10;
    ParmLengthMax = 10;
    DataLengthInOut = 10;
    DataLengthMax = 10;

    rc = DosDevIOCtl ( ad , Category , Function , ParmList ,
                        ParmLengthMax , &ParmLengthInOut , DataList ,
                        DataLengthMax , NULL );

 ============================================================================

THIS IS THE CODE FROM THE DEVICE DRIVER ..........

    DEVICEHDR devhdr = {
                       ( void * ) 0xFFFFFFFF ,
                       ( DAW_OPN | DAW_LEVEL1 | DAW_GIO | DAW_CHR ) ,
                       ( USHORT ) STRATEGY ,
                       ( USHORT ) 0 ,
                       "DT2812$ "
                       };

        case RPIOCTL:

            AdData = adBuffer;
            TotalBytes = 0;

 ......  Start A/D SubSystem on Interrupts

            Block ( ( ULONG ) ReadRP , 1225L , FALSE , &i );

 ..... I've Tried with and without the Verify, Lock, and Unlock

            if ( VerifyAccess (  SELECTOROF ( rp->s.IOCtl.parameters ) ,
            OFFSETOF ( rp->s.IOCtl.parameters ) ,
                 sizeof ( int _far * ) , 1 ) )
                      return ( RPDONE | RPERR | ERROR_GEN_FAILURE );

            if ( LockSeg ( SELECTOROF ( rp->s.IOCtl.parameters ) ,
                  1 ,          /* lock for < 2 sec      */
                  0 ,          /* wait for seg lock     */
                  ( PLHANDLE ) &lock_seg_han ) ) /* handle */
                       return ( RPDONE | RPERR | ERROR_GEN_FAILURE );

            pint = ( short _far * ) rp->s.IOCtl.buffer;

 ...... Tried direct equates in a for Loop, MoveBytes, and _fmemcpy

            /*MoveBytes ( ( FARPOINTER ) adBuffer , ( FARPOINTER )
            rp->s.IOCtl.buffer , 6 );*/
            _fmemcpy ( pint , adBuffer , 8 );

            if ( UnLockSeg ( lock_seg_han ) )
                return ( RPDONE | RPERR | ERROR_GEN_FAILURE );


ANSWER:
He should try to lock the buffer(data packet) in the request packet and use
the GDT selector.  Then he does not need to do anything about the area from
the application.  There is an example of this in
ddk\src\dev\dasd\ibmscsi\scsubrs.c.




!OTHER__________________________________**********
May 10, 1994
QUESTION: (Ref: 316)
I am trying to make a DosDevIOCtl call from a C/Set application.  What I did
was to copy the call as documented in the "Information" folder Example Code,
and placed this into my code.  I made the following changes.

        Ad - is a Structure which sets up the parameters needed for
             the A/D both Setup and the data buffer area to pass back
             the results.

            Function = 0;
            ParmList = ( PVOID ) &Ad;
            ParmLengthInOut = sizeof ( Ad );
            ParmLengthMax = sizeof ( Ad );
            DataLengthMax = 0; ***** This I changed from 200
                                     but left the data Definition
                                     for DataArea [200] alone ******

            Call DosDevIOCtl

With DevHandle = ad which is a ( HFILE ) returned from the DosOpen of the
Device Driver for the A/D ( which gave a 0 return showing that it opened
without error ).

I get error 87 ERROR_INVALID_PARAMETER.


ANSWER:
DataLengthMax and the size of the DataArea have to agree, otherwise the data
will be lost or incorrect.  I think either the CP Ref.  or the CPGREF1.INF
(from OS/2 2.1 Toolkit) give a very detailed description about this function.
call.



=================== Administrative Stuff ===================
________________________________________**********
May 27, 1994
