May 1996 How-To Columns

By Tom Henderson

THE CODE CRANKERS at Microsoft and Novell have again been busy stabilizing Windows 95: Microsoft released its NetWare Directory Services-compatible client for Win95, and Novell finally put the sealing wax on its NetWare Client 32 for Win95.

Both releases improve connectivity to networks built on Novell's NetWare 4.1 and its NetWare Directory Services (NDS). This means Microsoft can remove one of those aspirin packets from the Win95 box.

The original Win95 offered four ways to get to NetWare 4.1. The default, Microsoft Client for NetWare (32 bit), was luxuriously easy to install and use compared to the other three. The Novell Client options came in three flavors: an anachronistic driver for Novell's 8-year-old IPX.COM, a Novell IPXODI driver and Novell VLM drivers. No one could think of a good reason to use the first one, and the second one is a 16-bit program set that's incompatible with NDS. The third choice wasn't included in the box (you had to order the VLM drivers from Novell or its business partners). And, even though VLMs allowed NDS access, these 16-bit drivers didn't connect well to certain Win95 features.

Win95 also allows only one 16-bit network client on a single PC. However, you can run up to 10 32-bit network clients concurrently.

Microsoft's Client for NetWare was stable, but it was incompatible with Novell's printer objects and certain NetWare protocol stacks, such as Novell's LAN Workplace (LWP) TCP/IP implementation. Add to that printing stability problems that occasionally required deletion and reinstallation of the VLM client software. Reinstallation sometimes wrote the AUTOEXEC.BAT file incorrectly, wreaking havoc when that start-up file failed to connect.

The good news is Microsoft has released three products that fix these problems-the Win95 Service Pack Update, the MSNDS (Microsoft NDS) upgrade and the Shellupd (Shell Update). The Shell Update is a subset of the Service Pack Update. Win95 users can download all three for free.

The Service Pack Update comes in two flavors: a single executable file for ad hoc installation and an update for files on the Win95 diskette installation set. The update includes new redirector software that allows more stable network resource use and the new SHELL.DLL that's more closely tied to network resources.

Be careful, though, because the Service Pack Update's installation routine likes to munch passwords. The Service Pack contains the new, updated password encryption algorithm, and several users have complained it destroyed their password files. To avoid this, delete the *.PWD files from the Windows subdirectory. The next time you start Win95, it will prompt you for new log-on and other access passwords.

When you use the MSNDS upgrade with the Service Pack Update, the Microsoft Novell client becomes a participating NDS member on a NetWare network, but it prefers to support Winsock over Novell's LWP. In addition, the MSNDS upgrade has a peculiarity: It still forces you to store shared Win95 policies in Novell's mail directories (SYS: MAIL\userobjectnumber).

Novell's approach to a 32-bit NDS client for Win95 was different. Although many networkers chided Novell for a tardy 32-bit Win95 client release, it may have been worth waiting for. Novell's Client 32 goes further than just stabilizing the basics of the Microsoft Client for NetWare. For one thing, it can store network policies either under the mail directory or where a Home Directory variable points.

Novell also added many user log-on options. A revamped NetWare log-on program that's automatically placed as a Startup item lets you easily choose a different NDS. You can use the same program to point to different NDS trees, log-in scripts and so on, that provide greater functionality than the revamped Microsoft Client for NetWare.

Novell's client software also includes some subtleties, such as a shell for launching applications. The NetWare Application Launcher (NAL) offers a choice of applications based upon entries you make in the NDS. Not only is NAL a convenient way to distribute application use, it's also a hook into NDS-based electronic software-distribution capability. Unfortunately, you can't take advantage of this capability because there are no programs available that understand it.

Novell's new client software also supports multiple network cards, a failing of the updated Microsoft NetWare client. It also supports either Microsoft's TCP/IP infrastructure (WINSOCK.DLL) or its own. Novell extends this egalitarian protocol support by adding LIP (large Internet packet) and its own IPX packet burst protocol-often used in high-speed networks and WANs. Microsoft's implementation is not so democratic.

NetWare Client 32 now incorporates some functionality that Microsoft's Client for NetWare already had. The most important new function is Autoreconnect. If a network connection is interrupted, NetWare Client 32 enters a mode that waits for the network to become available again, instead of crashing the session in use prior to the network loss. Novell, surpassing Microsoft, restores all printer connections, file locks and drive mapping.

What makes this so important? The toughest crash to recover from is when one of the myriad network foibles interrupts a session. After such a crash it's difficult to assess the damage to files and databases. Recovery efforts are costly and may delay network use until you complete the recovery cycles.

