This is file: 09_95QA.TXT

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

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

The following KEY WORDS are supported in this file.

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

!NETWORK________________________________**********
October 9, 1995
QUESTION: (Ref: ID9)

I am attempting to write a MAC driver for an ISDN card and I need help in
locating a document called OS/2 XS ISDN OEM NDIS Mini-Spec March 17 1991.  Can
you help me?

ANSWER:
The mini spec doc that you are requesting is no longer available.  This
document is an internel document that has been discontinued and no longer
available.




!OTHER__________________________________**********
October 6, 1995
QUESTION: (Ref: IM4)
I got out of sync with all my recent upgrades and would like some help...  I
have VisualAge C++, and DevCon DDK dated Oct 11, 94.  It looks that the two
don't like each other too well.  Should I upgrade DDK as well, is there some
compatability mode, or am I missing some pieces.  E.g., the DASD samples
require MS C 6.0 and don't seem to work without it.

ANSWER:
Currently, the DDK is at version 2 and can be ordered by calling
1-800-633-8266.  The 32 bit device drivers in the DDK were compiled using IBM
C Set++ version 2.01.  Unfortunately, VisualAge C++ uses some different
library names and a different linker which are problematic for the makefiles
in the DDK.  Please refer to the USEDDK.INF located in the DDK for device
driver build requirements.  ADDs require Microsoft C 6.0 and MASM 6.0a.  These
compilers are no longer in production.  A new alternative to Microsoft C 6.0
is Watcom C 10.5 however the ADDs on the DDK were compiled with Microsoft C
6.0.


!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IM5)

Currently it runs OS2/1.3.  The group could not move up to 2.x until they had
a way to take a view application (not device driver) dumps.  They are using
MultiScope on 1.3 to do this.

I joined the group 9 months ago from the mainframe where I did assembly coding
for a multi/task (thread) Vtam (communications) program that monitors these
servers in the field.  During the Spring I wrote a PostMortem debugger that
dumps the application to a file.  This file can then be read by my Dll which
is hooked up to Ipmd (hook pt.  provided by Ibm).  So we now have a PostMortem
for any 2.x application.  Ibm will release it this winter as part of Ipmd.

The major uplink to our home site (Yorktown) is done thru a device driver that
communicates with a Portmaster card (Ibm).  The device driver and code on the
Portmaster where done many years ago under OS2/1.1 or 1.2.  out of a group in
Boca.  That group contracted to us but has been disbanded for 2 years.

I am really a rooky at this device driver stuff.  I do have the DDk and have
been reading the Q&A for a while.  However I have never written a device
driver.

PROBLEM:
On trying to move to Warp (Connect) we observe the following:
    1) When the process that does the uplink is killed or fails the system
        grinds to a halt within 2mins.
     2) By changing the LockSeg calls from short to long it now takes much
        longer to fail but still fails.
    3) The process never clears from the task list (big suprise).
    4) The code still works fine on 1.3

Question:
Q-1) Should I send the device driver code.  It is one 2600 line asm source
module?

Q-2) Will LockSeg cause the under lying phy.  addr.  to be contiguous?  At
first it was not clear that it would and coming from the mainframe I was well
aware that external hardware has to deal with 4k phy.  address.  So I thought
we might be crossing a boundary, but I have found some docs.  that basically
say this is "the problem" with LockSeg.  in you are forcing the operating
system to give you back contiguous addresess.  Of course if this is not the
case I fail to see how any 1.3 drivers dealing with Dma could work without
some serious rewrite.


I will try to give an overview of what I think the driver code does.  The
init.  stuff seems ok it read the Pos registers for info on the card.  then it
just hangs around waiting for our app.

The process loads the card with the portmaster code.  If we force an exception
here we are ok and have no hangs.  Then a request to read data off the Sna
link (that is what is hooked up to the card).  An AppBlock is created filled
in with the passed user buffer (which does not cross segments) and then a
Generic Ioctl call is done.

Now the device driver has it.  I am muddling my way thru MASM and it seems
that there is a memory "window" between the Portmaster and the Cpu.  Basically
the AppBlock we have is copied to one of X number of spots in the window.
There are two parms which are first locked (Seg) and translated to phy.  Then
a check is made to see if there are a chain of blocks in a ptr in the AppBlock
and they are locked/translated and the phy.  addr.  put in a ptr.  in the
prior block.  Finally an OUT is done to one of the addresses that came back
during init.  to set what is commented as the Shared_Win reg.  I assume that
the card will pickup the first block (copy) and fill in data.  Finally an
interrupt is sent to the card.  Then the device driver blocks.  The interrupt
rtn will get control back in the "window" and force a run of waiting threads
that have a AppBlock in the window.

Q3) It seems the address of the window is at this time is via a PhysToVirt.
Ok I follow that we are in a different thread context.  However it seems
multiple run commands will be issued going down an array of waiting elements
in the window.  Was this ok in 1.3?  Is it ok now (2.3).  My Pdd says the
first time another command other than a PhystoVirt is issued I will lose the
temp selector.

Q4) Since we seem to use up some system resource (locked memory?)  after we
have a shutdown would I be better tracing what happens to memory coming out of
the block code (is Control-C the same in 2.3) or what.

As a note I will be using Asdt for the moment since I can get the developer on
the phone if I need him, and this if we use the Kernel debugger we have to
change some code not to use the modem.

ANSWER:
We assume that you are using DevHlp_Lock and trying to change short-term
lock to long-term lock.

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 fault.

If the "Block until available" bit is set, the call will wait until the
segment is available.  But in the event of a failure a long-term lock will
return even if the caller specified the request - Block until available.  In
case of error you can check the AX register for error code.  Refer to Section
"Lock" in Chapter "Device Helper (DevHlp) Services" in "PDD Reference".

The call could fail if there is not enough memory to hold the OS/2 working
set, all the memory already fixed, your memory supposed to be fixed + a range
of pages the system keep for further page in/out requests.

When DosDevIOCtl passes an address to a device driver, it passes the address
in the form of a temporary selector.  This selector is valid only for the
duration of the call and cannot be used to lock the memory.  The calling
program must use the DosAllocMem function with the object tile (OBJ_TILE) bit
set.  Then the application can pass a pointer to this memory to the device
driver.

The DosRead does a "short-term pin" of the memory in the buffer.  These pages
may not be contiguous.  If you try to do a "long-term pin - contiguous", it
won't work and will probably fail.  In OS/2 1.x, the page size was 64K, so
when an application wanted to do a DosRead or DosWrite for 64K, OS/2 could
easily find 64K of contiguous physical memory.  In OS/2 2.x and above 4K pages
are used.

The DevHlp_Lock must make memory contiguous, NOT JUST lock all of the pages
(very expensive operation).  The Lock DevHlp is very expensive call for a 32
bit OS like OS/2 2.x to emulate.  In this call the locked pages must be below
the 16MB address line and the length cannot exceed 64KB.  DevHlp_VMLock is a
better alternative on OS/2 2.x & Warp.

