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

!OTHER__________________________________**********
SEPTEMBER 23, 1994
QUESTION: (Ref: FA2)
I am trying to use the Kernel Debugger. I did not find the Terminal Program
that is supposed to run on the second machine (the first machine is the one on
which the device driver is running). It is not in the OS/2 Toolkit either.
How can I obtain it it? Can other program's like Procomm be used instead?


ANSWER:
I am assuming from your question that you are using a system as your debug
terminal, rather than a dumb ASCII terminal.  That's OK.  If you used an ASCII
terminal you wouldn't be needing a terminal program.

If you are using a system, any communication package that supports terminal
mode can be used. You asked about Procom. That should be fine.

There is another choice that will work very well. The DDK contains a terminal
emulater called DEBUGO (DDK\MISCTOOL\DEBUGO). To find out more about it, look
at the "Using Your DDK" manual on the DDK. Select the "Components and Build
Requirements" section. Scroll down to Miscellaneous/Other Tools, Debuggers,
DEBUGO. Double click on the blue DEBUGO.

There is also a file (DEBUGO.REA) on the DDK, in the path shown above, that
gives more information.




!OTHER__________________________________**********
September 23, 1994
QUESTION: (Ref: F72)
I am writing a device driver in assembly language and I want to use
DosPutMessage to display a message when it is installed.  How can I call this
system function from assembly language (without libraries).  Isn't there some
int call or something I can make with registers set a certain way to do this
(like DOS)?


ANSWER:
If you are using DosPutMessage, you have to use any one of the following
libraries:

              ddk\lib\os2386.lib   (for 32 bit code)
              ddk\lib\os2286.lib   (for 16 bit code)
              ddk\lib\doscalls.lib

You could use it in the following manner (for the 16 bit code)-

              EXTRN DosPutMessage:FAR
              INCL_DOSMISC EQU 1

              PUSH  WORD FileHandle      ; Handle of output file/device
              PUSH  WORD MessageLength   ; Length of message buffer
              PUSH@ OTHER MessageBuffer  ; Message Buffer


              CALL  DosPutMessage

If you are using the 32 bit code do appropriate 32bit PUSHes for the
DosPutMessage parameters.

If you would like to do it the DOS way, you have to have your own Virtual
Device Driver and hook the DOS Interrupts.




!STORAGE________________________________**********
September 23, 1994
QUESTION: (Ref: F68)
We have developed a parallel port based IDE adapter.  The ADD driver for this
adapter works well with OS/2 2.1.  With OS/2 2.11, if I attempt to access the
HPFS partition on the drive connected to the parallel port IDE drive the
system hangs.  If we use the HPFS.IFS file that comes with OS/2 2.1 (file size
129090 and date stamp 04-29-93 8:25p) under OS/2 2.11 we do not see this
problem.

What do we need to do so our driver will work with HPFS.IFS file that is being
shipped with OS/2 2.11 (file size 133698 date stamp 01-28-94 11:23p).

Also please clarify if it is OK to pass 'Adapter Flags' as Zero and
'MAXCDBTranserLength as 64*1024 for ADD Device configuration call.  We notice
that with the values mentioned above the problematic HPFS.IFS issues calls to
the ADD driver with 1 SGLIST as per MAXHWSGLIST value.  After the ADD
completes the request and returns, it does not receive further packets.  In
other words, the system hangs.


ANSWER:
By downloading the latest HPFS.IFS file, both problems were solved.  But as
general info, the Adapter Flags indicate that <16MB Address is supported & the
Device Driver is emulating the S/G function in software.  Commands received
from SCSI.SYS device class drivers will require a min of 16 S/G Elements.  If
OS2SCSI or OS2ASPI device managers receive an S/G List that does not conform
to the Adapter Device Driver's S/G requirement,these device managers will
reject the request.




!BASE___________________________________**********
September 23, 1994
QUESTION: (Ref: F63)
We need to allocate contiguous memory in process address space.  The memory
would ideally be page aligned.  Right now, we issue 2 vmalloc's:

1. vmalloc fixed, contiguous, below 16mb memory in global address space.
2. vmalloc process address space to the physical address obtained from above.

Q1: How can we get the memory aligned?

A1: Memory requested in process space can only be swappable.  Allocate the
    memory in global address space and call VMGlobalToProcess to make it
    accessable to the app.
==============================================================================

Q2: Is there a way to allocate memory as stated above with one
    further restriction: it does not cross a 64K boundary. We need to
    allocate 32K buffers and do DMA's into them.  Ideally, the
    addresses could be obtained such that a single dma could transfer
    all of the data without having to worry about wraps.  Keep in
    mind the memory needs to be in process address space.

A2: Currently it is not possible to request 64K aligned allocation
    from the OS/2 Kernel. The paged linear memory model supports
    aligned allocation only for 4K pages. The DMA code has to check
    if the contiguous memory crosses 64K and if so, split the block
    into two and perform data transfer twice.  Because the pages
    themselves are aligned on 4K boundary, the performance penalty
    would not be as severe as in the case of byte aligned allocation.

    Another way, if memory is not a big concern, is for the device
    driver itself to maintain a big chunk of memory (say 256K) and
    meet allocation requests out of this pool.  The allocation and
    freeing algorithms in the driver can ensure that no allocated
    memory crosses 64K boundary.  In any case, as the customer has
    pointed out rightly, the user application cannot allocate memory
    using VMAlloc directly.  The allocation has to be done thru a
    device driver only (global->process).




