This is file: 12_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________________________________**********
December 22, 1994
QUESTION: (Ref: FX5)
I tried to install C SET++ on a PC that had only 36 Meg of space on the C:
disk.  C SET++ is now partly installed and I would like to back out the
installation.

ANSWER:
By reinstalling CSET++ over itself, the choice for deinstall appears.





!OTHER________________________________**********
December 22, 1994
QUESTION: (Ref: FV2)
The watcom librarys were very usefull in that it helped me to get more than a
system crash.  I even did get some messages and a working (sample) DD.  Hurray
for that.  But now the sad part.  After trying very hard I could not get a
timer routine running other than trapping the system after passing the
timerpointer.

Is there any example on how to implement this and also implementing a irq
service routine?  This would greatly help me in understanding developing DDs.


ANSWER:
Check out Steve Mastrianni's book on Writing OS/2 2.1 Device Drivers in C, II
Edition.  Especially the sample serial driver listed in Appendix C (pgs 406,
456-7, 466).  Also \ddk\src\dev\atcom\atcom.asm in DDK v1.2 CDROM contains an
example of using SetTimer/TimerHandler at assembly level.  If you are using
the Watcom Compiler, you will also have to take into account the Naming & the
Calling Convention.  Watcom C prefixes an underscore character to the
beginning of the variable names & appends an underscore to the end of function
names during the compilation process.  We do not have any Watcom Sample
implementing the ISR.




!I/O________________________________**********
December 22, 1994
QUESTION: (Ref: FS9)
In DOS you can look at 40:0 for the com port addresses and 40:8 for the
parallel port addresses.  How can i look from my device driver for these
addresses.


ANSWER:
In OS/2 the COM & LPT Port Addresses are also at the same locations in the
BIOS Data Area (40:0 & 40:8).  The only difference is you have to access these
locations in the Protected Mode.  Refer to the Serial Communication Device
Driver Source Code in the DDK.  ATINIT.ASM contains the code that checks the
40:x Data Area for a Valid Port Address.  (DDKX86\SRC\DEV\ATCOM Directory).




!OTHER__________________________________**********
December 22, 1994
QUESTION: (Ref: FS4)
I need the debug kernel for the OS/2 Warp 3, GERMAN Version.  Can you help me?


ANSWER:
IBM does not release International versions of the Debug Kernel.  However,
since the _MRI files are not different, it is suggested that you use the U.S.
version of the Warp Debug Kernel.




!OTHER__________________________________**********
December 22, 1994
QUESTION: (Ref: FR8)
In version 1.3 of os2 one could use the DosCallback() function to call a
ring-3 function from a ring-2 function.  Is this still possible in os2 2.1?
If so how?


ANSWER:
The 16 bit function - DosCallBack does not have a 32 bit counterpart.  This
function existed because of the 3 Ring nature of the 80286 Privilege Levels.
The Linear Addressing Scheme supports a two level ( Supervisor/User )
privilege mechanism, which makes this function unnecessary in OS/2 2.x

This is explained in detail in "The Design of OS/2" - Deitel & Kogan.  Please
refer to the Chapter on Kernel Architecture - Section :  Kernel APIs




!OTHER__________________________________**********
December 22, 1994
QUESTION: (Ref: FR6)
Starting a second thread, then using it to output data.

We manufacture several multiport serial boards, both intelligent and
non-intelligent.  A customer has encountered a problem using one of these
boards.  His problem has been simplified to a short test that starts a second
thread and waits for it to output 2 bytes to a port and then terminates the
test.  The second thread is started with a '_beginthread' call, using a stack
size of '8192'.  This is done with the C-Set++ compiler v2.01.  The on-line
help says to use a thread size in multiples of 4k and a minimun of 8k.  The
on-line example shows a value of 8192 byte stack size being used.  When it is
done this way the test outputs 2 bytes when run on the system com port.
However, when it is run on our board, 8192 bytes are output on the port.

To confuse the issue we tried the same test on our other boards and their
respective drivers.  The results were the same for four different boards, all
of which are different architectures, indicating it is probably not a hardware
specific problem.  The drivers for these boards are all different also, some
of them being written in house and some written by external people, indicating
it is not a specific driver issue unless everyone involved made the same
mistake when writing the drivers involved.

The next thing that was tried was modifying the '_beginthread' call because
its stack size was the same as the failing number of bytes being written.
Sure enough the problem changed.  A stack size of 4096 or less yields a
correct output of two bytes.  The same is true for a stack size of 8193 or
above, including stack sizes of 12k, 16k and 20k, to follow the 4k increments
described in the on-line help for the call.  The failure of writing the wrong
number of bytes only occurrs when using a stack size of 4097-8192 bytes in the
call to '_beginthread'.

Next we tried replacing the '_beginthread' call with 'DosCreateThread'.  This
also fixed the problem, as the correct number of bytes were output on the
port.