3) The virtual address returned by the PhysToVirt DevHlp does not remain valid
if the device driver block or yield control.  The returned virtual address can
also be destroyed if the physical device driver routine that issues the
DevHlp_PhysToVirt call another routine.

If an interrupt handler needs to use converted address after its EOI, it must
protect the converted address by running with interrupts disabled.  Refer to
Section "PhysToVirt", Chapter "Device Helper (DevHlp) services" in PDD Ref.

4)  Ctrl-C works the same way on OS/2 2.x & Warp.
On receiving Close Request packet, the following points must be taken care of :
 a) If any interrupt level was registered, it must be released.
 b) If any requests are pending in the queue, RPDONE must be issued to these
    requests.
 c) The device driver must ensure that the Pid of closing application is the
    same as the Pid of the program that opened the device. If the Pid is valid,
    the driver must decrement Open counter and return DONE status to the kernel.
d) Any memory previously allocated must be freed.
e) If the application has created additional handles to a file with DosDupHandle
    it must issue DosClose for the duplicate handles.

Refer chapter on " A simple OS/2 Device Driver", section "Device Driver
Operation" in "Writing OS/2 2.1 Device Drivers in C" by Steve.J.Mastrianni.
Also refer to the "Sample OS/2 Serial Device Driver" listing in Appendix C of
the same book.

QUESTION2:
The following is a code snipet during the block and then the return.  If we
have a C-break then it seems that we will issue the NMI.  I have no idea what
this was about so using ASDT I zapped the OUT inst.  to Nop and while the
process does not clear from the system it no longer seems to freeze the
system.

I realize I am asking a lot but could you give me any insite into why the Nmi
is there, and why by not issuing the out instruction things seem to go a bit
better?
(CODE DELETED)

ANSWER2:
When the application is terminated by Ctrl-Break, the device driver indicates
to the Port Master Card that the application is dying, by giving an NMI
Interrupt.  Since the the system does not freeze when you mask the OUT
instruction, the problem could be in the NMI Interrupt Handler.  You could
look into the NMI Interrupt Handler running on the Port Master card.

You will also not be able to debug Interrupts with ASDT.This would be possible
only with the Kernel Debugger.




!OTHER__________________________________**********
October 6, 1995
QUESTION: (Ref: IM6)
I get a trap 14 - page fault 0000 every time from my Timer Handler routine to
the OS2KNRL:Tick_Handler routine.  I use the DevHlp_TickCount call to register
my timer handler routine, the tickcount is set to 18 ticks The Timer Handler
does not do anything except pushing all the flags, pop all the flags, then
iret.  I call the DevHlp_TickCount routine at the end of my initialization
code before returning.  Am I doing something wrong ??  Any help is greatly
appreciated.

 The Trap 14 screen contains the following :
 Trap 14 - Page fault 0000, Not Present, Read Access, Supervisor
 eax=0000001b ebx=fff006e0 ecx=fff00400 edx=00000001 esi=000089f8 edi=fe6f0001
 eip=0000336c esp=00001fda ebp=00001fe0 iopl=1 rf -- nt ov dn di ng nz na po nc
 cs=1100 ss=00e8 ds=0fc8 es=0400 fs=0000 gs=0000 cr2=abaf9f48 cr3=001d6000

     I use the following codes to register for the TimerHandler :
   mov     ax, offset CGROUP:TimerHandler  ; offset to timer Handler
   mov     bx, 18                          ; call TimerHandler every 18 ticks
   mov     dl, DevHlp_TickCount
   call    devhelper
        jc      init_fail

     The TimerHandler routine does simply :
        pusha
        push    ds
        push    es

        pop     es
        pop     ds
        popa
        iret

ANSWER:
The timer handler is in the format of far call/return routine.  This is called
by the OS/2 kernel and is not an Interrupt Service Routine itself.  Therefore
the IRET instruction at the end of your timer handler should be changed to a
normal RET instruction.

Refer section " DevHlp_TickCount", chapter " Device Helper (DevHlp) Services "
in Physical Device Driver Reference.



!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IM8)

I have a PDD that needs to read data back from a scanner via DMA.  The read
command in my strategy section gets a packet with a physical address in it.
Can I DMA directly to that address?  Will the address always be within the
first 16MB?  Will the length specified exceed the current page?  Do I need to
allocate a buffer to DMA to instead of the address given?  How do I allocate a
buffer that does not wrap at a page boundary?

ANSWER:
Refer to AllocDMABuffer() in MMOS2\SAMPLES\AUDIODD\AUDIODD.C (DDK 2) which has
sample code to ensure that your Buffers are on Page boundaries.

1. You can DMA directly with the physical address if the memory is below 16 MB
and it is contiguous.

2. The physical address passed need not necessarily be within the first 16 MB.
You should allocate your own DMA Buffer to ensure you are below the 16MB line.

3. The length specified could exceed the current page.Refer to the
AllocDMABuffer Routine for a workaround.

4. You could also allocate a buffer for DMA in the device driver.  This can be
done by using VMAlloc DevHelp call with Flags to indicate the memory allocated
should be less than 16MB, contiguous, fixed( if it is to be accessed during
interrupt time ) and in the global address space.  This memory could then be
made accessible to the application using VMGlobalToProcess DevHelp call.

Refer sections "VMAlloc" and "VMGlobalToProcess", chapter Device Helper
Services in Physical Device Driver Reference.
Also refer to the function GetDMABuffer() in
\ddkx86\src\dev\dasd\ibm\ibm1flpy\flp1osm3.c for usage of VMAlloc.

Alternatively you could also use DevHlp_AllocPhys and request contiguous
memory above 1MB.AllocPhys returns memory below the 16MB line.

5. You can allocate buffer which is page aligned by setting bit 8 in VMAlloc
DevHelp.  This will only reserve the memory.  You can commit the memory using
DevHelp VMSetMem.  Refer section "VMSetMem", chapter Device Helper Services in
Physical Device Driver Reference.




!OTHER__________________________________**********
October 5, 1995
QUESTION: (Ref: IN3)
It is not clear to me, after reading the trace customization document, whether
or not trace customization can be used with drivers compiled using the
MicroSoft C6 compiler.

If trace customization can be used with a driver program, what compiler
options need to be set?

ANSWER:
If you are using Microsoft C 6.0,there are no additional compiler/linker
options to be used.

Refer to ddkx86\src\dev\dasd\cdrom\mitsumi directory.The only additional
compiler option used is "/DTRACE".This is used to enable the trace flag in the
C Code.

Add the TRACEBUF=63 line in CONFIG.SYS
TRACE ON MajorCode will enable tracing on your Major Code.

You could then use TRACEFMT to get a copy of it or .T, if you are using the
Kernel Debugger.

For additional info refer to the OS/2 Dynamic Trace Customizer Documentation
available on the DDK.  If you were using IBM CSet/2 ,the C programs could be
compiled using /Ti option and linked using /CO option.

Refer section "Building a Module", chapter "Dynamic Trace Customizer( TRCUST)"
in OS/2 Dynamic Trace Customizer.




!STORAGE________________________________**********
October 9,1995
QUESTION: (Ref: IN4)
Where is the storage documentation for DDTT?

