Copyright: ® Ziff-Davis Interactive
Citation: Copyright Ziff-Davis Interactive, 1995. All rights reserved.


Help Contents
Getting Ready for Windows 95


Getting Ready for Windows 95

Upgrade or Wait?

Features Plus

The Preview Program: Previewing Performance

Myths and Realities

Best Bet for the Mainstream

Networking and the Internet

Going for the Logo

Preemptive Strikes: Support Strategies for Windows 95

OS/2 Warp and Beyond

OS/2 Warp: Deep, Rich, and Powerful

New Software

Comparative User Interfaces


Under the Hood

Windows 95 and its Competitors

DOS Is Dead? Look Again

Windows 95: The Programmer's Challenge

Joining the Multimedia Party


Plug and Play: Effortless Upgrades

By John Clyman and Nick Stam

Solutions to the Thorniest Problems

Introducing -- Plug and Play

True Plug and Play

What It's Like

Beyond ISA

Under the Hood

Certification

Looking Ahead

The Prognosis


Communicating with Windows 95

Hooked and Linked

Laptop Links

Dawn of the Universal Client?


Upgrade or Wait?

By Michael J. Miller

Waiting for Windows 95

The Issues You Face

The Desktop

Getting Used To It

Architectural Innovations

Plug, Play, and Port

Networking Niceties

Dial Me Up

Third-Party Plans

Hardware Requirements

Compatibility

The Bottom Line


Introduction

This Windows Help file represents the Windows 95 special feature from PC Magazine for May 16, 1995 (Vol. 14, No. 9). You can page through this file by using the arrow buttons (<< and >>), find topics with the Search button, or customize your copy with the built-in Bookmark and Annotate features.

Windows Help file created by Scot Hacker, Ziff-Davis Interactive. Please send comments to:

72241.1777@compuserve.com

Copyright 1995 by Ziff-Davis Interactive. All rights reserved.

This file may not be reproduced in any form, or stored in a database or retrieval system, or transmitted or distributed in any form by any means, electronic, mechanical photocopying, recording, or otherwise, without the prior written permission of Ziff-Davis Interactive.


Waiting for Windows 95

By Michael J. Miller

Upgrade or wait? It's time for tough choices. Here's what you need to know.

If you're waiting for Microsoft to ship Windows 95, you aren't waiting alone. As software vendors frantically work on Windows 95 versions of their applications and as hardware vendors announce plans to preload the operating system on their machines, hundreds of thousands of users are already working with prerelease copies of Windows 95 and wondering what will happen when the real thing finally ships.

The level of interest is unprecedented. By the time you read this, Microsoft expects to have sold 400,000 copies of the Microsoft Windows 95 Preview Program beta, mostly to business customers who will pay $27 plus $5 shipping for the privilege of getting a head start on their implementation plans. Adding in the 50,000 original beta testers brings the total to almost half a million people who will see copies of Windows 95 before it officially ships (currently slated for sometime in August). We've never seen anything like this with any upgrade of an operating system or application.

But why? Certainly, it's not just the technology. From an architectural standpoint, it's easy to see where others have gone before Windows 95. Yes, it's a 32-bit operating system, allowing you to run 32-bit applications that are theoretically faster than current 16-bit apps. But 32-bit operating systems have been around for a long time, from Unix to the Macintosh System, IBM's OS/2, and Microsoft Windows NT. Through Microsoft's Win32s API, programmers have even been able to write 32-bit code that runs on top of the 16-bit Windows 3.1.

Windows 95 is also a multitasking, multithreaded operating system that can control multiple programs at once. And each program can have multiple concurrent threads, or independently executing subcomponents. But again, this is nothing new. Virtually all modern operating systems including OS/2, Unix, and Windows NT (but with the exception of Macintosh System 7) support preemptive multitasking and multithreading.

No, what makes Windows 95 the focus of so much attention is simple: It's the most significant upgrade to Windows since Version 3.0 came out in 1990. That release took a poorly selling add-on to DOS and turned it into the world's dominant PC operating environment. For years now, Microsoft has been carefully laying out the case for Windows 95 (originally code-named Chicago) as the logical next step for the estimated 70 million users who have joined the Windows fold.

Today, Windows 3.1 and Windows for Workgroups 3.11 come with some 85 percent of new PCs and account for 62 percent of software sales. Not surprisingly, virtually all of the largest PC software developers have announced plans for Windows 95 versions of their applications, and PC vendors like Compaq and Dell have announced that Windows 95 will be the standard operating system loaded on most of their machines. With so much momentum, it's clear that a lot of people will be taking a hard look at Windows 95.


The Issues You Face

Windows 95 is an ambitious upgrade but one that involves trade-offs between advanced features and backward compatibility. It offers a number of major changes in the user interface, underlying architecture, and networking features; these will be attractive to many people but may cause others to seek out alternatives (such as OS/2 Warp or Windows NT) or even consider sticking with Windows 3.1.

In this story, we set out to preview the issues you will face as Windows 95 comes onto the market. Among the questions we consider:

* What are the implications of the new user interface?

* What's new in Windows 95's architecture?

* How will Windows 95 fit in with your existing network environment, and what new connectivity possibilities does it offer?

* How well does Windows 95 work with your existing machines and software, and how will it influence your future hardware and software choices?

We also look at how Windows 95 contrasts with alternatives such as OS/2 Warp or Windows NT and even Windows 3.1.

By now, you've probably heard the basic litany of what's new in Windows 95 many times. The user interface has changed dramatically, gaining such elements as true folders and icons on the desktop, animated icons, a Start button and a Taskbar to launch new applications, and a Recycle Bin for drag-and-drop deletions. The basic architecture has also changed to let you run 32-bit applications with preemptive multitasking, multithreading, and memory protection, so that one bad application is less likely to hang the whole system.

New hardware-support features, such as Plug and Play, AutoPlay for CDs, and several new enhancements aimed at portable computer users are designed to make the hardware and software work together better. Finally, there are new networking features designed to make Windows a better network client, including such things as remote-node access and a new universal mail box. Let's look at each of these areas.


The Desktop

The most visible changes are, of course, in the user interface. Windows 95 sports a number of fundamental improvements over Windows 3.1 designed to focus users on their documents instead of their applications.

Perhaps the most obvious is the addition of icons and folders to the desktop, thus combining many of the functions of Windows 3.1's Program Manager and File Manager. This new look--with subdirectories shown as folders and files appearing inside them as icons of spreadsheets, documents, or other objects--is a big change for Windows. To open a document or program, you just double-click on the icon. You'll also be able to nest folders inside other folders, giving you intuitive visual management of subdirectory hierarchies.

A new Taskbar at the bottom of the screen provides a button for each program you're currently running and each window you have open or minimized on your desktop. You simply click on a button to switch to a particular program or window. In addition, a Start button on the left side of the Taskbar brings up a pop-up menu that lets you quickly move to any application or document, search for programs, run Windows help, or shut down or suspend Windows itself.

Another big change is the addition of object-oriented functionality to the desktop. For example, when you right-click on any icon, you immediately access a menu that lets you see all the things you can do to the underlying object (which might be a file, program, or system component such as a drive). Depending on the object, you could then open it, copy its contents, or change a variety of other property settings. This approach extends to the file system itself; to copy a file, you simply drag it from one window to another. In this way, the functions of Program Manager and File Manager have been combined and extended.

Everything in the environment, even the desktop itself, shows object-oriented behavior. By right-clicking on the desktop, you pull up a menu that lets you arrange your icons or change desktop properties such as your wallpaper, screen saver, or Windows color scheme. You can even change your display resolution and color depth on the fly, if your display hardware supports it.

Much of this is just Windows 95 playing catch-up, of course. The folder-and-icon metaphor dates back to work at Xerox PARC two decades ago and has long been on the Macintosh. Object-oriented desktop paradigms were pioneered on the PC years ago in products like HP's NewWave, NeXT's NeXSTtep, and OS/2's Workplace Shell. The Taskbar concept is very similar to Dashboard 2.0 (originally from HP, now from Starfish Software), or the Launch Pad in OS/2 Warp, Version 3.


Getting Used To It

If you're used to Windows 3.1, you'll find that performing basic file management from the desktop by dragging and dropping file icons takes some getting used to. But you'll soon notice how much power this UI can offer. For example, a single icon called My Computer provides access to your drives (and all the files they contain), the Control Panel, your printers, and dial-up networking options. The Windows desktop also comes with a Mac-like Recycle Bin that you can use to delete files (just drag the file's icon into the bin), and you can put a printer on the desktop to enable drag-and-drop printing. Clicking the Network Neighborhood icon displays all the servers and printers in your immediate workgroup, and clicking Entire Network displays all the servers you can connect to--which could be dozens in a large corporation.

You'll also have to rethink file-naming conventions. The familiar DOS file-naming scheme of eight characters followed by a three-character extension has been replaced by long filenames (for example, "Getting Ready for Windows 95"). Much of this, however, is skin-deep. Internally, the file system still stores filenames in the old FAT scheme, automatically picking the most logical choice. This is so that files can be opened by existing Windows applications, which typically don't allow or recognize long filenames. But you should expect all new applications to work with these new names, which now can be as long as 255 characters.

In addition to performing basic file management from the desktop, you can also use the new Windows Explorer, essentially a souped-up File Manager. Since Explorer uses an outline metaphor, you can get to all your drives, whether local or network, from the same window and view them as large or small icons or a list.

A much-improved Find command (which you can run from Explorer or directly from the Start menu) can scan all or part of a disk for files matching specified criteria, including embedded words and phrases; you can also save commonly used searches. Find can also find other computers on your network. Another slick new feature is the Quick View option. When you right-click a document object on the desktop or select a document in Explorer, you can choose Quick View to scan the contents of the file without having to load the app that created it.

The Windows 95 viewers are based on viewers from Systems Compatibility Corp.'s well-known Outside In/for Windows. At press time, Microsoft was planning to ship a basic set of file viewers to OEMs and on the CD version but was undecided whether viewers would be included with the floppy-disk-based product. We also expect a number of third parties, including Systems Compatibility, to ship viewers for other applications and to extend Quick View's functionality (by enabling printing from a view, for example).

Explorer is different enough from File Manager that it takes some getting used to. For instance, you now see the amount of free disk space on a drive only when the drive is selected in the Details window. But Explorer offers much better integration and smoother operation. You can finally move a file from one drive or directory (folder) to another without opening multiple windows, for instance. Many third-party file management utilities have had these features for some time, but it's good to have them in the base operating system. Again, you should expect a lot of third-party programs designed to enhance or replace Explorer.

Another useful enhancement, called Shortcuts, gives you the ability to create icons that point to objects (such as files, folders, or programs) that are normally stored somewhere out of view. You can place Shortcut icons almost anywhere in the user interface, although the desktop or the Start-button menu are the most convenient locations. Typically, you'll use Shortcuts to access regularly used documents or programs. By clicking on the Shortcut, you launch whatever object it points to. (This approach is similar to the Shadows used in OS/2's Workplace Shell.)

Finally, there are many cosmetic changes, including the 3-D look of menus and icons and the new animated icons that show actions such as windows being opened or files being copied or moved from one folder to another.

In summary, there is a lot to learn. Though Microsoft has done some things to make the transition easier (like converting your Program Manager groups into items on the Programs menu), even the most experienced Windows user will need several hours to feel at home. At the beginning, at least, some Windows 3.1 users may find the interface actually slows them down for certain operations.


Architectural Innovations

The basic architecture of Windows has changed significantly. Most dramatically, DOS and Windows are now combined as one operating system.

Windows 95 offers a 32-bit applications programming interface (API), called Win32c, that incorporates most of the Win32 API from Windows NT and adds a few extensions. Indeed, we've been able to run Windows NT applications such as Word and Excel under Windows 95, where they behave as native applications.

For some kinds of applications, particularly ones that involve large files or calculations that use 32-bit register operations, 32-bit support could result in faster execution of 16- and 32-bit applications. But in many cases, developers have had so many years to tune their 16-bit applications that you may not see an improvement from a move to 32 bits. You should also expect to see many developers write their first Windows 95 applications using a combination of 16- and 32-bit code. Of course, competing operating systems (including OS/2 and Windows NT) have had 32-bit APIs available for some time. Developers can even write 32-bit applications that run under Windows 3.1 using the Win32s subset of the Win32 API.

The basic information about most new 32-bit programs will be stored in a system registry, similar to that used by Windows NT, OS/2, and OLE applications running under Windows 3.1. In most cases, this registry takes the place of the .INI files for Windows, the system, and for applications. The registry is complex and not designed for most users to edit manually. Again, it's an area where third-party utilities could improve on the product's basic functionality.

Windows 95 supports preemptive multitasking of 32-bit applications, meaning that the operating system doles out fixed amounts of system resources to as many applications as you have in use. Each 32-bit app also runs in its own protected address space, lessening the chances that one rogue program will hang the entire system. But 16-bit Windows 3.1 applications all run in the same address space, where they are cooperatively multitasked. One bad Windows 3.1 app can still bring down the others, and the division of system resources is less predictable. In comparison, OS/2 and Windows NT offer an option for handling 16-bit Windows apps more gracefully, letting you run them in individual, protected address spaces. Though setting up the details of individual versus shared memory in OS/2 or Windows NT can be complex, it does provide better safety and more predictable execution.

Unlike OS/2 or Windows NT, Windows 95 does include a DOS component--effectively MS-DOS 7--that lets you use real-mode device drivers and TSR programs. This is necessary for compatibility, but does mean that a bad driver or TSR is free to crash the entire system.

From the developer's standpoint, Object Linking and Embedding (OLE) is also a crucial part of the Windows 95 story. Microsoft has long been pushing OLE--with its support for compound documents, cross-application macro control, and common object registration--as a critical API. In fact, Microsoft requires OLE support in order for an application to get the coveted Windows 95 logo. (Recently, the company softened its position by announcing that it might also award the logo to applications written to Component Integration Lab's OpenDoc specification, a competing object standard that should be compatible with OLE.)

For a detailed discussion of the Windows 95 architecture, see "Under the Hood: Windows 95 and Its Competitors."


Plug, Play, and Port

Many of the innovations in Windows 95 are designed to make Windows work better with hardware. The most obvious improvement in this area is Plug and Play, a new specification designed to make an operating system recognize and control any peripheral. Plug and Play is designed to put an end to the configuration frustrations that just about all of us have experienced with PCs. But to take full advantage of this scheme, you'll also need a Plug and Play BIOS and add-in boards. Similar features are available as add-ins for Windows 3.1; OS/2 and Windows NT are expected to get Plug and Play upgrades at some point.

In the meantime, our experience with Plug and Play has been mixed. With Windows 95, a machine with a Plug and Play BIOS, and boards specifically designed for Plug and Play, preliminary testing has demonstrated nearly trouble-free operation. But with older machines or even new machines with older boards, we ran into a lot of difficulties. (See "Plug and Play: Effortless Upgrades.")

The elegant new AutoPlay feature offers instant access to AutoPlay-compatible CDs. Just put one in your CD-ROM drive and it will play, eliminating software setup and unnecessary directories on your hard disk.

A number of other changes are designed to make Windows 95 work better with portable computers. One advance is that the system can now recognize multiple configurations, so that it can automatically detect if the portable is plugged into a docking station. This would allow your laptop to check for a network connection or a CD-ROM if you are plugged into the dock, but not otherwise. Theoretically, this technology could even be used to change your display resolution on the fly, so that you could use standard VGA resolution on your laptop screen but immediately switch to a higher resolution when you plug into a larger monitor. You won't be able to change your color depth on the fly, however, since the system forces you to restart the machine--something not necessary with the Macintosh.

Other portable-oriented basics included in the operating system are a Suspend option on the Start menu and a built-in battery meter, which appears in the Taskbar.

Some of the biggest differences between Windows 95 and Windows 3.1 or even Windows for Workgroups 3.11 center on networking. Windows 95 is a far better network client and has a lot of additional networking features.


Networking Niceties