I am now at wits end with this problem.  If the problem is with all of these
drivers, why does changing the stack size in the call to '_beginthread' or
replacing it with 'DosCreateThread' make it work?  On the other hand if it is
a compiler issue, which it appears to be, why does it work ok on the com port?

The customer has since jumped to the conclusion that it is related to the
compiler and 'OPTILINK' .


ANSWER:
I would be really nervous with a stack size of only 8K in a C++ function.
Your described symptoms look very much like those experienced when you run out
of stack.  Note the automatic ofstream object in testhost1().  It will eat up
a *lot* of stack.

BTW, our current recommendation is to make stack size a multiple of 64K.  With
the "lazy commit" behaviour of the OS, there is usually no additional cost to
rounding the stack size up to a multiple of 64K.

The big difference between DosCreateThread and _beginthread() is that
_beginthread will register the C/C++ exception handlers.  These can chew up a
fair amount of stack on thread termination.




!BASE !OTHER____________________________**********
December 22, 1994
QUESTION: (Ref: FQ5)
Could someone please explain to me the general architecture of OS/2 V2.1 and
above.  Specifically, the mode in which device drivers actually operate.  Is
it 16-bit or 32-bit?  If it is 16-bit, why?  I have read most of the
Mastrianni book and he gives no clear indication on this matter.  Also, I
would like to know how OS/2 WARP may differ so that I can take any precautions
that are necessary.


ANSWER:
1. "The Design of OS/2" by H.M.  Deitel & M.S.  Kogan is a suggested book for
information on the OS/2 2.x architecture.

2. The 16-bit device driver model utilized by OS/2 2.x is very similar to the
device driver model utilized by OS/2 1.x.  During the design of OS/2 2.x,
32-bit models were investigated but the gain in per- formance did justify
switching from the 16-bit model.

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

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




!BASE________________________________**********
December 22, 1994
QUESTION: (Ref: FP7)
How much stack does the routine called via SetTimer have?  Is there any way to
get 4K?


ANSWER:
An 8KB Stack is provided by the System.  However the entire space is not
available to the Device Driver.  A portion of the Stack Space is used by the
Kernel and hence it is safe to assume that the Device Driver will have around
4KB of Stack Space at Task Time.  It is therefore important to keep the amount
of local variables at minimum.  You could achieve this by pushing some of the
local variables to the Data Segment.  The DevHlp_GetDOSVar could be invoked
with the Index for LocalInfoSeg for information on the Stack Size.  This could
be done either at Task Time or at Init Time.


FOLLOW-UP QUESTION:
Though your mail indicates an 8K stack of which 4K should be available.  We
have observed only a 1K stack.  Are you sure your answer is in regards to the
stack for the SetTimer routine that is called every 32ms?


FOLLOW-UP ANSWER:
The timer handler set by the SetTimer.  The system tick handler calls this
handler on every timer tick (this can be modified using TickCount DevHelp).
In OS/2, interrupt handlers run off a separate stack that starts at 8K.  All
interrupt handlers share the same stack, so if there are nested interrupts
then the stack gets used up.  If you do find that your stack is only 1K when
your timer handler gets called, could you please send us the details of the
registers and the stack sizes.  You can get these values thru the kernel
debugger.




!STORAGE________________________________**********
December 22, 1994
QUESTION: (Ref: FP4)
Q1. What were the issues for NOT allowing the ASPI Device Manager to link to
a unit that was already allocated by another device manager?

Q2. Could a filter driver safely make it appear to the ASPI Device Manager
that none of the filtered devices are allocated during the ASPI managers
initialization?  If so, again, what are the issues?

Q3. Is there a way to determine which device manager is sending a request
buffer?


ANSWER:
A1. The architecture allows only ONE device manager to claim a device.  This
is the way it works.

A2. No.  A filter cannot cause the device to appear unallocated.  Only the
allocating device manager can do this.

A3. No, there is no way to determine the source of a request.  Note that a
request might come from a filter of a filter and NOT from the device manager
anyhow.




!OTHER__________________________________**********
December 22, 1994
QUESTION: (Ref: FN4)
Q1. We currently have drivers for our products for OS/2 2.x and we need to
know what we need to do to support both OS/2 Warp and OS/2 for PowerPC.  Our
products are networking (Token Ring, Ethernet) and communications (modem)
products for PCMCIA and the parallel port.

Does the Developer Connection DDK for OS/2 contain all of the tools etc.
necessary to develop drivers for OS/2 Warp?

A1. The DevCon DDK Version 1 contains the latest (Warp) level versions of
drivers from DDK Version 1.2 plus:

         Graphics PMI Support Package
         32-bit MiniDriver 2 Rasterizing Sample
         IDE CD-ROM Driver
         Socket Services Sample
         Layered Keyboard
         AD1848 Codec
         PCVideo Capture
         Audio Interface
         Vendor Specific Driver (Ring 3)
         DBCS PMVideo
         Test Certification Suite
         Device Driver Conference Proceedings
         Writing OS/2 2.1 Device Drivers in C (online)

