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