Sorry for the delay in replying.

Vitus Jensen wrote in a message to Mike Bilow:

 MB> These packets are owned by the caller, and the callee has no
 MB> business changing their lengths.

 VJ> ? Has no business ?

 VJ> [...nasty address mapping removed...]

 VJ> ? Did you understand what I meant?  My english is very bad,
 VJ> but I thought you could made some sense out of it.
 VJ> I released DSKSleep.flt 0.81 some days ago (the header
 VJ> solution) but let me provide an example anyway.

You are right: I completely misunderstood your question.

 VJ>   pcbDataLen (PULONG) - in/out 
 VJ>      Pointer to the length of data. 
* * *
 VJ> *HOW* do I return this "length of the data returned"?

OS/2 is trying to confuse you.  In OS/2 1.x, DosDevIOCtl() has a certain
defined calling format.  When length information was added in OS/2 2.x, the
old format had to be preserved, and the new format became DosDevIOCtl2().

System magic occurs to translate these back and forth.  New format drivers
must indicate upon load that they will accept the longer format packet by
setting the proper bit in the DD header.  You must flag the driver as
function level 3 in bits 9-7 (DEV_FCNLEV) of the Device Attributes
(SysDev.SDevAtt), which indicates that there is an extra doubleword at the
end of the DD header, the Device Capabilities Doubleword
(SysDev3.SDevCaps).  You must then set the DEV_IOCTL2 bit (0x00000001) of
this SDevCaps field to indicate support for the longer IOCtl packet format.

      If the physical device driver indicates in the function level of the 
      Device Attribute field of its device header that it supports 
      DosDevIOCtl2, the generic IOCtl request packets passed to the physical 
      device driver will have two additional WORDs containing the lengths of 
      the Parameter Buffer and Data Buffer.  If the physical device driver 
      indicates through the function level that it supports DosDevIOCtl2, 
      but the application issues DosDevIOCtl, the Parameter Buffer and Data 
      Buffer Length fields will be set to 0.

In other words, your new format driver will receive this as the request
packet format, with the extra words added:

   typedef struct _RP_GENIOCTL  {          /* RPGIO */
     RPH           rph;
     UCHAR         Category;
     UCHAR         Function;
     PUCHAR        ParmPacket;
     PUCHAR        DataPacket;
     USHORT        sfn;
     USHORT        ParmLen;                /* VPNP */
     USHORT        DataLen;                /* VPNP */
   } RP_GENIOCTL, FAR *PRP_GENIOCTL;

If you modify the RP_GENIOCTL.ParmLen of RP_GENIOCTL.DataLen words in the
driver before signalling "done," then this information should be
returned to the caller.  Note that there is no way for the driver to know,
if these words initially contain 0, whether the caller is actually making a
new style call, in which case the values will be returned, or an old style
call, in which case the values will be discarded.

When OS/2 processes the DosDevIOCtl()/DosDevIOCtl2() call, it uses the
ulParmLengthMax and ulDataLengthMax arguments only to process the buffers
into a specially mapped segment for the driver, but does not actually pass
these argyments to the driver.  It is *pParmLengthInOut and
*pDataLengthInOut which are passed back and forth to the driver, with OS/2
handling the dereferencing on its own.

Finally, note also that, although several of these parameters are 32-bit,
this is done simply to promote speed of stack handling.  You cannot under
any circumstances pass IOCtl buffers or buffer size counts larger than 64
KB.  (The actual limitation is that the parameter packet buffer and data
packet buffer *combined* cannot exceed 64 KB, but this is just an
implementation restriction in the current versions of OS/2.)  You must also
avoid the special case where an IOCtl buffer is exactly 64 KB if you intend
to rely on the length information, since 0x00010000 would be truncated to
0x0000 in the request packet, and zero values have special meanings as
described above.
 
-- Mike


---