Winsock Print Manager and Print Spooler Version 1.1 Written by Dave Brooks Design Specification by Robert Peterson Idaho National Engineering Laboratory Table of Contents Disclaimer Introduction Requirements to run this software Quick Start: How to Install it A few other things you Need to Know Disclaimer ---------- Copyright 1994 EG&G Idaho, Inc. "ALL RIGHTS RESERVED" Idaho National Engineering Labratory This material resulted from work developed under Government Contract No. DE-AC07-76ID01570 at the Idaho National Engineering Laboratory and is subject to Broad Government License. Neither the United States nor the United States Department of Energy, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Introduction ------------ If you are familiar with the idea of printing from one system to a printer on remote system, and would like to set up your Microsoft Windows version 3.1 printer to be a compatible "remote" printer, then this is the software for you. I use it regularly to print text from my Ultrix system, as do other folks in this vicinity from various Unix systems. You can print using standard Unix "lpr" print client. I've also used the sample print client from Stevens' famous "Network Programming" text, and a Macintosh "lpr" client. Yes, folks, we printed text _directly_ from a Mac to a PC. This package comes in two parts: 1) The 'Print Manager' is the part that speaks the network protocol. For those of you into standards (and you wouldn't care about WinSock if you weren't), I used RFC 1179 as the reference rather than the Berkeley code. 2) The 'Spooler' takes the text and writes it to your Windows printer. The 'Spoolraw' program is a version of the 'spooler' that handles non-text files, such as PostScript, PCL, HPGL, etc, text with embedded escape sequences, etc. (I know that PostScript is plain ASCII text, usually, but still you don't want to see PostScript code coming out of your printer). Notes: * This software is engineered to run "unattended". That is, after a minimal amount of setup, you can put them in your StartUp group and start printing to your PC from remote systems without manual intervention. In fact, if you are already running Windows and WinSock, and have your printer configured to work with Windows, then all you'll need to do to is to have a remote system configured to know about your printer, and run this software. * It supports all five commands required in the RFC, namely 'print', 'display queue (short)', 'display queue (long)', 'remove job (jobs)', and 'start printer'. The 'remove jobs' command supports removing by user or job numbers, and does the usual checking for privilege. It also recognizes the user "root" as the "superuser", with the ability to remove any job. The 'start printer' command is not required to make this software work, but it is supported and is useful in some circumstances (see the "Things to Know" section below). * Only text is supported, but enough formatting characters are understood so that you can print basic nroff output, like Unix man pages. For example: man X | lpr -Ppebbles works. I'm sure that "tbl" output will not work, since I don't do any line drawing. To reach me, here is the relevant information from my .signature file: David L. Brooks Idaho National Engineering Lab. POB 1625 Idaho Falls, Id. 83415-3730 INTERNET: dob@INEL.GOV Alternate address: support@tis.inel.gov Requirements ------------ You'll need: * A PC with Microsoft Windows 3.1, and a supported network card. * Windows Sockets 1.1 or better, installed and running. * A printer that you have configured Windows to work with; if you can't print from the Notepad, for example, then you can't print with this software either. * A remote system with a 'print' command that understands how to print to Berkeley-compatible systems. The BSD Unix 'lpr' program should fill the bill. I'll include some info for your Unix sysadmin below. Quick Start: How to Install it ----- ----- --- -- ------- -- 1. Install the files wslpd.exe, spooler.exe and spoolraw.exe in some directory, typically \netprint or \windows. If you can see this file, you've probably unpacked the file wslpd-11.exe. You've also noticed the executables, wslpd.exe, spooler.exe and spoolraw.exe. They don't *have* to be a \netprint directory, but that's usually how I set it up for people, so that when/if I have to update the software, I know where to find the executables in a hurry. It doesn't matter where you install the programs; they don't use the current directory anyway. 2. Make a few support directories. you do have to do this: mkdir \var mkdir \var\log mkdir \spool mkdir \spool\nlpd These should be on the same drive as the working directory for all three programs. It doesn't have to be the C drive. Yes, a nice setup program would be a Good Thing; however, I had to start working on a different project. 3. Add wslpd.exe and one of the following: spooler.exe or spoolraw.exe, to your StartUp group. Important issue: how do you know which to use, spooler.exe or spoolraw.exe? Answer: If you print straight text, use spooler.exe. If you print anything but straight text, use spoolraw.exe. Well, they don't *have* to be in StartUp, but for many folks that will probably make the most sense. This way you can print to your PC without intervention. Important note: if the 'Print Manager' isn't running then you won't be able to print to your PC. Important note: if you use spoolraw.exe, then spooling has to be enabled on your system. You check that by looking in WIN.INI in your Windows directory; look for the section [windows], and the entry 'spooler='. The text to the right of '=' has to be 'yes', not 'no'. So, it should look like: [windows] spooler=yes The 'Print Manager' is the network daemon part of the Berkeley Print Protocol, and the 'Spooler' and 'Spoolraw' are the Microsoft Windows part, and roughly correspond to the output filter in the Berkeley universe. The cute icons are from the Icon Manager 1.1 package, which I picked up from the "Windows Secrets" diskette. 4. To the 'remote' System Administrator: In the Berkeley world, you could set up a printcap entry with the hostname of the PC as the 'remote machine' entry. Windows does not have the concept of a printer ID, and I didn't layer one on top in this software, so you can use any arbitrary text string as the printer ID; however, it is still required by the protocol. The Ultrix hosts I print from have a printcap entry looks like this: pebbles|pebbles printer:\ :lp=:\ :of=/usr/lib/lpdfilters/lpf:\ :mx#0:\ :rm=pebbles:\ :rp=lp0:\ :sd=/usr/spool/lpd:\ :lf=/usr/adm/lpd-errs: I had an HP 720 at one time, and used SAM to set up a Berkeley compatible remote print entry. However, there was an unfriendly router between it and "pebbles", so I have not tested printing from a System V machine. 5. Execute the 'Print Manager' and 'Spooler' or 'Spoolraw'. You can run them from the File Manager, or restart Windows, or click on the icons, whatever. I haven't tried the Run menu in the Program Manager. A few other things you Need to Know - --- ----- ------ --- ---- -- ---- 1. "WSLPD" stands for "WinSock LPD". The goal was to make a compatible print daemon which to a remote print client would be indistinguishable from a Unix program, but would still fit comfortably under Windows. I started with the free Berkeley 'lpd' code, but soon gave up as it was oriented towards Unix and inherited file descriptors. There are about four lines of code remaining from lpd which have to do with checking the range on the client port. I left in the Berkeley copyright, but the rest is totally new. 2. The way the programs work follows: * The remote print requestor (usually 'lpd') contacts the 'Print Manager'. All network protocol takes place between these two programs. * The end result of a print request (as opposed to one of the other commands) is a 'control file' and one or more data files. The control file specifies all manner of things about the print request, such as the requestor's ID and host, the optional title, number of copies, etc. This stuff is written to the directory "\spool\nlpd". I suppose it should really be "\var\spool\nlpd". * After a print request is finished, the 'Print Manager' will post a message to the 'Spooler' or 'Spoolraw' using the Windows function "PostMessage". The upshot of this is that the 'Spooler' will kick in if it is running, but if it's not running, the 'Print Manager' continues to run unimpeded. This means that files can be queued to your machine, and that you can control whether it is printed now or later. It's manual but it gives you more control over your machine. The way queue files without actually printing them is to simply exit the 'Spooler'. To print files that have been queued but not printed, start up the 'Spooler' and select "Print" from the "File" menu. Or, use a 'start printer' command from a remote machine. I have done this using "lpc" on an Ultrix system. * The remote user can 'see' items in the queue up until the 'Spooler' processes the item. After that, they will be visible only in the Windows Print Manager queue. 3. The 'Spooler' understands the following control characters: TAB: Goes to the next tab stop, using eight character tabs. Backspace: writes the next character to a 'shadow' buffer, so that you can get underlining. I haven't tested this technique with 'bold' but it should work. Form feed: does a page eject. 4. A word about the 'Spooler': it does basic, generic Windows printing. No fancy fonts, no margin control. There is a "Printer Setup" dialog but I'm not convinced it works right. You're probably better off using the Windows Print Manager to control setup. 5. And a word about 'Spoolraw': it uses the same Windows API call, SpoolFile(), that print drivers (apparently) use. You probably won't want to use it to print straight Unix text files; I don't care for the way they look. Spoolraw is intended for PostScript, PCL, HPGL, text with embedded escape sequences, stuff like that. 5. The 'Print Manager' has a nice status window that tells you what's happening, as it happens. My only complaint is that it goes by too quickly, and that the 'control file' is typically sent last so you miss the info about the data file or files. The 'Spooler' has a nice status window that tells you about pages printed and % completion, as well as requestor info. I have them both configured to start minimized on my PC. The programs don't iconify themself automatically; if someone were to show me how to do this, I'd probably add it in later. 6. Here is something I really hated the first few times it happened to me. The 'Spooler' started out as a clone of the "printfile" program that comes with the Microsoft C examples stuff. Like many programs that print to Windows, it has a little popup window that says "Now printing ". The first time I was using PWB in full screen mode, and someone else printed to my PC, that iconified my DOS window. It was most disconcerting, and other users have objected as well. The "Now printing" window still exists but is now optional, and is off by default. 7. So, what happens when you don't have your printer configured to work with Windows, or have no printer? Does the software GPF? Nope. It turns out that Windows intercepts the calls to the Windows printer, and flashes a dialog on your screen to the effect that you had better install a printer before you print. Conversely, what happens when you print from a Unix system, but don't have the 'Print Manager' running? In our case the remote "lpd" just keeps trying now and then. One user here printed from his Unix workstation, and then some time later realized he wasn't running the 'Print Manager' on his PC. He started it up, and shortly his print jobs came rolling out. It seems this is implementation dependent and is handled by the print requestor.