!I/O____________________________________**********
September 23, 1994
QUESTION: (Ref: F61)
An issue concerning KEYBOARD.DCP arose during our testing with the WARP Beta
II of OS/2.  Our program finds KEYBOARD.DCP by searching for it on the path.
This has been fine in the past since KEYBOARD.DCP is installed in c:\os2 which
is on the path.

However, starting in WARP Beta II, KEYBOARD.DCP is installed in c:\os2\boot
which is not on the path.  It is only referenced in the DEVINFO statement:
DEVINFO KBD,US,C:\OS2\BOOT\KEYBOARD.DCP.  Is there a mechanism for finding
KEYBOARD.DCP based on the DEVINFO statment.  In the meanwhile I will always
look in the /os2/boot directory.  However, does a method exist which is more
immune to future changes.  Say, a way to get the info from the DEVINFO
statement (other than parsing config.sys myself).


ANSWER:
The portable way of getting to the KEYBOARD.DCP file is through the pathname
specified in the DEVINFO=KBD,...  line in the config.sys.  The file being
accessible through the PATH setting is purely coincidental.  The simplest way
currently is to parse the config.sys file for this setting to get the
pathname.  You could use Category 04h Keyboard IOCtl Commands,Function 7Bh -
Query KeyBoard Code Page Information to get the Code Page to which the
Keyboard is initialised.  To get to KEYBOARD.DCP you have to parse the
CONFIG.SYS Line.  The other alternative is to use the DosFindFirst API - to
find the first file object that matches your specs.




!NETWORK________________________________**********
September 23, 1994
QUESTION: (Ref: F59)
I am experiencing a problem with our NDIS 2.01 Token Ring driver under LSP
1.35 /LS 3.0. When we have heavy insertion/deinsertion activity, our hardware
sometimes has an unusually long transmit confirm from a transmit chain, and
sometimes the transmit gets lost altogether. I have tried the START_RESET /
END_RESET status calls to notify the protocol stack of the problems, but I
end up getting a NET810 error.

What is the recommended method for a MAC driver to notify the protocol stack
that a transmit has been delayed or lost, or that the adapter needs to be
reset?


ANSWER:
In my opinion, the best way to notify the protocol stack that the adapter
needs reset is with the StartReset/EndReset calls.  The problem is that when
the LSP protocol driver DXME0MOD.SYS receives the StartReset call, it closes
down the 802.2 interface and calls the application with an Adapter Check
status.  When the NETBIOS driver, DXMT0MOD.SYS, gets this Adapter Check
status, it closes down the NETBIOS interface and requires an NCB.RESET to
start the NETBIOS interface back up.  DLR does not issue an NCB.RESET and
therefore, DLR does not recover from the StartReset call.




!OTHER !STORAGE_________________________**********
September 23, 1994
QUESTION: (Ref: E44)
I am writing a .ADD file and need to recieve notification of system shutdown.
I looked at messages comming into the stratagy 1 entry point and the only
message I recieve is th 1Bh for initializing the .ADD.  How do I get a
shutdown notification.  This is a driver for a disk subsystem with on board
cache and I need to be sure the cache is flushed before I allow anyone to
reboot or power down.


ANSWER:
A device driver is called with the System SHUTDOWN request packet only if it
is a Level 2 device driver or if it is Level 3 Device Driver and has turned on
the SHUTDOWN support flag of the Capabilities Field found in the Physical
Device Driver Header.  Check your Device Attribute Word in the Device Header.
Also make sure that the INIT goes through successfully.




!I/O____________________________________**********
September 23, 1994
QUESTION: (Ref: F43)
After the EXE header there is the device driver header.  Inside here is the
device name, a la MOUSE$, etc...

What I need to do is find the offset to the beginning of this name given only
the object code.  I have documents to the structure of the device driver
header, but it is the EXE header that is throwing me off.  We are lead to
believe that the differences between a DOS/Windows and OS/2 EXE header are the
complication.  I understand that the beginning is just like a DOS header...
but I think that there is an OS/2 specific header appended to the end.  Could
you provide some structure, so that we can figure out the size of this, with
the ultimate goal of getting the offset of the beginning of the device driver
header so we can further get to (the really ultimate goal) of getting the
string such as MOUSE$, etc to figure out if an executable is a driver for a
certain thing?

I would also appreciate any information that I can get about the possibility
of implementing the following procedure:

Is there a way, API call, etc to query the current running MOUSE$ driver to
get a return of the filename that was loaded for the driver?  If not fully
qualified with pathname, etc, a base name would be better than no clue at all.
Point being that a third party manufacturer might not call a mouse driver
MOUSE.SYS.


ANSWER:
The contents of the OS/2 EXE Header are documented in certain standard
references like Advanced OS/2 Programming - Ray Duncan.  The important thing
is that the EXE Header is 512 Bytes long, hence the Device Driver Header is at
an Offset of 200h (512 bytes).  The Device Driver Header is located starting
from offset 200h.  There is no API Call to query the current driver to get a
return of the filename that was loaded for the driver.

