The more I learn about Windows NT, the more I need to know. NT includes so much that I think I'll be learning about it continuously (or at least until the next release comes along, and I have to start over). On the other hand, much of that learning is coincidental--things I pick up trying to install one or another feature--or accidental. The support materials or even the Windows NT Resource Kit don't cover many topics.
Searching for something on-line requires installing the CD-ROM, because the electronic manuals aren't on a new system automatically. The icon for Help is stuck in the Main program group, but Setup doesn't ask whether you want to copy the files from CD. When you run Help without mounting the CD-ROM, you get complaints about not seeing the manuals. Help does give you a chance to point at a different directory, so if you've manually copied the files, you're all set. I've made this step part of my installation sequence, and I suggest you do, too; disk space is cheap these days, and Help covers many topics.
It's the topics Help doesn't cover that concern me. Free support for NT is sketchy at best--you get one phone call, and that's it. Microsoft does have excellent for-pay support, but the gaps in the provided materials are simply unacceptable, especially for a product as detailed and complex as NT.
For example, when you send a file to print on another computer, a notification pops up on your screen when the file is printed. A "message from spooler" goes out to every user with your login name; if you're using more than one computer, it appears on every one of them. Print Manager, where all these things are set, has no apparent way to turn off notification entirely. I suppose you could set a bogus user to receive those messages, but nothing is in any of the standard materials on this subject.
The same criticism can apply to UNIX, where important facts are buried in the middle of an obscure passage, or you must infer them by carefully reading two different passages. You certainly can't determine such facts from the examples. NT isn't as maddeningly difficult to support as UNIX--one reason many people fear NT will replace UNIX--but it needs to be much easier than it is.
RAS Code Done Right
The Remote Access Service (RAS) that comes with NT is well written,
straightforward, and easy-to-use, a piece of code that Microsoft has every right
to be proud of. RAS does an outstanding job of connecting computers, especially
NT to NT. You simply install it on your computer and forget it. It runs on top
of any protocol including NetBEUI. Even users unfamiliar with Windows needed
only five minutes of training on RAS.
The installation was remarkably smooth. RAS autorecognized the Practical Peripherals 14,400 bits per second (bps) internal modem on COM2. Using RAS is as simple as installing it: Double-click on the entry in the phone list. RAS dials the number and authenticates to the other end, and you're connected as if you were on the LAN. The speed of file transfers, even with a 14,400 bps connection, is good.
Some caveats about RAS: It's not a terminal program for dialing a BBS, nor is it a remote-control application. To take over someone's computer remotely, you need an application such as pcAnywhere32 from Symantec. RAS is only a network-to-network connection; that is, it lets you share drives and printers. To use a printer connected to a remote computer, RAS takes a bit of time to install because NT automatically copies the driver from the remote system. On a 14,400 bps connection, this can take several minutes.
I'd like to see more controls in RAS, such as automatic disconnect if no activity occurs for a set amount of time. Even better would be disconnect and reconnect controls, so the user wouldn't know a disruption occurred. Statistics on call duration would be a nice feature, too.
RAS is larger than it first appears. In addition to the program you see, it runs a service in NT that monitors the serial ports you assigned to it. RAS isn't gone just because you aren't running the user-control part.
What all this means is: If you want to run Terminal to dial out to some BBS on the modem RAS is using, you must terminate RAS from the Services Control Panel. This restriction isn't explicitly documented. Terminal just says that something else is using the serial port. I had to call my good friend Gavin Doughtie, who'd recently run into this problem, to get clued in. "The service is exactly like a getty daemon," he reminded me. "Stop it to run Terminal." He was exactly right; NT services are very much like UNIX daemons. The "getty" or "get-TTY" daemon watches for activity on a serial port. The best UNIX systems let you use that port for dial-in or dial-out, as does RAS.
Terminal, as shipped with Windows NT, looks exactly like the version in Windows 3.1. It's not meant to be a full-featured program, but it needs at least some improvement. What I'd like to see in future versions of NT is a better Terminal program, one that can borrow a modem from RAS. I'd settle for a better message that says something like "Don't forget to turn off RAS if you want to use the modem."
One last compliment to RAS: It's industry-standard. Connections are made with Point-to-Point Protocol (PPP), which is the most popular way to connect to Internet Service Providers. PPP supports compression, too. If you want to surf the Internet from NT, you'll probably use RAS; you won't need a different dial-in program for each application, except to call BBSs.
More Printing Adventures
For a new Windows NT network, a client of ours bought a Hewlett-Packard (HP)
LaserJet 5SI, the latest and greatest of HP's phenomenally successful laser
printers. And the 5SI is a doozy: 24 pages per minute (ppm) out of the
box--faster than most desk-sized laser printers of three years ago. It seems
truly built for workgroup printing too; it has a high-capacity toner cartridge,
three paper trays (with options for more), and an easy-to-use front-panel
display.
The only thing it lacks is a printer driver for NT, but the 4SI driver worked fine with the 5SI. In fact, almost any older HP driver would be compatible; the client just wanted to take full advantage of the printer's features. Microsoft has taken driver production back from the manufacturers, so you have to wait until Microsoft is finished with them. And, to its credit, Microsoft finished within two months of the printer's ship date. The 5SI drivers are available via FTP at //ftp.microsoft.com, but they require Service Pack 3, the latest series of bug fixes for NT. You must download 7.8MB from the Service Pack to use the 191KB of drivers. Isn't life always like that?
Setting up the 5SI on the network uncovered another gap in the NT support materials. The client is a commodities trader and has a number of DOS programs that run in the background and need to print on the HP. I used Print Manager to redirect the Windows applications to the network printer, but the DOS applications couldn't see it.
The key to all printer (and drive) redirection within an NT command window, where DOS programs run, is NET. The NET command has a long history; users of most peer-to-peer networks know it well. Everything from LAN Manager through OS/2 to LANtastic uses it. Windows for Workgroups, if you access it directly from DOS, uses NET to redirect drive letters and printers.
I must have left my good brain in my other shirt, because it took quite a while for me to remember NET USE. (Well, OK, actually my father reminded me, but don't rub it in.) First I scoured all the NT materials. If one word on NET is in any of them, I couldn't find it. NET is only useful in a command window, but many people still use DOS programs or want to write batch files. If something as basic as NET isn't documented, I wonder what else isn't.
But NET wasn't doing the job. Print Manager saw the printer just fine, and Windows applications sent jobs, but the command NET USE LPT1: \\server\laserjet wasn't hooking up. It gave me an error indicating that it didn't know of any such printer.
Clearly, I had the right printer name--I'd taken it right from Print Manager--but NET just wasn't going to use it. Finally, I called long-suffering Andrew McGehee, Windows NT Workstation Product Manager at Microsoft. He couldn't figure it out either. He finally suggested I delete the printer definition on the server and recreate it. I did, with no spaces in the name, and this time the NET command worked as planned.
Another undocumented feature of NET in NT that may interest you: The assignments are persistent from login to login. I had to assign the printer only once, and it was reconnected, even after the computer was turned off. This is not like NET under other operating systems and is, once again, not documented. It's not bad--mind you--just different.
Now That's Fast!
The computers delivered to the commodities traders were the fastest Workman &
Associates could build at the time: 133-MHz Pentiums with 32MB of Enhanced Data
Output (EDO) RAM, Fast and Wide SCSI drives, and PCI 3Com Ethernet cards. We
knew they were fast, but we didn't know how fast until we tried to print. The
commodities traders have several DOS programs that they run in the background;
they send various reports to the printer for reference. (That's what all the
business with NET was about.)
The reports rely on a set of downloaded fonts for line drawing, fonts that are deleted every time a Windows print job is sent. The traders had a batch file that used COPY /B to upload the fonts; it worked fine on DOS, Windows 3.1, and Windows 95. It was inconsistent, however, with NT. In a command window, sometimes the batch file would run without complaint, but usually it would error out. And the errors were truly bizarre--"pipe already in use," "LPT1: device not available." After I put PAUSE statements between the COPY commands, it worked. This system was so blazingly fast that one COPY wasn't finished before the next one began!
There's another part of NT that's also not well documented. It comes with QBASIC and EDIT. EDIT is familiar to DOS users who've argued with their CONFIG.SYS files, but using it on a system running several big Windows programs shows the limits of multitasking in NT. EDIT and QBASIC just crawl when Windows programs are running, even on a Pentium/133.
More Lessons Learned
Installing these computers uncovered a wealth of information about the
insides of NT. Next month, I'll say more on pcAnywhere32, RAS, NT backup, plus
using Windows 95 and NT together. And who knows what else will come up.