ANSWER:
You can find the DDTT documention in the STORAGE.INF file in the DDK.




!OTHER__________________________________**********
October 6, 1995
QUESTION: (Ref: IN7)
1. At the initial stage, the driver needs to use I/O to make sure of the
memory size because the memory is variable and shares with system memory.  But
the procedure DllLoadProc can not do any I/O function.  I have tried to set
the segment IOPL, but it does not work.  I also have tried to write a
subroutine in another segment that can do I/O functions.  It dos not work
either.  I think the procedure DLlLoadProc is ran in ring 3. How can I do I/O
function in this procedure?

ANSWER:
As you said correctly, the procedure DllLoadProc gets called from and runs at
ring 3.

IOPL is not permitted from 32-bit segments.  Since VGA32 is a 32-bit code you
cannot set the segment IOPL to this code.

To use IOPL from a 32-bit application, the application must call I/O routines
located in a 16-bit segment.  The easiest way to do this is to create a 16-bit
segment, then link it to the driver.  For more information refer to "Writting
OS/2 2.1 Device Drivers in C" by Steve.J.Mastrianni, Chapter-10 "Memory Mapped
adapters and IOPL".  This book is available online in DDK.

When you make a call to 16-bit, Ring 2 routine, OS/2 will perform a ring
transition from Ring 3 to Ring 2, call the routine and perform another ring
transition back to Ring 3. There will be a performance penalty in this method
because of the ring transition.

To get the amount of memory available in the system you can use OEMHLP IOCtl
Function 09h Query Memory Information.  Refer to Appendix-D of the above
mentioned book for sample source code.

There are IOCTL calls in TESTCFG$ Driver ( Cat 80h , Func 41 &42h) to allow
I/O to be done at R3 or Appl level.  The limitation is I/O addr should be
greater than 100h.  This also has performance issues due to Ring transitions.



!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IO1)
We are trying to write some code that executes routines in BIOS.  Is that
possible without writing a device driver?  Can a DLL make calls into BIOS
directly?  Is it possible to read information from BIOS.  One of the header
files, VDMBIOS.H, has #define ROMBIOS_START in it.  It looks from the name
that this file is used to write code for virtual dos machine...  Am I right in
my guess?  Is there any help (on-line or hard copy) available for that?

To make things even more complicated, the code in BIOS supports 16-bit (real
and protected mode) calls only.  We are now using MS C 6 for 16-bit
development (device drivers mostly).  Can a 16-bit DLL have sufficient
privileges (ring 0?)  to make calls into BIOS.  Again, our main goal is to
avoid writing a device driver.

ANSWER:
1) BIOS execution Interface is provided to real mode applications but not to
protect mode applications.  It is not possible to execute routines in BIOS
without writing device drivers.

2) In OS/2 ,Physical Device Drivers do not have access to the BIOS.  The
Virtual Device Drivers does support the BIOS Hardware & Software
Interrupts.Refer to the Virtual Device Driver Ref.,Ch.-Virtual Device Driver
Architecture & Operations.Depending on the support provide by the Device's
Virtual Device Driver,DOS applications can hook the interrupt vector.  You
could use any 32-bit compiler for the Virtual Device Driver Development.

3) A Physical Device Driver could read information from BIOS using Generic
IOCtl & OEMHLP for Adapter Presence-Check Services ( TESTCFG.SYS), Category
80H and Function 40H.  Refer section " TESTCFG_SYS_GETBIOSADAPTER (40h) - Get
Copy of BIOS/ Adapter", chapter "Generic IOCtl Commands" in Physical Device
Driver Reference.

4) The file VDMBIOS.H is used for writing virtual device drivers which provide
virtual hardware support for DOS sessions( Virtual Dos Machine ) and DOS
applications.  Refer Virtual Device Driver Reference.

5) No, a 16-bit DLL does not have sufficient privilege to make calls into
BIOS.

6) To access BIOS Services you could have OS/2 Applications talk to a user
written VDD using OS/2 API's DosRequestVDD & DosOpenVDD.  This VDD could pass
BIOS parameters and calls to a small user written DOS TSR which could execute
BIOS calls on behalf of this OS/2 client ( This may involve lot of buffer
allocation and copying of parameters from one environment to the other i.e
between V86 and OS/2 environment) and pass status back to the VDD, which in
turn could pass it back to the OS/2 client.  Refer to " Communication between
OS/2 and Win-OS2 article in Devcon" for more details.




!OTHER__________________________________**********
October 6, 1995
QUESTION: (Ref: IO2)
With our implementation of the IBM ARTIC960 we have an 8MB window of dual
ported memory that is mapped above the installed system-unit memory.  It would
be nice if we could access the 8MB using a single selector because the memory
is contiguous; however the standard device helper routines do not seem to have
taken this type of situation into consideration.  Using AllocGDTSelector and
PhysToGDTSelector the 8MB region can be chopped up into 64KB sections (128 of
them).  I thought that this type of limitation should NOT exist with true
32-bit operating systems because 64K blocks are only significant when running
in 16-bit mode.  Also, the granularity bit associated with descriptors can
allow the creation of segments whose maximum lengths can be either 1MB or 2GB
(depending on the state of the granularity bit) so why the 64K limitation with
the device helper function named PhysToGDTSelector?  Our ring-3 driver
(DEVICE=) gives direct access to the 960 window to our 32-bit OS2 application
program, and 8MB descriptors can be used by 32-bit apps.  Maybe I have
overlooked something in the DDK documentation?  Please advise me if it is
possible to map the entire IBM ARTIC960 8MB window to a single selector.

If it is not possible to map the dual ported RAM to a single selector, then we
will have to treat the memory as if it were 16-bit memory by chopping it up
into 128 64K blocks (not a desirable situation in a 32-bit OS).

ANSWER:
It is not clear if you are trying to access 8MB using a single selector from a
device driver or from the application, we have the following two cases :

1) The device driver is a 16-bit model even though it is running on a 32-bit
Operating System.  Therefore it is not possible to access 8MB memory using a
single GDT selector in the driver.

2) An application could access 8MB of memory in the following manner.  The
driver could use DevHlp_VMAlloc call ( with VMDHA_PROCESS set to 1 ) to map
virtual memory to a given physical address in the process address space.
Refer section "VMAlloc", chapter "Device Helper Services" in Physical Device
Driver Reference.  Alternatively, you can set the VMDHA_PROCESS bit to 0 in
DevHlp_VMAlloc call and make the memory available to application using
DevHlp_VMGlobalToProcess call.  Refer to the routine GetLinearAccess() in the
source code \ddkx86\src\dev\screendd\svgarout.asm

3) Try DOS32FLATDS,the 32 bit r/w FLAT selector.This is an undocumented
Selector, however there are instances in which they have been used in the DDK.
Refer to - \ddkx86\src\DEV\VDISK\VDISK.ASM
\ddkx86\mmos2\SAMPLES\PCVIDEO\VBCL.ASM
\ddkx86\mmos2\SAMPLES\PCVIDEO\VBCLINIT.ASM
\ddkx86\mmos2\SAMPLES\VCADDT\VCA32.ASM
\ddkx86\mmos2\SAMPLES\VCADDT\VCAINIT.ASM

