[jcifs] Shared Printing - Figured it out (sorta)

[Christopher R. Hertel]

On Tue, Jun 17, 2003 at 02:53:41PM -0500, Michael.Colemen at anixter.com wrote:
> I think I've found out why shared printing is not working (invalid
> parameter error). In the SmbFile.open(int) method there is a query of the
> server capabilities. If CAP_NT_SMBS is supported, then a SmbComNTCreateAndX
> is performed. Otherwise a SmbComOpenAndX() is performed. I'm not sure if
> there is any correlation, but in the SMB documentation I found, there is a
> OPEN_PRINT_FILE but not a CREATE_PRINT_FILE. In any case, when I remove the
> check for capabilities, I am successful at printing.

There are three different print systems in SMB.  The earliest uses these 
SMBs:
SMB_COM_OPEN_PRINT_FILE  0xC0
SMB_COM_WRITE_PRINT_FILE 0xC1
SMB_COM_CLOSE_PRINT_FILE 0xC2
SMB_COM_GET_PRINT_QUEUE  0xC3

In older docs (eg. SMB-CORE.ps) these are known as:
SMBsplopen  0xC0
SMBsplwr    0xC1
SMBsplclose 0xC2
SMBsplretq  0xC3

These go way, way back.  In the CORE Protocol documentation, the 
SMBsplopen command is documented in a section labeled "5.23 Create Print 
File"... so the terminology gets confused.

So, moving along several years, the CAP_NT_SMBs capability bit is used to 
indicate whether or not WindowsNT features are supported.  If they are, 
then more advanced SMBs can be used...if you're brave.

The NT_CREATE_ANDX SMB is an evil mess.  It shows what can happen if 
you're adding message types to a protocol and you know too much about the 
specifics of the one and only OS you're interested in talking to.

Here's the deal, though.  The two other printing subsystems are both based
on remote proceedure call interfaces.  The mid-level system (commonly used
by W9x, I believe) is based on RAP (Remote Administration Protocol) while
the most "advanced" uses MS-RPC.

The RAP system may be do-able.  I don't know, because I've never tried.

There have been several presentations given by Samba-folk regarding the 
MS-RPC-based print system.  It does odd things like send object code 
(Intel-only, with Win32 API calls) to the server, expect the server to run 
the object code, and return the results.  I have a feeling that we won't 
be playing with that system much.

So, anyway, what you have implemented is the original system.  That's a
very worth-while starting point.  I don't know if Mike and Eric will be
interested in merging it into the main code tree but I'm glad it's
available.

Thanks!

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org