FOLLOW-UP QUESTION:
Here's the problem I am having with the physical device driver header (my
example is using a regular MOUSE.SYS that I compiled from the DDK.)  At offset
3Ch (old .EXE header) I get the offset of the new .EXE header.  It says 80h.
I go to 80h and then offset 22h from that (to A2h) to get the offset to the
segment table.  This tells me 40h.  This 40h is from the start of the new .EXE
header, and from the start of the file, it is C0h.  I read a double-word in
the segment table that tells me the "offset of beginning of segment within
file."  I read 0011h (doule-word.)  This value is multiplied by the "size of
file alignment unit", which is at offset 32h from the start of the new .EXE
header (which is a power of 2...)  The value I read at 0B2h (which is offset
32h from 80h, which is the beginning of the new .EXE header) is 04h.
Therefore 2 to the 4th power = 16.  Therefore I multiply 011h by 010h and get
0110h.  This is the actual address that the first segment is at (and the
exehdr utility confirms this.)  Now...  here's the problem:

  At this address, where the PDD header should be (and is... almost) I get
  an initial 4 bytes reading 01-00-51-01 BEFORE the PDD header starting
  with FF-FF-FF-FF (being the -1 to initialize to) ... etc....

The meat of this question is:  What are these initial 4 bytes?  I can not find
them documented anywhere...  and they do not appear in certain dumps.
KBD01.SYS does not have the initial 4 bytes.  Our driver we are developing for
a mouse has an initial 4 bytes reading 01-00-30-01 (0001:0130 ??)


FOLLOW-UP ANSWER:
Please check the attribute flags for the segment table entry.  For mouse
driver it is ITERATED.  This means that the first word in the segment entry
contains an iteration count and the next word contains the size of the record
being repeated.  These two words are followed by the actual segment contents.
The keyboard driver is not ITERATED and contains the segment values directly.
Please refer to the header TOOLKT21\C\OS2H\NEWEXE.H that is supplied with the
TOOLKIT for details about the struct new_seg and struct new_segdata
definitions.




!STORAGE________________________________**********
September 22, 1994
QUESTION: (Ref: F38)
I'm working on a split-level IFS that performs caching on a network client.
The 'daemon' provides local and network disk access for the FSD.

I'm not quite sure that I understand the memory management architecture
completely, so please point out my errors as they become apparent.

I intend to use the VMxxx DevHlp functions as they appear to be what I need to
manage the cache.

The sequence would appear to me as follows:
1. Application issues DosRead -> results in entry at FS_Read (file already
   opened)

2. If data is not in cache, thread VMAllocs sufficient memory in Global space.

3. Thread awakens daemon thread, which calls VMGlobalToProcess to bring this
   memory into it's LDT.  App thread then blocks.

4. Thread converts the linear address to 16:16 and passes it back to daemon in
   FSCtl buffer.

5. Daemon issues DosRead to distant file, places data in address returned in
   buffer.  Then returns via DosFSCtl.

6. Thread then clears mapping via VMFree and awakens App thread.  Data is now
   "in the cache" and available for apps.

7. App thread gets the data via VMGlobalToProcess and returns to the app.

I'm most concerned by #7 because the mapping is never cleared.  Also, I'm not
sure whether the data passed in a mapping is a 'copy' or is, via address
translation, the 'original'.

Is this sequence proper operation for a caching FSD?

Should #7 be replaced with something akin to memcpy?

Is all of the above nonsense?

ANSWER:
Regarding #7, the mapping is just a translation between address space.  The
process pointer points to the original and not a copy.

If the driver code does a VMAlloc for every request, it is better to copy the
data returned by the daemon thread into the buffer passed in the READ ioctl.
The lookup operations for caching are not described in the question, so I
would hazard a guess as to the sequence of operations :

     1. The driver can keep a pool of memory blocks in global space
     2. When a request comes in, look up caching tables and return data
        if it is already in the 'cache'. Otherwise, get a free chunk from
        the memory pool or if that is not available, by discarding old
        data from the cache.

     3. Pass a global address to the memory block to the daemon to fill it up
        and wakeup the driver.  The driver can then 'COPY' the data to the
        application buffer (process space) and return.  Existence of the
        cache in global space is transparent to the application and therefore
        it is not advisable to pass pointers to the global memory.

An excellent discussion of the memory management techniques can be found in
the book 'The Design of OS/2' by H.M.Deitel et.  al.  (Chap 6.0).




!PRINTER________________________________**********
September 23, 1994
QUESTION: (Ref: F30)
We are developing an application to talk to some hardware connected to the
parallel port.  Our hardware looks like a printer as far as the interface is
concerned.

We have tried using the standard printer driver, as well as writing our own,
and in both cases experience long delays (up to 4 seconds) in writing to the
device.  The delays are intermittent, so that we might write 2 or 3 Kbytes to
the display, and then we see a pause, then it starts back up again.

We are running full screen (no PMSHELL) and have tried just doing a copy of
config.sys to either the printer device driver, or to our device driver with
the same delay problem.  No other processes are running, so we need to find
out what is holding up the device for those times.  We have also written an
interrupt driven program under DOS to write to the same device, and it runs
forever with no delays, so that would tend to rule out hardware.  To add to
this, we have written a fairly simple device driver that grabs IRQ5 and
handles outputting to the printer port.

With PRINTO1.SYS loaded, we saw the same delays with our device as we did when
talking to LPT1.  We then removed the PRINT01.SYS driver, and found that we
had no delays when outputting to our device driver.  This will work as a
temporary solution, but it appears that PRINT01 is still looking at LPT2 even
though we registered our device on IRQ5 with no sharing.  If there is an easy
way to tell PRINT01 to only look at LPT1, that may resolve the problem.  We
know the cable is not the problem.