Windows 95 comes out of the box as a client for both NetWare and Windows networks and includes the NetBEUI, IPX/SPX, and TCP/IP protocol stacks. Windows 95 is also currently being tested by other companies as a client for NOSs such as Banyan's VINES, Digital's Pathworks, and FTP's NFS. (You can still use older real-mode clients or drivers, although in practice, we ran into occasional but unexplained problems.) Like Windows for Workgroups, Windows 95 comes with the software to act as a server on a Windows network, providing peer-to-peer networking services.

Microsoft has also developed a variety of new networking utilities; although at press time, the company was still undecided whether to include them in the final package. The utilities include Netwatch and System Monitor (which let you monitor the performance of your machine as a network client), an SNMP agent, a backup agent, and a System Policy Editor. The list is designed to make it easier for network administrators to manage Windows 95 clients.

Another new networking feature is the Microsoft Exchange client, intended to be able to collect mail from multiple services. Exchange, which was called InfoCenter in earlier test releases, is designed so that third-party vendors can write drivers that let it exchange mail with other mail systems. The current version includes drivers for Microsoft Mail, Microsoft's forthcoming Exchange server, Internet mail, and CompuServe. Microsoft says several other drivers are currently being written, but it hasn't yet decided which will be included in which versions of the operating system.

The Exchange client can also dial up The Microsoft Network, Microsoft's forthcoming on-line service. This is expected to be one of the first options that users of the final Windows 95 will see. One elegant feature is the ability to place a shortcut from Microsoft Network into a file or application, allowing you to go directly from an application to a support area for that application. As yet, we haven't been able to test Microsoft Network extensively, although Microsoft has signed up many third-party firms to offer support through that service (for details, see "Preemptive Strikes: Support Strategies for Windows 95").


Dial Me Up

The powerful new Dial-Up Networking option extends the network by letting a remote system act as a node on several different network types. Windows 95 can dial a Windows NT Remote Access Server, NetWare Connect, a PPP connection to Internet-access providers, or systems such as Shiva's NetModem or LanRover. Another option lets you set up your office machine as a dial-up server, so you could dial in to your desktop from your portable and use your hard disk, printer, or even network resources remotely. You could also connect via a serial or parallel port. In all these cases, your machine acts as a remote node, although Windows 95 does not provide remote-control software.

Briefcases, which can be used to store copies of files that you want to synchronize between two Windows machines automatically, are a welcome addition for those who use both mobile and desktop systems. Basic Briefcases provide only rudimentary replication--they get confused if the same document gets changed in both places--but a Briefcase API makes the system extensible.

In terms of networking, Windows 95 has a lot more features than Windows for Workgroups, Windows NT, or OS/2 Warp 3. But Warp has a more extensive list of Internet connectivity features, and IBM has plans to include features such as peer-to-peer networking, a remote-access client, and a Lotus Notes Express client in its forthcoming OS/2 Warp Connect (for details on upcoming Warp releases, see "OS/2 Warp and Beyond").


Third-Party Plans

It's no secret that virtually all large software vendors are currently working on upgrades of their major applications to take advantage of Windows 95, including its new user-interface elements and 32-bit operation. Because Windows 95 has been delayed so often, few of these vendors are making specific plans public, but you can expect to see Windows 95 versions of many of the major applications from Adobe, Corel, Lotus, and Novell/WordPerfect. You can also expect most of these firms to wait at least a few weeks after Windows 95 ships to test compatibility with the final version.

Windows 95 includes a number of features that have been sold in the past as standalone utilities--including disk scanning, remote-node software, and a disk compression utility. But virtually all of the major utility vendors, including Helix, Qualitas, Quarterdeck, Stac, and Symantec, are working on upgrades of their own. For instance, many of The Norton Desktop's current features will be redundant under Windows 95, but Symantec is working on a new version of The Norton Utilities and on Norton Navigator, a new file management utility. Interestingly, some utilities that were part of DOS 6.0, such as an antivirus utility, are not a part of Windows 95 (Symantec also plans to ship its Norton AntiVirus for Windows 95).

On the hardware front, most PC vendors tell us they have plans to preload Windows 95 on the bulk of their systems as soon as it is available, although many say they will offer alternatives as well. For instance, Compaq announced that Windows 95 will be its "preferred operating system" but said it would continue to offer Windows 3.1 to customers who ask for it.


Hardware Requirements

If you already have a system, you'll wonder whether Windows 95 will run on it. The first issue is hardware requirements. Microsoft says that a Windows 95 system requires at least a 386DX processor with 4MB of RAM, but it recommends a 33-MHz 486 with 8MB of RAM. The latter configuration seems like a reasonable minimum to us.

Our preliminary tests on prerelease code show that Windows 95 runs somewhat slower than Windows for Workgroups 3.11 on a 4MB configuration (and probably too slow for most users). But on an 8MB or 16MB system, it performed as fast as or slightly faster than WfWG 3.11, with more marked speed increases noticeable on faster systems (for details, see "The Microsoft Windows 95 Preview Program: Previewing Performance"). As always, it depends on what you are doing. In general, we found Windows 95 to be faster at graphics but slower at disk operations than WfWG 3.11.

We recommend 16MB of RAM, particularly if you plan to run multiple applications. In general, Windows 95 system requirements appear to be greater than those of Windows 3.1, about on a par with OS/2 Warp 3's, and well below those of Windows NT 3.5. (For details, refer to "OS/2 Warp 3 and Windows NT 3.5: The Future's Here Today," December 20, 1994).

Windows 95 takes up about 40MB of hard disk space, some 15MB more than Windows 3.1. Applications just seem to get larger, too, so you probably should have at least a 250MB hard disk (before using any compression utility).


Compatibility

The biggest issue with any new or upgraded operating system is backward compatibility with existing hardware and software. Indeed, compatibility problems have caused most of this year's delays of Windows 95.

The task of ensuring complete compatibility with every available driver, peripheral, and application is daunting and probably impossible, as demonstrated by the problems faced by Windows NT and OS/2 users. (Even though OS/2 has been through several releases and is now extremely compatible with Windows applications and machines, users still run into some compatibility and installation problems.) Some products and combinations will undoubtedly cause problems for Windows 95 users as well.

As Windows 95 is still in testing, it's too early to evaluate compatibility fully. In fact, we won't really know for sure until the operating system is in the hands of millions of users, each with unique hardware and software combinations.

Our preliminary tests show good but not perfect compatibility. Most applications ran well on our configurations, including the 13 top-selling Windows applications that are part of our Winstone 95 benchmark test suite and several more challenging ones, such as id Software's DOOM, Brderbund's Myst, and Traveling Software's Laplink V for DOS. But we did run into difficulties with Lotus Freelance Graphics for Windows, and we were unable to get Windows 95 to work properly with PCMCIA modems on the Hewlett-Packard OmniBook 600. We also ran into occasional TCP/IP conflicts. We were most likely to run into system crashes when working with existing device drivers that run in real mode.


The Bottom Line

For many people, the choice of moving to Windows 95 will be made for them by their hardware vendors, which appear to be getting on the bandwagon in ever larger numbers. Windows 95 is also receiving broad support from the bulk of software vendors, although we expect many to support and enhance their applications for Windows 3.1, as well.

On the whole, in terms of performance and general architecture, Windows 95 promises to finish about even with OS/2 Warp; it is considerably more powerful and sophisticated than Windows 3.1. Not surprisingly, it beats Windows NT's performance, but it lacks many of Windows NT's sophisticated features such as symmetric multiprocessing support, advanced task protection, and C2-level security. At this stage, compatibility remains an open question; the early indications are good.

The sheer size of the Windows installed base and the huge amount of Windows software clearly elevate the release of Windows 95 to a defining moment. It's also clear that, despite many built-in compromises, Windows 95 marks a major advance over its predecessor in terms of user interface, utilities, architecture, configuration, and networking. But Windows 95 is not your only choice. In order to match the popularity of Windows 3.1, the final release of Windows 95 will have to deliver what the current beta can only promise.


Features Plus

From May 8 through May 12, you can go on-line to discuss the Microsoft Windows 95 Preview Program with Microsoft's Brad Chase (general manager, Personal Systems Group) and Brad Silverberg (senior vice president, Personal Systems Group). Hosting the event will be PC Magazine editor-in-chief Michael J. Miller and editor Robin Raskin. Type GO EDITOR from any CompuServe ! prompt.


The Preview Program: Previewing Performance

We tested the Windows 95 Preview Edition, which Microsoft is now selling to selected corporate customers, against Microsoft Windows for Workgroups 3.11. The test-bed was a Compaq Deskpro 486/33M with a 340MB IDE hard disk and a Number Nine GXE S3-based ISA video card. We tested at 800-by-600 resolution with 256 colors. At Microsoft's recommendation, we did not use SmartDrive in any of these tests. Windows for Workgroups' virtual memory cache size was set to one-fourth the size of physical RAM in each memory configuration.


Myths and Realities

MYTH: DOS is gone, and Windows 95 is a completely new operating system.

REALITY: Most of Windows 95 is new, but it still has a DOS component and some DOS structures--mostly (but not entirely) for backward compatibility.

MYTH: Now I can quit worrying about low and high memory.

REALITY: More drivers and utilities are being written as virtual device drivers. They reside above 1MB, but you can also load real-mode device drivers and TSRs in lower memory. But you can still run out of lower memory, which is why Windows 95 includes MemMaker and why third-party memory managers are still important.

MYTH: Program Manager and File Manager are dead.

REALITY: Program Manager is dead, replaced by a true desktop. But you can think of Explorer as File Manager 4.0.

MYTH: Windows 95 is "crash-proof."

REALITY: Nothing is crash-proof. It's more difficult to crash Windows 95 than Windows 3.1, but badly behaved programs can still bring everything down.

MYTH: Plug and Play means adding new cards and software will be completely seamless.

REALITY: Plug and Play is great on paper, but you'll need a machine with a custom BIOS and adapter boards.

MYTH: 32-bit applications are faster than 16-bit applications.

REALITY: For some tasks, 32-bit is faster. For others, tight hand-tuned 16-bit code may still be superior.

MYTH: Windows 95 is much easier to learn than Windows 3.1.

REALITY: Maybe for new users. But if you're used to Windows 3.1, prepare to spend some quality time with this new operating system and its new desktop before you really feel at home.


Best Bet for the Mainstream

By Jim Seymour

We've waited so long for Windows 95 that our expectations are sky-high. Windows 95 has been sold (oversold, perhaps inevitably) as the answer to all our Windows problems--maybe to the world's problems, as well.

Of course, Windows 95 won't meet all those expectations; we're kidding ourselves if we ignore its not-so-good aspects. At the same time, it has a host of important new features and improvements. On balance, the good far outweighs the bad; this is a solid, important upgrade.

Don't look at Windows 95 as a performance upgrade--especially if you define performance in terms of speed. As a 32-bit operating system, it should run faster. Realistically, the first release of Windows 95 and the first apps written for it won't take full advantage of the new 32-bit architecture.

Windows 95 will improve on Windows 3.x's marginal multitasking right away, however. When one program went south in Windows 3.1, it was all too easy for everything else to go along. Windows 95 already seems more stable, and I'm optimistic about finally being able to breathe deeply when running important jobs.

Another long-standing gripe, resource limits, gets fixed. With Windows 3.1, two hidden 64K memory heaps manage essential system functions. When these system resources fall below about 15 to 20 percent, you're heading for a crash. In Windows 95, system resources still count, but you're much less likely to run out of them. I've been able to run many more applications simultaneously under Windows 95. And it cleans up after ill-behaved apps (including Microsoft's own) that upon closing don't give back all the resources they claimed.

Plug and Play? Windows 95-equipped PCs still won't be as easy to set up and reconfigure as Macs. But they'll be a lot easier to rejigger than any x86 PC you've used before. A Plug and Play-compatible computer checks attached components when it boots and handles such irritating grit in x86 designs as IRQ and port assignments automatically.


Networking and the Internet

By Jim Seymour

The Microsoft Network, an entirely new venture, poses a challenge--but not necessarily a threat--to on-line services such as America Online, CompuServe, GEnie, and Prodigy, as well as New Age on-line wanna-bes such as AT&T's Interchange. Whatever the merits of The Microsoft Network, it can't hurt Microsoft to have the necessary connection software installed on perhaps 25 million PCs by the end of 1995.

The quality or even the existence of Windows 95's built-in Internet tools is as yet unknown, but Microsoft has been investing in the right companies and technologies to provide a first-class connection and a great Web browser.

Finally, moving to Windows 95 is frankly unsettling for Windows 3.1 users. The interface is completely different. Double-clicking has nearly disappeared. Program Manager has been replaced. But the learning curve, while steep, is short. I estimate most Windows 3.1 users will pick up the essentials in about half an hour. Becoming comfortable may take another two or three hours. At first, Windows 95 seems hopelessly awkward, but trust me: It's worth the effort, and you'll soon feel at home.

That's it, in a nutshell. Most of Windows 95's changes are profound and welcome. The areas that still need improvement are likely to get attention from Microsoft in a second release sometime in late 1996. Until then, Windows 95 looks to me like the best bet for a mass-market PC operating system.


Going for the Logo

By Nick Stam

What's in a name, you ask? Well, the Windows 95 name and logo on the box of a PC or peripheral will denote many things about what's inside.

Microsoft has designed a hardware certification testing program and specified minimum configurations for PCs or peripherals that want to wear the coveted Windows 95 logo. And to display the logo, a PC must be sold with Windows 95 preinstalled. (Microsoft is, however, currently developing a program for the retail market to let some hardware vendors display the "Designed for Windows 95" logo before the software ships.) The company also released a list of recommended PC and peripheral features that contribute to higher performance and ease of use. hardware certification

Microsoft's Hardware Compatibility Tests (HCTs) determine whether specific functions of PCs and peripherals operate correctly under Windows 95. A device must pass the HCTs under the supervision of an independent test lab or Microsoft's own Compatibility Labs. system requirements

Microsoft's Hardware Design Guide for Windows 95 specifies the minimum required configuration for laptops, desktop PCs, and peripherals that want to claim they were "Designed for Windows 95." The book also notes recommended features for multimedia-oriented systems.

For a desktop PC to qualify for the logo, it must be at least a 386 with 4MB of RAM, a Plug and Play BIOS (though Plug and Play expansion cards are not required), and a standard VGA display adapter capable of 640-by-480 resolution with 256 colors. Interestingly, neither a CD-ROM drive nor audio capability is required.


Preemptive Strikes: Support Strategies for Windows 95

By Robin Raskin

Historically, Microsoft hasn't exactly earned high marks from PC Magazine readers when it comes to supporting Windows. As the ship date for Windows 95 nears, the company wants to turn that around with a preemptive support strike involving documentation, training, and technical support. Considering that Microsoft expects to get at least three times as many support calls per day as it did at the launch of Windows 3.1, that's probably a wise move.

Software vendors, resellers, solution providers, and large sites that have bought the beta version have already received the Migration Planning Kit--a 1,500-page collection of tools and information for organizations rolling out Windows 95 upgrades. Buyers of the Windows 95 CD-ROM will also get these tools.

Microsoft has also instituted a series of Windows 95 help forums, the most ambitious of which are WinNews and TrainCast. WinNews offers documents and will be carried by most major on-line services. TrainCast is a 30-hour educational television series for information specialists and technical-support personnel.

Organizations with a satellite dish can download TrainCast free or send attendees to scheduled sessions at Microsoft Authorized Technical Education Centers worldwide. Eventually, the content for the series will be carried by the Jones Computer Network via the Mind Extension University cable television channel.

During testing of the Windows 95 Preview Program beta, calls to Microsoft Technical Support are free. After the launch, new users will get free 24-hour, 7-day-a-week support for 90 days following their purchase.

Microsoft has hired five companies with experience in the field to handle Windows 95 technical support: Digital Equipment Corp., Keane, MicroAge, Softmart, and Unisys. After your 90 days of free support are up, you'll have a variety of cost-based support plans from these providers or Microsoft.