FOLLOWUP:
Thank you for your suggestions on how to obtain a single descriptor for a
32-bit app for an 8MB window above installed system memory.  I came to the
conclusion over the weekend that VMAlloc was the way to go, and after seeing
your response this week I became more certain.  In the meantime I have tested
the VMAlloc method, and it works.  I read thru all devhelp memory related
functions over the weekend and was surprised that the function named VMAlloc
looked like it could be used for this purpose (because of the name, VM stands
for virtual memory and my requirement was for physical memory).




!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IO4)

I'm currently developing a 32-bit Display Driver on OS/2 Warp for our graphics
card.  Based on the DDK sample code for S3 display driver, I've tried to
support the new DDI architecture and the old model driver.  When a command
DevOpenDC is issued or during the driver initialization, following are the
functions received in a sequential manner.

Old Model Driver                New Model Driver
================                ================

QueryDeviceSurface              QueryDeviceSurface FillLogicalDeviceBlock
FillLogicalDeviceBlock          FillPhysicalDeviceBlock
FillPhysicalDeviceBlock         EnableDC (OD_DIRECT)            EnableDC
CompleteOpenDeviceContext       CompleteOpenDeviceContext EnableDC
(OD_MEMORY)                     QueryDeviceSurface CompleteOpenDC
      etc ...
EnableDC (OD_MEMORY)
CompleteOpenDC
MoveCursor
        etc ...

Using the kernel debugger, I always get a DelayHardError at PMSHELL.EXE and
somtimes follow by trap 0D.  I managed to trace some of the functions that are
also required to be supported at the initialization after installing the debug
version of PM.  Some of these functions are QueryDeviceCaps, SetPickWindow,
etc.

So, I believe these are required for the Graphics Engine to function properly.
My questions is what are the functions that I've to support at the driver
initialization level besides those specified above ?  Also, why can't the
Graphics Engine support these ?

ANSWER:
1) Refer to the following chapters in the Presentation Device Driver Reference
for the Presentation manager functions as mandatory for all and display
drivers.  "Graphics Engine/Presentation driver design changes" and
"Presentation manager function categories".  You can also refer to section
"OS2_PM_DRV_ENABLE" for OS2_PM_DRV_ENABLE subfunctions and section "Device
Context management" for a series of calls to the OS2_PM_DRV_ENABLE entry point
at the load time of the driver in chapter "Exported driver function
reference".  QueryDeviceCaps is now supported by the OS/2 Warp GRE and is no
longer a mandatory function.Your Presentation Driver has to support only the
current OS2_PM_DRV_ENABLE and DEVESC_ functions.

2) The graphics engine is device independent.  This cannot handle device
dependent (hardware releated) issues.  Moreover the GRE simulates the given
task by breaking them into simpler graphics primitives that the device
indicates it can handle.

The graphics engine is designed so that a developer can create a presentation
driver with minimul effort and then incrementally add functions that supports
specific hardware.  By allowing presentation drivers to hook out more than a
minimum set of functions from the engine dispatch table, they will still be
able to exploit built-in algorithms and features of hardware device that are
provided to help speed up the graphics rendering process.

3) There has been some changes in the Warp level driver from the 2.x level
driver.  Replace PMWINP (in 2.x) with PMWINX Header file for the Warp level
driver.

There has also been a restructuring of the PMWIN,PMGRE & PMGPI dll's in Warp.
Consequently, you will not be able to execute your code on OS/2 2.x with the
Warp level (DevCon DDK Version 1/2) headers & OS2386P library.You could use
the 2.x Headers & Libraries to have the driver working both in 2.x & Warp.


!OTHER__________________________________
October 10, 1995
QUESTION: (Ref: IO6)

We're attempting to install a kernel debugger for OS/2 Warp Connect.  We've
got the latest Technical Connection (ver 8), but we can't find the right
debugger for Warp.  It keeps telling us that "retail version and debug version
do not match".  Do you Dudes have any hints for us?


ANSWER:
The Devcon 8 does not have the KDEBUG for WARP Connect.  You can find the
KDEBUG on the WARP Connect cd in the directory path \OS2IMAGE\DEBUG.




!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IO8)

I am trying to port a DLL from Windows into OS/2.  The DLL allows us to call
our Dell-unique BIOS functions (called XBIOS) from a 16-bit Windows DLL (and
thus from a Windows application).  The goal under OS/2 is to call these XBIOS
functions from a native OS/2 application (from a Win-OS/2 application would be
nice too).

The XBIOS functions are 16-bit real-mode functions.  In the Windows DLL we use
the DPMI service, "Call Real Mode Procedure w/ Far Return Frame," to actually
call the XBIOS function from the 16-bit protected-mode DLL.  The DPMI server
under Windows then takes care of executing the code in a real-mode (V86 mode)
context.

Parameters are passed to the XBIOS function ina buffer that is allocated by
the DLL.  Since the XBIOS functions are real-mode functions, the buffer must
be allocated in the first 1MByte of physical memory.  This is accomplished
under WIndows with the GlobalDOSAlloc call which guarantees allocated memory
to be in that range and further assures that it will not be swapped,
discarded, or relocated.

In order to locate the XBIOS function the DLL needs read access to the system
ROM in the physical range F0000h to FFFFFh.  This is accomplished under
WIndows using the AllocSelector Call.

I need to find out if this same approach is possible under OS/2.  In other
words, does OS/2 provide similar functions to applications?  If not, what do
you recommend as an alternative approach?

ANSWER:
There is no BIOS execution interface that is available to protect mode
applications.  We don't have an immediate plan to provide such, although it
has been requested over and over again and some solutions are being evaluated.

It is possible to run BIOS in protect mode by loading its code and data
segment into a linear allocated segment and execute at the correct offset.
This is risky because your BIOS code is not allowed to perform far calls into
any other segment or issue INT instructions, as these wouldn't be
translatable.

To access BIOS Services you could have OS/2 Applications talk to a user
written VDD using OS/2 API's DosRequestVDD & DosOpenVDD.  This VDD could pass
BIOS parameters and calls to a small user written DOS TSR which could execute
BIOS calls on behalf of this OS/2 client ( This may involve lot of buffer
allocation and copying of parameters from one environment to the other i.e
between V86 and OS/2 environment) and pass status back to the VDD, which in
turn could pass it back to the OS/2 client.  Refer to " Communication between
OS/2 and Win-OS2 article in Devcon" for more details.

TESTCFG has an IOCtl to read non-system memory C0000 - FFFFF which Copy areas
between 0xC0000 and 0xFFFFF to user space.The sequence is -

VerifyAccess
PhysToVirt
Read Memory
UnPhysToVirt




!OTHER__________________________________**********
October 13, 1995
QUESTION: (Ref: IQ0)
I found the sample ANDIS driver and reconstructed it using Microsoft C 6.0.
Loads and runs just fine.  Our problem is that we would like to use Watcom
10.5 to do driver development.  It's a supported compiler and produced much
better code.

