
PSHARE V1 shares printers across IPX network without Novell.


PSHARE is a print utility which provides shared use of one or more 
printers across an IPX network.  It utilizes a 5k DOS TSR on each client 
workstation and does not require a Novell file server or software other 
than the PSHARE programs & network drivers.  The PSHARE server program 
runs on a PC to which the shared printer is attached.  It queues, then 
spools, print jobs sent by the clients.  An automatic upgrade option is 
built in; if the client program is upgraded, the server can field the 
upgrade to all users without use of any shared directories.  Printing 
from Windows 3.x is supported.


PSHARE is written in Microsoft C 6.0 & assembly and runs under DOS.  It 
requires Novell IPX drivers to be loaded, but uses only IPX/SPX and 
never requires any Novell file server resources or the user to be logged 
in.


Server side:  (PSS.EXE):  This collects the jobs sent by all the PSC 
installations, queues & prints them.

1.  Running PSS

	PSS requires one parameter; the name you want to assign to it.  It 
is best run by your AUTOEXEC.BAT, after the network drivers are loaded.  
Although PSS will work in DOS box under Windows, generally it will be 
better to run it on a stand-alone PC to which the shared printers are 
attached.  (Some old, funcky 286 is fine, we're using a PS/2 70).  PSS 
uses only disk space for the queued files and conventional memory for 
buffers.  PSS doesn't use EMS, DPMI, XMS or graphics.  By default, PSS 
uses direct port I/O when printing, supplying /B on the command line 
will force use of slower BIOS writes.

2.  PSS Printer ports

	PSS will support redirection to LPT1 thru LPT3 only.  If a printer 
is not attached to a port to which a job is sent, the job will just sit 
there waiting for a printer ready signal.  If PSS is run in a DOS box 
under Windows 3.x, you may experience character loss (by virtue of how 
Windows operates the DOS box).

3.  Job Control

	PSS offers no job control options, (ie: pausing, canceling jobs), 
BUT if PSC stops sending (rebooted PC, for example), after a minute or 
so, PSS will assume something happened, and will kill the job.


Client side:  (PSC.EXE):  Run on each PC which will use the shared 
printer(s).

1.  Running PSC

	PSC requires a couple parameters to run; first the name of the PSS 
instance to which it will attach, and the local LPT to remote LPT 
assignments.  The client PC has LPT1 thru LPT3, as does the PSS machine.  
By specifying Lx=Ry; where x represents the client PC port (L 
representing Local) and y represents the server PC port (R representing 
Remote), you assign local ports to remote ports.  At least one 
assignment is required, but you're don't have to use LPT1 first.  Run 
PSC without parameters to see the command line help.  At this time, PSC 
cannot concurrently connect to printers on more than one PSS server.

2.  General

	When PSC is run & the parameters found valid, it tries to find the 
PSS instance to which it is supposed to attach, then it connects and the 
PSC version is checked.  If it is old, PSS transmits a copy of the new 
version to PSC, which writes it out to disk and exits with return code 
255.  If PSC is run from a batch file, the ERRORLEVEL function can test 
for this, loop and re-run PSC.  The PSC version is then OK, and PSC can 
proceed.  Once the version is resolved, PSC installs itself, leaving the 
5k TSR resident.  The resident portion is what redirects the printer 
output.  PSC picks off data sent via INT 17h, builds buffers and 
transmits them via IPX to PSS where they are spooled to a file.  PSC & 
PSS use basic flow control to handle packet loss & duplication.  Once a 
job has started, if there is no data sent to INT 17h for a given time 
period, PSC considers the job done and commits it.  PSS then queues the 
file and spools the job to the printer.  Unfortunately there is no 
attractive way I know of to detect the end of print jobs at the BIOS 
level, so the timeout is the mechanism.  If you start printing a new job 
before the timeout expires, your new job will be added to the end of the 
previous one, giving you a single bigger job.  (Might print OK, might 
not).  The timeout is about 15 seconds, and is hardcoded (via #define).  
Jobs can be sent concurrently via any combination of the 3 local LPT 
ports, and they will not interfere with each other.


3.  Interaction w/ other printer redirectors

	If PSC receives INT 17h data, and is not already redirecting a 
job, it calls down into the INT 17h chain to find the port status.  If a 
local printer is online or a lower-level driver is redirecting that 
port, a result code is returned indicating the printer is ready.  PSC 
will then pass data directly down the chain without redirecting, until 
the job is completed.  If drivers higher in the INT 17h chain are 
redirecting, the data will never reach PSC so PSC doesn't do anything.  
This way, if CAPTURE, for example, redirects a particular port, it will 
override PSC until the CAPTURE is removed.  Similarly, if your local 
port has an AB switch, you'll print locally when the switch is in your 
position, and to the PSS printer when not.  Ports not redirected by PSC 
are not affected by PSC's presence.  PSC always returns a printer ready 
status when queried via INT 17h.  If PSS isn't ready for the job, or 
stops receiving part way through, PSC will timeout after a while and 
return a printer error via the printer status code.


4.  PSC under Windows 3.x

	PSC will redirect the Windows print output just as in DOS.  You 
might consider enabling Print Manager so pauses in printing won't cause 
the job to be prematurely committed.


5.  Auto-Upgrade issues

	This option is relevant if you modify PSC and want the updates 
fielded to the user workstations.  Compile PSC & PSS and put both 
executables on the PSS server machine, in the same directory.  Run PSS 
from the directory where it is located.  Then when the users connect, 
they will be automatically upgraded by PSS.  No hassle!  If you write 
protect the user PC copies of PSC, the upgrade will fail, and PSC will 
start anyway (the old version, of course).  PSC.EXE must exist in the 
directory from which it is run for the upgrade to work.  Obviously the 
autoupgrade feature could easily spread a virus if your new PSC version 
on the PSS machine became infected.

6.  Unloading PSC

	PSC can be unloaded once it is resident by running it again, 
without parameters.  It will check for re-hooked interrupts, and if 
there are none, it will unload itself.  When unloading, PSC will 
immediately commit any jobs waiting on the job complete timeout.



Techie stuff:

1.  You might experience some trouble with the TLI functions (they are a 
wrapper around SPX, which PSHARE uses for the autoupgrade), particularly 
in terms of opening/binding endpoints in PSS.  I'm not sure why this is, 
but appears related to the size of the app's near heap (data segment - 
stack)- larger near heaps cause the app to generally work better than 
smaller.  The far heap size appears to not matter very much.  A while 
back, Novell offered free tech support via email; I used it and they 
couldn't give me any hints other than the obvious ones.

2.  PSS uses SAP to indicate its presence on the network.  PSC does a 
SAP query (not a Bindery or NDS query) to find PSS and consequently 
doesn't require Novell file servers for anything.  I didn't use the 
Novell SDK versions of the SAP advertising or querying functions because 
I wanted to query based on server name and type, which you can't do with 
the canned Novell functions.  Although I haven't tested this, you should 
be able to have multiple PSS servers (with unique names).  PSC should 
find the one indicated on its command line, by name.  The server type 
values are hard-coded (using #define), so they can be redefined if 
necessary.


PSHARE is fully public domain, and may be distributed in any form.


I wrote this program because my office needed a shared printer and 
connected to different Novell 3.x servers, and I didn't want to end up 
fooling with lots of attach foolishness.  This software is public 
domain, use it at your own risk.  If you have trouble, please feel free 
to send e-mail, but I can't assume a support or bug-fixing role with 
PSHARE.

Also; Novell's headers & libraries are copyrighted, so I can't send them 
to people.  If you want to get into network programming with IPX/SPX, I 
strongly suggest you get a copy of Novell's SDK CD-ROM. I've found it to 
be pretty complete, although weak on discussing problems & workarounds.

Greg Menke

Greg.Menke@hq.doe.gov

---------------------------------------------------------
(v1.00) PSHARE - DOS Network Print IPX SPX TLI
DOS TSR which redirects DOS/WIN 3.x printer output 
via IPX to a DOS print server program.  Uses a 5k 
TSR on each client machine and a DOS PC for the print 
server.  Does not require a Novell log-in or print queues.
Public Domain.
Greg Menke, Greg.Menke@hq.doe.gov