ANSWER:
You could install your own Device Driver which has a Header that matches the
Printer Driver LPT2.  Inclusion of your own device driver in the DEVICE=
Statement in the CONFIG.SYS will cause a DeInstall command to be processed for
the currently installed LPT2 ( thus giving up the IRQ5 from LPT2).  Ensure
that in your Device Driver you register you Interrupt Handler using the
DevHlp_SetIRQ.  The LPT2 Header is specified in
\ddk\src\dev\printer\prtddtsk.asm




!NETWORK________________________________**********
September 23, 1994
QUESTION: (Ref: F27)
I would like to implement an error message in my ndis 2 driver a run-time (for
the cable disconnect case) and a "wait for a key " pause after the message.  I
have some error messages going on the screen at init time as far as driver is
at ring 3 at this time but I don't know how to do it at run-time, from ring 0.
Is it possible?


ANSWER:
There is a API interface for LANMSGDD.OS2 device driver that may be what you
are looking for.  I have seen it popup a message before.  But am not sure it
does exactually what you want.  Try this experiment.  Load IBMTOK.OS2 on Token
Ring.  And run some protocol that uses it ie Netbios, or 802.2...  Then unplug
the Token Ring cable from the MAU.  You should see a message shortly about a
Lobe-Wire Fault.  I beleive that IBMTOK uses the Ring 0 LANMSGDD.OS2 driver to
display this message.


FOLLOW-UP QUESTION:
I have two problems with the suggestion to use lanmsgdd driver to display an
error at run-time from ndis 2 OS/2 driver:

1. The interface to lanmsgdd driver is not documented (At least I did not find
it on DDK or elsewere)

2. This solution will not work on IBM OS/2 1.3 (Some customers of ours still
use it) and lanmsgdd is not always present on the system (if I'm not mistaken,
it is part of Lan Server, isn't it?)  What if I have Lan Manager on top of
NDIS-2 driver?

Could you think about more generic way to display an error message (cable
disconnect, for instance) from OS/2 device driver at run-time (from ring 0)?
There is a DevHlp call but for a basedev drivers only.  Also, could you point
me to some documentation/samples for the interface to lanmsgdd driver?


FOLLOW-UP ANSWER:
LANMSGDD provides a facility for device drivers and ring-3 applications to
display and log messages at run time.  Please download NDIS.ZIP from the DUDE
BBS, it describes how to do this, along with some other helpful information.
Also, LANMSGDD is in the LAPS poriton of NTS/2.  It is loaded when LAPS is
installed.  EE 1.3 does not have LANMSGDD, but LAPS can be loaded onto OS/2
1.3, and the function will work.




!I/O____________________________________**********
September 23, 1994
QUESTION: (Ref: F01)
1) What would I have to do to get a current cursor position in Presentation
   Manager (and perhaps a full-screen session), and even change it?  I've
   considered the GETCURPOS api call to get the cursor position.  What I need
   to do is possibly get a current cursor position and even change it.  I would
   need to do this from ring 0, using assembly code.  Are there any hints,
   perhaps, in the DDK code?  I've looked at process_absolute, and the calls &
   functions that it makes, and am wondering if you could point out a specific
   from either there or someplace else.

2) Is there a way in a driver to get a signal when the Presentation Manager
   comes up?  Perhaps in the same way that there is a signal that indicates
   when driver initialization completes?  For example, say you wanted to change
   a value such as mouse acceleration or button swap.  Without the PM up, you
   can not do this from the driver, correct?  Is there a work-around?


ANSWER:
1) At the Device Driver Level the Cursor Manipulation is done through
   GreGetCurrentPosition & GreSetCurrentPosition Functions.  You could browse
   through ddk\src\vga32\ibmdev32\cursors.asm & cursor2.asm.

2) There is no way a driver can get a signal when the PM comes up.  This is
   because,the sequence after PowerOn is Kernel gets loaded, Base Device gets
   loaded,DEVICE= gets loaded,RUN= gets executed & then the PM Shell comes up.




!I/O____________________________________**********
September 23, 1994
QUESTION: (Ref: E29)
I am using the KEYBOARD.DCP file to do my own translation from keystrokes to
ASCII characters.  New countries were added to KEYBOARD.DCP in OS/2 2.1, e.g.
Hungary, which use a slightly modified format.  In particular, the info for
each country used to be a fixed length 1251 byte record.  For the new
countries this record is variable length.  The new original format is
documented in the Physical Device Driver Reference under Generic IOCtl
commands, Category 04 keyboard, function 50h.  How can I get an update with
the correct documentation.


ANSWER:
We have been told that this documentation will be incorporated in the next
DDK.  In the meantime, you can download the file KEYBOARD.TXT from the DUDE
MAIN file area.  It contains the information you are looking for.




!STORAGE________________________________**********
September 16, 1994
QUESTION: (Ref: F57)
I've been looking with great interest at the extended diskette format on which
the warp II is shipped.  I know that the system is capable of
creating/reading/writing these things because my beta arrived as diskette
images and I had to make them.  We've been trying to use the standard diskette
ioctl's to 'talk' to these diskettes, and have had little or no success.  If
somebody could steer me in the direction of some documentation on how we could
co-erce our product to read/write this format just like xdfcopy.exe does, it
would be much appreciated.


ANSWER:
The original answer has been deleted due to an announcement that was made
after the answer was created. The following is the text of the announcement
internally posted by IBM.

============PSPINFO   PSP Information on OS/2, LAN Systems and DOS=============
Ametron Technologies, Inc. Announces XDF
October 18, 1994

  An OS/2 Warp V3 Floppy Disk Format That Permits IBM's 3.5" Disks
  To Hold 1.84M Bytes Of Formatted Data

