|Top||Networking Windows||Windows NT||Programming Windows|
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.
Contributing Editor Tom Henderson is vice president of engineering for Indianapolis-based Unitel. Contact Tom in the "Networking Windows" topic of WINDOWS Magazine's areas on America Online and CompuServe. Click Here to find the e-mail IDs for our editors, who can put you in touch with this author.
|Top||Networking Windows||Windows NT||Programming Windows|
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
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 email@example.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).
When in doubt, ask. If you find an NT user who's running the software, you're probably safe. To find NT users, check Microsoft's WinNT Forum and the NT sections of our WINDOWS Magazine Online Locations. WinMag's Reviews section is another good place to check: We've been indicating what platforms software runs on since January.
If you need to use incompatible software or hardware on the same system you use for NT, you'll need to dual-boot. Start with a clean system, install DOS and Windows for Workgroups (WFWG) or Windows 95, then install NT. You'll have a boot-time option to run either system.
If you do this, you'll have to keep a few things in mind. First, use the FAT (File Allocation Table) file system without compression. DOS, WFWG and Win95 don't support NTFS (NT File System), and NT doesn't support any FAT compression scheme. Because both operating systems will be resident, you'll need a lot of disk space. Second, don't use the pre-beta NT Shell Technology Preview (STP) because NT and Win95 will play games with the Registry. You can either dual-boot WFWG and NT with STP, or Win95 and NT without STP. Finally, make your life easier by setting up both operating systems to use the same user account name and password.
It's kind of a mess, but it works. Microsoft plans to add a one-shot migration tool to NT 4.0 that will migrate most (but not all) applications from Win95. That will make life a little simpler, but it's a one-time process that works only during setup. After that, you'll have to install applications twice-once on Win95 and again on NT.
Q: Why does Microsoft have both Windows 95 and NT?
A: It appears impossible to create an operating system that's absolutely reliable, C2-securable, portable to RISC and multiprocessor hardware, and 100 percent compatible with all your DOS and 16-bit Windows apps. Even if Microsoft finds a way to merge both products into a single common code base, it'll probably package separate versions for home and business users.
Q: What will I find in the Windows NT 3.51 Resource Kit?
A: Lots of stuff. In addition to four books, the latest kit includes a slew of utilities and tools for end users and system administrators. Among the highlights: Perl and REXX scripting languages, a C2 security configuration manager, command-line access to other NT systems over the Internet, a UNIX-style POP3 mail server, tools to shut down and restart NT systems via remote control, Simple Network Management Protocol (SNMP) tools and troubleshooting utilities.
As I've so altruistically said before, if you have to choose between the Resource Kit and my book, Networking Windows NT 3.51, get the Resource Kit-first.
One warning: Some users tell me that certain tools from the kit don't work with early beta versions of NT 4.0. This could indicate a bug that Microsoft will fix in later versions of NT, or it could mean you need new tools. If you depend on these tools, find out before you upgrade from NT 3.51.
Q: How can you log on across domains using Remote Access
A: NT Server's Domain Administration model is a mixed blessing. When you log onto another domain using Remote Access Service (RAS), that domain controller attempts to contact your domain controller to verify your access rights. Unless a full-time connection exists between the controllers, this will fail.
To work around the problem, get a local account on the domain you're logging onto. You can then make a RAS connection, log off and log back on under the new local account.
My Web site answers a lot of questions I couldn't fit in this space, including topics such as fax support, undeleting files, defragmenting disks (no, NT 4.0 does not have a built-in defragmenter) and getting technical support. If you have additional questions about NT, try there first. If you still can't find the right answers, e-mail me at firstname.lastname@example.org.
Editor-at-Large John D. Ruley is the principal author of Networking Windows NT 3.51 (John Wiley & Sons, 1995). Contact John in the "Windows NT" topic of the WINDOWS Magazine areas on America Online and CompuServe, or at email@example.com.
|Top||Networking Windows||Windows NT||Programming Windows|
by Martin Heller
A code sample which goes with this column is available from our ftp site.
"IN THE BEGINNING, there was UNIX ..." That isn't quite accurate, but you get the picture. The Internet as we know it has a long history of association with UNIX-based systems. Yet much of the current Internet action revolves around Windows.
Making Windows-based systems look like UNIX-based systems is one way to deal with the shift. There's been a lot of that. The Berkeley UNIX Sockets interface, for instance, was adapted for Windows. Windows Sockets (Winsock) was the result.
Winsock is sort of a compromise between UNIX and Windows. Many Berkeley Standard Distribution (BSD) Socket programs won't work without modification. It's not as bad as it sounds, because all the standard programs are already ported. But if you have a lot of your own UNIX code, you may find it time-consuming to move it to Windows-even when porting to Windows NT's POSIX subsystem.
I've long regarded the POSIX subsystem as a bad joke-something that was thrown into Windows NT as a check-off item to get Microsoft into government markets. POSIX, a government standard, is supposed to ease portability. But it doesn't enable you to port any real UNIX programs because POSIX is not real UNIX; it's just a neutral subset. Just about the only application written to POSIX is the POSIX test suite.
It gets worse. You can't combine the APIs of different subsystems in Windows NT. And the POSIX subsystem is missing most of the good stuff from the Win32 subsystem, such as graphics, networking and multithreading. In other words, the POSIX subsystem is useless for real programs, even quickie ports from UNIX.
You can port from UNIX to Win32, but either the porting process or the resulting program will be slow. If the original program uses fork(), you'll probably want to rewrite some parts to use threads. If it uses X-Windows, Motif or Curses, you'll probably want to rewrite your screen management with native Win32 windowing. And if it uses BSD sockets and relies on select() to handle multiple clients from a single server, you'll probably want to redesign your socket code to use multiple threads and/or asynchronous sockets with I/O completion ports.
Real porting along these lines provides clear performance benefits, but often the time and cost involved can be overwhelming. Enter the Nutcracker X/SDK from DataFocus (800-637-8034, 703-631-6770). This adds UNIX-compatible libraries and a UNIX-like build environment to the Win32 subsystems of Windows NT and Windows 95. Nutcracker gets your UNIX program ported quickly. After that, you can add features such as OLE and Registry support. You can also revise your code for better performance by changing from fork()to threads.
On the other hand, if sockets prove too primitive a network interface for your needs, you may prefer Microsoft's new Sweeper or Internet Function SDK.
The Sweeper API set lets you address the Internet in straightforward ways. You don't have to worry about TCP/IP and sockets, or Internet protocol details. Just open a connection, session or URL, retrieve the data, and close the session. At its simplest level, Sweeper makes opening a URL on the Internet look a lot like opening a local or LAN file.
To open a URL that starts with http: , ftp: or gopher: , call InternetOpenUrl with an open session handle, the URL string and any header strings you need to supply, and you'll get back an Internet file handle. You can then call InternetReadFile with the file handle as often as necessary to retrieve the full file, and finally call InternetCloseHandle to close the connection.
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.
You can download the Sweeper SDK from the Internet-all 7.5MB of it. The URL is http://www.microsoft.com/intdev/tech.htm. You'll find some related goodies there as well. If you don't have the time or bandwidth to download that much stuff, you can get it on Microsoft's erstwhile MSDN Level II CD-ROM set.
The Sweeper APIs take care of retrieving things from the Net, but they don't help you format what you get. Ideally, you want something that looks like the Windows 95 Explorer interface to display gopher and ftp directories, along with a formatted browsing window for displaying Web pages (preferably one with full support for HTML 3.0 and all the Netscape and Microsoft extensions). That's a bit of work-but Microsoft is apparently one step ahead of us. I'm told Microsoft and NetManage are jointly developing a set of Internet OLE controls based on the Sweeper APIs. They should be available free at http://www.microsoft.com/intdev by the time you read this, and will ship with new versions of pretty much all of Microsoft's language and database products. NetManage will enhance the suite and market it separately.
Similar controls are already available, although they predate Sweeper. I know of only one full-blown HTTP 3.0 Web browser control: Webster from Sax Software (800-645-3729, http://www.saxsoft.com/product/webs.htm). I also know of several controls and SDKs that support other Internet protocols: from Intelligent Objects (800-876-6585, http://www.intelligent-objects.com/), Distinct (408-366-8933, http://www.distinct.com) and NetManage (408-973-7171, http://www.netmanage.com/).
That's not a complete list. In fact, the Internet programming area is so volatile, the only way to track it is on the Net itself.
Self-referential objects trigger something in me. When Aristotle talked about the Unmoved Mover and Kant wrote of the Ding am Sich, they were referring to God. "In the beginning was the Net ..." Naah.
Contact Senior Contributing Editor Martin Heller at his Web page at http://www.winmag.com/people/mheller. To find his E-Mail ID Click Here
Online Winsock Support Files:
Winsock Programming Q&A:
On the Web:
Windows Sockets Network Programming, by Bob Quinn and Dave Shute (Addison-Wesley, 1996), teaches you to write Winsock programs in C++ with great authority.
Developing for the Internet with Winsock, by Dave Roberts (Coriolis
Group Books, 1995), explains how to implement clients for several
major Internet protocols (Finger, POP3, SMTP, MIME, ftp and NNTP)