The Certification Test Suites contains a set of test tools and test cases to
help you test various device drivers.  These tools and test suites includes
PCMCIA ,I/O etc.  There are no additional Compilers/Assemblers, than what was
available on DDK v1.2.  Devcon DDK Version 1 has all the tools necessary to
develop drivers for OS/2 Warp.
==============================================================================

Q2. Are drivers for OS/2 2.x compatible with OS/2 Warp or will new drivers
have to be developed?

A2. Drivers for OS/2 2.x are compatible with OS/2 Warp and new drivers need
not be developed for WARP.

OS/2 Warp introduces a centralized Resource Management Architecture to
facilitate the coexistence & cooperation of the increasing number of device
drivers.  With the introduction of this architecture, a functional line has
been drawn separating previous device driver capabilities and those of the
OS/2 device drivers written to use the Resource Manager Services.  Device
drivers written to use the Resource Manager Services are referred to as
RM-Aware drivers.  Existing OS/2 2.x device drivers are referred to as legacy
drivers.  Both types of drivers are supported on OS/2 Warp.
==============================================================================

Q3. Are these drivers compatible with OS/2 for PowerPC?

A3. The drivers are not compatible with OS/2 for Power PC since the Device
Driver Architecture is slightly different (ADD32).
==============================================================================

Q4. Is networking support for OS/2 Warp available yet?