TAMPA, Florida, October 11, 1994 ---AMETRON TECHNOLOGIES, INC.  announces
today that IBM has introduced a new media expansion software technology called
XDF (eXtended Density Format) integrated into OS/2 WARP V3.  XDF dramatically
increases the amount of formatted space available on floppy disks by 28%.
IBM's 3.5" floppy disk, which previously held 1.44 M Bytes of formatted data,
will now hold 1.84 MBytes of formatted data.  IBM is shipping XDF with OS/2
WARP V3 to simplify the installation process.  In addition, a special copy
routine is included to allow users to create back up copies of OS/2 WARP V3
using the XDF format.

AMETRON will make the XDF technology available to application software
developers to reduce the number of disks required to create their programs.
Software developers using XDF will benefit by reducing their manufacturing
costs to produce their programs.

"AMETRON is pleased to provide IBM with a new high quality disk format
solution as part of IBM's new advanced operating system known as OS/2 WARP V3"
stated Jon Gordon, President of AMETRON.

AMETRON TECHNOLOGIES, INC.  is a privately held company located in Tampa,
Florida.  The principals of the company include Jon Gordon, who was previously
President of Phoenix Computer Products, the BIOS and Publishing company and
Roger Ivey, the original author of Fastback and a founder of Fifth Generation
Computers.

For more information, contact AMETRON TECHNOLOGIES, INC, P.O.  Box 4870, Palm
Harbor, FL 34685; (813) 934-1920.

AMETRON TECHNOLOGIES is a member of IBM's Developer Assistance Program.

Contact:    Jon Gordon   (813) 934-1920

                             ###
OS/2 is a registered trademark of International Business Machines Corporation
XDF is a registered trademark of  AMETRON




!OTHER__________________________________**********
September 16, 1994
QUESTION: (Ref: F49)
The PCMCIA 2.1 specification indicates that the first logical PCMCIA socket
number is ZERO.  The docs on DDK 1.2 for the PCMCIA system do not explicitly
indicate what the first logical socket number is, but the sample fax/modem
client driver implies that it is ONE.

I'm working on a client driver now, and I need to know where the start of the
socket numbers I'll get from Card Services is.  So which is it, ZERO or ONE?


ANSWER:
We do not have access to the PCMCIA 2.1 Specs.  However, OS/2 does support
PCMCIA 2.0.  The first physical socket on the first physical adapter is
logical socket one (1).  The maximum logical socket is the total number of
sockets present.  PCMCIA.SYS supports Card Services of PCMCIA 2.0 and you can
go ahead with One as the starting logical socket number.




!OTHER__________________________________**********
September 16, 1994
QUESTION: (Ref: F41)
Is there any way to display an error message on the console from a device
driver's run time code?  We have a condition where during run time we can
experience a error condition and would like to notify someone.


ANSWER:
Use the DosPutMessage API - this sends a message to an output file or device.

    char Message Y" = "Hello World";
    DosPutMessage(1,strlen(Message),Message);

These instructions print the message on the STDOUT.  For further details refer
to the OS/2 Control Programming Reference.




!MULTIMEDIA_____________________________**********
September 16, 1994
QUESTION: (Ref: F28)
Can you supply a copy of what the IOCTL 140 functions are for video capture
devices?  I have the PC Video driver and am trying to comply with it's design,
but I am having some fun (?)  trying to figure out exactly what is required.
A detailed description of the IOCTL functions would help me.


ANSWER:
There is information on IOCTL 140 functions in the OS/2 2.1 MMPM/2 Device
Driver Reference Manual.  The manual is located on the DDK, but is also
available in hardcopy.  To order the manual, call 1-800-879-2755 and request
part# S71G-3678.




!PRINT__________________________________**********
September 16, 1994
QUESTION: (Ref: F23)
What level Postscript is the Printer Driver in Device Driver sourcekit version
1.0?  Does the latest version of the DDK for OS/2 include a Postscript Level 2
driver?  Is there a level 2 driver available anywhere?


ANSWER:
The Source Code of PostScript Level 1 is provided in DDK v1.0.  We have still
not released the PostScript Level 2 Device Driver.




!OTHER__________________________________**********
September 16, 1994
QUESTION: (Ref: F12)
After installing DDK, how do I compile source files.  In particular, I try to
compile files in c:\ddk\src\dev\dasd\ibm\ibm1s506.  Do you have a
set_environment command?  How about make_path command?  How to run nmake from
OS/2 windows?  Do I have to go into command prompt?  I copy cl.exe and cl.*
from DOS to OS/2.  Nmake reports error message to indicate that it does not
like this cl.exe.  Why?


ANSWER:
After installing DDK,make sure you have installed the Microsoft C v6.0 with
the OS/2 option.  Then execute the COPYC60.CMD -this takes care of copying the
relevant files from the Installed directory to the DDK tree.  You could run
nmake from the OS/2 command prompt after making sure you are in the right
directory.On executing nmake without any parameters,the "Makefile" in the
current directory is used as the make file and you should be able to build
your executable.




!STORAGE________________________________**********
September 16, 1994
QUESTION: (Ref: F06)
I'm working on my FSD and have a question.  I'm trying to detect if a new
FS_OPENCREATE is for a file that is already open.  I believe that I read
somewhere that the sffsi passed in is a per instance item and thus is unique
even if it is for an alraedy open file.  Is the sfi_selfsfn field of the sffsi
the same for all instances of the same file?  If not, is there an item
somewhere that will identify the file without having to parse the
path+filename?