The problem is that none of the Watcom PDD examples are for NDIS drivers.
They are all for PDDs.  I attempted to interpolate and rebuild the driver
using Watcom, but so far I have not been successful.

The problem is that the dll constructed by my Watcom makefiles is not
compatible with the driver loader that installs MAC drivers.

Do you know of any tools either in the DEVCON or available from other vendors
that let one disassemble/decypher a DLL?  I strongly suspect a bug in my build
procedures is causing me to have a table in the wrong place or a format error
that confuses the loader.  Unfortunately, I don't know how to further narrow
down this problem.

As a last resort, can you point me to references for the .DLL executable
format?  I can write my own disassembler.

ANSWER:
An example, dllexamp.zip, to create a dll using Watcom C compiler is available
in ftp.watcom.com/pub/bbs/c_gen.

You could use the following command to get an assembly listing of the dll
     wdisasm -l -s  <your_dll.obj>

Options:
     -l[=list_file]          generate listing file
     -s[=source_file]    include source lines




!I/O____________________________________**********
October 17, 1995
QUESTION: (Ref: IQ1)
I have a question concerning the ASYNC IOCtl Commands and their functionality
with serial ports.  It appears as though within the device driver manual there
is only Int 14H to 74H functions, yet does the IOCtl functions 4H, 5H, 8H, 6H,
10H, 13H, and 21H work with Serial ports as well?  Is there documentation out
on these ports and how to use them?  thx.

ANSWER:
Cat. 01h ASYNC Control IOCtl Commands supported by COM.SYS are -
Fns. 41h,42h,43h,44h,45h,46h,47h,48h,4Bh,53h,54h,61h,62h,63h,64h,65h,
66h,67h,68h,69h,6Dh,72h,73h,74h.

These IOCtls are documented in the Physical Device Driver & I/O Device
Driver Ref.These references are available in the DDK.

Functions 04h,05h,06h,08h,10h,13h & 21h are not supported by COM.SYS.




!I/O____________________________________**********
October 13, 1995
QUESTION: (Ref: IQ3)

We are developing a Warp 32-bit PDD for a Highspeed Multimedia Serial
Communications Adapter (ASYN/SYNC).  I have the Developers connection DDK of
OS/2 with the ATCOM source code samples in ASEMBLER but would like to find
another source code sample of a 32-bit PDD for a Serial Comm Adapter in 'C'.
If you could provide me with some sample code or know where I might be able to
find it please let me know.

ANSWER:
There are no sample source codes for a 32-bit serial com drivers in C. As a
matter of fact the driver on the DDK that is written in ASSEMBLER is 16-bit
not 32-bit.



!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IQ6)
Working on c/c++ programs, compiling with cset c++ v2.0, i get edc4005 error
"error occurred in an intermediate file.  an internal compiler error has
occurred.  recovery:  contact your ibm service rep."

Any clues as to what i need to do to get around this error?

ANSWER:
Please contact the CSETT Group in Toronto, this is not a device driver
problem.




!VIDEO________________________________**********
October 13, 1995
QUESTION: (REF IQ8)

I have a Image Capture Board.  The PCI Plug&Play is telling me that the board
is located at 0xC800.  I need to read and write registers that are mapped in
the boards space.  The space is 0x01FFh large.

To do this do I:


    PBYTE           pdimem;         <-- Pointer returned by PhysToUVirt
    USHORT          TagType=0;      <-- Do I set this to 0;


 rc=DevHelp_PhysToUVirt((ULONG)pdi.base_sel, // Where pdi.base_sel is (USHORT)
                           (USHORT)0x01FF,      // Size of register space
Is this Correct----------->(USHORT)SELTYPE_R2DATA,  <-- Is this correct
                           (USHORT)TagType,
                           (PPVOID)&pdimem);


Then to access the memory, like a register:
        Set A Register:
                *(pdimem|0x0200) = 4;
        Read A Register:
                MyValue = *(pdimem|0x200);
                // So MyValue here should be 4 ???

ANSWER:
I am unsure what context from which you wish to write to these registers.
Since you are using PhysToUVirt, I will assume that the memory (registers) are
to be accessed outside of the device driver.  If you want the device driver to
have access to the registers, you should use DevHlp_PhysToVirt.  Concerning
PhysToUVirt, the TagType is only important when the flag is set to
SELTYPE_R3VIDEO.  In your case, the TagType is unimportant.  Concerning your
other question, the flag SELTYPE_R2DATA means that the virtual address
returned will be accessible only by IOPL code (which are ran at Ring 2).  If
you want your application to access the virtual address, you should choose
SELTYPE_R3DATA (which can be accessed by Ring 3 programs).  Again, I am unsure
of which context you are accessing the registers.

For a complete description of these flags and the function PhysToUVirt, please
check the Physical Device Driver Reference under DevHlp Services.

I hope this answers your questions completely, but if not please let me know.

QUESTION2:
Thanks for the answers.

I need to access my memory mapped card is all cases.  So I changed things a
bit.

I am mapping the card to a GDT and then getting a pointer to the base memory.

My code fragment:

    SEL             Selector;                   // For board address
    PVOID           pPDI;                       // Pointer to Board base

    ULONG           FEid;

    rc=DevHelp_AllocGDTSelector((PSEL)&Selector,1);
    if(rc){
        sprntf(MSGBUF,"\r\nERROR: AllocGDTSelector = %ud\r\n",rc);
        usMsgLen = DDstrlen ( MSGBUF );
        DosPutMessage(1,usMsgLen,MSGBUF);
    }

    rc=DevHelp_PhysToGDTSelector((ULONG)pdi.base_sel,(USHORT)0x01FF,
                                 (SEL)Selector);
    if(rc){
        sprntf(MSGBUF,"\r\nERROR:PhysToGDTSelector=%d\r\n",rc);
        usMsgLen = DDstrlen ( MSGBUF );
        DosPutMessage(1,usMsgLen,MSGBUF);
    }

    pPDI=(PVOID)MAKEP(Selector,0);

FYI here are predefined values
{
#define RegisterBase        0x00000000UL
#define WhiteVoltageReg     (RegisterBase|0x0454)
#define StatusReg           (RegisterBase|0x0474);
}


ANSWER2:
The physical address you are using is given as 0xc800.  This should be a ULONG
value i.e.  0xc8000 in the PhysToGDTSelector DevHelp call.  Also your selector
has an addressability of 0x1ff (512) bytes.Consequently all your accesses
beyond 512 bytes will cause a Trap.  You could use an appropriate value in
PhysToGDTSelector - Segment Length for addressability greater than 512 bytes.




!OTHER________________________________**********
October 20, 1995

QUESTION1:      (Ref: IR0)
I'm looking for a way to address a DMA buffer allocated in the VDD with
VDHAllocDMABuffer from a 286 protect-mode task (Win .drv).  I've tried calling
the PDD for a PhysToUVirt at VDM task time but that didn't work Now I'm
looking at the VPMX services but I see know way of setting the base (linear)
address of an allocated selector.  Any ideas?

ANSWER1:
You could use the following DPMI calls, ver 0.9 :

1) Int 31h, function 00h, AllocateLDTDescriptor, which gives the base
selector.