A4. LAN Server 4.0 is currently available and is supported on WARP. The OS/2
Warp BonusPak includes P2P (Peer To Peer Communication) & Compuserve
Information Manager for Internet Access. IBM OS/2 Warp LAN Server
Connectivity Solution 3.0 is scheduled for release sometime next year
('95). For further details on these contact Warp Technical Support.
==============================================================================

Q5. When will the tools for developing drivers for OS/2 Warp and OS/2 for
PowerPC be available?

A5. Tools for developing drivers for OS/2 Warp is available on DevCon DDK
Version 1. Tools for developing drivers for OS/2 for PowerPC will be available
on the WorkPlace OS DDK scheduled for Mar.'95.




!NETWORK________________________________**********
December 22, 1994
QUESTION: (Ref: FL2)
I have written several NDIS MAC drivers and protocol drivers for OS/2 and Dos.
My product additionally has a Ring 3 application component that talks 802.2
LLC to an IBM bridge (the IBM Token-Ring Network Bridge program, or an 8209).

I have successfully connected to the bridge and can execute most of the
commands documented in my IBM Token Ring Network Architecture Reference
(SC30-3374-02).  I have problems executing the Set Bridge Parameters command.
I can use every subvector of this command except Notification Interval.  When
I use this, the bridge returns me an 0x8503 specifying and invalid subvector
value.  He points out the value in my Notification Interval subvector.

I have tried several combinations of subvectors and values to no avail!


ANSWER:
The notification interval must be a multiple of 60.  The lowest value is 1
minute (send a value of 60 for 1 min).  You get an error if its not.




!STORAGE________________________________**********
December 14, 1994
QUESTION: (Ref: FT6)
I'm writing an IFS that exchanges data with an application-level "daemon"
through the FS_FSCTL interface.  I run OS/2 v2.11.  The daemon is compiled with
CSet++ v2.1 with all current CSDs and the FSD is compiled with MS C v6.0a.
When the daemon calls DosFSCtl, I set the DataArea parameter to &Buffer (Buffer
is a struct of 330 bytes).  When I step through the code(using asdt32)
&Buffer==12fe84 as it leaves the daemon but when FS_FSCTL receives it, it has
become 97fe84.  Something is causing the high 16 bits to get trashed between
the application and the FSD.  I have also tried setting ParmList to &Buffer
with the same results.  Is there something I can do to fix or work around this?


ANSWER:
The IFS uses 16:16 segmented pointers, and the Daemon is using 16:32 (32 bit
offset) pointers.  This process is called Thunking.  When a 16:32 pointer is
passsed to a 16:16 api, it is converted to 16:16 format.




!STORAGE________________________________**********
December 14, 1994
QUESTION: (Ref: FS1)
I am the editor of the QIC-157 document which specifies attachment of tape
drives to the IDE interface via ATAPI.  We have ATAPI pre-release tape drives
we support by going directly to the IDE hardware.  However, this precludes
being able to share the bus with another device under OS/2.  We would like to
know if there is a way our tape backup software can communicate with ATAPI tape
drives and coexist peacefully with a CD-ROM or hard drive on the same cable.
This could be in the form of:

1. being able to issue ATAPI cmd packets (CDB's) through an os/2 ADD -or-

2. being able to detect an os/2 add needs to send a command and backing off
until os/2 completes the command (this is what we do in Dos).


ANSWER:
They will need to get the NEW (Warp level) IBM1S506.ADD driver source, which
has suspend/resume logic in it for the IDE (Atapi) CDROM driver.




!OTHER__________________________________**********
December 14, 1994
QUESTION: (Ref: FR9)
Q1. I am currently compiling my 16bit OS/2 Physical device driver (.SYS) with
    Microsoft C 6.00.  Is it possible to compile and make a Physical device
    driver with IBM C Set++ for OS/2 2.0?

A1. IBM C Set++ for OS/2 is a 32-bit compiler and is not for use with 16-bit
    device drivers.
==============================================================================

Q2. Will the following tools works on Warp (OS/2 3.0)?
      - IMB C Set ++ for OS/2 2.0
      - Microsoft C 6.00
      - DDK v 1.02
      - my multimedia Audio Physical device driver Pcxpdd.SYS

A2. IBM C Set ++ for OS/2, MS C 6.0, and DDK 1.2 are compatible with OS/2 Warp.

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

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

Q3. In other words, if I buy and install warp, do I need to buy a new C Set ++,
    a new DDK, etc...?

A3. No, see answer #2 above.  In addition, although DDK 1.2 is compatible with
    OS/2 Warp, it is suggested that you upgrade to Devcon DDK 1.0 which
    includes Warp source code & Warp kernel debugger not included with DDK 1.2.
    To order Devcon DDK 1.0, please call 1-800-633-8266.




!VIDEO__________________________________**********
December 14, 1994
QUESTION: (Ref: FR0)
I have written a PM application to install Trident Display Driver.  I need to
overwrite BVHSVGA.DLL when installing Trident Display Driver.  When
BVHSVGA.DLL is in use, OS/2 will not allow me to copy a new BVHSVGA.DLL.  I
would like to know how I can overwrite BVHSVGA.DLL from PM application when it
is in use.  (not to use DSPINSTL.EXE or DDINSTL.EXE).


ANSWER:
In your header file include the following :

APIRET APIENTRY  DosReplaceModule( char *pszOldModule,
                                  char *pszNewModule,
                                  char *pszBackupModule) ;

This is an Undocumented Call and is private to IBM and could be modified for
functionality.

DosReplaceModule - Replaces an in use DLL or EXE

This routine is called to replace an in use DLL or EXE to cache the contents
of the old module and then copying a new file over the old module's file.
Just in case something goes wrong, a backup copy of the old module's file is
made before the new module is copied over it.  If an error occurs, the backup
copy is used to replace the bad new copy of the module.

    ULONG DosReplaceModule( char *pszOldModule,
                            char *pszNewModule,
                            char *pszBackupModule)

If pszNewModule or pszBackupModule are NULL, then the appropriate
functionality is not performed.  With both of these NULL, then the result is
just to cache and close the file.

ENTRY   pszOldModule    - name of the module to replace
        pszNewModule    - name of the module to replace the old module
        pszBackupModule - backup module name




!VIDEO__________________________________**********
December 14, 1994
QUESTION: (Ref: FP9)
How difficult, or easy, is it to create a DBCS pm driver from the S3 source on
the DDK 1.2?  My problem now is to say how much time it will take to convert
my SBCS S3 pm driver to a DBCS pm driver and I have no idea.  Perhaps you can
give me an idea how long it will take.


ANSWER:
I think he has already created SBCS PM driver for their chip from S3 source
code, and he wants to convert it to use on DBCS environment by referring to
DBCS enabled S3 code.  If this assumption is true, it takes about 1 month.
But please make sure that it depends on developer's skill.  DBCS enabling code
is put both on logical part and physical part.  Most of DBCS enabling works on
logical part are routine work, but he has to create new code for support AVIO
on physical part.  And if there is no tester who can identify DBCS character,
its not so easy to debug.




!MULTIMEDIA_____________________________**********
December 14, 1994
QUESTION: (Ref: FP8)
1. Has something changed in the DevEscapes for SMV in Warp?

2. Is there a way to use SMV in my 32bpp modes?

3. What is when my hw-palette uses other rgb formats?  (For example, rgb and
   not bgr in the hw-palette).


ANSWER:
1. Yes, the DevEscape changed in Warp.  The get aperture structure changed in
   meaning but not definition.  This should not change older programs since
   the DevEscapes didn't work in the modes where the changes took place.  What
   changed is the scan-line-size parameter.  In 8-bit or 16-bit modes, the
   line-size is specified in pixels (only in the lower word).  In 24-bit or
   32-bit modes, the line-size is specified in bytes (again, only the lower
   word).  One twist here:  if the ordering is BGR, the number of bytes is
   negated; if the ordering is RGB, the number of bytes is positive.  Finally,
   the upper word specifies a number of bytes offset from the beginning of
   physical vram to the first pixel on the display.  This is typically zero,
   but on cards like the ATI MACH 64, it may be something like 512 bytes.

2. Warp and SMV support 32bpp modes.  If it doesn't work on a particular
   machine, suspect a display driver problem (i.e.  the DevEscape is
   misreporting information).

3. Addressed in the DevEscape change above.




!BASE !OTHER___________________________**********
December 14, 1994
QUESTION: (Ref: FP3)
Currently I am developing a driver for my conpany's PCMCIA-SCSI adapter.  It
is supposed to be an ADD driver.  I found out that when the operating system
tried to initialized those BASEDEV Drivers, the PCMCIA driver is not yet
loaded.  Is there any workaround?  I intend to let the driver give some fate
information to the OS and initialize itself later when the PCMCIA CARD SERVICE
is already loaded.


ANSWER:
The ADD driver is a BASEDEV and all BASEDEVs get loaded before all DEVICEs in
the config.sys file in the order - SYS, BID, VID, TSD, ADD, I13, FLT, DMD.

Note that in the case of an ADD the extension is significant and determines
the load order.  The OS/2 2.1 Enhanced PCMCIA Support has a Field Upgrade
Support Package, which has the Card Services PDD (as a BASEDEV) and an ATA
Super Client PDD (BASEDEV).  With the upgraded Card Services PDD installed as
BASEDEV, you should be able to initialise the ADD.  (For information on the
Field Upgrade Support Package, download OS2PCM.ZIP file off the OS/2
BBS-(919)517-0001.  Unpack the support file using PKUNZIP2.)




!OTHER__________________________________**********
December 14, 1994
QUESTION: (Ref: FP1)
We have noted that if we issue a VMProcessToGlobal twice in a row on the same
process address, the system crashes in the kernel.  The memory was allocated
using VMAlloc + VMLock.  Can we do something to avoid this without a VMFree
before the second VMProcessToGlobal?


ANSWER:
If you use OS/2 2.0 thru' OS/2 2.11 you may get Trap E when you access a
locked page via a linear address (obtained through DevHlp VMProcessToGlobal)
at Interrupt Time.  The Linear Address is valid but the kernel marks it not
present at some point.  You could refer to APAR PJ15296.  This has been fixed
in 6.644 OS2KRNL contact OS/2 Support for this Fix.




!OTHER__________________________________**********
December 06, 1994
QUESTION: (Ref: FS3)
Is there a way to have multiple code segments available after initialization
of an ADD driver?  At the end of initialization the ADD driver returns a value
indicating where the driver code ends.  This value is a USHORT so is only an
offset.  My runtime code in my driver is larger than 64K.  I need a way to
have multiple code segments during runtime.  Is this possible?


ANSWER:
The physical device driver can have multiple code & data segments.  The first
segment in the Device Driver must be the Data Segment and the second segment
must be a Code Segment.  These two segments are fixed in memory and ( by
default ) will be the only two segments kept in the System after Device Driver
Initialisation.  OS/2 assumes that every other segment is needed for
initialisation only, unless marked as permanent in the header of the Device
Drive EXE File.  Multi-Segmented DDs -- How do I keep the extra segments
around ??  This is done by making them IOPL segments with the IOPL keyword in
the module definitions file.  Since DDs already have IOPL, this keyword has
been overloaded for DD use to tell the loader to keep the extra segments
around.  By default these extra segments are movable and swappable, so lock
them if you need them at interrupt time.  Please refer to the Documentation in
the Physical Device Driver Reference Manual - PDD Architecture & Structure.




!NETWORK________________________________**********
December 06, 1994
QUESTION: (Ref: FQ3)
Are there any test tools provided by IBM for NDIS driver testing?  I know
about tests from DWB and from Microsoft test tools.  That's all at the moment.


ANSWER:
According to our NDIS developer/coordinator, there are no other tools etc...
except for what you mentioned in your note (DWB).  There is a file on the DUDE
BBS called OS2TG.ZIP.  This doc has info on a tools guide.




!OTHER__________________________________**********
December 06, 1994
QUESTION: (Ref: FO8)
Is there a debug kernel for WARP available on the DUDE?


ANSWER:
The debug kernel for WARP is included with the Devon DDK 1.0 product, it is
not on the DUDE.  To order Devcon DDK 1.0, please call 1-800-633-8266.




!VIDEO__________________________________**********
December 06, 1994
QUESTION: (Ref: F04)
At initialization time the pm graphics engine searches the os2.ini for an
application entry PM_ED_HOOKS.  Is this still true?  Is there any more info
available on the initialization of pmgre?  What I would like to accomplish
with this is to intercept the calls to GpiCharStringPos, GpiCharStringAt, etc.


ANSWER:
InstallPMEngineDisplayHooks is documented in the Presentation Driver Reference
- Exported Driver Function Reference - Subfunction 0Ch.  The Application Name
PM_ED_HOOKS in OS2.INI should have your display hook DLL.  However we do not
have any sample code on the DDK which uses this Function.




!STORAGE__________________________________**********
December 06, 1994
QUESTION: (Ref: FO3)
A bug had been reported by users where our ADD would crash at random odd
times.  I have traced this problem to the fact the the ADD driver does a
VirtToPhys to get the physical address of the data segment at init time.  At
some later time, OS/2 moves the drivers segment to another physical location.
Using the captured physical address to transfer SCSI sense data (after init
time) causes the system to crash.

Our code was based on the sample in the DDK, which uses similar code.
Basically, I have three questions:

Q1. Is it safe to reconvert the data segment address in the
    IOCM_COMPLETE_INIT IORB?

Q2. Under what conditions will OS/2 move a device drivers data segment?

Q3. Is this behaviour documented somewhere?


ANSWER:
A1. Yes it is.  The segment has to be locked into physical memory in all
    cases where the physical addresses are involved.  Virtual Address should
    be locked with DevHelp Lock before invoking DevHelp VirtToPhys.

A2. Any segment other than the first data segment and the first code segment
    is potentially movable unless specified as fixed at link time.

A3. Please refer to PDD Ref, Chapter 3. - Physical Device Driver Programming
    Model & Physical Device Driver Load Module Layout.




!OTHER__________________________________**********
December 06, 1994
QUESTION: (Ref: FO0)
We have customers asking us to be CID-compliant.  We have a (old) spec on CID,
but that is not enough to develop the program and response file.  We did not
find anything in the DDK.

Is there a CID tool kit available?  How can we get it?


ANSWER:
There is no CID Toolkit.




!OTHER !VIDEO___________________________**********
December 06, 1994
QUESTION: (Ref: FN9)
I'm currently researching the feasibility of CID enabling our display driver
installation procedure.  At this point, I don't have a lot of information.  I
am basically trying to figure out what it would take to do this and if it's
even possible.

I have a document entitled "CID Enablement of DOS Lans".  Apparently, the
scenario it assumes is an OS/2 server with DOS clients.  It discusses how to
install CID enabled apps on the clients using NetView DM/2.  It seems that CID
requires NetView DM/2.

However, if I were to CID enable our OS2 display driver installation
procedure, then would I need NetView DM/2 for OS/2?  Is NetView DM/2 even
available for OS/2?  If it isn't, does that mean that I can't CID enable
display driver installation?


ANSWER:
CID does not require NetView DM/2, so you will not need it to CID enable your
OS/2 display driver installation.  Yes, NetView DM/2 is available for OS/2.




!VIDEO__________________________________**********
December 06, 1994
QUESTION: (Ref: FN8)
Is DSPINSTL CID capable?  If not, does that mean I would have to write my own
utilities to modify the INI files as well as CONFIG.SYS, in order to complete
display driver installation?


ANSWER:
DSPINSTL is CID capable in OS/2 WARP.  If you are not running WARP then you
may use RSDSPI during response file install.  Response file install
documentation is included with OS/2 2.1 or later.




!BASE !OTHER____________________________**********
December 06, 1994
QUESTION: (Ref: FN3)
I remember reading somewhere that there was a way of querying the system for
the selector value of the Flat selector (the selector that can address the
whole of memory).  But I cannot remember whether it was a Dos call or a
getdosvar.

I hardcoded it as 0x168, which happens to work fine on OS/2 2.1 and Warp GA, I
have just discovered that on Warp Beta it is 0x158.

Can you tell me the correct way to identify the systems flat selector?


ANSWER:
I don't know how you could access all the address space on OS/2 2.x and Warp
using 0x168.  The correct selector is 0x158.  This selector is mapped as a
data segment with base=0x0 and limit= 0xffffffff.  There is no documented way
to get this selector.  If your intent is to access the full 4GB area then you
can try looping on selectors using DevHelp GetDescInfo for all 8K combinations
till you find a selector with the 0x0 base and 0xffffffff limit for the data
segment.

If you are using the selector 0x168, please verify that it does map to these
numbers.

Please be aware that indiscriminate writes using this selector is likely to
affect system integrity.

The flat selector used by the kernel is stored in a kernel structure called
System Anchor Segment.  This can be seen using the tool THESEUS2.
(System->General System Info->System Anchor Segment).  THESEUS2 is a part of
the SPM/2 2.0 Package.  The DevHelp does not document it anywhere neither can
it be determined through the Control Program Functions.



CUSTOMER FOLLOW-UP:
I am using the Warp 3 GA product BUT with the debug kernel.  This definitely
uses 168.  I have found examples of this flat selector usage in the mmos2
toolkit.

In files VCA32.ASM & VCAINIT.ASM, the variable DOS32FLATDS is declared :

EXTRN DOS32FLATDS:ABS

Presumably the variable is declared in a library & the linker resolves the
link.  But how should I compile/link to make use of this variable.

As far as the mapping,

With Warp GA it maps to 158
With Warp GA + kdb it maps to 168

The problem is that the SAS segment is at a fixed selector too.  AND its
structure will probably change in the future.


FOLLOW-UP ANSWER:
To use DOS32FLATDS you could include the following in your .ASM file :

extern          DOS32FLATDS : ABS
        :
        :
mov     ax,DOS32FLATDS
mov     ds,ax

Link the DOSCALLS.LIB and in the .DEF file IMPORT the following :

IMPORTS
DOS32FLATDS = DOSCALLS.370




!OTHER__________________________________**********
December 06, 1994
QUESTION: (Ref: FM4)
I am having problems when loading the device driver am a currently developing.
I get the following error in DEBUGO when loading the driver:

---------------
Internal symbol error: SegDefLinkUp
Invalid error code: 6d20 - %7b7c6008
##
---------------

At this point if I type G and <enter> the SUT(system under test) hangs.  I
suspect it has to do with the program layout.  Any ideas?

Compiler used: Watcom 16 bit( ver 10.0)
Linker used:    Link.exe

Furthermore, it may be non-related, but as soon as I install the debug kernel
at some point the SUT hangs with the following message on the DEBUGO screen:

---------------
The system detected an internal processing
error at location ##0170:fff59be1 - 000f:0001abe1.
line 192, in file 4044 @(#)vmalloc.c  6.8 92/03/11

048600b4 - 10/26 19:02:53.53
Internal revision 6.514, 93/04/12

The system is stopped.  Record the location number of the error and contact
your service representative.  eax=fecff262 ebx=7bba9a04 ecx=fecf0026
edx=00000000 esi=7b9d3d64 edi=fff12af4 eip=fff59be1 esp=00006adc ebp=00006af8
iopl=2 -- -- -- nv up ei pl nz na po nc cs=0170 ss=0030 ds=0168 es=0168
fs=0000 gs=0000 cr2=ffe59000 cr3=001d2000 0170:fff59be1 eb2d jmp fff59c10
----------------

At this point after entering G and <enter> at the DEBUGO prompt, the SUT
machine continues to boot without any errors.

Can it be a memory problem? (I have had strange hangs on my machine lately.)


For your conveniance I have included my map file at the end.  Please let me
know if you need more info.  Please note that the *_ syntax is due to the fact
that I am using the Watcom compiler.

(DELETED FOR PRIVACY)


ANSWER:
1. When you are using the Watcom Compiler, the normal procedure is to use LINK
to generate the MAP File and then use MAPSYM to generate the SYM File which
will be used during Debugging.  However, WLINK is used to generate the SYS
File and it is this executable which is loaded in the DEVICE= Statement in the
CONFIG.SYS.  This is because the Map File Generated by the WLINK is not
compatible with MAPSYM.

2. Regarding the error in VMALLOC.C, is it after you load your driver?  Please
try after removing your driver from the CONFIG.SYS.  Does the problem persist
even after the removal of your driver?  It need not be related to a memory
failure, since this would be detected by the System Diagnostics.  However, it
could be related to the usage of DevHelp_VMAlloc in your driver.




!OTHER__________________________________**********
December 06, 1994
QUESTION: (Ref: FM5)
It seems that the keywords used for the Pascal calling convention by the DDK
.h files are not recognized by the CSET++ compiler.

The DDK uses PASCAL, which it #defines as _pascal.  The DDK also uses PASCAL
NEAR, PASCAL FAR, and PASCAL FAR32.

It looks like CSET++ uses _Pascal and _Far32_Pascal.

What are my options for resolving this incompatibility?


ANSWER:
CSet++ supports 16 bit Pascal Linkage also.  You could either use linkage
keywords or the pragma linkage directive to make it compatible to the pascal
convention.

   Linkage Keyword
   _Pascal           32 bit Pascal linkage
   _Far32 _Pascal    32 bit far _Pascal linkage
   _Far16 _Pascal    16 bit _Pascal linkage

#Pragma Linkage
In this directive you could use :
   pascal
   far32 pascal
   far16 pascal
   far16 _pascal

Pascal & _pascal are equivalent and specify CSet/2 Linkage.

The keywords used for the Pascal calling convention by the DDK .h files are
compatible with the IBM CSet/2 Compiler.




!OTHER__________________________________**********
December 06, 1994
QUESTION: (Ref: FL4)
We are seeing this message from the kernel debugger when the application does
a _beginthread:

   Short Term Lock for > 10 secs :  hob = 2c7

The message comes out twice, and the application appears to hang for 20
seconds.  We don't know if the problem is caused by our driver or the
application (the hob references the application).  The problem does not occur
on 2.11, but it does happen under 2.10 and 1.3.

Can you tell me what this message means, and what countermeasures we can take
to work around it in 2.10?


ANSWER:
If you are using DevHlp_Lock in your driver, the duration of the lock must be
set to long term, or a verify lock should be used for operations that are
expected to take two or more seconds to complete.  Use of short term locks for
longer periods of time can prevent an adequate amount of movable, swappable
memory from being available for system use and can cause a System Halt.

A physical device driver can use short term locks where necessary for its own
code and data segments, provided the 2-second rule is not violated.




!VIDEO__________________________________**********
December 06, 1994
QUESTION: (Ref: FK2)
Can the GRE handle 32bpp?


ANSWER:
The GRE does not support 32bpp.  However, you could have your own routines to
support 32bpp which do not depend on the GRE.




!VIDEO__________________________________**********
December 06, 1994
QUESTION: (Ref: FK0)
I am looking for specs/docs for the SMVDD.SYS device driver.  In particular
IOCtls and interface.


ANSWER:
We do not document the interface to the SMVDD.SYS device driver.  Instead, you
can use the DIVE APIs to interface.  (DIVE = Direct Interface Video Extension,
ENDIVE=Enhanced Direct Interface Video Extension).  The DiveOpen function
specifically gives you addressability to the frame buffer.




!VIDEO__________________________________**********
December 06, 1994
QUESTION:  (Ref:FI6) It appears that the Warp video subsystem (BASE VIDEO &
VIRTUAL VIDEO) has implemented some portion, at least, of the new Centralized
Services video architecture.  I'd like to move to this new architecture as
soon as possible.  If I implement base and virtual video subsystems for the
Number Nine I-128 using Centralized Services as in Warp, can the
implementation be used as well under OS/2 2.1x?  If so, how?


ANSWER:
All of the PMI specification published in the DEVCON-DDK v1.0 is implemented
in Warp.  DDK contains sources to virtual driver which uses the PMI SVGA.EXE
which formats it and IBMGPMI which can export functions that are hard to
implement as native PMI sequence.  The PMI parser for the protect mode
VIDEOPMI is shipped with Warp and in upcoming video driver BBS releases.
BVHSVGA which is a client of VIDEOPMI is also shipped as binary in Warp & BBS
as well as source in the DDK.  If a vendor is interested in using the PMI spec
in their implementation of base video and would like to target 2.x customers
than the following guidance applies:

a) BVHSVGA.DLL and VIDEOPMI.DLL do not require modification/compilation and
should be taken from the upcoming S3-864 video driver release on the BBS.

b) If IBMGPMI.DLL is required recompile it using 2.11 DDK level of libraries
and 3.0 source level for IBMGPMI.DLL.  This is due to a newly discovered
incompatibility problem with some OS/2 libs, which are going to be fixed in
our BBS release for the binary level of VIDEOPMI and BVHSVGA.

If you need to make modification to the source of the BVHSVGA from the DDK,
the same rule applies, compile using the 2.11 build environment and 3.0 source
level.

All of the base video files are then to be bundled:  BVHSVGA.DLL
(BBS/DDK-2.11) VSVGA.SYS (DDK) VIDEOPMI(BBS), SCREEN01.SYS from DDK, SVGA.EXE
(DDK) and IBMGPMI.DLL (DDK-2.11).  This bundle can be installed then on any
2.x and 3.0 release.

We expect that you would need to make modification to SVGA.EXE and VSVGA.S*
needs to be recompiled after the new adapter is added to the SVGADEFS header
file.  If the new adapter is not compatible with any of the ones already
supported by the VSVGA, you could follow VVS3.C, VVTSENG.C or VVCIRRUS.C
source files as a model for how to add a new adapter to the virtual video
support.




!NETWORK________________________________**********
December 06, 1994
QUESTION:(Ref:FG5)
I have written several NDIS Mac drivers and protocol drivers for OS/2 and DOS
since attending your NDIS workshop.  I am currently attempting to modify one
of my OS/2 drivers so that it can be entered in CONFIG.SYS twice without any
parameters, and dynamically change it's name in the device header based on the
existence of a previous instance.  This is what your IBMTOK.OS2 appears to do.

In order to get around the kernel trying to DEINSTALL a previous instance, I
am initially setting the name in the device header to all blanks (he shouldn't
find another case of that already loaded), and then in the INIT routine,
running the device chain myself looking for a previous instance.  For
instance, suppose my name is PROTO$.  If upon INIT I find a previously loaded
PROTO$ I copy "PROTO2$" into the name field of the device header.  My first
question is...does this sound plausible?...and if so, how do I find the start
of the device chain?

In the NDIS workshop, they told me the OS/2 system anchor block starts at
70:00 and the device chain starts at 70:20.  Yet when I scan these areas in my
OS/2 2.11 system (debug version), I can not find a reasonable looking device
header.  When I run the DDINFO program I got at your workshop, he finds all of
the devices with no problem, so I am doing something wrong.  I would be
grateful for any assistance you could give.


ANSWER:
You can do dynamic renaming; use the audio dd (PASTK16) to give an example.