ANSWER:
I don't think there is any way for the IFS to GET info that it's for an
already opened file.  You could SAVE info and compare, but the two instances
are unique.




!VIDEO__________________________________**********
September 16, 1994
QUESTION: (Ref: D98)
I'm trying to figure out how to implement dynamic display format changing for
my display driver.  Assuming I've managed to add a page to the system settings
notebook, how can I force the GRE to restart the display driver so that the
new display format takes effect?


ANSWER:
The SET_RESOLUTION command informs the 32-bit graphics engine of the initial
display resolution for the display driver being installed.  This command is
used only for display drivers that can support multiple display resolutions
and that use the DspDefaultResolution function to determine, during
initialization, which resolution to display.

The format of the SET_RESOLUTION command line is :SET_RESOLUTION.  The
parameters associated with this command are listed in the lines following the
SET_RESOLUTION command line.  Each parameter is specified as a <keyword> =
<value> pair.

The following lists the parameters that must be specified after the
SET_RESOLUTION command line.  All the parameter values in this list are
numeric values and are specified as parameter values in this list are numeric
values and are specified as unsigned decimal numbers.

     WIDTH          = <Width of the display resolution in pels>
     HEIGHT         = <Height of the display resolution in pels>
     COLORS         = <Number of colors supported in this display resolution>
     PLANES         = <Number of planes in this display resolution>

Following is an example of how to specify the parameters associated with the
SET_RESOLUTION keyword command:

      :SET_RESOLUTION
      WIDTH=1024
      HEIGHT=768
      COLORS=256
      PLANES=1




!STORAGE________________________________**********
September 16, 1994
QUESTION: (Ref: D59)
I've run into a problem with my API in a DOS box.  I have a custom Generic
IOCTL I/F (that works just fine from an OS/2 session) on my block device
driver.  From an OS/2 app, I use the DosDevIOCtl function with a handle to the
drive obtained by opening the physical drive.  When I try to do the
corresponding operation in a DOS box, the call does not come through to my
device driver.  I am using an INT21 440Dh function call.  When I looked at the
device header for the virtual block device driver (which apparently include my
logical unit(s) also), the device attribute is 0000.  This would seem to
indicate that no IOCTL's are supported.  Please clarify this point for me.  My
API relies on being accessible from either an OS/2 session or a DOS session.


ANSWER:
You are trying to do block mode I/O from a DOS box.  Block mode devices are
not supported by the DOS compatibility support in OS/2.  This is a documented
restriction.




!STORAGE________________________________**********
September 08, 1994
QUESTION: (Ref: F53)
We want to create an application for writing CDROMs via special hardware.
Do you know any system of that kind that is supported by OS/2 device drivers
and OS/2 software - if not is there any info on the CDROM support for OS/2
more than the DDK?  Specifically, the CDFS.IFS isn't documented there, and it
would be great to get help on that if we want to write a new one for
CDROM-writers.


ANSWER:
1. We are not aware of an OS/2 application that supports writing CDROMs.
However, that doesn't mean there is none. Posting this question on one of the
public forums (ie. CompuServe) would reach a larger audience. Possibly someone
out there knows of an OS/2 application to do what you wish.

2. There is no other CDROM information available on CDROM support other than
what is on the DDK. With regards to the CDFS.IFS, IBM is working to release
documentation at a later date.

The CDFS IFS would not help you accomplish what you want to do as it supports
read only, not write. To do what you want will require you to write an
application, an IFS, and a device ADD type driver. You can get information on
an IFS by downloading the following files from the MAIN file area of the DUDE:
IFS.ZIP and IFSSRC.ZIP.




!OTHER__________________________________**********
September 08, 1994
QUESTION: (Ref: F29)
I investigated the PCMCIA CARD services function.  INOUT.INF describes the
RequestWindow function, but it does not describe the input/output parameters.

DDK CLDFM has client.h and this file shows the RequestWindow parameter
structure, but the output parameters are not shown.

Where can I find these references?  Also, will this function get virtual
address (sel:off) or flat address?


ANSWER:
1. The complete documentation of the Card Service Function RequestWindow is
not available on IN_OUT.INF since this is not IBM Proprietary.  For details on
these functions, please contact:

                          PCMCIA
                          1030G East Duane Avenue
                          Sunnyvale,CA 94086
                          Fax: (408) 720-9416

This is also documented in the PCMCIA Specifications Section of IN_OUT.INF.

2. The Base Field points to the Physical Location in the System Address Space
to map Card Memory.




!VIDEO__________________________________**********
September 08, 1994
QUESTION: (Ref: F20)
I follow OS/2 DDK v1.1 source directory \DDK\SRC_S3 source code to update my
display driver bvhsvga.dll and svga.exe and new add for 640x480x64K &
640x480x16M resolutions.  During installation of the driver, if I select
either 640x480x16M or 640x480x64K resolution, the following message always
appears in the Display Driver Install screen:

                 "The file A:\VGA does not exist."

I can't find out which file does not exist.  If I select 640x480x256,
800x600x256, or 1024x768x256 resolution, they are installed successfully.

Does OS/2 v2.1 support Hi-Color & True-Color resolution?  Which driver do I
need to update in order to support Hi-Color & True-Color driver?