Both the Novell and Microsoft NetWare (when upgraded with MSNDS) clients show NDS trees in Win95's Explorer, and both support browsing network objects, such as printers. Microsoft's updated client now allows more control over NetWare-shared printers by making them not only visible (as before), but more obvious by revealing more of the printers' characteristics.

Both client updates also allow you to view and browse multiple NDS trees. Although many NDS networks have only one NDS tree, others (like my own) have multiple trees to combine application and user functionality. Swinging from tree to tree is as easy as clicking on the tree in the Win95 Explorer or Network Neighborhood.

Because NetWare Client 32 has dynamic resource allocation and file-caching capabilities, it can find files and shared objects on multiple trees or contexts faster than its Microsoft counterpart. The downside of dynamic resource allocation (which also includes things like IPX socket allocation) is that resources take up memory. And although the resource use expands in a session, it doesn't automatically contract. Applications may not load completely on systems light on memory. You can check the resources dynamically used by invoking the System Monitor from Programs/Accessories/System Tools. If users need to disable the dynamic allocation of resources, they can do so.

It's unfortunate for Novell that it released this mature networking client five to six months after the Win95 introduction, because it's a better client than Microsoft's. But with Microsoft's Service Pack and its new NetWare client, Win95 users have a stronger chance of successful initial deployment than they did with the client that shipped with Win95.

By John D. Ruley

IT'S THAT TIME of year again. Spring is in the air, Microsoft is beta-testing a new version (4.0) of Windows NT, and folks are emerging from their lairs with lots of questions.

Because many of the questions readers ask me crop up time and again, I maintain an NT "Frequently Asked Questions" list, or FAQ, on the Windows Magazine Web site. In that spirit, here's a Top 10 selection from the FAQ; additional questions and answers are available on the Web (http://www.winmag.com/people/jruley).

Q: Should I get NT or Windows 95?
A: My answer to this question has not changed since last year: "Run NT if you can-otherwise, get Windows 95." "If you can" means if you have NT-compatible hardware and software, at least 12MB of RAM and a large hard disk (NT requires more than 100MB). If you have all that, forget Windows 95 and go with NT. It's a much more stable and reliable platform, with real advantages for both 16- and 32-bit Windows applications. Windows 95 is better for some users: It runs in about half as much RAM as NT, offers full Plug and Play, takes better advantage of notebooks and other portables, and is probably a better platform for games and DOS-based legacy applications.

Q: I've been hearing so much about NT 4.0. How can I get it?
A: At this writing, NT 4.0 has just entered beta testing. By the time you read this, subscribers to Microsoft Developers Network (MSDN) Level 2 or Level 3 should have it, as should developers. Other folks will probably have to wait until it ships, but that won't be too far off.

In the meantime, you can download update software-called a Service Pack-from the WinNT Forum on CompuServe (GO: WINFILE) or from ftp.microsoft.com. Microsoft offers these Service Packs (big binary files or CDs that contain new versions of NT system files) between major releases of NT (3.1, 3.5, 3.51, 4.0). The most current one is Service Pack 3 (SP3) for NT 3.51. For details on NT 4.0, see "What's Hot!" in the Reviews section of this issue.

Q: Is it possible to get the old look and feel in NT 4.0?
A: You can get close. You can still launch Program Manager by using Start/Run/PROGMAN.EXE, and you can get to an old-style File Manager with Start/Run/WINFILE.EXE. You can set Program Manager as the default shell by hacking the NT Registry, but you'll lose access to many of NT 4.0's new and improved features.

Q: How does NT's performance compare to Windows 95's?
A: This depends primarily on how much memory you have. As long as you can keep NT from swapping memory out to disk, it's just about as fast as Windows 95-and in some cases, faster. I run NT Workstation on a Zenith Z-Noteflex 486/75 notebook computer with 16MB of RAM-and I wish I had more memory. With my usual load of applications (Microsoft's Exchange client for NT, Remote Access, a command prompt and Word for Windows 95), NT swaps when I try to launch additional apps. From past experience with other systems, I'm confident swapping would go away if I could boost the RAM to at least 20MB.