2) You could then use Int 31h, function 07h, SetSegmentBaseAddress with the
selector obtained from AllocateLDTDescriptor and Linear Address from
VDHAllocDMABuffer.

Alternatively, you could use the following window calls :
AllocSelector and SetSelectorBase.

QUESTION2:
I would prefer to use one of the VPMX calls for setting the base address since
that should be easier from the VDD (which this must originate from).  Do you
have any code snippets for doing something like this with VPM calls?

ANSWER2:
There are no VPMX calls for obtaining a selector .Use the DPMI calls mentioned
in the previous response.

QUESTION3:
Just to add more confusion to the fire, I've tried to map a selector in a 286
PM test program and realized that the linear address being returned by
VDHAllocDMABuffer is higher than the 24-bit limit imposed on tasks at that
level!  Does this imply that this VDH call shouldn't be used to allocate such
a buffer if it to be addressed in the DOS session?

ANSWER3:
The VDHAllocDMABuffer returns both linear & physical address.  The linear
address is returned by the call in the return value RC and the third parameter
PhysAddrPtr gives the address of the physical address of the allocation.

You are probably checking the linear address, which can be anywhere in the
memory.It is the PHYSICAL ADDRESS of the memory that should be below 16MB.

What is the value you are getting in the third parameter i.e., PhysAddrPtr to
the VDHAllocDMABuffer call?

QUESTION4:
I'm confused then.  What does the vpmx_SELAllocVDM in vpmx2.h point to?
Cannot this mechanism be used by the VDD instead of DPMI int calls.  Also, any
comments on linear address returned by the AllocDMABuffer function (>24 MB).

ANSWER4:
The VPMX service is provided by the kernel to the virtual DPMI driver, not for
user VDDs.  You can make DPMI calls through INT 31H.  The linear address
returned by the AllocDMABuffer can be anywhere in the memory.

Alternatively you could have win.drv allocate the memory and pass the linear
address to the memory in a call to the virtual device driver.  The virtual
device driver then can issue VDHLockMem to convert the linear address to
physical addresses for DMA purposes.  Win.drv can then always access the
memory since the vitual address was returned on the allocate call.

CONCLUSION1:
I understand all about VDHAllocDMABuffer and the physical addresses I've been
getting back have been fine but the linear address seemed unadressable by the
VDM.  In turns out that an VDHAllocPages with the physical address returned
did the trick for the VDM linear address which left only the selector to be
setup.  I've also got that working now with the DPMI calls from the VDD
(although pushing and arming in that way one after the other is overly messy).

CONCLUSION2:
I have solved the problem but all the PushInt and Hook returns make it very
messy.  It's a shame that user VDDs can't make DPMI calls directly.  Also,
since I'm trying to emulate a VxD with minimal changes to the Win DRV, I'm
unable to make the DPMI calls from the DRV or to allocated the memory through
win.drv.




!OTHER__________________________________**********
October 12, 1995
QUESTION: (Ref: IR4)
PCI presence check does not work with OS/2 2.11

We have written a presence-check function to be used during installation of
our device driver for a PCI-to-SCSI host adapter.  We use Category
IOCTL_OEMHLP (80h), Function OEMHLP_PCI (0Bh) and Subfunction 01h, Find PCI
Device.  We open the file OEMHLP$ and make the call to DosDevIOCtl with the
above parameters included.  When the OS version is OS/2 Warp Full Pack or OS/2
Warp Connect, our presence check works and we install automatically if our
board is present and do not install if the board is not present.  However,
when the OS version is 2.11 (with no fix packs), the Device Driver
Installation routine reports that the board is not present even when it is.

Is the OEMHLP support as described in oemhlp.pci present in OS/2 2.11?  If
not, how do you recommend we handle presence checks?

ANSWER:
This problem is documented in APAR PJ14230.  PCI support was not added until
OS/2 Warp.  To get the PCI support for OS/2 2.11, you will need a fixpak 98 or
later.  You can obtain the fixpak from the IBM BBS (919-517-0001), or you can
contact the OS/2 supportline (407-994-5544) and request APAR PJ14230.



!OTHER________________________________**********
October 13, 1995
QUESTION: (Ref: IR5)

My question is for a developer that a call on.  They have written a 32bit
program that accesses a proprietary board to control a testing unit.  The
board is not being shared, it is only being used by this program.  They have
ran their program on NT, writting a driver for their board, and they are
unhappy with the timing delay of how long it takes from the time the program
makes a call, to the time that the device driver is accessed.

They want to know if in OS/2 they can write the address and interupt of the
board in their program and make direct calls, or if OS/2 has less overhead
allowing the time between the program call and the device driver starting to
be very little.  (Most importantly is the timing less than NT.)

ANSWER:
There are ways in OS/2 that will allow you to "map" the physical memory space
of the proprietary board to virtual memory and then pass it to the application
via an DosDevIOCTL call.  In order to do this, a device driver must be written
and called by the application at least once in the beginning to get the
virtual addresses.  This device driver must be loaded at boot time but may map
the physical memory of the board at init time or call time.  There is no way,
however, for the application to directly intercept interupts.  This can only
be done by the device driver.  If the application is addressing the device
directly and not going thru the driver, there will have to be some tricky
coding, such as the use of semaphores and multi-threading, for example, to
allow the interupts to be passed by the device driver to the application and
be noticed.  Therefore a physical device driver interface should still be
considered versus a direct application interface.

When the application calls the device driver to communicate with the device,
the kernal acts as an interface between the application and the device driver.
It is the kernal's job to format a request packet and call the device driver.
This can be as simple as just reorganizing the application input and calling
the device driver.  At most the kernal verifies and locks down the buffer the
application provides, as well as converting it to a physical address.  This
happens on DosReads and DosWrites, whereas the kernal does little when
DosDevIOCTLs are used to communicate to the device driver.  Interupt routines
are kept as short as possible and are called quickly when an interupt occurs
with little intervention by the kernal.  Let me stress that the device driver
talks directly to the device it is controlling and does not have to go thru an
abstraction layer.  I have no knowledge of Windows NT but I hope this helps.

ALSO:
The direct I/O can be made by the application with a 16-bit IOPL segment.  But
this is not portable.  The I/O can also be done using the TESTCFG$ driver
calls if the port address is above 100h.  However there will be a performance
penalty in these methods due to Ring transitions.

Only a device driver can handle the interrupts.  If you want to do the
operation at the application level, you could write a device driver which
hooks the interrupt (shared or non-shared mode) and post the application
thread's semaphore when an interrupt is detected.  So when there is an
interrupt, the application thread will wake up to do the operation.  But the
response will be slower than doing the operation in the driver itself.

The performance in OS/2 will be faster than NT due to lesser number of layers.
The I/O request flow in OS/2 and NT is given below.

         OS/2                                          NT

    +---------------+                             +---------------+
      Application                                 Application  
    +---------------+                             +---------------+
                                                            
           V                                                 V
    +---------------+                             +---------------+
        Kernel                                       Kernel    
    +---------------+                             +---------------+
                                                               
             V                                                  V
    +---------------+                           +---------------------+
     Device Driver                             I/O Management Layer
    +---------------+                           +---------------------+
                                                           
             V                                              V
    +---------------+                             +---------------+
       Hardware                                  Device Driver 
    +---------------+                             +---------------+
                                                             
                                                             V
                                                +----------------------+
                                                 H/W Abstraction Layer
                                                +----------------------+
                                                          
                                                          V
                                                   +---------------+
                                                       Hardware   
                                                   +---------------+