ANSWER:
The S3 display driver in DDK v1.1 supports the following resolutions/colors:

     640 x  480 x 256 colors
     800 x  600 x 256 colors
     1024 x  768 x 256 colors
     1280 x 1024 x 256 colors  (minimum of 2MB video memory  required)

This is documented in ddk\src_s3\s3disp.txt file.

DDK v1.2 includes a new, totally integrated video device driver for S3, 8514,
and XGA video accelerator cards.  This new driver provides up to 16.7 million
colors and takes advantage of 86C801/86C805 and 86C928 GUI hardware
accelerators.  The source code for this new driver is located in
\DDK\SRC\PMVIDEO and supersedes the previous release.

Make sure your board uses one of 86C801/86C805 and 86C928 GUI hardware
accelerators before going in for the S3 Driver.




!OTHER__________________________________**********
September 08, 1994
QUESTION: (Ref: F17)
If you want to do some profiling in a device driver, is there a way you can
measure it with a finer granularity than the standard 32Msec tick count?
Could you grab a finer granularity msec count from the global info seg?  And
if so, what's the resolution of that global info seg counter?  I see C/Set 2.0
has a profiler in it, and it can get sub millisecond resolution...  This is
the kindof thing I'm after - Is there anyway to do this at the DD level?


ANSWER:
There are two responses to this question.  Response#1 is based on a
Developer's Driver and is not part of DDK, the information was picked up from
the OS2DDRVR Forum.

1. A high resolution timer device driver (timer.sys) is available.  There was
   an article about it in the Fall '91 issue of "IBM Personal Systems
   Developer" by Derek Williams.  It accesses the 8253 counters and can record
   timer ticks down to 840 nanoseconds.  You can read from the driver via
   DosRead's which your driver can do at Init time.  Contact Derek Williams at
   Charlotte for the driver.

2. Currently there is no way of getting Microsecond resolution with the OS/2
   timer.  The only way to get timer interrupts faster than 32 milliseconds is
   to use a hardware timer card that supplies interrupts at a faster rate, and
   provide a physical device driver to field the interrupts thru
   DevHelp_SetIrq.




!OTHER__________________________________**********
September 08, 1994
QUESTION: (Ref: F09)
I have 2 things I want to do with the VDD and I'm not sure how to do them.

Q1. The first thing is how does a vdd get a unique System File Number?

    Background - My vdd talks to a pdd.  The pdd uses the system file number
    found in the generic ioctl (10h) request packet as a unique id.  I would
    like to be able to get a unique system file number and uses pass it from
    the vdd to the pdd when I open another channel.  The pdd would then store
    this id and would not confuse channels from the vdd with channels from
    normal dosopens.

A1. The system file number is the value which can be used to find the
    SFT(system file table entry) for the particular invocation of the DosOpen
    API.  The SFT contains such information as sharing values, device type,
    current index into the file etc.  File handles are kept on a per-process
    basis and are only good in the process in which they were created.  SFNs
    are a global resource which are associated to a particular process' file
    open but are kept in global memory.  The System File Number is a unique
    number associated with an Open Request.  With a successful DosOpen the
    System File Number is assigned by the Kernel and this can be verified in
    the Open/Close Request Packet.  After you do a VDHOpen you get a System
    File Number and this could be checked in the Open Request Packet.  When
    DosDevIOCtl is invoked with the relevant Device Handle , a Generic IOCtl
    Request Packet is generated with the corresponding System File Number as
    assigned by the Kernel.
    ==============================================================================

Q2. The second thing I need to do has to do with the interrupt vector table.
    The dos driver I am emulating allows a dos program to check if the driver
    is installed.  the dos program gets the vector from the interrupt table,
    goes to the interupt address specified by the vector table and then looks
    for a special signature in front of the vector code, for example:
    |S|I|G|N|A|T|U|R|E| interrupt code starts . How do I do this with a vdd?
    If I look at the vector table, I can see that when I do a
    VDHInstallIntHook call, the contents of the table change.  However I dont
    know what the contents mean.  I thought I had this working allocating some
    dos memory, writing the signature in the memory, and then hooking dos int
    21 function 35 and pointing to my allocated memory if the vector was my
    driver.  This worked fine in real mode, but in protected mode the dpmi
    code seems to bypass dos int 21 function 35 and just read straight from
    the vector table.

A2. The major functions of Software Interrupt Emulation are:
        VDHInstallIntHook
        VDHPushInt
        VDHARmReturnHook
      Try using all these functions.




!OTHER__________________________________**********
September 08, 1994
QUESTION: (Ref: D61)
I had a problem where under OS/2 2.1 in my PDD, the Block - Run mechanism
fails once in a while, even though I used the same ID (my driver has internal
tracing).  I moved this to os/2 2.11 and the system gives me a trap right
after the Run call The trap is number 0002.

What is trap 0002? What can I do to resolve it?

ANSWER:
TRAP 0002 - NMI INTERRUPT
    An NMI interrupt is generated by the system when a catastrophic
    error occurs.  There are four possible causes of this poblem.
    These are summarized below:

          110 error - system board memory parity error
          111 error - I/O channel check (adapter card error)
          112 error - watching timeout (may be hardware or software)
          113 error - DMA timeout (may be hardware or software)

Trap reports seem to follow the Intel exceptions fairly well.

This doesn't help much for a Trap 0002, but for the others:

The registers AX, BX, CX, etc are the values in those registers at the time
the exception occurred.