Microsoft is also continuing its on-line support (on America Online, CompuServe, the Internet--via FTP--and GEnie), FastTips (a fax-back system of quick tips), and other databases, including the Microsoft KnowledgeBase. The Microsoft Network, scheduled to ship with Windows 95, will also be a part of the support solution, both during the preview phase and after the product launch.


OS/2 Warp and Beyond

32-Bit -- Finally!

Warp Connect

Extend Pack

OS/2 for the PowerPC

The Big Picture


32-Bit -- Finally!

By Michael J. Miller

Finally, Windows 3.1 users are getting 32-bit operation, preemptive multitasking, multithreading, and an object-oriented desktop. Big deal, say OS/2 users, who've enjoyed these features for years.

Since Version 2.1--which introduced a full 32-bit implementation and the Workplace Shell user interface--OS/2 has kept essentially the same underlying architecture it uses today. Since OS/2 Warp Version 3 (the most recent OS/2 release) has no need to play catch-up on fundamentals, it focuses instead on usability, cosmetic enhancements, and additional utilities.

Known as the BonusPak, the utilities include IBM Works, an entry-level integrated software package, and the Internet Access Kit--the most complete set of Internet tools yet shipped with a PC operating system. (And it's more advanced than the Internet tools promised for Windows 95.)

In February, IBM shipped OS/2 Warp 3 Full Pack, which includes the Win-OS/2 libraries. These effectively give you the ability to run Windows software without having to own a licensed copy of Microsoft Windows. In the near future, IBM will be focusing its efforts on four new versions of OS/2 that each offer a healthy dose of networking features.


Warp Connect

The first new OS/2 Warp version, Warp Connect (slated for release by the time this article appears), will include the most important network drivers and utilities. Planned new features include requesters designed to connect OS/2 clients directly to NetWare 3.x and 4.1 and OS/2 LAN Server-based networks.

Warp Connect will also include IPX and NetBIOS support, as well as a new TCP/IP protocol stack. IBM says that this new stack will include PPP connections instead of just the SLIP connection provided in the base OS/2 Warp pack. This stack will offer reduced CPU utilization and provide concurrent access to your network and the Internet.

In addition, Warp Connect finally includes the long-awaited OS/2 peer-to-peer networking services. These will let you share files, printers, and applications via either a parallel port or a network card. IBM says it will include drivers in the box that support about 70 percent of existing Ethernet cards and 90 percent of Token-Ring cards. The same software will let a Warp Connect client connect to a LAN Server 4.0 server, allowing an easy upgrade from a peer network to a client/server network.

Warp Connect will also include IBM's LAN Distance software, which enables remote dial-in to a connection server on a network and subsequent point-to-point connections to any devices on the network. Unlike Windows 95, Warp Connect does not include facilities to turn your PC into a dial-up server. Other new features include ASK PSP, a new help database CD with an English-like query interface.

On the mail side of Warp Connect, IBM has chosen to bundle Lotus Notes Express rather than its own Ultimedia Mail/2. Notes Express lets you connect to any Notes server, although you can use only seven preinstalled templates.

Like the standard Warp edition, Warp Connect will also come in two versions: one without the Windows libraries and the other as a Full Pack that includes Win-OS/2.


Extend Pack

IBM is planning yet another set of utilities, tentatively called the Extend Pack, which is designed for larger enterprises and which the company will offer its corporate customers. The Extend Pack will include mobile file synchronization, 3270 emulation, full SNA stacks (including APPC support), and a remote client for Shiva dial-up modems. New network management utilities will include a systems performance monitor and hooks for the NetView Distribution Manager 2.0 agent for remote distribution of software. IBM currently plans to offer the Extend Pack to corporations for a nominal material and fulfillment fee at the same time as Warp Connect.


OS/2 for the PowerPC

Though Warp 3 didn't bring changes to OS/2's underlying architecture, that change is coming this summer. IBM has long talked about a future operating system called Workplace OS based on a microkernel architecture. Originally, various operating system personalities--including OS/2, Windows, AIX, and possibly the Macintosh System--would have run on top of that kernel, potentially at the same time.

The multiple personalities part of the plan has since been shelved, but the rest remains. IBM plans the first release of the microkernel-based operating system this summer; it will be called OS/2 Warp for PowerPC. The system will rely on emulation to provide backward compatibility. In particular, it will run the Win-OS/2 library through emulation of the Intel x86 architecture, thereby letting you run Windows 3.1 applications. IBM plans a microkernel-based version of OS/2 for x86-based PCs sometime in 1996.


Getting Ready for Windows 95 - OS/2 Warp and Beyond - The Big Picture
The Big Picture

IBM says it has now sold more than eight million copies of OS/2, including upgrades and multiple versions. It also claims that more than one million copies of Warp 3 have been shipped to dealers since it was introduced in November 1994. (For more information, refer to "OS/2 Warp 3 and Windows NT 3.5: The Future's Here Today," December 20, 1994.)

OS/2 still lacks the broad native application support of Windows 3.1, though there are signs that this may be changing. Lotus plans to release its next generation of applications for both OS/2 and Windows, and other developers such as Corel are reconsidering their plans. In the meantime, OS/2 (either the Warp Full Pack or an earlier version installed on top of Windows) runs most Windows 3.1 applications quite well. Warp can run applications written to the Win32s API but does not support Win32 as implemented in Windows NT or Windows 95. IBM says it has the rights to support such applications and will do so if its customers so desire.

From an architectural standpoint, Warp is already far more sophisticated than Windows 3.1. It also offers some features not found in Windows 95, like the ability to run Windows 3.1 sessions in separate virtual machines. And it gives you more extensive customization of Windows and DOS applications than either version of Windows. Warp does have some disadvantages (such as a single input queue), but the additional networking support of Warp Connect and the coming microkernel version will add strength and flexibility to an already powerful platform.

OS/2 Warp Version 3. List price: $129. OS/2 Warp Version 3 Full Pack. List price: $199. OS/2 Warp Connect Version 3. List price: $229. OS/2 Warp Connect Version 3 Full Pack. List price: $299. OS/2 Warp Connect Version 3 with Extend Pack. List price: $235. IBM Corp., Armonk NY 10504; 800-342-6672.


 OS/2 Warp: Deep, Rich, and Powerful

By John C. Dvorak

More than a few people have suggested that OS/2 Warp now has an opportunity to become important, because Windows 95 is very late. In fact, its chances would be much better if Windows 95 were actually shipping so that the two systems could be compared head to head. But since Windows 95 is still in beta testing, you can't honestly do the necessary comparison. Anytime someone tries to compare the two, the critics complain that it's unfair. Meanwhile, the Windows 95 boosters seem free to promote their unseen darling like a lover buying a mail-order bride: All that ardor is based on pictures.

While this continues, Warp is at an extreme disadvantage. And even worse, the excitement over Warp will be ebbing just as Windows 95 hits the streets. Warp will be perceived in the market as old, and Windows 95 (or Windows 96) will be perceived as new. It's another classic case of Microsoft outfoxing IBM, quality be damned.

But at the heart of it all is Warp itself. The more I use Warp, the more I see its greatness. I find it to be phenomenal. And the BonusPak, which includes an easy-to-use Internet browser and Internet access tools, is worth the price of the whole package.

Warp is deep. It's deep with power, deep with richness. The BonusPak makes it deep with a slew of applications that are very cool. With Warp, you can almost avoid buying any other applications. It's that complete.

When looked at objectively, Warp (even with the BonusPak) is an enormous loss leader for IBM. If it really took off in sales, I can assure you that Microsoft would be suing IBM in court for dumping a product in the market--and Microsoft would win! I'm personally stunned that the majority of computer users haven't seen this offering as the deal of the century and kept Warp at the top of the bestseller list.

Git along, little dogies

But they haven't, and I don't expect them to change. Once the Microsoft ring is in their nose, they don't veer too far away from the path set out for them. The current path is one of waiting and grazing. I suppose the best we can do for these users is to turn them away from the storm when it comes so they don't swallow too much rain and drown.

What they will have a tough time swallowing, however, is the fact that Microsoft's desire to copy Apple and The Macintosh Way will result in their inheritance of the exact same problem that Mac users have: The constant need to upgrade all applications. Windows 95 and its offerings will not be nearly as backward-compatible with old applications as Warp. Warp's VDMs (Virtual DOS Machines), that "better DOS than DOS" they talk about, are indeed better than DOS. They allow me to multitask a few old DOS programs in ways I never could before. Multitasking old DOS programs with Windows 95? I think not.

Though newcomers don't care, the power users who really use their computers and actually do have legacy applications will prefer Warp. And users who do not want to get onto the upgrade merry-go-round will prefer Warp. And users who like depth, power, and even a degree of nerdiness (sorry, guys) will prefer Warp.

But Warp users must realize that the next wave of users are being cajoled by programs like Microsoft Bob. They are the ones who will slide into Windows 95 comfortably. And Warp users must realize that Microsoft has smart kids who work 16 hours a day to beat IBM. The smart kids at IBM with this kind of energy are unseen and unheard. It's a problem. But do I care? I use Warp, and I can do a lot with it.


New Software

Getting in on the Act

New Utilities

Big Opportunity


Getting in on the Act

By Michael J. Miller

It seems as if just about every significant vendor of personal computer software is currently working on new releases of its major products designed specifically for Windows 95. From a technical standpoint, they see much to gain. By building new versions, they can leverage Windows 95's advanced features such as 32-bit linear addressing and multiple program threads or at least the new user interface and the new, more powerful common dialog boxes.

From a practical business standpoint, there's another reason why so many vendors are frantically writing code for Windows 95. They know from experience that many computer users look to buy new applications or new utilities when they update their operating system. application software

On the application side of the software business, just about everyone wants into the act. Most companies are now quietly showing Windows 95 beta versions of their wares, but several upgrades have been publicly announced. For instance, Lotus has shown an early version of its Freelance Graphics that will include such things as the LotusScript cross-application macro language, an Infobox for changing the properties of different parts of the system, and several changes in the user interface. Expect similar changes in other parts of Lotus's SmartSuite.

Similarly, Novell plans to add multithreading to core features (such as printing and spell-checking) in WordPerfect and, later, to other parts of its PerfectOffice suite of applications.

Microsoft itself has been relatively quiet about upgrades to its Microsoft Office applications, but you can expect the minimum of a move to 32-bit applications with support for the new common dialogs. Note that Microsoft Word and Excel for Windows NT will already run as native applications under Windows 95, although they are visually identical to the existing Windows 3.1 versions. At press time, there have been some unconfirmed rumors that Microsoft may even include a locked version of Microsoft Office on the Windows 95 CD.

Corel Corp. has had to delay its CorelDRAW 6.0, which was designed for Windows 95, because of delays to the operating system. And Corel is also working on a new office suite for this environment.

A few smaller vendors have also shown early versions of their Windows 95 applications. These include Micrografx's Picture Publisher, an image-editing program; Shapeware's Visio, a drag-and-drop drawing program; Delrina's WinFax PRO, which adds voice messaging capability; and NCSA's Mosaic World-Wide Web browser.


New Utilities

A number of utility vendors are also looking forward to Windows 95. This is despite the fact that the new operating system offers many features (an object-oriented desktop, for example) that used to be available only through add-on utilities.

The largest utility company, Symantec, has several new Windows 95 products in the works. The Norton Utilities for Windows 95 is out in a Preview Edition designed to be used with the Microsoft Windows 95 Preview Program beta. This package offers many of Norton's traditional features and some updates of its classic data-recovery capabilities. The latter include UnErase, here implemented using a Wizard-style interface; an improved Recycle Bin, making it easier to retrieve deleted files; a rescue disk feature for creating floppy disks with important system files; and a new Space Wizard for finding duplicate files on a hard disk.

To give you more information about your system, the new version of The Norton Utilities will also include a much more graphical System Information screen, as well as a new System Doctor for tracking disk space, disk fragmentation, and CPU and memory usage. Another addition is a new version of the SpeedDisk disk cache.

McAfee Associates, Symantec, and other utility vendors are preparing versions of their antivirus programs, as an antivirus scanner is no longer a built-in feature of the operating system. And though Windows 95 includes a disk-compression utility called DriveSpace, you can expect Stac Electronics to update its Stacker to take advantage of things such as long filenames and Plug and Play. new interface

One of the most important changes that Windows 95 brings to the user interface is a new set of common dialogs. These are the standard boxes that programs use for tasks like Open, Save, and Save As, as well as for changing font settings and performing other common functions. Windows programs don't have to use Windows' common dialogs (in the past, some of Microsoft's own applications haven't), but the boxes are always available for any program to call.

In addition to a more user-friendly layout, the new Windows 95 common dialogs offer important file management features that were unknown in Windows 3.1. These features include the ability to work directly with folders (rather than with physical paths) and to use long filenames. You'll also be able to create new folders on the fly without having to exit a dialog.

Though these features cover some of the ground that Windows 3.1 left to add-on utilities, you can still expect to see a number of utility vendors offering their own user-interface enhancements and extensions to those in Windows 95. The list of contenders will include Symantec's Norton Navigator (a new product similar to a next-generation XTreeGold for Windows) and Dashboard (originally from Hewlett-Packard, recently acquired by Starfish Software).

Systems Compatibility Corp., which supplies the basic viewers that come with Windows 95, will offer a utility called Outside In/for Windows 95 that offers hundreds of additional file viewers, as well as the ability to print a document from a view.


Big Opportunity

Clearly, Windows 95 will bring big changes to the software industry and will pose a special challenge for vendors of system utilities and shell enhancements. At the same time, it spells a big opportunity. Even the most conservative estimates see millions of users moving to the new platform this year and as much as half the Windows installed base switching over in 1996. Many of those people will be making software upgrades that are currently on hold as the industry waits for Windows 95 to ship.

Yes, we'll also go on using some 16-bit applications for quite some time (although they may well start to look and feel increasingly old-fashioned). But not since the appearance of Windows 3.0 has there been such a compelling reason for so many people to evaluate new software.


Comparative User Interfaces

Click on the underlined text to view screenshots,	Opening a Document	Copying a Document	Navigating Your System	Changing Properties
Microsoft Windows 95 Users now get the advantages of an object-oriented interface, including a true desktop and icons, drag-and-drop copy and delete, nestable folders, and easily accessible property dialogs. The file system supports long filenames and is well integrated with the folder/desktop metaphor.	Double-clicking an icon opens a file; right-clicking brings up an Open dialog.	Windows 95 now supports drag-and-drop copying throughout the UI.	The Windows Explorer is a slick tool for local and network navigation.	Property sheets pop up when you right-click the corresponding object.
Microsoft Windows 3.1 Program Manager groups are basically just frames for program icons; groups cannot be nested. File Manager uses physical DOS paths only, so it can't see your groups. Drag-and-drop is limited and counterintuitive. You can't place documents, apps, or groups on the Windows 3/1 desktop.	Most Windows 3.1 users do it the hard way by opening an application and using that app to open the document.	File Manager does offer an awkward form of drag -and -drop copying. Most users just fill in the command line.	You need Program Manager and File Manager to navigate groups and files.	Changing settings means digging deep inside the Control Panel items.
IBM's OS/2 Warp The Workplace Shell is a deep, object-oriented interface with true folders and drag-and-drop support for copying, deleting, printing, and other functions. Object property sheets are easily accessible via right-click menus. The LaunchPad is a convenient place to dock often-used documents or apps.	Open files on the LaunchPad, on the desktop, or in folders by double-clicking.	Everything on the Warp desktop is an object. Just drag and drop to copy.	Warp gives you a hierarchical view of your system's files and objects.	Warp's tabbed property sheets are accessed by right-clicking objects.
The Macintosh The Mac has long offered most of the object-oriented interface features now considered standard, including program and document icons, a true desktop, double-click document launching, drag-and-drop copying, and the famous Trash Can. Physical paths for files and documents are hidden from the user.	Most users just double -click a document icon to open a file.	The Mac has had drag -and -drop copying for years.	Users get a hierarchical view of local and network objects.	The Mac uses conventional property dialogs accessed via the Apple menu.


Windows 95: Opening Documents

Double-clicking an icon opens a file; right-clicking brings up an Open dialog.

Return to Chart: Comparative User Interfaces


Windows 95: Copying Documents

Windows 95 now supports drag-and-drop copying throughout the UI.

Return to Chart: Comparative User Interfaces


Windows 95: Navigating Your System

The Windows Explorer is a slick tool for local and network navigation.

Return to Chart: Comparative User Interfaces


Windows 95: Changing Properties

Property sheets pop up when you right-click the corresponding object.

Return to Chart: Comparative User Interfaces


Windows 3.1: Opening Documents

Most Windows 3.1 users do it the hard way by opening an application and using that app to open the document.

Return to Chart: Comparative User Interfaces


Windows 3.1: Copying Documents

File Manager does offer an awkward form of drag-and-drop copying. Most users just fill in the command line.

Return to Chart: Comparative User Interfaces


Windows 3.1: Navigating Your System

You need Program Manager and File Manager to navigate groups and files.

Return to Chart: Comparative User Interfaces


Windows 3.1: Changing Properties

Changing settings means digging deep inside the Control Panel items.

Return to Chart: Comparative User Interfaces


IBM's OS/2 Warp: Opening Documents

Open files on the LaunchPad, on the desktop, or in folders by double-clicking.

Return to Chart: Comparative User Interfaces


IBM's OS/2 Warp: Copying Documents

Everything on the Warp desktop is an object. Just drag and drop to copy.

Return to Chart: Comparative User Interfaces


IBM's OS/2 Warp: Navigating Your System

Warp gives you a hierarchical view of your system's files and objects.

Return to Chart: Comparative User Interfaces


IBM's OS/2 Warp: Changing Properties

Warp's tabbed property sheets are accessed by right-clicking objects.

Return to Chart: Comparative User Interfaces


The Macintosh: Opening Documents

Most users just double-click a document icon to open a file.

Return to Chart: Comparative User Interfaces


The Macintosh: Copying Documents

The Mac has had drag-and-drop copying for years.

Return to Chart: Comparative User Interfaces


The Macintosh: Navigating Your System

Users get a hierarchical view of local and network objects.

Return to Chart: Comparative User Interfaces


The Macintosh: Changing Properties

The Mac uses conventional property dialogs accessed via the Apple menu.

Return to Chart: Comparative User Interfaces


Windows 95 and its Competitors

By Jeff Prosise

The Subject of Raging Debate

The Big Picture

Multitasking and Multithreading

The API

OLE: The API's Other Half

16-Bit vs. 32-Bit Code

Resource Management

The VFAT File System

Stability

A Little Old, A Little New


The Subject of Raging Debate

Months before its release, Windows 95 is already the subject of raging debate among advocates of 32-bit operating systems. The fundamental question: Is it or isn't it? Is Windows 95 a full-fledged 32-bit OS like Windows NT and OS/2, or is it merely a warmed-over version of 16-bit Windows 3.1?

A year ago, we knew only what Microsoft would tell us or what we could glean from very early developer prereleases (see "Chicago: Under Construction," April 12, 1994). Today we know much more. We see a solid operating system that improves on Windows 3.1 in several ways. Still, it is clearly not the "NT Lite" some hoped it would be. Architecturally, Windows 95 resembles Windows 3.1 and Windows for Workgroups 3.11 more than it resembles Windows NT or IBM's OS/2. That's good from the standpoint of compatibility with existing DOS and Windows applications, but it means that some of the baggage found in Windows 3.1 will be with us for some time yet.

On the outside, Windows 95 has a very different look from Windows 3.1. On the inside, parts of it are very new, but other parts remain fundamentally unaltered. Here is a critical assessment of Windows 95's foundation and how it compares with that of Windows 3.1, Windows NT, and OS/2.


Under the Hood - Windows 95 and its Competitors - The Big Picture
The Big Picture

From an architectural perspective, Windows 95 represents the next logical step in the evolution of Windows rather than a radical break with the past. The greatest enhancements include support for 32-bit Windows executables, preemptive multitasking of 32-bit applications, support for multithreaded applications, private address spaces for 32-bit applications, integrated support for file I/O functions formerly handled by DOS, a new file system that remains compatible with the old while supporting long filenames, and an installable file system manager with 32-bit file-system drivers for local, CD-ROM, and network drives. Throw in other enhancements (such as better resource handling and a flat memory-addressing scheme) and the total is an architecture that is superior to present-day Windows and bears comparison with OS/2 but that falls short of the more robust architecture of Windows NT.

Windows 95 uses two rings, or levels, of the four-ring Intel x86 protection model: ring 3, where applications and the dynamic link libraries (DLLs) that provide OS services run, and ring 0, where the low-level components of the OS reside. This arrangement, similar to that of Windows 3.1 and OS/2, isolates critical OS components from applications. It provides nominally greater stability than a DOS environment, where wayward applications frequently write into areas of memory they don't own and can corrupt the OS itself.

Ring 3 hosts the virtual machines (VMs) in which applications execute. All Windows applications, including 16-bit programs developed for Windows 3.1, run in the system VM. MS-DOS applications run in separate VMs known as virtual DOS machines (VDMs). Virtual machines provide protection against crashes by preventing applications executing in one VM from seeing applications executing in another and writing into each other's address spaces. As far as an application is concerned, a process executing in another VM may as well be running on another PC. (A process is a running application, its address space, and its resources.) Theoretically, it's difficult for a DOS application to bring down Windows 95 by intruding upon code and data owned by something else. In practice, however, it's quite easy for a DOS program to crash the system, because some memory is global to all VMs.

The system VM is unique among VMs in that it hosts multiple concurrent processes. Windows 95 applications (those written to the Win32 API) are isolated from one another in private address spaces supervised by the memory manager running in ring 0. Windows 3.1 applications (those written to the Win16 API) run in an address space shared by all active Win16 apps. Thus, Win16 programs operate in essentially the same environment that they ran in under Windows 3.1: They can see each other, but they can't see their Win32 counterparts. (In contrast, OS/2 and Windows NT 3.5 can run Win16 apps in private address spaces, providing better protection and marginally better multitasking.)

Win16 programs are still cooperatively multitasked as they were in Windows 3.1, but Win32 applications are preemptively multitasked. So by just upgrading to 32-bit versions of your applications, you'll get a smoother-running system. Until you replace those 16-bit applications, however, Windows 95 won't divvy up processor time any better than Windows 3.1.

Within the private address space allocated to a Win32 process, the application has a 4GB view of memory. The application is loaded in the lower half of the address space, normally at the 4MB mark. DLLs mapped into the process's address space are loaded between 2GB and 3GB, with the upper gigabyte reserved for system DLLs and virtual device drivers (VxDs). The system DLLs GDI, GDI32, USER, USER32, KERNEL, and KERNEL32--the 16- and 32-bit halves of the GDI, USER, and KERNEL modules present in Windows since Version 1.0--provide services to the OS. GDI and GDI32 are primarily responsible for output to the screen and printer, USER and USER32 for window management, and KERNEL and KERNEL32 for the management of memory, processes, and threads. Placing these components of the OS in ring 3 enhances performance by minimizing time-consuming ring transitions. It also makes them somewhat vulnerable to applications that write to areas of memory they shouldn't. This is an Achilles heel that Windows NT proponents are quick to point out when explaining why Windows NT is slower than Windows or OS/2.

This aspect of the architecture is fundamentally different from Windows NT, which isolates ring 3 OS code and data in protected subsystems that run in address spaces separate from the applications. Using a client/server message-passing mechanism implemented in the Windows NT Executive, Windows NT applications ("clients") invoke OS services in the Win32 subsystem (the "server") indirectly and cannot access the memory owned by the subsystem. Because OS code is either mapped into a separate address space or protected in ring 0, it is virtually impossible for an application to compromise the system. This design is the main reason that Windows NT is so extraordinarily stable. Even OS/2 can't boast such stability, though it does play tricks with selectors (values loaded into segment registers in protected mode to access areas of memory) to protect OS components in ring 3.

Drop down to ring 0 in Windows 95 and you'll find the virtual machine management (VMM) subsystem--which includes a group of VxDs--and the file management subsystem. The VMM and its drivers work together to virtualize hardware such as the keyboard, mouse, and interrupt controller and to perform low-level operations such as scheduling threads for processor time and paging memory to and from the hard disk. The VMM subsystem is not new in Windows 95, but its role has been expanded.

The ring 0 file management subsystem is new to Windows 95, although elements of it were also present in Windows for Workgroups 3.11. This subsystem is heavily layered, with the installable file system (IFS) manager at the top, file system drivers in the middle, and the multitiered block I/O subsystem (which manages input and output to the storage devices) at the bottom. Windows 95's native VFAT file system is supported by a file-system driver, as is the new compact disk file system (CDFS), whose driver replaces the MSCDEX CD-ROM driver on systems equipped with CD-ROM drives.

Network redirectors are also supported at this level in the hierarchy, and third parties may add support for additional file systems by providing the requisite file-system drivers. It's entirely possible, for example, that someone will write High-Performance File System (HPFS) and NT File System (NTFS) drivers, enabling Windows 95 users to utilize disk partitions formatted by OS/2 or Windows NT. By contrast, only Microsoft could realistically augment Windows 3.1 with nonnative file systems, because the only hooks are undocumented interfaces hidden deep inside real-mode DOS.


Multitasking and Multithreading

To divide processor time among active Windows applications, Windows 3.1 uses a crude scheduling mechanism known as cooperative multitasking. Applications are never forced to yield the CPU to other applications; they yield voluntarily when they call messaging functions in USER to retrieve messages and the message queue is empty. This works reasonably well, because a typical Windows application spins in a continuous cycle, retrieving and dispatching messages and often processing several messages a second. Still, a poorly written application can spoil the party for everyone by engaging in a lengthy processing task and failing to check its message queue for an extended period of time.

Like Windows NT and OS/2, Windows 95 solves this problem with a preemptive scheduler that distributes CPU time at the behest of the OS rather than the applications. Scheduling is performed on a per-thread basis. A thread is the atomic unit of execution; it is literally a piece of executing code. The primary scheduler, which is part of the VMM subsystem, pauses every 20 milliseconds (by default) to reevaluate the status of each active thread and determine which thread gets the processor next. Individual time-slices may be divided among two or more threads by a secondary scheduler that works with the primary scheduler to ensure that the CPU is utilized as efficiently as possible.

Win16 and MS-DOS apps are limited to one thread each, but Win32 processes may spawn additional threads. Secondary threads are useful for performing asynchronous tasks in the background, such as buffering input from a serial port, recomputing the values in a spreadsheet, or spooling data to a printer. Writing an app that performs background processing requires a great deal more effort in Windows 3.1, and the results are rarely as satisfactory, because of the built-in limitations of the scheduler. With Windows 95, Windows users will finally experience the superior multitasking that Windows NT and OS/2 users have enjoyed for years. Applications will be more responsive and hourglass cursors less common.

Win16 applications in Windows 95 are still multitasked the old way, running much as they do under Windows 3.1. But though a Win16 app can freeze other Win16 apps by going too long without dipping into the message queue, this alone will not visibly affect Win32 applications. The Win32 apps will continue to receive their time-slices, just as background VDMs do under Windows 3.1 today. OS/2 has an option permitting Win16 apps to run in separate sessions (virtual machines), meaning those apps can be multitasked preemptively just like native 32-bit apps. If you plan to run Win16 programs for a while, this is a feature you'll want.

OS/2's one weakness in multitasking is its serialized input queue. Messages generated from mouse and keyboard events wait in a single, system-wide input queue to be retrieved by applications. If one application fails to retrieve input messages, others may be prevented from retrieving them also. When this occurs, it is typically debilitating enough that the user can't even switch away from the offending application, because the message signaling the switch gets stuck in the queue behind all the others.

Windows 95 and Windows NT circumvent this problem by providing each application with a private input queue, a technique known as deserialization. A Windows 95 or Windows NT application that goes for an extended period of time without retrieving messages will stop responding to input but won't prevent other programs from responding, and it won't prevent you from switching to another application. OS/2 programmers can avoid serialization problems by making sure their apps are written properly, however. If an application can't process a message quickly, it should use a message pump to keep the messages flowing or delegate the job to a secondary thread.


The API

An OS's inner functions are accessed by its applications through the application programming interface, or API. An API is a set of subroutine-like procedures called functions that programs can call to open files, allocate memory, and perform other routine tasks. In Windows 95, these functions are implemented in GDI, GDI32, USER, USER32, KERNEL, KERNEL32, and other DLLs. Since these DLLs are mapped into each process's address space, calling an API function amounts to little more than executing a CALL instruction to the proper location in memory.

The API is an important part of an OS's architecture, because it defines how programs will interact with the system. It is also one of the primary factors that decides who will support a new OS. Today's APIs are complex, often comprising a thousand or more functions and requiring a year or more of full-time study to master. Force programmers to learn a new API and you run the risk that no one will develop applications for your platform, especially if competing platforms with familiar APIs are outselling yours ten to one. That's one solid reason Windows applications far outnumber OS/2 apps.

Windows 95 uses the Win32 API, which is a 32-bit version of the 16-bit Windows 3.1 API and is native to Windows NT. A simple port of a Windows 3.1 application to Windows 95 generally requires no more than a few days; porting from Windows NT (or the little-used Win32s subsystem that converts Windows 3.1 into a 32-bit platform) requires even less. Many Windows NT applications, in fact, run unchanged under Windows 95. And if you were prescient enough to write your Windows 3.1 application in C++ using the Microsoft Foundation Class (MFC) library, porting could be as simple as loading up the source code and recompiling.

Of course, a simple port generally isn't enough. Most developers coming from Windows 3.1 will want to take advantage of Windows 95's new features, such as multithreading, memory-mapped files, and the common controls library (new controls provided in a DLL that supplement the built-in control classes). Adding support for such features often impacts the structure of your program and requires more than just a rewrite. For this reason, upgrades to some popular applications will lag behind the release of Windows 95 by several months.

How does Windows 95's version of the Win32 API square with the Windows NT version? Each supports some features that the other doesn't, but there is a very high degree of overlap. Windows 95 doesn't support Windows NT's security and event-logging functions, but it includes new functions for image color matching and other operations that Windows NT doesn't. Contrary to some press reports that describe Windows 95's API as a subset of Windows NT's, Windows 95 expands the Win32 API; neither Windows 95 nor Windows NT currently provides the 32-bit Windows API implementation. But because the bulk of the API is common to both, it is now possible for developers to support Windows 95 and Windows NT users with a single code base (for further discussion, see "Windows 95: The Programmer's Challenge").


OLE: The API's Other Half

Unfortunately for developers, the Win32 API is only half the story. To qualify to use the Windows 95 logo, developers of most applications will have to add Object Linking and Embedding (OLE) 2.0 support. OLE is a vast, complex, and (by most programmers) poorly understood protocol that is very different from what most Windows programmers are accustomed to. OLE programming is orders of magnitude easier if you work in C++ and take advantage of the substantial OLE support built into the Microsoft Foundation Classes (MFC), but the majority of Windows applications today are still written in C. That will change, but for now OLE presents a major obstacle to many developers.

The driving force behind OLE is the notion that interoperability among applications can be taken to a higher level if code and data are encapsulated in objects; applications that use those objects can then interact with them using standard interfaces. OLE defines protocols for in-place editing, drag-and-drop data transfers, structured storage, custom controls, and more.

OLE faces competition from OpenDoc and System Object Model (SOM), but if Windows is ever to become a fully object-oriented, document-centric OS, OLE is the vehicle that will get it there. The Component Object Model technology upon which OLE is based is being woven into the fabric of Cairo, the fabled successor to Windows NT. If so, OLE is on its way to becoming not just an extension of the API, but an integral part of the OS architecture.

Windows 95 makes it abundantly clear that Microsoft sees OLE as more than a tool for applications developers. Many of the functions of the user interface shell are accessed through OLE interfaces in what may be a preview of things to come. DLLs can now provide document icons to the shell on the fly by registering to be notified whenever an icon is displayed; this is designed to strengthen the bond between documents and applications.

Windows programming is changing--and fast. The underlying API is becoming less important than which class library you use. To write first-class Windows 95 applications, even some of the more experienced Win32 developers will find themselves wading through stacks of new programming documentation describing obscure interfaces that are unrelated to the API. It may not be pleasant, but it'll be a fact of life. Programmers willing to bite the bullet and adapt to the new order now will save themselves a lot of time and trouble down the road.


16-Bit vs. 32-Bit Code

It's no secret that Windows 95, unlike Windows NT (and, to a lesser extent, OS/2), is no thoroughbred 32-bit OS. Some of the 16-bit code from Windows 3.1 still resides in GDI, USER, and KERNEL. Most of KERNEL has been rewritten with 32-bit code and renamed KERNEL32, but about half of what was formerly GDI and almost all of USER is still 16-bit. How much of a problem does this present for users? How does it affect performance? And does it matter that an OS written for 386, 486, and Pentium CPUs still relies partially on 16-bit code?

First, let's clarify the difference between 16- and 32-bit code. Prior to the 386, Intel processors were built primarily to deal with 16-bit quantities. For example, a pair of 16-bit numbers could be multiplied with a single instruction, but multiplying two 32-bit numbers required perhaps 15 to 20 instructions. More important, memory could be addressed efficiently in chunks of up to 64K, but dealing with larger expanses of memory required more extraordinary measures. Merely increasing the size of an array from 64K to 65K in a C program could easily halve the program's speed (or worse).

The 386 fixed this by increasing the width of the CPU's registers from 16 bits to 32 bits and by upgrading the instruction set to handle 32-bit quantities. Programs could now multiply 32-bit numbers with a single instruction and address areas of memory as large as 4GB with ease. Since a 386 will execute 16-bit instructions, a programmer writing code for it can choose between 16- and 32-bit code (or even mix the two together). The latter is superior when dealing with 32-bit quantities and large regions of memory, but it offers no advantage when dealing with 16-bit data.

Sixteen-bit code is not inherently bad. It can be as fast as or faster than 32-bit code, depending on what the code is designed to do and how well it is written. The 16-bit portions of the system won't be a drag on performance if they stay within the bounds of what 16-bit code can do efficiently. If 16-bit code is isolated in 16-bit code segments, and 32-bit code in 32-bit code segments, the use of 16-bit code won't swell the code size either. (16-bit code and 32-bit code occupy the same amount of space unless they're mixed together in the same segment, in which case one must be expanded in order to differentiate it from the other.)

Still, it's a little disconcerting to learn that an OS designed for 32-bit processors contains 16-bit code at all. So why is Microsoft willing to settle for any 16-bit code? Is this the result of a conscious design decision, or is Microsoft simply trying to put the best face on a mediocre design?

Probably a little of both. Microsoft admits that the problem was partially one of resources: The company felt it didn't have the time to rewrite everything using 32 bits. In retrospect, given the delays, maybe it could've taken the time. But another factor in the decision was compatibility with existing applications. Some of the 16-bit code in USER is so idiosyncratic that Microsoft feared a ground-up rewrite would inevitably break a number of Win16 applications. Some efficiency may be gained by allowing Win16 apps to call directly into the 16-bit GDI, USER, and KERNEL and avoid thunking to 32 bits. (Thunking is the mechanism used to call 32-bit code from 16-bit code, or vice versa, and to translate the parameters that accompany the calls.)

This efficiency is offset by the fact that some of the calls made by Win32 apps must now be thunked down to 16 bits, something that isn't necessary in Windows NT and OS/2. Microsoft programmers have gone to great pains to maximize thunking efficiency, but thunking still takes time. Win32 apps can't help but run slightly slower because of the 16/32-bit division of labor in the OS kernel.

The diagram "Windows 95 System DLLs (not included in this help version -- see print publication): The 16-Bit/32-Bit Division of Labor" illustrates the 16/32-bit code dichotomy. The 16-bit GDI, USER, and KERNEL and the 32-bit GDI32, USER32, and KERNEL32 are separated by a thunking layer that facilitates calls back and forth. When a Win32 application calls an API function, the call is received on the 32-bit side but may eventually execute code in GDI, USER, or KERNEL. Conversely, Win16 apps that invoke API function calls into the 16-bit half of the kernel may be thunked internally to GDI32, USER32, or KERNEL32.

On the surface, there's nothing wrong with this arrangement--especially for an OS that is designed to run both 16- and 32-bit apps. But the 16-bit code in the kernel presents something of a problem because it is nonreentrant, meaning two threads cannot access it at the same time without risking a nasty system crash. This isn't a big deal in Windows 3.1, because Windows apps are not preemptively multitasked. But it's a grave concern in Windows 95, where processes are preempted and any thread is likely to be interrupted at any point during its execution.

As Adrian King documented in his book Inside Windows 95 (Microsoft Press, 1994), Microsoft explored a number of solutions to this problem before finally deciding upon the Win16Mutex. (A mutex is a flag that warns threads away from the 16-bit kernel when another thread is executing code there.) Win32 threads that wish to call across to the 16-bit side must stop what they're doing if the flag is raised. Significantly, a Win32 thread sets this flag only when it enters and leaves the 16-bit kernel, but threads devoted to Win16 processes force the flag to be set the whole time they're active.

The result? Win32 apps may be less responsive when Win16 apps are running, and a Win16 app that locks up may lock up Win32 apps, too. This is in stark contrast to Windows NT and OS/2, where 16-bit apps have no effect on 32-bit apps other than the CPU time they consume.

Exactly how much the Win16Mutex bottleneck will affect Win32 processes is still unclear. (PC Magazine will compare the performance of 32-bit applications with and without Win16 apps running later this year, when final Windows 95 code is available.) What is clear is that you'll get better performance from Windows 95 if you run only 32-bit applications.

The system DLLs aren't the only components of Windows 95 in which 16-bit code and data can be found. As Andrew Schulman notes in his book Unauthorized Windows 95 (IDG Books Worldwide, 1994), Windows 95 still relies on several 16-bit DOS data structures and at times switches to Virtual 86 (V86) mode to execute old 16-bit DOS code. The 16-bitness may not be bad in itself, but switching from protected mode to V86 mode and back exacts a price in performance. Fortunately, the most important calls--those directly related to file I/O--are handled in protected mode. Windows 95 seems to reserve V86 mode for rather innocuous tasks, such as setting the current drive and getting and setting the current time, for example. But the code requesting those tasks ends up being reflected to a 16-bit handler that executes in V86 mode.

This fact has led some to charge that Windows 95 still requires DOS, and that it's therefore not strictly an integrated OS. Whether it is or isn't ultimately boils down to an issue of semantics. Yes, Windows 95 makes some use of 16-bit code that used to be part of DOS. No, it doesn't require a separate product called MS-DOS in order to run. This latter fact is probably the more relevant one for end users who tend to think of DOS not as a code base but as something you buy in a box at a computer store.

A final instance in which 16-bit code comes into play is when Windows 95 communicates with a device for which a 32-bit driver is not available. For compatibility with existing hardware, Windows 95 can still use 16-bit real-mode device drivers when necessary. This isn't a problem in and of itself, but 16-bit drivers impede performance and may reduce the amount of memory available to DOS apps. Windows 95 will therefore provide 32-bit versions of common 16-bit drivers such as MSCDEX and ASPI4DOS. In the future, most hardware devices for which Windows 95 does not provide direct driver support will come with 32-bit drivers written by their manufacturers.


Resource Management

One problem that has pestered Windows users since day one is its limitations on free system resources. Windows 3.1 sets aside a fixed amount of memory in local heaps (64K segments of memory addressed with 16-bit pointers) belonging to USER and GDI. These hold data structures for windows, menus, GDI objects such as brushes and pens, and other resources that an application creates in the normal course of doing business. The percentage of free system resources displayed in Program Manager's About box is roughly equivalent to the percentage of memory in these heaps that is currently unallocated.

When the heaps fill up, Windows will complain about insufficient memory and refuse to start another program, even if there are megabytes of free memory remaining elsewhere in the system. To make matters worse, many programs fail to free some of the resources that they own prior to terminating, and Windows doesn't clean up behind them. The mere act of repeatedly starting and stopping one of these programs may drop free system resources to where Windows is unusable. The only recourse is to restart Windows.

This situation is greatly improved. Many of the data structures have been moved out of the 16-bit USER and GDI heaps and relocated in 32-bit heaps, whose size is virtually unlimited. So why weren't all data structures moved to 32-bit heaps? Compatibility. Some Windows 3.1 applications bypass the Windows API and access objects in the heaps directly. Moving everything to 32-bit heaps breaks these applications and renders them incompatible with Windows 95. The OS architects found themselves in the unenviable position of evaluating each object type and moving only those that weren't likely to cause major compatibility problems.

In addition to providing expanded heap space, Windows 95 also cleans up after apps that fail to clean up after themselves. Resources are tracked on a per-thread basis; when a thread ends, any resources it failed to deallocate are automatically freed by the OS.

Here again Microsoft encountered compatibility problems with existing programs. Some Windows 3.1 applications intentionally leave resources behind for use by other programs or DLLs. Automatic resource cleanup poses a problem for these applications.

The solution? Resources left behind by Win16 apps aren't freed until all Win16 apps are closed. You may still experience resource leakage if you run primarily Win16 apps, but because of the expanded heap space, the leakage won't be as severe. And lost resource space can be recovered by terminating all active Win16 processes. In addition, if you know that your favorite Win16 applications do not rely on the persistence of resources that they leave behind, you can mark them as such and their resources will be cleaned up immediately.

One interesting quirk related to Windows 3.1's handling of memory has been partially carried over to Windows 95, at least in current beta versions. In Windows 3.1, information regarding active programs is stored in data structures known as task databases, or TDBs. Each TDB has embedded inside it a DOS program segment prefix (PSP) that must be located in memory below 1MB. (This region of memory is sometimes referred to as global DOS memory, a name borrowed from the Windows API function used to allocate space there--GlobalDosAlloc.) If global DOS memory is so full that there's no more room for TDBs, Windows 3.1 will refuse to start additional programs even if free memory above 1MB and free system resources are plentiful.

TDBs and PSPs are still used in Windows 95. TDBs have been moved out of global DOS memory, but PSPs haven't. So it's still possible to encounter out-of-memory errors when there is no shortage of free memory. Fortunately, such situations should be rare. Windows 3.1 took steps to alleviate this problem (which was sometimes quite severe in 3.0) by transparently fulfilling most memory requests that formerly allocated global DOS memory with memory located above 1MB. Windows 95 improves the situation further by moving TDBs out of global memory, but it's still a hack rather than a genuine fix.


The VFAT File System

One of an OS's most important jobs is to manage data on hard and floppy disks. Typically this is done by generalizing the interface to the system's mass-storage devices and permitting applications to address files rather than individual sectors on the disk. When an application writes data to a file, the OS writes the data to the disk and creates a record of where it is stored. Knowing the filename, the application can later open the file and read the data back. The application neither knows nor cares how the data is physically stored; the details are handled by the OS.

Until Windows NT came along, Windows had no file system of its own. Instead, it relied on the DOS file system, which used a simple method of organizing files on a disk that centered around an on-disk data structure called the file allocation table (FAT). The FAT file system was adequate in the days of real-mode OSs and 10MB hard disks, but it has outlived its usefulness. Its greatest drawback is that it limits filenames to eight characters plus a three-letter extension. And when the file-system code resides in DOS, as it does today, Windows must kick out of protected mode every time it accesses a file. Clearly an OS that wishes to compete with the likes of Windows NT and OS/2, which support high-performance native file systems, must replace the FAT file system with one of its own.

Windows 95 addresses these concerns with a new file system that is basically an extension of the FAT file system called virtual FAT (VFAT). VFAT is a 32-bit file-system driver that sits under the IFS manager in ring 0. The driver borrows heavily from the 32-bit file-access code in Windows for Workgroups 3.11 to provide a mostly protected-mode path to a disk and back. It also supports long filenames (up to 255 characters each) and maintains backward compatibility with FAT volumes.

Such a feat of magic is accomplished by recording two names--one long and one short--for each file, chaining 32-byte directory entries together to hold the long filenames and hiding these directory entries by marking them with an "impossible" combination of hidden, system, read-only, and volume label attribute bits. The short filename, or alias, is generated by truncating the long filename. DOS and Win16 apps see only the short filename; Win32 apps see the long version.

In some ways, it seems an ideal compromise. End users get the long filenames they've been waiting for, plus faster disk accesses and an easy upgrade path from FAT volumes. The long filenames work pretty well if you are careful not to modify a directory entry with a 16-bit app. If this happens, you can lose the long filename.

VFAT suffers, however, from many of the same limitations as the FAT file system. The size of the root directory is still fixed once the disk is formatted, so its capacity to hold file and subdirectory names is limited. The fixed size is even more constraining on a VFAT volume because every file (and subdirectory) requires at least two 32-byte directory entries--often more, depending on the length of the filename. The 16-bit limit on VFAT entries means that large hard disks require large cluster sizes (potentially reducing their storage efficiency) and that VFAT volumes are practically limited to about 2GB. Also, long filenames aren't visible until after the file-system driver is loaded, so long filenames can't be used during the boot process (say, in a CONFIG.SYS or AUTOEXEC.BAT file).

How does VFAT compare to OS/2's HPFS and Windows NT's NTFS file systems? HPFS and NTFS are much more sophisticated file systems designed for high performance, large hard disk capacities (up to 2 terabytes for HPFS and a mind-boggling 68 billion terabytes for NTFS), greater storage efficiency, and greater reliability. NTFS is somewhat more sophisticated than HPFS. In particular, NTFS uses a transaction-based processing model that makes it possible to recover in a matter of minutes from just about any type of file-system error--even hard crashes resulting from power failures. Both HPFS and NTFS are light years beyond VFAT.

On one hand, VFAT is compatible with existing disk volumes and disk repair utilities; this is a huge plus for the installed base of more than 50 million Windows users, most of whom could care less about the nuts and bolts of file-system operation. On the other hand, it is an outdated file system on crutches. It's too bad Windows 95 users won't be offered the choice of making a clean break with the past.


Stability

Almost every Windows user has experienced mysterious crashes that bring down an application and sometimes the entire system. Most of these crashes are due not to inherent flaws in the OS, but to buggy applications and device drivers. Video drivers are particularly notorious, as evidenced by the driver-of-the-week upgrades put out by many video board makers. These drivers are both a blessing and a curse: They enable Windows to work with a wide range of hardware, but they're so difficult to write that one can never be confident that all the bugs are gone.

One of the ways Windows 95 seeks to increase reliability is by decreasing the load on the independent hardware vendors (IHVs) who write the drivers. Borrowing a page from the design of printer drivers in Windows 3.1 and disk drivers in Windows NT, Microsoft has modified the disk- and display-driver model in Windows 95 so that a driver's core functionality is provided by a VxD written by Microsoft. Hardware-dependent functions supplied by the IHV are localized in a minidriver that works in tandem with the VxD. Windows calls the VxD, and the VxD, when necessary, calls the minidriver. This simplifies the code that the IHV writes and therefore reduces the likelihood of error.

Other improvements designed to heighten reliability include the private address spaces allocated to Win32 apps, better parameter validation when system services are called, and, for the first time, parameter validation for VxDs. Parameter validation is the simple act of verifying that parameters passed through function calls contain legal values that won't wreak havoc with the system. Users of DOS apps may now click a check box in a property sheet and acquire better protection of conventional memory, always a soft spot because some of the code and data stored there is global to all virtual machines.

How well does the protected memory feature work? Not very well--at least not yet. Here's a simple experiment to try if you don't mind crashing your system. Open a DOS window and type DEBUG to start the DOS debugger. At the hyphen prompt, type

F 0000:0000 FFFF 66

This command overwrites the first 64K of memory with the arbitrarily chosen hexadecimal value 66. In Windows 3.1, this locks up the system, forcing a reset. Windows NT and OS/2 recover gracefully, allowing you to close down the DOS box. (In OS/2, make sure you're running DEBUG in a window; otherwise, you might not be able to switch back to the shell and close the DOS session.) In the beta 2 release of Windows 95, whose handling of low memory is much like Windows 3.1's, you also get a complete lockup--even if memory is marked "protected."

This could be fixed before Windows 95 is released, but for now it's evidence that Windows 95 is not the rock-solid performer some claim it to be. The burden still falls on applications developers to deliver safe and reliable products.


A Little Old, A Little New

In general, Windows users will find Windows 95 to be a more robust and pleasing environment in which to run their favorite programs. The multitude of enhancements that sit on top of the base architecture--the redesigned user interface, better networking support, and easier configuration--will help to make it so. Microsoft has borrowed some of the best aspects of Windows 3.1 and built on that foundation to produce an OS whose exterior bears little resemblance to the Windows of years past but whose interior looks more than a little familiar.

Is Windows 95 a 32-bit OS? Not by the strictest of definitions, since it contains some residual 16-bit code. But it runs 32-bit applications and does everything else a 32-bit OS is supposed to do. In the final analysis, what will decide the success or failure of this OS is not the minutiae of its implementation, but how well it runs applications, how enthusiastically software developers support it, and how reliably it performs. Everything else is just noise.


DOS Is Dead? Look Again

By Andrew Schulman

Far from "NT Lite"

Microsoft is careful never to claim that Windows 95 is a Windows NT derivative. Still, the company has left many developers, computer journalists, and end users with the impression that it is a ground-up rewrite of Windows 3.x with an architecture that's closer to Windows NT than to the old Windows DOS combination.

To cite just one example, the February 1994 issue of the Microsoft Systems Journal (page 20) states that "Windows no longer can be likened to a fancy paint job on an old MS-DOS Yugo. Because the entire operating system is freshly designed from the ground up, you now have killer features such as threads, memory-mapped files, and asynch I/O."

In my view, for better or for worse, Windows 95 is far from being an "NT Lite." Instead, Windows 95's structure is quite closely related to the architecture behind Windows 3.x 386 Enhanced mode. Yes, Microsoft has made many improvements to this underlying foundation (including threads and so forth), but Windows 95 remains fundamentally closer to the combination of Windows for Workgroups 3.11 and Win32s than to Windows NT. study your windows 3.x!

Particularly crucial to understanding Windows 95 is understanding the Windows 3.x Enhanced mode virtual machine manager (which provides APIs such as Hook_V86_Int_Chain, Begin_Nest_V86_Exec, and Allocate_V86_Break_Point) and virtual device drivers (such as IFSMGR, IOS, VWIN32, VPICD, V86MMGR, and DOSMGR). For details, see my book Unauthorized Windows 95 (IDG Books Worldwide, 1994).

Windows 95's relation to MS-DOS is the same as that of Windows 3.x Enhanced mode to MS-DOS. Specifically: Windows 95 does not replace DOS, use DOS solely for compatibility with old DOS applications, or rely on DOS solely to boot up. Even Win32 applications under Windows 95 will employ DOS for some operations, such as getting and setting the current program segment prefix (PSP, a DOS data structure that acts as a process identifier), the date and time, and the current drive.

At the same time, even DOS apps running under Windows 95 will bypass DOS for file operations (much as Windows for Workgroups 3.11 provides 32-bit file access). And Windows 95 provides memory-mapped file I/O. This new feature is a good example of what bypassing DOS really looks like.

Wanting To Believe

Clearly, many developers and users want to believe that DOS is gone. Indeed, it is easy to blame DOS (and real mode) for all problems and instabilities. They think that if DOS is gone, somehow their systems will automatically be more stable. Windows 95 may or may not be more reliable than Windows 3.x, but DOS is still there--just as in Windows 3.x.

In response to Unauthorized Windows 95, Microsoft has downplayed the importance of the Windows 95 architecture. For example, Rogers Weed, group product manager for Windows 95, told Computer Reseller News (January 2, 1995, page 3) that "I don't think [the architectural details] make a difference to most customers."

This is indeed odd. If Windows 95's relationship to DOS doesn't matter, why the many claims that Windows 95 eliminates DOS, that it is a brand-new integrated operating system, and so on? One reason may be that these claims help Microsoft justify its hefty price hike to OEMs. Another may have to do with the word integrated itself, since the proposed antitrust consent decree between Microsoft and the U.S. Department of Justice explicitly excludes "integrated products" from its clauses.

Whatever the reasons for Microsoft's claims, the truth about the architecture of Windows 95 does matter to users and developers. As one example, several beta testers have noticed that even in a pure Windows 95 configuration running only Win32 apps, they can't start any more apps if all DOS memory is allocated by a piggish device driver. This is because each Win32 app running in Windows 95 requires some DOS memory for its PSP.

The Bottom Line

Windows 95 is an excellent product, but the industry must bring its expectations in line with the realities of the design. Otherwise, when Windows 95 finally ships--hopefully in 1995--it could face a nasty backlash from those who believed in NT Lite only to find they have Windows 4.0 lashed together with MS-DOS 7.0.


Windows 95: The Programmer's Challenge

By Charles Petzold

Writing good application code is tough enough. Revising or rewriting that code for new operating systems and application programming interfaces (APIs) can be pure torture. Programmers should be able to expand their knowledge of existing APIs rather than continually having to learn completely new ones.

Fortunately for programmers, the evolution of Windows over the past decade has been fairly smooth in this regard. As versions of Windows have expanded in functionality, they have also retained much backward compatibility. An application written for Windows 1.0 in 1985 would require minimal changes (if any) to run under Windows 3.1 in 1995. It might look a bit quaint, but it would still run.

But the move from the 16-bit architecture of early Windows to a 32-bit interface is the biggest leap yet. Using 32-bit memory management and integers can provide programs with improved efficiency that simply cannot be ignored. This move to 32 bits has a long history--with Microsoft providing programmers with an unsettling variety of 32-bit solutions.

First there was something called WINMEM32, a dynamic link library that allowed programmers to write some (but not all) of their Windows 3.0 code using a 32-bit address space. Then there was a Windows 3.1 API called Win32s (s for subset), an interim 32-bit API that eased the transition to Windows NT and Windows 95 but fell short of the Win32 API defined for Windows NT. Then came Win32c (c for compatible), an API that Microsoft initially defined and then abandoned for Windows 95. Although Microsoft has attempted to allay programmers' fears by defining APIs that are subsets of one another, few people are fooled. hoping for dominance

Windows programmers should be crossing their fingers in the hope that Windows 95 will soon dominate their users' market as much as Windows 3.1 does now. Such market dominance will give them a vital tool: the ability to focus on a single API, to learn it inside and out with little fear of their efforts going to waste.

Normally, porting an existing 16-bit program to a 32-bit architecture involves two fundamental issues--integers and memory addressing. Windows, however, adds other layers of complexity to this process.

C, the language used most widely in Windows development, defines three different integer types: The short (usually 16 bits), the long (usually 32 bits), and the int, which can be 16 bits or 32 bits depending upon the underlying hardware and operating system. Skillful C programmers can use these three integer types to make their code easily portable from 16- to 32-bit environments.

The early developers of Windows, however, avoided the int almost entirely; instead, they defined new data types that were specifically 16 bits or 32 bits in length. This did not display much foresight. A more thoughtful definition of integer data types might have alerted programmers early on that Windows would one day be making the 32-bit plunge.

Some 16-to-32 bit changes (for example, graphical coordinates and handles that programs use to refer to objects such as windows) have even necessitated changes in function calls and messages that programs receive from Windows. In porting apps from Windows 3.1 to Windows 95, some changes will be mindlessly mechanical (or can even be automated), but programmers will also be meticulously searching for those 16-to-32 bit gotchas. memory management

The other big issue is memory management. Rather than dealing with the insanity of 64K memory segments, programmers can now use a flat 32-bit address space. No programmer alive mourns this change, but those with applications that deal with huge chunks of memory will have to revise their entire memory management strategy.

Interestingly enough, the changes in the user interface of Windows 95 can be largely ignored, at least for fast ports of normal applications. It's always been one of the wonders of Windows that the visual interface is treated in an abstract manner from the programmer's perspective. Still, application developers will want to keep up with current trends, such as toolbars, status lines, and the monster known as OLE. The good news is that Windows 95 is still Windows. Most of the programming skills and knowledge already learned over the past decade need not be unlearned--only supplemented. Windows is richer now, not poorer.


Joining the Multimedia Party

Up to now, Windows hasn't brought much to the multimedia party. It's never been the great graphics performer DOS is, because it denies programs direct access to the video buffer. And its sheer overhead makes makes achieving high-quality video and audio difficult. But that's rapidly changing. With Windows 95, multimedia developers should have a far better array of tools available.

For Games: WinG and WinToon

For 3-D: OpenGL or Reality Lab?


For Games: WinG and WinToon

The most popular tool for achieving superior graphics performance is the WinG (pronounced win-gee) library introduced last year. WinG allows programmers to reduce overhead by bypassing the Graphics Device Interface (GDI) and writing directly to a bitmap. Completed bitmaps are then transferred to the video buffer with optimized versions of Windows' BitBlt and StretchBlt functions. More important, WinG keeps graphics accelerators in the loop, so games that utilize WinG run astonishingly fast; so fast, in fact, that they sometimes outperform their DOS counterparts.

WinToon, another new multimedia graphics API, is a tool for making cartoon-like animations by creating foreground frames and overlaying them on a static background. The resulting .AVI files are optimized for speed, because only the portions of each frame that change are redrawn.


 For 3-D: OpenGL or Reality Lab?

At the moment, it looks as if the first release of Windows 95 will not support OpenGL, the 3-D graphics language introduced in Windows NT 3.5. But OpenGL is expected soon thereafter, probably in the form of a freely distributable dynamic link library. OpenGL performs shading, texturing, hidden surface removal, and other rendering operations in real time.

Microsoft recently acquired the London-based RenderMorphics, whose Reality Lab graphics library supports high-performance 3-D rendering in hardware and software. This gives Microsoft another new technology that is ideally suited for game and multimedia development. That's great news for users, but developers must now guess which (if either) API will become the standard.

Windows 95 will also introduce AutoPlay, a feature that allows a multimedia application on CD-ROM to be started automatically when the CD is inserted into a drive.

Compression also plays a big role in boosting multimedia performance, particularly when it comes to full-motion video. Windows 95 will ship with 32-bit versions of the Indeo and Cinepak codecs. An MPEG driver apparently will not be included, but Microsoft is actively promoting the standard and has been demonstrating a software decoder from Mediamatics that plays flawless high-quality MPEG video on a 90-MHz Pentium with a PCI bus.

Other works in progress include TrueSpeech voice compression, a general MIDI standard for Windows, a standard for digital joysticks, and a new multisession CD format that combines audio and data on one disk.

Only time will tell if Windows 95 can offer one of the biggest multimedia platforms around. But one thing's for certain: No matter what the outcome, it's going to be great fun getting there.


Solutions to the Thorniest Problems

By John Clyman and Nick Stam

Plug and Play support integrated into Windows 95 promises to bring order to the chaos of adding new devices to your system. But if you're using legacy hardware, it's not exactly Shangri-La.

Microsoft is nothing if not ambitious. Among a multitude of enhancements, Windows 95 promises a solution to one of the thorniest problems facing PC users today: How to make installing peripherals in your PC as easy as adding components to a stereo system.

You've probably encountered the problem firsthand. A PC upgrade can turn into a game of "What's My Line" as you try to figure out which devices need which DMA channels, IRQ lines, I/O port assignments, and memory-address ranges; which of those limited resources are currently used by other devices; and how you can juggle them all to eliminate conflicts. Multimedia upgrade kits are among the most notorious offenders, but hardware and software manufacturers alike will attest that the problem permeates the PC industry.

Past attempts to regulate the PC architecture have generally proved ill-fated. EISA, originally promoted by Compaq and the so-called Gang of Nine, offered automatic configuration of EISA cards and compatibility with ISA products, but it never made significant inroads except in servers and Compaq desktop systems. IBM's technically impressive Micro Channel architecture, with its own automatic configuration features, is all but disappearing from the map. And although PCI and PCMCIA provide some automatic configuration capabilities, neither standard answers the truly critical compatibility question: how to support the thousands of existing legacy ISA expansion cards.


Introducing -- Plug and Play

Windows 95 will include support for Plug and Play (PnP), a set of frameworks promoted by Microsoft, Compaq, Intel, and BIOS manufacturer Phoenix Technologies that aims to alleviate PC configuration problems. The standards, which were first proposed in January 1993, are intended to make device configuration entirely automatic and transparent--just plug in a new device and you're up and running.

PnP's ultimate goal: No more device conflicts; no more fiddling with jumpers, tweaking CONFIG.SYS files, or even loading device drivers. This benefits not only users but also vendors by dramatically reducing volume of costly technical support calls they must field. PnP also demands that device drivers support dynamic reconfiguration, forming a foundation for capabilities like PCMCIA hot swapping (which allows you to swap PCMCIA cards without rebooting your notebook), notebook hot docking (enabling the notebook to link with or unlink from devices in a docking station without rebooting), and wireless file exchange. PnP enjoys broad promises of support in the industry (although relatively few products are actually shipping today), and from a hardware perspective it's extremely inexpensive to implement.

While our testing of early Plug and Play products demonstrated their promise, it's also clear that PnP faces tremendous obstacles, particularly when it comes to handling legacy (that is, non-Plug and Play) ISA cards. Automatic identification of legacy cards is likely to remain spotty at best, and until the entire industry implements PnP capabilities, users will still require education about IRQs and DMAs and need to be comfortable setting DIP switches and jumpers.


True Plug and Play

In theory, a complete PnP solution will automatically configure virtually every device inside your system: motherboard-mounted controllers, ISA cards, SCSI devices, displays, printers, and more. Such a solution requires a number of PnP components.

First, your system must have a PnP-ready BIOS, flexible enough to resolve any potential conflicts between the devices required to boot the operating system. PnP BIOSes from all three major BIOS vendors (Phoenix, AMI, and Award) are already shipping in many systems, including those from Dell, Digital, Gateway, and Packard Bell. By mid-1995, we expect most systems to ship with PnP BIOSes.

You must also install a Plug and Play-capable operating system, whether it be Windows 95 or something else. The PnP-capable OS maintains structures that track the devices installed in the machine and their use of resources.

Finally, all your expansion devices and device driver software must also support the Plug and Play standard: Peripherals vendors have to add logic to their devices to support PnP and to write device drivers to support dynamic reconfiguration. Dynamic reconfiguration even affects application developers, who might want a communications package to ask whether you'd like to send pending messages before letting you eject a PCMCIA fax/modem, for instance. Several PnP expansion cards have already begun to appear on the market.

In the immediate future, Plug and Play will provide the fullest solution for buyers of new machines with new PnP-compliant boards. But it turns out that you can reap partial benefits from PnP features even if you don't have all the pieces in place on your machine.


What It's Like

Our experiences in testing ISA Plug and Play support under a beta version of Windows 95 in various scenarios were generally positive. We did run into problems and conflicting messages at times, but most functions worked as specified. It was too early to make any conclusions about the problems we encountered since we were working with a prerelease package.

Here is a snapshot of what we found. Keep in mind that changes in the way configuration is handled are still possible.

Adding a PnP ISA device to a machine with a PnP BIOS. In this best-case scenario, the machine should be able to handle device configuration without any user intervention at all. That's exactly what happened when we installed an NEC 501 quad-speed CD-ROM drive and a Future Domain PNP-1630 SCSI card in a Digital Equipment Corp. Celebris 590 PC with Phoenix Technologies' PnP BIOS. When we booted the system, it automatically detected the addition of the PnP SCSI card and enabled both the card and the CD-ROM drive. We didn't even have to load drivers from a floppy disk.

We also found that Windows 95 was able to identify and configure two other early PnP ISA cards that we tested: an Aztech Labs Explorer sound card and an Intel TokenExpress PRO network interface card. Because we did not have Windows 95 drivers for these cards at the time of this writing, we weren't actually able to use them from within Windows 95 except in a Windows 3.1 compatibility mode. Windows 95 will include device drivers for a variety of PnP ISA cards (just as printer drivers for popular printers are included in Windows 3.1), but you may still need to install drivers manually for some products.

Adding legacy ISA cards to a machine with a PnP BIOS. Upon bootup, Windows 95 was unable to detect automatically that legacy ISA devices had been added to the system. As a result, when we added legacy cards to the PnP-enabled Celebris 590 system, we had to initiate the configuration process ourselves by invoking the Add New Hardware wizard provided (with its own icon) in Windows 95. This wizard--similar in concept to the wizards in Microsoft applications such as Excel--walks you through the legacy card installation process and works with you to identify legacy ISA boards that cannot automatically identify themselves to the system.

The Add New Hardware wizard can automatically identify many legacy ISA products by looking for identifying snippets of code or similar markers in the board's ROM or by interrogating I/O addresses for board-specific information. Determining what ISA cards are present is an arcane art at best, though, and Windows 95 was unable to recognize the specific boards we tried: an Aztech Sound Galaxy 16, a Creative Labs Video Blaster, an Intel TokenExpress ISA 16/4, a 3Com EtherLink 16, and a Trantor T160 SCSI. As a result, we had to bypass the auto-detection process and manually select the name of the adapter we installed from a list of close to 2,000 products. (All but one of the cards we tested--the Video Blaster--were in the provided database.)

Windows 95 knows the default settings for products in this database and will instruct you to reset the adapter's resource usage manually (DMA channel, IRQ lines, and so forth) if the defaults would cause a conflict. Usually this means setting jumpers or DIP switches based on instructions in the board's documentation. In other words, Windows 95 does not provide explicit instructions on how to set the board properly; it just informs you what resources will work best and relies on you to figure out how to configure your hardware. This could obviously be a problem for the novice user. Hope that you haven't misplaced your instruction manuals.

Installing Windows 95 in a PC with a PnP BIOS. When we installed Windows 95 into an existing PC with legacy devices for the first time, it didn't make any overt attempt to identify the hardware inside. What this means is that sooner or later you'll need to tediously catalog all of the existing components in your system and the IRQs, DMAs, and memory addresses that they use--as we did--so that the operating system will know what resources are available for a new peripheral. But then, that's really no worse than what you typically need to do to install new hardware today, and once you're done, you should never have to repeat the process. If you don't take the time to tell Windows 95 about the installed hardware, adding PnP cards could easily cause a conflict: The operating system could assign resources to the PnP card that are not available simply because it doesn't know that they're in use.

Adding PnP ISA cards to a machine without a PnP BIOS. Microsoft has taken great pains to ensure that Windows 95 can properly configure PnP cards even in machines that lack a PnP BIOS. This approach will be inherently less reliable than that in machines that do have a PnP BIOS because it means that Windows 95 has to try to identify various motherboard devices itself since the BIOS can't do it automatically. Still, we were able to make Windows' PnP work most of the time.

Using a Compaq Deskpro/M, which does not have a PnP BIOS, we installed the same PnP ISA boards as in the PnP-enabled Digital system. As before, configuration required no user intervention. For products with device drivers not included in Windows 95, you might need to install device drivers at this point.

Adding legacy ISA cards to a machine without a PnP BIOS. Installing Windows 95 onto an existing, non-PnP-ready PC and configuring legacy ISA cards will entail many of the same difficulties that exist today. The Add New Hardware wizard in Windows 95 may alleviate some difficulties; it will at least do its best to suggest settings for the card that won't conflict with other legacy devices that are already installed and known to Windows 95.


Beyond ISA

The PCI and PCMCIA buses were designed with Plug and Play-like capabilities in mind, so even existing cards should support automatic configuration and work within the Windows 95 PnP framework with the help of Windows 95 bus enumerators for PCI and PCMCIA devices. (An enumerator is a special software program that identifies devices attached to a bus.) Windows 95 then loads the appropriate device drivers. We tested this capability using an ATI Graphics Pro Turbo (1600 version) PCI graphics adapter in the Digital Celebris 590 and it worked, to a degree: The machine booted, albeit into a VGA-compatible mode, since we didn't have the Windows 95 device drivers to support higher resolutions and work with the board's special features.

When we tried a Proteon p1990 EISA network interface card in the Compaq Deskpro/M to test EISA's integration into the Plug and Play framework, configuration was slightly more complex but still manageable. We first had to identify the board using the ECU (EISA Configuration Utility, the tool EISA systems have always used to perform expansion card configuration). Then, when we reentered Windows 95, the built-in EISA enumerator was able to detect the updated information from the CMOS nonvolatile storage area and configure devices appropriately.

Microsoft says EISA support was still spotty in the beta version of Windows 95 that we tested, and that improved enumerators will ultimately mean that you won't need to use the ECU at all. Similar support is planned for Micro Channel devices, although it is uncertain whether the IBM-developed enumerator required for transparent Micro Channel configuration will be available when Windows 95 originally ships.

The VL-Bus 2.0 standard supports Plug and Play autoconfiguration, but in practice, this will be implemented rarely. By the time the VL-Bus 2.0 spec was ratified, PCI had become entrenched as the high-speed bus of choice. As a result, most VL-Bus cards comply with only the Version 1.0 specification and therefore operate like legacy ISA cards.

Plug and Play SCSI support is built into Windows 95 as well. If you're in the market to buy SCSI peripherals, look for devices that comply with a specification called SCAM, which stands for SCSI Configuration Automatically. SCAM not only allows SCSI devices to be recognized by a PnP operating system, it provides automatic termination of the SCSI bus and remapping of SCSI device IDs, which should eliminate many of the traditional difficulties associated with SCSI configuration.

A draft standard for PnP monitors extends the VESA DDC (Display Data Channel) standard; this lets monitors communicate the resolutions and refresh rates they support to graphics cards, the OS, graphics drivers, and configuration utilities. These can then take actions such as blocking out unsupported modes or automatically setting themselves to exploit the monitor's highest refresh rate at a particular resolution. DDC-compliant monitors are just beginning to appear, but we expect the feature to become standard in monitors introduced in the second half of 1995.

Additional specs cover PnP parallel and serial port devices as well. Here, the underlying idea is to enable the PC to automatically identify connected devices and install the appropriate device drivers. In theory, this would make connecting a printer or modem a simple matter of plugging the cable into the back of the machine: You wouldn't have to know what model it is or what capabilities it offers.


Plug and Play: Effortless Upgrades - Under the Hood
Under the Hood

How do the BIOS, operating system, and hardware devices interact to work their autoconfiguration magic? In a fully PnP-enabled machine, the PnP BIOS enables all PnP cards, then puts them to sleep, waking each one individually to assign a unique card-select number (CSN). The BIOS then queries each PnP device by its CSN and compiles a list of PnP cards and their required resources.

Some BIOSes then disable all PnP devices except those needed to boot the system (keyboard, hard disk, graphics adapter); others configure and enable all PnP cards at this time. There are advantages and disadvantages to both scenarios. Enabling all the PnP cards up front is the only way to make them work if the operating system does not contain PnP support; keeping some PnP cards dormant until the OS loads reduces the likelihood of a conflict with a legacy device (which the PnP OS might know about even if the BIOS doesn't). Intel is encouraging BIOS manufacturers to support both approaches through a user-accessible CMOS setting.

If the BIOS is set to enable only boot devices, it will try to set them up in a way that avoids conflicts and allows the operating system to enable remaining PnP devices. Even this process could fail if a misconfigured legacy card is installed in the system, however. When it loads, the operating system must also invoke device drivers for all the devices in the system.

The operating system's PnP functionality is coordinated by the Configuration Manager (CM). The CM controls the operating system components that actually interact with the hardware, including enumerators for each expansion bus in the system. Information that the CM and supporting software gather about devices in the system is collected in a structure called the Hardware Tree. A visual representation of the Hardware Tree is available on the Device Manager dialog page, accessed through the System icon on the Windows 95 Control Panel. By clicking on individual devices in the tree, you can see their resource allocations and driver information.


Certification

With an ambitious set of standards like those proposed for PnP, there's a risk that different vendors will interpret them in subtly different ways that lead to incompatibilities. Even barring this possibility, it will be many months, if not years, before systems are entirely PnP-enabled. The potential for confusion in the interim is enormous.

Microsoft plans to make buyers' decisions easier by undertaking an aggressive compatibility certification program. Machines that pass the tests will be eligible for a Windows 95 logo.

For systems, the logo means that the machine includes a PnP BIOS, plus additional system-specific PnP support. For instance, notebooks with docking station options need to support hot docking. And Microsoft also recommends (but doesn't require) that desktops include PnP-compatible devices--from IDE hard disks to ISA cards. The Windows 95 logo will also indicate that the machine's components meet Microsoft's minimum "PC 95" hardware specifications for running Windows 95: a 386-based or better CPU, 4MB RAM, a 640-by-480 display supporting 256 colors via a flat-frame buffer, a dedicated mouse port or integrated pointing device, one serial port, and one parallel port.


Looking Ahead

One of the most exciting aspects of Plug and Play is its support for dynamic reconfiguration events, which helps lay a foundation for "anywhere, anytime" computing. PCMCIA hot swapping is nothing new, but the Plug and Play frameworks hint at a far more robust communication model that would actually let applications make intelligent responses to configuration events. Your word processor might ask whether you want to save your file before ejecting a notebook from a docking station with a hard disk. Or, as you walk into your office, your notebook could transparently connect to the network and begin downloading your e-mail. Also covered under the dynamic reconfiguration umbrella: Basic notebook hot-docking capabilities, such as informing the PC about the availability of additional serial and parallel ports, mass-storage devices, and a higher-resolution display. Dynamic reconfiguration events will require support not just in the OS but also in applications. Windows 95 and the PnP frameworks define a strategy for providing these capabilities, but it will be at least a year before software really implements them effectively.


The Prognosis

Our initial impressions of Plug and Play are relatively favorable. Although the standards are bound to experience growing pains, Microsoft's PC 95 certification program should help steer vendors in the right direction. And even if some of the proposed aspects of the PnP frameworks don't fall into place immediately, many of Plug and Play's benefits will be tangible as soon as PnP-compatible ISA cards begin shipping.

For owners of older machines, PnP may reduce configuration hassles, although legacy card configuration problems will persist. And there are a few other limitations that PnP simply cannot eliminate. For instance, it's possible that two legacy ISA cards will support such a limited selection of resources that they simply cannot be used in the same machine without conflicts. (To avoid this difficulty with new products, Microsoft strongly recommends that PnP devices be built to support eight IRQ lines, three DMA channels, eight base I/O address locations, and eight base memory address locations.)

PnP also doesn't remove a fundamental barrier built into the PC architecture, namely the finite number of IRQs (15) and DMA channels (7) that exist. Many of these are allocated for hardwired system devices such as timers and various controllers; in fact, a point of contention among PnP's backers is how to handle some interrupts that are often assigned to devices, such as printer ports, that don't actively use the IRQs. That means that if you add enough cards, sooner or later you'll still run out of options.

Some misbehaved applications that write directly to hardware may also prove incompatible with PnP's potential to remap key resources. With PnP OSes and PnP devices still in preproduction stages, it's too early to tell whether this will be a significant problem or not. The most likely culprits are games, which are notorious for breaking every hardware-interface convention in the interest of performance.

These limitations are insignificant given PnP's promise. While reaching its utopian goals will take time--probably a matter of years rather than months--Microsoft and its collaborators are laying the foundation for a fundamental improvement in the usability of the PC.

You can find more PnP information, including standards documents, in the Plug and Play Forum on CompuServe (GO PLUGPLAY).


 Hooked and Linked

The Best Network Client

What You'll See

How It Networks

How Well It Networks

Security: Two Levels

Peer-To-Peer Networking

Monitoring and Management

Network Client of Choice


The Best Network Client

By Steve Rigney

The best network client, strong remote access, and a capable peer-to-peer LAN, Windows 95 makes communicating a breeze.

What does Microsoft Windows 95 mean to network users and administrators? In a nutshell: a customizable, universal network client. You'll have to do some work up front, but after installation you can bend and shape Windows 95 to fit into any network configuration.

We spent weeks comparing the network features of Windows 95 and OS/2 Warp, Windows 3.1, Windows for Workgroups 3.11, and Windows NT Workstation. We connected clients running these operating systems to servers running NetWare 3.12 and 4.1, IBM OS/2 LAN Server Advanced 4.0, and Windows NT Server 3.5.

We found that in terms of flexibility and functionality, Windows 95 is the best network client for all these network operating systems. All features are easy for administrators to install and manage. The networking benefits of Windows 95 include:

* The best NetWare integration in its class.

* The utilities you need to connect to almost any other existing network.

* Good peer-to-peer networking that allows you to set up a small workgroup LAN by adding network cards and cabling.

* Multiple dial-in options. There's client software for Windows NT's Remote Access Server, Windows 95's own limited dial-in server, Novell's NetWare Connect, and Shiva's LanRover or NetModem.

* Easy-to-use laptop synchronization by parallel or serial cable. Also, laptops hooked to a desktop have access to all the same drives, printers, and other resources as the desktop PC (see the sidebar "Laptop Links").

Windows 95 has even more features than its big brother, Windows NT, and far more than its predecessor, Windows for Workgroups. In comparison, the current version of IBM's OS/2 Warp lacks robust networking functionality (other than stellar Internet access), although that should change with the imminent arrival of the next version, Warp Connect, which is expected to offer peer-to-peer functionality, remote access, and a range of protocols. (See "OS/2 Warp and Beyond" in the main introduction to this cover story.)

We also found that the four clients differed in their included networked applications. Where Windows for Workgroups and Windows NT both have Microsoft Mail and Schedule Plus, Windows 95 provides a new set of programs collectively known as Microsoft Exchange. With Exchange you finally have a single mailbox that offers mail, fax, and data, as well as connections with some third-party services. The current beta version of Windows 95 ships with drivers for Microsoft Mail, CompuServe mail (but not CompuServe forums), Internet mail, and Microsoft Network, but not MCI Mail. Exchange will work with existing Windows for Workgroups and Windows NT post offices (see the sidebar "Dawn of the Universal Client?"). In comparison, OS/2 Warp includes the Internet Access Kit, Web Browser, and Internet Mail, and Warp Connect will add Lotus Notes Express and other drivers.


What You'll See

In-the-office users can take advantage of the built-in networking and communications functionality with four utilities: Network Neighborhood, Windows Explorer, Control Panel, and Briefcase.

Network Neighborhood makes connecting to and disconnecting from network resources far easier than in Windows for Workgroups or Windows NT. But it's not as intuitive as with other peer-to-peer LANs such as LANtastic or PowerLAN. Warp Connect promises this functionality.

Network Neighborhood presents a list of available servers. You can select, map a drive, or attach to the server. If you have logged onto the server, you can also browse resources such as file and queue names. While you can open a file or run an application, you cannot perform other file operations such as copy, delete, move, or rename. For that you'll need Windows Explorer, Microsoft's juiced-up version of File Manager. As with Program Manager and File Manager in the current Windows, the relationship between Network Neighborhood and Explorer is muddled, and for many jobs you'll need both of them.

You configure the client through the Control Panel, as you do currently. But Microsoft has greatly expanded Control Panel's functionality. You can define the PC as a server or client and set the user name and password, security information, network type, and kinds of network protocols used.

For road warriors, there's Briefcase. It allows you to copy files from the network or desktop to a portable or floppy disk and have Windows 95 handle the file copying, disk compression, and disk management of moving files. But for PC-to-portable transfers, you'll have to provide your own parallel or serial cable.

Also, when desktop and laptop are linked, you can take advantage of all the functionality of your desktop PC: You can print to a local or network printer, access a CD-ROM drive, or use the local PC or file server as a backup device. Windows 95 even lets you set up your desktop PC as a dial-up server, so you can access it (with the appropriate passwords) from afar with your portable.


How It Networks

As you dig deeper into Windows 95, you find a tremendous software infrastructure. There are network drivers for linking your PC to the LAN, network protocols for speaking the right language once you're connected, and network redirectors that let you log into NetWare and Windows NT servers. All these components use 32-bit code, which means they are very fast.

Windows 95 follows the Microsoft networking structure established in Windows NT and Windows for Workgroups. In the default configuration, the Server Message Block formulates and answers requests for services while NetBEUI packets carry the requests across the LAN. But Windows 95, like Windows NT, can alternatively use Microsoft's version of Novell's Internetwork Packet Exchange (IPX) to carry the LAN traffic. The package also includes TCP/IP LAN protocols and utilities that are particularly useful for Internet connections.

The 32-bit protected-mode versions of TCP/IP, NetBEUI, and IPX/SPX bundled in Windows 95 are faster and use less memory than Windows for Workgroups' 16-bit drivers. Best of all, because the drivers run in protected mode, the client software won't freeze if the node is disconnected from the LAN, as it does with Windows for Workgroups. You can use third-party drivers for different networks, but these typically will run in real mode and so will be slower and more fragile.

PCs running Windows 95 can share disk drives and attached printers with NetWare, Windows NT, or Windows for Workgroups clients without changing any software in the clients. A utility called NetWare File and Print Services responds to requests from NetWare clients, and Windows Network File and Print Services does the same for Windows network clients. Unfortunately, you can't install both Windows' and NetWare's file and print service on the same Windows 95 PC. Network administrators should note that sharing is not a default, and you can elect not to install the server capabilities.


How Well It Networks

Does all this connectivity stuff work as Microsoft claims? For the most part, yes. We were able to connect easily to our respective servers when running the appropriate protocol--IPX/SPX for NetWare, NetBEUI for LAN Server, or any of the protocols for NT Server. We were also able to use the built-in TCP/IP stack for accessing the Internet. But implementation differences prevented us from logging into a NetWare server using the TCP/IP software. Microsoft claims that Novell implements the IP stack differently.

Windows NT and Windows 95 IPX protocols worked fine, and we could connect to both NetWare and Windows NT file servers. Windows NT and Windows 95 both also provide a built-in driver for LAN Manager networks, but to use any LAN Manager utilities you will have to use the optional real-mode driver. OS/2 Warp does not provide client interfaces for network operating systems, but expect to see them later with Warp Connect.

The Windows 95 NetWare client software also executes your NetWare login script and--like the other operating systems--allows you to use all the NetWare utilities, such as NetAdmin, Syscon, Pconsole, and Fconsole. Only Windows 95, however, has a built-in utility to execute your login script. Unfortunately, Windows 95 cannot load any TSRs that may be in your login script. You'll have to launch them from your AUTOEXEC.BAT or another batch file.

Third-party drivers are also available for Windows 95, but these will typically run in conventional memory and thus be slower. Also, there's no guarantee third-party drivers will comply with NDIS, Microsoft's Network Driver Interface Specification, which defines how network drivers should be written and allows multiple protocol stacks to share one adapter. NDIS now uses a new architecture for smaller drivers. These drivers can also now automatically detect and configure an adapter through NDIS's inclusion of card and socket services.


Security: Two Levels

Peer-to-peer networks let you quickly share resources such as CD-ROM drives and printers, but you don't want everyone connecting to your PC and playing with your important data. Windows 95 provides two levels of security: share-level and user-level. The share-level security is similar to the security found in Windows for Workgroups: If you want to protect a resource such as a subdirectory or a printer, you simply assign a password to that resource. Unfortunately, share-level security does not allow you to control access to individual files.

User-level security assigns a set of privileges to a specific user ID and provides file-level security. To implement user-level security, Windows 95 employs a concept known as pass-through validation, meaning the user information comes from a NetWare or Windows NT server. Pass-through security eliminates the need to reconfigure groups, user names, and passwords. You can use the same security design for your Windows 95 servers as you do for your Windows NT and NetWare servers.

If you are using file and print services for NetWare, then your validation server must be a NetWare file server. If you are using file and print services for Windows networks, then you will need a Windows NT server.

When you install user-level security, Windows 95 requires you to provide a NetWare or Windows NT server name. Windows 95 uses the pass-through security model to gather user and group information. To connect to a Windows 95 server configured for user-level security, you must have rights to either a Windows NT or a NetWare server on the same network.

If you do not have a Windows NT or a NetWare server on your network, you can't implement user-level security. If that's the case, you'll find that other peer LANs such as LANtastic offer stronger security than Windows 95's share-level security. So the security of Windows 95 on its own is a mixed bag.


Peer-To-Peer Networking

As with Windows for Workgroups and Windows NT, Windows 95 lets you share files and resources with other similarly equipped users. Windows 95 goes further and lets you share files and printers with NetWare-based network clients. OS/2 Warp currently does not provide peer-to-peer networking, though IBM does have plans to add it in OS/2 Warp Connect.

Think of Windows 95's peer-to-peer services as a 32-bit upgrade to the same network features available in Windows for Workgroups. You can use the Windows file and print services in Windows 95 to share files, printers, and CD-ROM

drives among networked PCs running Workgroups and Windows NT. You don't have to add any software to your existing Windows network, and you can use the same tools to connect to and browse your existing Windows network.

You also can connect all your existing NetWare clients to a PC running Windows 95. The Windows network in Windows 95 is a true peer-to-peer network, but the file and print services for NetWare clients that cannot be loaded with the peer-to-peer networking are based on a server-centric model. Confused? That means any DOS- or Windows-based NetWare client can connect to a Windows 95 PC running file and print services for NetWare, but the opposite is not possible: A Windows 95 PC cannot log into a NetWare client.

As a peer-to-peer LAN, Windows 95 represents a considerable step up from Windows for Workgroups. At the same time, its functionality still falls short of what you'll find in standalone peer LANs such as LANtastic or PowerLAN.


Monitoring and Management

In addition to security features, network managers look for management tools. Windows 95 has plenty, particularly Netwatch, System Monitor, Registry Editor, and System Policy Editor.

Netwatch lets you manage users' network connections to Windows 95 servers from a local or remote PC. You can connect to a Windows 95 server and monitor how many users are connected and what files they have open. You can even disconnect users remotely. Netwatch is a great tool for monitoring system performance and network usage. For instance, if a user complains of a slow PC, you can determine if too many clients are straining that PC's resources.

System Monitor lets you locally or remotely monitor all the system performance attributes on your Windows 95 PCs, including memory usage, cache, network packets, and a host of other useful data. The information is provided in a graphical format, and you can select a bar chart, numeric chart, or line graph. System Monitor is an ideal tool for troubleshooting.

To ease the transition to Windows 95 for the administrator, Microsoft has added a global database called System Policies within the Windows 95 Registry. You can set each user's interface and rights to certain network resources. You can even have different interfaces and network rights for multiple users sharing a single PC. By controlling what the users see on their screens, you can simplify some processes and eliminate functions that certain users should not have. For instance, you might want to prevent some users from offering up their PCs as servers.

In addition to the built-in management utilities, you can use a Simple Network Management Protocol (SNMP) console, such as HP OpenView for Windows, for remote management and control of your Windows 95 client PCs. The Windows 95 SNMP agent supports MIB II and an extensible MIB that developers can use to create custom MIBs for Windows 95 clients. You have probably heard about the Desktop Management Interface (DMI), but you won't be seeing it for a while: The DMI agent will not ship in the initial release of Windows 95. When it does, DMI products may take advantage of the more fundamental Plug and Play information file created by Plug and Play products.


Network Client of Choice

As a network client, Windows 95 is top-rate, but upgrading will cost you time and money. The network features bundled with Windows 95 are impressive. You don't often see a single operating system that includes remote access, multiple protocols, and network drivers, as well as security, performance monitoring, and network management. Compared with the other operating systems we look at in this review, Windows 95 is definitely the network client to beat. It's ahead of Windows NT and clearly in front of OS/2 Warp, although the coming Warp Connect should narrow the gap.


Laptop Links

When Microsoft's engineers designed the networking features of Windows 95, they didn't forget the mobile PC users of the world. With remote access and Plug and Play, Windows 95 lets you easily connect to a Windows NT or NetWare network whether you're in the office or away.

Windows 95's remote-access services are probably its most exciting features for mobile PC users. With a laptop and modem, you can reach back to your LAN by calling directly into a Windows 95 machine or by using a remote-node server to connect as a node on the LAN. Windows 95 includes drivers for Windows NT's Remote Access Server (RAS), Novell's NetWare Connect, and Shiva's LanRover and NetModem remote-node servers. You can also use any Windows- or DOS-based third-party remote-access client to connect to your Windows NT or NetWare network (for more information, see "Extend Your Reach," August 1994).

While IBM's OS/2 Warp, Version 3, does not have any built-in remote access, Warp Connect--expected to ship this quarter--will include a LAN Distance remote-access client among other networking features (see "OS/2 Warp and Beyond" in the main introduction to the cover story).

We tested remote-access capabilities using several different servers, including Windows 95, Windows NT, and a Shiva NetModem. All the clients worked as advertised, but you will need a few hours to set up the server and client software. Also, each client you install can require as much as 2MB of additional disk space--a limited resource on most notebook PCs.

If you don't want to invest in a remote-access server like NetWare Connect, you can configure a standalone Windows 95 PC as a dial-up server. Unlike Windows NT's RAS server, the Windows 95 dial-up server has no IP routing, and you're limited to one connection at a time. Once connected to the Windows 95 dial-up PC, you can use the System Policy editor for network maintenance, and send and receive Microsoft Exchange e-mail (see the sidebar "Dawn of the Universal Client?").

You connect to a Windows NT RAS server with the same client software you use to dial up a Windows 95 server. But using Windows NT as your access server offers more power and flexibility, with up to 256 concurrent connections, simultaneous IP and IPX routing, and the ability to use high-speed X.25 and ISDN links.

Windows 95's Plug and Play capabilities also will make linking your PC into the network easier than ever. (See "Windows 95 Plug and Play: Effortless Upgrades" in this issue.) You won't have to guess at modem setup strings or try to find the right NDIS interface software.

Like IBM's OS/2 Warp, Windows 95 includes Card and Socket Service drivers for PC Cards (the new name for PCMCIA cards). The built-in card and socket services allow Windows 95 to determine what type of PC Card you have in your notebook and let you add and remove adapters without turning off your notebook or rebooting. Windows 95 can also determine when you are disconnected from the network and automatically unload the network drivers to make the extra memory available.


Dawn of the Universal Client?

By Tony Pompili

Holistic messaging--that's the promise of the Microsoft Exchange Client, a single interface to services and systems such as MCI Mail, CompuServe mail, The Microsoft Network, the Internet, faxes, and yes, the Microsoft Exchange Server. All messages are created, sent, received, read, organized, and deleted through a single interface. PC Magazine looked at the prerelease versions of the Exchange Server and Exchange Client, and we found them complex products that could unite all of your mishmash of mail, BBS, and local communications services into a single application.

In Your Interface

One for All

The Complete Package


In Your Interface

The Exchange Client will be built into Windows 95. Although Microsoft hopes it will be used frequently with the Exchange Server in a client/server mail system, the Exchange Client is designed to dovetail with a variety of Microsoft and third-party messaging services and systems including Microsoft Mail, the Internet, and CompuServe. (For an overview of the Exchange Server and Microsoft's messaging strategy, see "Four Paths to Messaging," PC Magazine, April 25, 1995.) In addition to the Windows 95 Exchange Client, Microsoft plans to ship Windows 3.1 and DOS versions, which we also had a chance to see.

Unlike yesterday's e-mail, the Exchange Client goes beyond the LAN. Sitting on top of Microsoft's existing mountain of communications APIs and services, the Exchange Client also, for example, will let you send and receive faxes through a fax application or dial up CompuServe to collect mail. As with network back-end services, the Client makes this happen with hooks into Microsoft's Telephony APIs (TAPI). This architecture for supporting local communications through the Client is also key to Microsoft's remote-access strategy. The Client will be able to dial into Exchange Servers and Microsoft Mail post offices using Microsoft's Dial-Up Networking, also known as Remote Access Services (RAS).

The Client has a look and feel similar to other upcoming Windows 95 products, such as Microsoft Mail and Lotus Notes, Release 4. The Client eases maneuvering among folders using File Manager-like tree structures. An outline of the folder contents appears in the View window pane to the right. Views are completely customizable; you can move columns and sort messages within each View.

The companions to Views are Forms, the templates used for entering messages. The Exchange Client comes with a series of default Forms, the most basic of which is a Microsoft Mail-like message form for creating e-mail messages. With the Exchange Server, Microsoft will ship Exchange Electronic Forms applications for Windows 95 and Windows 3.1 that create forms using Visual Basic code. Forms we saw allowed users to create buttons, tabs, and even graphics with pointer-sensitive hot spots.

The Exchange Client provides other basic capabilities, such as searching and filtering to process messages automatically. For example, similar to cc:Mail's Rules, a filter can automatically place messages from your boss in a high-priority folder.

The Client's drop-and-drag implementation makes it possible to file documents quickly and is especially interesting when storing application documents. When we dragged a Word document into the View pane, OLE properties such as document title and author came with it. These properties were then available as View columns, which means that documents could be organized according to the detailed information provided by the OLE properties.

Microsoft has established rich-text messaging with a vengeance. Both the Exchange Client and Exchange Server support a wide array of rich-text tools that allowed us to change fonts and paragraph formats, as well as other tools for bulleted and listed items similar to what's available in Word for Windows. The Exchange Server supports these rich-text formats, but not all third-party back-end services will support the same formatting.


One for All

Besides working with the Exchange Server, the Client will snap into a wide range of non-Exchange Server services, including Microsoft Mail and CompuServe mail. Using MAPI 1.0 as the layer between the front end and back end, Microsoft's Service Provider Interface (SPI) will hook third-party services into the Exchange Client. Service Providers will come as drivers, like Windows printer drivers, allowing users to mix and match the services they use.

We were able to customize our own group of Service Providers by defining a user profile. An Exchange Client can have one or more profiles that tell the client what Service Providers to use. Microsoft has not announced which Service Providers will come with Windows 95, but support for Internet mail is expected. Other messaging services such as America Online, CompuServe, and SkyTel are currently working on their own drivers, which are expected to be available when Windows 95 ships. The Client will not include the Exchange Server Service Provider, available only to Exchange Server customers.

The SPI also lets providers add custom messaging features. For example, Exchange will allow users to create custom forms, such as an expense or contact management form. Exchange Server customers will get the Microsoft Electronic Forms development application to create these forms.


The Complete Package

Because it acts like any other messaging provider, the Exchange Server manifests itself subtly in the Exchange Client. The most apparent interface feature of the Client is the Public Folders, which anyone with appropriate Exchange Server rights can create. We were able to create a public folder and assign permissions for using the folders. Public folders can be used as discussion databases or public document stores, similar in function to the local document folders in the Client.

To set up the Server you use the Exchange Administrator, a Windows 95 application. Like the Client, the Administrator displays the hierarchy of the Exchange network. To distribute network access rights logically, the Administrator divides server administration tasks by enterprise, site, and server. For example, you can allow local administrators to create and edit Exchange users at their site but not modify users' accounts at other sites.

We were able to create new users easily with the Administrator. Microsoft has built-in Windows NT hooks that turn what could be a multistep user-creation process into just a few steps. We could set Windows NT to bring up Exchange's new-user administration program automatically whenever we added a new NT user, instead of separately creating a NetWare user and then creating a user on the e-mail post office.