In NT, the operation to be done at the interrupt time are carried out in DPC
(Deferred Procedure Call) which runs in the task context.  So this will be
called on priority basis after the completion of all the ISRs.  Where as in
OS/2 the operation can be carried out in the ISR itself provided the ISR takes
less than 400 micro seconds.



!NETWORK________________________________**********
October 18, 1995
QUESTION: (Ref: IR8)

I am new to the development of OS/2 Network Device Driver. What is the NDIS-
MAC develop environment ? What develop tools should order from I.B.M ? How
can I get a sample source of NDIS-MAC driver ?

I already have the DEVCON cd/DDK, and The DEVCON for LAN System cd.  But I can
never find the NDIS-MAC sample source code.  How can I get that ?

ANSWER:
There is one sample code in the DEVCON LAN SYSTEMS CD (Volume 4, Disc 1),
called MACNDIS.

There is a directory called ANDIS (in the root directory), in there in all the
information we currently have on NDIS.



!STORAGE________________________________**********
October 25, 1995
QUESTION: (Ref: IS2)
Is a guide avalible with example code on how to write floppy disk flt drivers

ANSWER:
The only general reference about filters is available in the Storage Device
Driver Ref.  - Ch.  Using Filter Device Drivers.

There are no source codes for floppy disk filter driver in the DDK.  However,
the DDK does have the source code for -

CDROM filters (ATAPI)
Removable DASD Conversion Filter (LOCKDRV)




!OTHER________________________________**********
October 20, 1995
QUESTION:  (Ref IS3)
Is it possible for a 32-bit app to have access (thru the device driver) to a
fixed, contiguous area of normal system memory (not adapter memory) if the
size of the memory block is greater than 64KB, from a single selector?

I already know several methods of obtaining application pointers to fixed and
contiguous memory suitable for PCI transfers, but they all have a 64KB
limitation on the length (i.e.  PhysToVirt, PhysToUVirt, VMAlloc + Global-
ToProcess).  Since AllocPhys allows fixed and contiguous allocations with
unlimited size, and because WARP is a 32-bit operating system, I expected to
see a device helper function that would produce addressability to a fixed and
contigous block of system memory whose length is not limited to 64K (using a
single base pointer).

If no such mapping is possible, then 32-bit system memory (when fixed and
contiguous) which is accessible to 32-bit applications must be treated
logically as 20-bit memory by the 32-bit applications.  This causes a
performance penalty for our realtime device that should only be encountered
with real mode programming, by adding complexity to the buffer management.

The size of the PCI buffers in our OEM devices are multiples of 4MB, and we
don't understand why these buffers need to be chopped up into 64K blocks.  As
far as I know, this restriction even applies if OS2 is run in non-paged mode
(which is the case with our OEM boxes).  Interestingly enough, this problem
does not exist if the buffers reside in adapter memory (i.e.  8MB of memory on
a PCI adapter which is mapped to physical address E0000000 can be accessed by
a 32-bit application using a single selector, after a device driver has made
the appropriate call to VMAlloc on behalf of the application.  Note that
VMAlloc cannot return fixed contiguous system memory to the app process space,
and if global space is requested then GlobalToProcess must be called in order
to make the pointer available to the app process space, and unfortunately
GlobalToProcess has a 64KB limitation).

ANSWER:
It is possible to obtain a fixed, contiguous, buffer of memory using VMAlloc
at init time.  The chances of getting this buffer only depends on how much
memory is left in the system at init time.

There is no 64K limit in VMGlobalToProcess.  If the VDHGP_SELMAP bit is set,
16-bit selectors are allocted to map the 32-bit region at 64 KB boundries
similar to DosAllocHugs, however setting this bit is optional.

VMAlloc does not create a selector to map memory.  A single selector can only
map 64KB of memory.  VMAllloc creates a linear address that does not have this
64KB limit.



!OTHER________________________________**********
October 20, 1995

QUESTION1:      (Ref:  IS6)
I have a question on using Watcom's C compiler to construct PDDs.  In
particular, I am confused by several examples in the Watcom sample PDD driver.

I don't know if the problem is that there are problems in the sample timer
driver code or if my understanding of DevHelp calls is simply wrong.

This code is distributed in the samples\os2\pdd directory of the Watcom 10.5
installation.  The file of interest is devaux.h

Now, according to the DevHelp documentation, The SetTimer dev help call takes
a timer handler offset in register AX.  If the call works, the C flag is
cleared.  If there is a problem, the C flag is set and an error code is set in
the AX register.

Furthermore, the documentation for DevHelp states that, unless specified
otherwise, registers are left unchanged by the function.

So, my read of the specification is that after a SetTimer DevHelp call the
following is true

C == 0 implies all registers unchanged.  AX continues to hold
       the code offset parameter.
C == 1 implies error code in AX.

Is my understanding correct?

Now, the Watcom interface for this call is shown below.  DevHlp is a 32 bit
word that contains the DevHlp pointer supplied by the init strategy request.

If the routine failed, ax contains:
   code & fffe, the error code returned by DevHelp with the
   low bit clear.

   Are error codes always even numbers?  If not, we've just
   changed the error code that we are going to return to the caller.

2) If the routine worked, ax contains:
   old_ax & 0xffff, or the original value in the ax register

In this case, that would be the timer service routine offset.  Most probably,
not zero.  The only way that I can see this code working is that if:

1) the DevHelp routine always clears ax if there are no errors and

2) DevHelp error codes are always even numbers.

Is this how these routines really work?

ANSWER1:
The DevHelp_SetTimer returns with the carry flag clear if the call was
successful and AX continues to hold the offset of the timer handler.  The
SetTimer call returns with carry set if an error occured and the error code is
returned in AX.

The error codes for DevHelp_SetTimer could have the following two values:
       324 : No Timers Available
       326 : Invalid Timer Handle

An appropriate DevHelp declaration would be -
USHORT DevHelp_SetTimer(NPFN TimerHandler);
#pragma aux DevHelp_SetTimer = \
                 "mov  dl,1Dh" \
                  DEVHELP_CALL \
                  parm caller nomemory [ax] \
                  modify nomemory exact [ax dl];

If you have the DDK,you could get the Watcom Version of the DevHlp Library.




!PCMCIA ____________________*************
October 25, 1995
QUESTION: (Ref IT1)
I have tried to build a socket services device driver from the source files in
the Development Kit but I have not been successful in getting it to work.  The
name of the device driver is SSPCIC.SYS.  It is built from the supplied source
files in the directory DDKX86\SRC\DEV\PCMCIA\SOCKET.  For testing purpose, I
replaced the IBM2NEC1.SYS in the CONFIG.SYS file with SSPCIC.SYS.  The system
halted after this replacement.  Could you tell me if the file SSPCIC.SYS is to
be used in the same manner as other socket services drivers such as
IBM2NEC1.SYS, IBM2MAT1.SYS, IBM2CMQ1.SYS , Etc?  Do I need to add additional
codes to make it work?

