Printer Sharing between UNIX and Windows for Workgroups

Dale Panattoni

I once heard a seminar speaker say that the leading edge of technology sometimes feels more like the bleeding edge. This was exactly my experience when a client asked me to integrate the company's SCO UNIX machine into an existing Windows for Workgroups network in such a way that any printer on the Windows' network could be accessible from the UNIX machine.

The task at first glance seemed simple enough, but it soon became apparent that because Windows for Workgroups 3.11 was so new, a lot of networking utilities were either not on the market or were themselves so new that they had not been completely tested.

The network consisted of eleven PCs connected via thinnet ethernet cable. Each PC had an Intel EtherExpress Network Interface Card and each was running Windows for Workgroups 3.11. Four of the PCs were connected to printers which had been setup to be shared and accessible to anyone on the network. The network PCs accessed the PC running SCO UNIX 3.4.2 by using a terminal emulator through serial lines.

Windows for Workgroups had been chosen as the network software because it was simple to install and met the site's requirements. The network's sole purpose was to allow file and printer sharing in a simple and straighforward manner. Windows for Workgroups fit this bill very nicely.

The machine running SCO UNIX housed all of the company's major software applications, such as inventory, A/R, A/P, payroll, etc. A number of terminals and PCs were connected to the SCO box via serial lines that were plugged into a 24-port Equinox Megaport board. The board was practically full and more PCs were to be installed within the year in the network. Integrating the UNIX machine into the network would mean that users could login to the UNIX box without having to use one of the serial ports. This solution would eliminate the need to either upgrade the current Equinox board or purchase another one.

Setting Up Communications between UNIX and Windows

Since Windows for Workgroups and UNIX are not the same operating system, they cannot talk directly to each other without some help. The first goal was to get the UNIX machine onto the network. Acquiring a TCP/IP (Transmission Control Protocol/Internet Protocol) stack seemed the best means to that end.

TCP/IP is a widely accepted protocol that reliably handles the transmission of data throughout a network. Because it is a standard, when TCP/IP is installed as the network protocol on systems of different operating systems, those operating systems will be able to transfer data to each other. Each workstation, or host, on the network is assigned an IP address, which is simply a 12-digit number that will uniquely identify that host on the network. (For a more detailed discussion of IP addressing, see the sidebar "IP Addresses.")

If SCO UNIX and Windows for Workgroups both ran TCP/IP as their network protocol, the two systems would be able to transmit data to each other. On the UNIX side, this entailed purchasing SCO's TCP/IP maintenance release for the UNIX machine and a 3Com Network Interface Card, both of which I installed with no problems.

On the PC side, many different TCP/IP packages were available. I found that two features were critical: the TCP/IP stack had to work with Windows for Workgroups and it should be WinSock compliant. WinSock is the new communication protocol standard that was established by Microsoft for Windows, and most of the network products are written to take advantage of this standard's features.

Certain other features determine how and when the PC's TCP/IP can be used. If the TCP/IP package loads as a TSR, you can use it either in Windows or in DOS. However, loading TCP/IP as a TSR can eat up a lot of RAM very quickly -- some of the packages we looked at needed more than 100Kb. To make matters worse, some could not be loaded in upper memory. Another alternative is to implement TCP/IP in a Windows DLL (dynamic link library). DLLs are loaded in the extended memory managed by Windows, so there's no penalty in RAM. The drawback is that TCP/IP can only be used while you are in Windows. An additional drawback is that DLLs are not as responsive as TSRs. The latest implementation for Windows loads TCP/IP as a virtual device drivers (VxD). VxDs run in 32-bit protected mode and can provide services to both DOS and Windows.

I tried all three implementations and found the VxD to be most useful -- mainly because I don't have to worry about memory problems. Since all of the client's users work strictly in Windows, there was no particular need to have TCP/IP available at the DOS prompt. But there have been times when I was playing around in DOS when I would have liked to have had that feature.

After sampling many different TCP/IP packages from many different vendors, I settled on the TCP/IP stack from Microsoft downloaded from CompuServe. It was the pre-release beta version of the TCP/IP stack that will be used in Microsoft's Windows 95 (formerly known as Chicago). I am usually nervous about using early releases, and was especially nervous about using a beta release, but the software proved to be very stable and easy to install.

Finding a Terminal Emulator

With TCP/IP running on all the PCs and on the UNIX machine, the next step was to find a new terminal emulator that would login to the UNIX machine via the network rather than the serial lines. This wasn't immediately mandatory, since the PCs could still login over the existing serial lines, but it was necessary if the goal of adding PCs without adding serial ports was to be met. Using the network to login would also speed up the data throughput between the UNIX machine and the PCs, since the ethernet would support up to 10Mbs and the baud rate of the serial lines was only 38,400 bps.

