![[Go to Content]](/images/uworld/tr-gotocontent.gif)
![[Search Editorial]](/images/uworld/tr-search-button.gif)
Last month, I wrote about using serial port links to tie PC systems to their Unix counterparts. This month I provide the basics of making high-speed local-area network connections between DOS or Windows and Unix.
Why not use Unix on the desktop? You could, but that would leave you out of touch with the millions of PC and Macintosh users out there. Even Novell Inc., maker of Unixware, has chosen to abandon the desktop market as a target for Unix. Novell has decided the most profitable role for Unix is as a server.
That Unix can't compete with Windows and Macintosh systems on their turf shouldn't surprise anyone who's used Unix. It is, without a doubt, more powerful. It cannot, however, touch commodity platforms for ease of use and administration. Within the limits of their capabilities, Windows and Mac systems give users exactly what they want. It'll stay that way until something better comes along. We've already learned that ``better'' doesn't necessarily translate to ``technically superior.'' Now Novell has learned that lesson, too.
Fans and admirers of Unix shouldn't begrudge commodity desktop systems their success. The future of Unix lies in its ability to tie all kinds of systems together. As a server, it's tops. And without the ``wimpy'' commodity systems, our favorite operating system will have nothing to serve.
The first step in getting your systems connected is to equip the PC with a compatible network adapter. Take your pick: Ethernet, token ring, fiber. I use Ethernet in my network, so that's what I'll describe. In general, I've found it easier to get the PC speaking the Unix host's topology and protocol than the reverse. In my lab, that means Ethernet and TCP/IP.
There are dozens of Ethernet cards to choose from for the PC, and each claims some advantage over the others. My only advice is to stay within name brands (SMC is a favorite of mine) or those 100 percent compatible with name brands and to use a board with at least a 16-bit bus interface. The latter comes not from a concern over throughput-good eight-bit cards have surprisingly good performance-but rather configurability. A 16-bit Ethernet adapter will support a broader range of potential IRQ (interrupt request) settings than 8-bit boards can. It may not matter in your systems, but in mine, I've been forced at times to sacrifice printer and serial ports to free up IRQs for network cards.
Ethernet 10BaseT or 10Base2? It's purely a matter of what you're set up for. For any new installation, 10Base2 (twisted pair) is certainly the smarter choice. I expect that 10BaseT (coax) will eventually disappear as twisted-pair concentrators get cheaper.
With PCs, and with portable PCs in particular, there's one other option to consider: parallel-port adapters. The parallel I/O, or printer port, on most PCs is able to pass data faster than standard serial ports. Several companies, with Xircom Inc. (Calabasas, Calif.) in the lead, offer cigarette-pack-sized boxes that have a parallel-port connector on one side and an Ethernet port (twisted pair or coax) on the other. These adapters come with software that masquerades as board-level drivers, so network protocol software doesn't know the difference.
The cost of convenience is performance, but it's not that steep a price. With a bi-directional parallel port, the speed of a good adapter approaches that of an eight-bit internal card. It's fast enough for everything from file transfer to X Window sessions.
There are a lot of choices with TCP/IP software as well. A dilemma for you is: would you rather have complete Windows point-and-click functionality or a more Unix-like command-line interface? You can't have both, at least not now, so you must choose one approach or the other.
If you're installing TCP/IP primarily to enable some Windows- based network client like X Window, then you should probably choose one of the Windows-hosted TCP/IP products. I've used Netmanage Inc.'s (Cupertino, Calif.) Chameleon, and Walker Richer & Quinn's (Seattle) Reflection Network Series beta software just arrived. These, and others like them, have the advantage of using comparatively little DOS memory because most of the TCP/IP functionality is loaded under Windows. Because Windows has virtual memory and no 640-kilobyte limit, that's just where TCP/IP belongs.
On the other side of the DOS and Windows divide lies packages like FTP Software Inc.'s (North Andover, Mass.) PC/TCP and Sunselect's (Mountain View, Calif.) PC-NFS. These provide Windows clients, but they load almost entirely into DOS memory. The advantage, especially in PC/TCP's case, is that a full set of DOS commands are included. These mimic the behavior of same- named Unix counterparts (rsh, rcp, ftp, and so on) and help Unix users cross over to the PC easily. The disadvantage is that, even with some pretty fancy memory management, the fully loaded software leaves many commercial DOS packages without enough room to run. Or at least they don't run efficiently. I tried running a DOS tape backup package while PC/TCP was loaded, but instead of streaming data to tape at full speed like normal, it went haltingly and took forever. Fortunately, DOS 6.x has support for multiple configurations. Now I have my PC/TCP configuration and my maximum memory configuration. I reboot to switch between them. It's an inconvenience, but nothing compared to the old way.
Windows-hosted TCP/IP packages always include graphical versions of common commands. The ftp utility, instead of being command-driven, becomes a point-and-click application with graphical file selection, one-button log-ins, and other amenities. It certainly takes the sting out of ftp transfers for those not accustomed to Unix. But for those of us who are, it is one example of a graphical interface that gets in the way more than it helps. As you would expect of a power user, I want both. FTP's PC/TCP and WRQ's Reflection offer a combination of command-line and mouse- driven versions of ftp. I'd like to see all PC TCP/IP packages invoke similar duality for all commands. PC/TCP is the only package I've worked with so far that manages it.
Installation of these packages requires a network driver for the adapter you've chosen. If you follow my advice about name brands, then the TCP/IP package probably includes a driver for your adapter. If you stray into the off-brands, you may have to load and configure a driver by hand using software that comes with the adapter.
DOS network drivers have, thankfully, been standardized. All commercial TCP/IP packages now operate with these standardized drivers, which fall roughly into three categories: NDIS, ODI, and Packet Driver. NDIS (Network Driver Interface Specification) is the most common; I haven't yet seen a network card, even a cheap one, that didn't include NDIS drivers. NDIS drivers have the disadvantage of being difficult to configure by hand. All the more reason to stick with a name-brand network adapter so the software can do the configuring for you. Packet Drivers were previously a popular choice, particularly for PC/TCP. ODI (Open Data-Link Interface) is an alternative that's not seeing much use just yet.
I'll leave the subject of configuring adapters to the hardware manuals. Suffice it to say that the vast majority of networking problems can be traced back to erroneous IRQ, I/O port, and memory address settings. The software that comes with your card should include some type of diagnostic software. Use these tools to test the settings you've chosen before you install TCP/IP.
Once your network card and drivers are installed, loading TCP/IP should be a breeze. You need to assign an IP address for your PC. You should also load in the IP address and name of one Unix host. Test the network link using the ping command (or graphical equivalent), and then use ftp to copy the hosts file from your Unix system to your PC.
Commercial TCP/IP packages vary in their functions and services. PC/TCP delivers a rich set of BSD Unix-style TCP/IP commands, running in DOS, for terminal emulation, remote execution, remote tape and archiving operations, file transfer, and, through Interdrive, NFS drive mounting. Everything's client-only except for ftp and smtp servers that you can either run standalone under DOS or in the background under Windows. All of the PC/TCP commands operate under Windows using DOS command windows.
Netmanage's Chameleon NFS goes far lighter on the commands but offers Windows-hosted NFS, ftp, and other servers. There's no inbound terminal emulation (I haven't yet seen that for DOS/Windows TCP/IP), but Chameleon's server functions make a Windows PC behave more like an equal partner on a Unix LAN.
The PC TCP/IP networking software isn't always the end of the road. Perhaps the most popular add-on is X Window, which requires TCP/IP to make its host connections. There are a lot of choices here as well: Hummingbird Communications Ltd. (Markham, Ontario, Canada), Netmanage Inc. (Cupertino, Calif.) and Network Computing Devices Inc. (Mountain View, Calif.), AGE Logic Inc. (San Diego, Calif.), and WRQ are just a few of the packages I've used. A Windows PC with a fast graphics card makes a better X terminal than most X terminals do, and the cost is comparable, sometimes even lower.
Once you get the TCP/IP layer going, your PC takes on new capabilities that go beyond terminals and files. Database managers, online browsers (like Mosaic), vertical applications, and others rely on TCP/IP to make the most of shared networks. PCs, even fast ones, are cheap and easy to use. In my own lab, I use a Windows PC to make connections to all of my Unix hosts. I've tried other ways but, in a mixed environment, the PC is simply the best choice for a multipurpose front end. With the addition of TCP/IP, the DOS/Windows PC becomes an indispensable network client.
Tom Yager is an Open Computing contributing editor. He can be reached through the Internet at tyager@maxx.net.