CSLIM, DSLIM, ESLIM, SSLIM are the maximum (minimum for SSLIM) addresses that
are valid for the segment descriptor in the register, i.e.  the segment limit
defined in the descriptor table.

CSACC, SSACC, DSACC, ESACC are the access codes from the segment descriptors.
The format for a data descriptor access code is
 |A|W|ED|0|1|DPL|P|     (DPL is two bits, the others are one bit each)
 ------------------
where A is the accessed bit
      W is the writable bit
      ED is the expansion direction bit
      DPL is the Descriptor Privilege level
      P is the present bit

The format for a code descriptor access code is
 |A|R|C|1|1|DPL|P|  (DPL is two bits, the others are one bit each)
 -----------------
where A is the accessed bit
      R is the readable bit
      C is the Conforming bit
      DPL is the Descriptor Privilege level
      P is the present bit

ERRCD, ERLIM, ERACC
Exceptions that might involve a particular segment push a error code onto the
stack.  If the error code is not zero, it is interpreted as follows:

  | EX | I | TI | INDEX       |
  -----------------------------

The EX (external) bit is set when the problem is not a task problem (usually a
system problem, not a software problem).

The I (IDT) bit is set if the INDEX refers to an interrupt gate descriptor.
If the I bit is set, ignore the TI bit, if reset the TI bit identifies the GDT
or the LDT as containing the problem selector (TI set => LDT).

The INDEX identifies the selector (if any) that is associated with the
exception.

ERLIM and ERACC are apparently the access code and limit for the suspect
selector.

CS:IP usually points to the failing instruction.  For some exceptions it will
point to the next instruction, and for some the CS:IP is totally unrelated.

Trap    exception            CS:IP pts to      error code
-----   ---------            ------------      ----------
 0       Divide error        failing inst          NO
 1       Single step         next inst             NO
 3       Breakpoint          next inst             NO
 4       Overflow            next inst             NO
 5       Bound chk           failing inst          NO
 6       Bad opcode          failing inst          NO
 7       Processor ext       unrelated             NO
         not available
 8       Double fault        failing inst          Yes (but it's always 0)
 9       Processor ext       unrelated             NO
         segment overrun
 A       Invalid TSS         failing inst          YES
 B       Seg Not Present     failing inst          YES
 C       Stack Exception     failing inst          YES
 D       General Protection  failing inst          YES
 10      Processor ext       unrelated             NO
          error

The reason that the TRAP 002 display doesn't help much is that it is not an
exception condition.  It is the NMI (Non-maskable interrupt) for the
processor.  This condition is raised whenever a piece of hardware places a
signal on the NMI pin on the chip and is used to report hardware failures.
Since the condition is not raised by the processor, the above information
doesn't mean much.  The executing instruction may have no relation to the
faulty memory.  (For example if the 80287 accesses memory and triggers a
parity error while running in parallel with the 80286, the CS:IP doesn't point
to the instruction that raised the NMI.)

General Troubleshooting procedure:

(1) Boot the Advanced Diagnostics and run all the diagnostics.  You are
looking for 2 things in particular:  memory errors and adapters that are not
known to the diagnostics.

(2) Assuming that the diagnostics find nothing (quite likely), remove all
adapters except the display card and the FD/HD controller, re-run SETUP (if
necessary), and try both cold and warm boots.  Warm boots probably work OK
now.

(3) Put back the other adapter cards, one at a time, doing the cold and warm
boot test after each.  Either you will find one of the conflicting cards, or
all of this activity will scare away the gremlins that were causing the Parity
2 (or other) checks.

                         ERROR CODES

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
CODES                      Description

113 DOS Internal Stack Overflow -- DOS error *not* POST or Diagnostics.  You
may be able to make the 113 go away by making a non-resident program resident
or install TTICK

110  (PS/2) Planar parity
111  (PS/2) I/O parity or 80286 type protect mode test
       -- POSSIBLE IMAGE ADAPTER error if (See 20000 series
       messages)  What 111 really means is that an NMI was signalled
       and the source was the IOCK line (on PC) or the CHCK line (on
       MicroChannel).

       On PCs, this was pulled by parity error detected on memory
       expansion cards. On MicroChannel PS/2s, there may be other
       cards which pull this error line active for other reasons. If
       you have a memory expansion card, this is very likely to be the
       source.

      The system BIOS cannot determine what card caused the problem.

      Possible fix -- replace 3 chip SIMMS with 9 chip SIMMS
      (especially for OS/2)

112  (PS/2) Watchdog time out or Test 80386 new extended
       registers
113  (PS/2) DMA arbitration time out or Test 80386 new
       instructions
       The hard disk drive may have to be replaced.  There is a
       Retain reference for the PS/2 model 55: H064377

NOTE:  "0002 1130" is basically a "211" error code, which is a memory error on
the planar.  The "3" indicates SIMM socket A2 (1=A1,2=B1,3=A2 etc) and the
last character ("0") gives the SIMM speed.  Alternately this could be a DOS
error -- see above on internal stack overflow.

The Service Aid Diskette (SADA) may be useful to determine whether the problem
was a 110, 111, 112 or 113 error.  Note, if a 112 or 113 error cannot be
resolved by hardware troubleshooting, software support should be contacted.
(Some operating systems do not support this Service Aid diskette).

Note:  Recent PS/2 Systems have serial and parallel ports with DMA
       arbitration.  If DMA arbitration errors are encountered
       during I/O opeations to these ports, changing the arbitration
       to another level, or to "disable" may correct the problem.