Finding a terminal emulator that uses the network is like looking for a green tree in the forest: there are a million to choose from. And as you might guess, they all are the same and all different. Each gives you the basic login capability, they differ with regards to the features that are bundled with the terminal emulator. Of the ten or so I tried, several had problems emulating the SCO console, which was required for the site's color applications. Of those that did emulate the SCO console, some interpreted the colors inconsistently. (The colors would sometimes be right, but the next time the screen redrew, they would be wrong.) Also, a few of the emulators incorrectly read the function keys or the cursor keys. Finding an emulator that met all of the site's requirements took quite a lot of time and effort.

An interesting feature of several of the terminal emulators on the market is the ability to support multiple logins. Most of the packages allow up to at least eight simultaneous logins to the UNIX machine from one PC. This really maximizes the productivity of the users, not to mention programmers (have you ever wished you could be doing other work while you were recompiling a long program?). The terminal emulators display multiple logins in one of two ways: some packages place each login into a separate window, others simply overlay each new login into the same window. In the latter case, to view the different logins, you have to press a hot-key or a button to progressively walk through the logins. I found that I much preferred working with the logins in separate windows. With each login in a different window, I could put two windows side by side so that I could compare files easily, or I could quickly go to the eighth login without having to pass through all of the prior logins first. I was also able to resize and move individual windows (for example, I could shrink windows that contained long-running programs and move them to the bottom of the screen so that I could visually monitor them).

With the terminal emulator selected and installed, users were able to login to UNIX via the network. As we had hoped, the screen response time was noticeably faster than the response time via the serial ports. The final goal was to set up the printers that were hung off of the PCs so that they could be shared not only by the other PCs but by UNIX as well.

Enabling Printer Access from Unix

At SCO's suggestion, we searched for a DOS-based LPR/LPD utility that would run on top of TCP/IP. LPR/LPD is a network printing utility that allows print requests from UNIX to be sent to remote printers. We tried several DOS-based LPR/LPD programs, and could not get any of them to work with UNIX. We literally spent weeks on the telephone to technical support. What was surprising was that every time I opened a magazine, I would see product advertisements promising to do exactly what I wanted. I would call the vendor and verify that it should work, but when I received the product, it would not. Typically, the tech support staff would say that while what I was trying to do was feasible, it had never been tried or tested with Windows for Workgroups

The major problem with what we were trying to do was that the only way to share a printer in Windows for Workgroups is to share it from within Window's print manager. This means that print jobs that are to be sent to a shared printer must be coordinated through print manager. Many of the packages that we tried did allow the sharing of the printer between Windows for Workgroups and UNIX, but the print jobs didn't go through print manager. Consequently, if two print jobs were sent at the same time -- one from UNIX and one from Windows -- to the same printer, both print jobs were printed at the same time. This was not what we had in mind.

The solution comes in the form of two shareware products that my client and I found while perusing CompuServe. When we put the two together, we were able to implement the type of printer sharing we needed. The first product was RCP, a TCP/IP remote copy utility from QVTNet that when installed on the PC side would allow it to receive binary and text files by using TCP/IP's rcp command. The rcp command copies a file from one host to another host on the network. By changing UNIX's printer interface file to invoke rcp instead of sending the print request through the printer's device driver, I could copy the print job over to a directory on the Window's PC (see the sidebar "Setting Up a Remote Printer in Unix with lp," for a more detailed discussion). That's where the second shareware product came into play. The second product was a program called WinSpool that runs under Windows. WinSpool monitors a specified directory or directories, and when a file is placed in that directory, sends the file to print manager.

To say I was a little gun-shy at this point would be an understatement. For six months I had been trying different products, all of which should have worked, could have worked, but didn't work. The client downloaded the RCP server and WinSpool from CompuServe and installed them the next day. We were delighted when the installation completed successfully on both products the very first time. We played around with copying files into WinSpool's specified directory. Every time a file went in there, it went to print manager just as it was supposed to. Then I rcp'd a file from UNIX over to the PC via the network. QVTNet's RCP server also did exactly what it was supposed to do. I tried to get it to fail by sending a huge file, over 3Mb, over the network, but it worked perfectly. I then rcp'd files into WinSpool's directory. Sure enough, they went straight to print manager. I then tested to see if everything worked when print jobs were sent simultaneously from UNIX and Windows and other Windows users on the network. It worked perfectly.

The client is still using this setup successfully and is very happy with it. The only drawback is that the PC to which the printer is connected must be on and in Windows at all times in order for WinSpool to be active. For sites where this is a problem, a product that was released in early August by Microplex Systems, Ltd., may provide an alternative. This product is a printer sharing device that, I am told, can be assigned an IP address and plugged into the network. As many as four printers can be connected to this device, and all of the printers then become available to the entire network. My understanding is that the device spools the requests while the data for the print job is spooled on the originating machine. I have not yet tried the product so I can't say if it does or doesn't work, but it does sound promising.

Incidentally, the performance degradation on the PC is almost not noticeable, even when WinSpool and QVTNet are doing their thing.

About the Author

Dale Panattoni has a Bachelor's Degree in Computer Information Systems from DeVry Institute of Technology in Los Angeles, CA. Dale is a programmer and Vice President of Software Development at DataStar Corporation in Yakima, WA. DataStar specializes in developing produce accounting software. Dale can be reached at his office at (509)453-2455.