ANSWER1
The Socket Services Driver is Hardware Specific and is not a Generic Driver.
SSPCIC.SYS   - Intel PCIC Step B Controller Socket Services Driver
IBM2NEC1.SYS - NEC VERSA Socket Services Device Driver
IBM2MAT1.SYS - Matsushita/Panasonic Socket Sservices Device Driver
IBM2CMQ1.SYS - Compaq Concerto Socket Services Device Driver

QUESTION2:
If I want to test SSPCIC.SYS, where do I place this driver in config.sys so
that OS/2 will use it ?

ANSWER2:
If your hardware supports Intel PCIC Step B Controller ,you should have the
following lines in your CONFIG.SYS (in the same order- Card Services & then
Socket Services) -

BASEDEV=PCMCIA.SYS
BASEDEV=SSPCIC.SYS

NEC VERSA  C , AST PowerExec ,NCR Safari  & ThinPad 500 / 350 should work
Matsushita/Panasonic & Compaq Concerto will not work (since they use Cirrus
Controller )

The socket services are implemented as BASEDEV drivers.  The Base Device
Drivers are loadedin the following order :  .SYS, .BID, .VSD, .TSD, .ADD,
.I13, .FLT, .DMD.  Among the files with the same extension, those files are
loaded in the order in which they are encountered in the CONFIG.SYS file.

Refer sections " OS/2 Initialization Architecture " and " Invoking the Sample
Socket Services Device Driver ", chapter "PCMCIA Architecture" in Input/Output
Device Driver Reference for more information.



!OTHER ____________________**************
October 25, 1995
QUESTION1:  (Ref IT2)
I am trying to write a daemon that will cause the system to shutdown and
reboot when an associated physical device driver detects a certain hardware
condition.  I was intending to use the WinSystemShutdown API, but don't see
any way to make the system reboot with that call.  Can this call be used to
make the system shutdown AND reboot?  Is there any way I can cause the system
to perform an orderly shutdown and reboot from the physical device driver
itself?

ANSWER1:
Use DevHelp_SendEvent( (USHORT) EventType, (USHORT) Parm ); With EventType = 7
and Parm = 0. EventType =7 will simulate a Ctr-Alt-Del.  Please refer to the
Physical Device Driver Reference in the DevHelp section under SendEvent for
further information.

FOLLOWUP:
I am trying to find out how to first perform an orderly shutdown of the
applications and OS and then reboot the machine.  I have found that the
WinSystemShutdown will perform the orderly shutdown from an application /
daemon, and that the DevHlp_SendEvent will allow a Ctrl+Alt+Del to be
simulated, but I can't figure out how to coordinate the two requests such that
the reboot via the Ctrl+Alt+Del is not performed until the orderly shutdown is
completed (i.e.  the message box telling the user it is OK to reboot or power
off appears).  Can you tell me how that can be done?

Also, I want to find out if there is a way for me to power the machine off
after the orderly shutdown is complete instead of rebooting the system.

ANSWER2:
The WinShutdownSystem function will close all running applications and will
then call DosShutdown.  Presentation Manager applications will receive a
WM_SAVEAPPLICATION message prior to a WM_QUIT message.  When the system is
restarted, all applications that were running when WinShutdownSystem was last
called will be restarted.  When DosShutdown is invoked , the kernel sends a
shutdown packet to all physical device drivers registered with the system.You
could write a simple PDD that comes up,registers with the system,then waits
for a shutdown packet.  When it receives a shutdown packet you could invoke
DevHlp_SendEvent with Event=REBOOT



!VIDEO _________________________________**********
October 25, 1995
QUESTION:  (Ref IT4)
I need to find out from some of the Multimedia driver folks at IBM exactly
what information is being fetched from our video driver to determine RGB
ordering when the Digital Video App is started.  We have different results
when using different version of the DIVE DLLs, and we believe that if we can
determine how the RGB ordering is determined, we can come up with a fix (or a
workaround) to correct a problem we are having with playback of .AVI files in
24BPP and greater color modes.  We currently get what looks like BGR rather
than RGB when we use the DIVE and SVSH DLLs dated August 27, 1995.  We get the
same results with or without ENDIVE support enabled.  When we use the July 21,
1995 versions, the color appears fine.

ANSWER
The fccColorEncoding will be BGR when the scan line size is negative and RGB
when the scan line size is positive.  If the bytes per pel are 4 then
BGR4/RGB4 is used, if the bytes per pel are 3 then BGR3/RGB3 is used.




!VIDEO__________________________________**********
October 27, 1995
QUESTION: (Ref: IS5)
I am trying to create a display driver install disk, and I am trying to find
out what do I need to put on the Disk (in addition to the driver and and the
DSP file), and once I have the Disk, where do I copy these files and what do I
need to change in config.sys, os2.ini, system.ini, and win.ini.  I read
Chapter 10 of Display Driver Refrences but it did not answer these questions.
It also seems to me that I need a CMD file that copies the files to the
HardDisk and after shutdown you run the DSP file!!?  At what step do I need to
modify config.sys.

ANSWER:
A complete display driver installation package will usually includes the
following files:

      DSPINSTL utility program.
      DLL, including the action routines( if they are used ).
      One or more DSC configuration files OR  One or more
      DSP files containing
      DSPINSTL installation and configuration commands. Display Driver files.
      Other files if necessary.
      Programs to be triggered by RUN commands in DSP files.

Refer section "DSPINSTL commands", chapter 12 - "Installing and Configuring
Display Drivers" in Display Device Driver Reference (DDK 2).  Also refer to
vga.dsp in \ddkx86\src\cmd\svgainst for usage of FILES, CONFIG, OS2INI, WININI
and RUN commands.
The files are copied with the :FILES - DSPINSTL command




!STORAGE ____________________**************
October 25, 1995
QUESTION: (Ref IT8)
I generated IBM1FLPY.ADD driver from the source code provided with DDK.
Loading this driver with OS/2 WARP, the machine (this happens with more then
one machine) hangs.  Using OS/2 KERNEL DEBUGGER I can see that an INT3
instruction (Break Interrupt) is executed and this causes the machine hangs
when using the retailed OS/2 KERNEL.  How I can make a running floppy driver
from DDK source code provided with THE DEVELOPER CONNECTION?

ANSWER:
The int 3 instruction is executed only when some call fails.  If the
information provided to the host system is incorrect or if the BIOS does not
support the third or fourth floppy drive, an error might occur.  IBM1FLPY is
the diskette driver for ISA/EISA bus system.  IBM2FLPY is the ABIOS floppy
adapter driver for diskette drivers on Micro Channel System.  Once you hit the
INT 3 Breakpoint you could invoke the following Kernel Debugger Command at the
"#" Prompt :  "ln" This should give you an approximate idea about where a Call
has failed.  You could also use the ".k" command.