I run NT Server on two systems-an ancient Mips Magnum R4000SC-50 and an equally mature NCR 3360 with dual Pentium-60 CPUs. Each has 32MB of RAM, and to make either of them swap is a real effort. I'm writing this column (using Word for Windows 95) on the NCR while Remote Access, SQL Server, Internet Information Server (IIS) and Print Manager run in the background, and there's no swapping going on. (If I start Microsoft's Exchange Server release candidate, it will start to swap, but I can make it stop by shutting down both IIS and SQL Server.)

Q: Is NT compatible with [insert hardware here]?
A: Check Microsoft's current hardware compatibility list; you'll find it at Microsoft's Internet site (http://www.microsoft.com), in the WinNT Forum on CompuServe, on any TechNet CD, as part of Microsoft's NT Workstation (and NT Server) evaluation guide diskettes, and on Microsoft's InfoSource CD. Look for a file named HCLmmmyr.HLP (where mmmyr=month and year).

If your hardware is on the list, you should be safe; if not, you're taking a chance. NT runs on most standard PCs, but your peripherals are a different story. Call the vendor to see if it supports NT. If it doesn't, your hardware probably won't work.

In addition to scanners, nonstandard pointing devices (particularly joysticks), low-end tape drives and multimedia upgrade kits, watch out for some accelerated video drivers. NT 4.0 introduced a completely new video driver model, and NT 3.x video drivers won't work with it.

Q: What should I do if my hardware isn't on the list?
A: You have a number of options. The first, as mentioned above, is to call the vendor and ask if it supports NT (and if not, why not?). Then check the NT-related message boards on CompuServe, America Online or the Internet to see if anyone else has used the hardware and can offer first-hand advice.

Finally, you can address requests for drivers to ntwish@microsoft.com. No guarantees here, but I'm told the resulting list of requests shows up once a week on an NT program manager's desk.

Q: Is NT compatible with [insert software here]?
A: You won't find a complete list of NT-compatible software. But as a rule, most 16-bit Windows software that doesn't depend on a proprietary device driver is compatible. Windows NT doesn't support VxDs (the kind of drivers that are standard for Win95), however, so any such software won't run on NT. Similarly, most DOS applications that don't perform direct hardware access will run. Low-level disk utility apps, such as those in PC Tools or the Norton Utilities, won't work unless you dual-boot to DOS and run the programs from there (or upgrade to a native NT version).

by Martin Heller

That's as simple as it's going to get. But there's good news and bad. The bad news is InternetOpenUrl doesn't always give you the control you need; the good news is you can drop down to more complicated levels that will afford you more control.

For starters, you can define a function to receive status reports, using InternetSetStatusCallback. When you're dealing with the Internet, an operation can fail at any stage, so it's important to let the user know what's happening. A status callback function gets codes like INTERNET_STATUS_RESOLVING_NAME. In addition, it can display appropriate messages in a status bar window, advance the state of a progress meter, turn on lights on a simulated control panel or whatever you like.

You can also get further into the guts of the http, ftp and gopher protocols. For instance, you can obtain the contents of a Web page with the sequence InternetOpen to initialize the DLLs, then InternetConnect to open a session on the desired Web server. If that succeeds, perform an HttpOpenRequest to construct a request for the file path part of the URL. The verb "get" will read a page. Another verb will perform a different operation, such as posting a query. As part of the request, specify a list of file types you're willing to accept. You can also specify flags to control caching, handle reuse and the format of some returned information. You can add free-format request headers as an option (for POST and SEND operations) before you transmit the request packet with HttpSendRequest.

Find out how much information you're about to get back by calling HttpQuery-Info with flag HTTP_QUERY_CONTENT_ LENGTH. Then you can allocate an adequate buffer and call InternetReadFile to obtain the data, and call InternetCloseHandle on your http file handle.

In a real Web browser, you'll then need to format the page for display and send back additional requests for embedded images and other references. If the user clicks a reference, you'd use that as a new connection's URL.

You could close the original connection before opening a new connection; or, if you wanted to optimize access speed, you could manage a cache of recent connections. When you're done, however, you'll need to close the handle of all the connections and then close the session handle.

Sweeper supports ftp and gopher sites at roughly the same level of detail. One additional twist is the use of GopherFindFirstFile or FtpFindFirstFile to begin a directory listing and InternetFindNextFile to continue either kind of directory listing. GopherOpenFile or FtpOpenFile opens a file handle, and InternetReadFile or InternetWriteFile reads or writes the actual data. FtpGetFile and FtpPutFile do this at a slightly higher level. FtpDeleteFile and FtpRenameFile give you file-level control on the remote directory. FtpGetCurrentDirectory and FtpSetCurrentDirectory let you navigate the server; FtpCreateDirectory and FtpRemoveDirectory let you manipulate the server's directory structure; and FtpCommand lets you issue an arbitrary server command.

If that's not object-oriented enough for you, use URL Monikers instead of the Internet API calls. URL Monikers are COM objects that can bind a URL to an asynchronous OLE moniker, and thus to storage. The actual code for URL Monikers isn't bad if you're already familiar with COM, but the documentation would make most people gag.