Although they share common features, the newest versions of Windows and NT have fundamental differences
Jon Udell
As summer 1994 drew to a close, beta testers were evaluating the two newest members of the Windows family of operating systems: Windows 95 (aka Chicago, due in 1995) in its first beta release, and Windows NT 3.5 (aka Daytona, due now) in its last.
The two siblings have a lot in common. They can run some of the same Win32 applications. They can work with each others' files, printers, clipboards, mailboxes, and even registries. And, of course, they can both run legacy DOS and Win16 applications.
But their differences are equally profound. Chicago is a mongrel, with preemptive multithreading and 32-bit capability grafted onto a 16-bit DOS/Windows found
ation. Daytona, the second generation of Windows NT, is a purebred, multithreaded and 32-bit from the ground up. To use another analogy, Chicago is like a car, designed for the average home or business user. Daytona, on the other hand, is like a Mack truck. It carries big loads for servers and serious business, scientific, and engineering users whose tasks justify powerful x86 or RISC workstations. Chicago, though built on a weaker foundation, can reach a large population of systems, so it gets first dibs on important advances, such as Plug and Play and MAPI 1.0. Although Daytona is built on a far stronger foundation, it finds a smaller group of machines to run on today, so it has to wait for some of the cutting-edge stuff.
Which to choose: Chicago or Daytona? It's increasingly clear that while both have important roles to play, they won't eradicate the deeply entrenched Windows 3.1 anytime soon. Four-MB desktop and laptop systems and 16-bit Windows applications continue to sell in huge numbers. Chicag
o and Daytona demand more powerful systems and applications.
The good news is that once companies start supplying users with bigger, smarter systems and Win32 applications, either Chicago or Daytona can make those users far more productive. The bad news is that during the transition period, the coexistence of Windows 3.1, Chicago, and Windows NT (not to mention other options, such as OS/2) will create headaches for software developers, systems managers, and users alike. As with all families, the Windows family of operating systems can sometimes drive you crazy.
Chicago in 4 MB
``Runs great in 4 MB!'' That was the unofficial battle cry of the Chicago development team. The official claim, once Microsoft admitted that there actually was a Chicago, was more guarded and more carefully qualified. ``If you're happy with Windows 3.1 in 4 MB,'' Microsoft said, ``you'll be happy with Chicago in 4 MB.'' Even this, however, now seems unlikely, based on the (admittedly two-months stale) beta 1 release
of the product.
I keep a low-end PC on hand, partly out of inertia and partly to test these kinds of claims. This system began life as a 4-MB Gateway 386/20. DoubleSpace expanded its 80-MB hard disk to a more livable 150 MB; a CPU upgrade (to a Cyrix CX486DRX2) accelerated the system nicely; and Media Vision's Memphis multimedia kit added sound, MIDI, and CD-ROM capabilities. But it's really still just a dinky PC. I won't say I'm happy with Windows 3.1's performance on this machine, but I will say that Windows 3.1 can get useful work out of it, handling easy tasks such as writing, telecommunicating, CD-ROM information retrieval, and MIDI recording/playback well enough.
Running Windows for Workgroups on this humble Gateway is another matter entirely, however. With networking turned on so that I can remotely access the office network, WFW thrashes. I've found 6 MB to be the practical minimum for WFW with networking; it works in 4 MB only without it--in effect, you're running the equivalent of Wind
ows 3.1 beefed up with 32-bit file access. (How can you work remotely with a 4-MB Windows PC? Straight Windows 3.1, the NetWare shell, and Shiva's asynchronous IPX is one lightweight combination that has worked well for me.)
Since WFW was the dress rehearsal for Chicago's 32-bit network and file I/O subsystems, you should base size expectations for Chicago on WFW rather than on straight Windows 3.1 (although Microsoft hasn't been clear about this distinction). I didn't expect Chicago to make the 4-MB Gateway a useful networked machine; I expected it to make it just a useful stand-alone machine, as both Windows 3.1 and WFW do.
Chicago found the Gateway's S3-based Orchid Fahrenheit video board and the ProAudio Spectrum sound card with its Trantor SCSI connector, migrated the Windows 3.1 program groups and desktop settings, and rebooted. Chicago came back up with the correct wallpaper and chimed to announce that the sound system was working.
Unfortunately, that's about all I could get it to
do. My 4-MB Gateway was transformed, for all practical purposes, into a boat anchor. It can run the Chicago shell, but almost nothing else--not even the Control Panel, which I might otherwise have used to start jettisoning nonessentials, such as sound support.
How do you reconfigure Chicago when you can't run the Control Panel? The trusty old DOS start-up files still matter more than you think. Although you hope that Chicago's protected-mode drivers support your hardware, installation doesn't assume that they will. Real-mode drivers that load from CONFIG.SYS and AUTOEXEC.BAT continue to load until you see that they aren't needed. For example, on my Adaptec 1742-equipped 16-MB Everex Step DX2/50, Chicago left the ASPI (advanced SCSI programming interface) and Corel SCSI drivers and MSCDEX in place. When I commented them out, the system still ran perfectly fine--even better, in fact, because its feet weren't stuck in the real-mode mud.
As with DOS, pressing the F8 key at boot time makes Chicago pr
ompt before executing each line of CONFIG.SYS and AUTOEXEC.BAT. (You can also clean-boot straight into the Chicago version of DOS by pressing Alt-F5.) Using this technique, I lightened Chicago's memory load by dumping sound and CD-ROM support. DBLSPACE.BIN had to stay because its protected-mode replacement wasn't included with beta 1, although it will be available later. DoubleSpace had to run somewhere if Chicago was going to work on this machine; shifting compression to protected mode might make the system faster but isn't likely to make it much smaller.
My tweaks helped a little, but Chicago still ran out of memory trying to run its own Control Panel applets. I will be fascinated to see whether the final Chicago product can do better. Admittedly, my DoubleSpace-equipped 4-MB Gateway represents a worst-case scenario. There are, however, many such worst-case scenarios in the real world, particularly in the form of laptop PCs.
Businesses that want their road warriors to have a fighting chance sh
ould plan to outfit their troops with bigger, faster systems, and they should jump on the Plug and Play bandwagon as soon as it's feasible to do so. But the center of gravity of the installed base moves slowly. Chicago will have to get a lot smaller and faster to run acceptably on many of the PCs that are now in use or being sold in retail stores and through mail-order catalogs.
Chicago in 8 MB
On a reasonable desktop machine--an Advanced Logic Research Flyer 32LCT with 8 MB of RAM, a 486/66 CPU, and a 340-MB Maxtor IDE drive--the Chicago story is, as you'd expect, far more compelling. I ran the installation from WFW 3.11 and, lacking a local CD-ROM drive, used the WFW redirector to borrow a remote one. In 20 minutes, Chicago was up and running, enjoying the same access to all the WFW, NT, and NetWare resources that WFW had previously enjoyed, including redirected drives, printers, and file-based and client/server network applications.
Moreover, Chicago made things better than before in a
couple of ways. One huge win is the unification of network namespaces and browsing methods across multiple network providers. (Note that NT has always had this kind of multiprovider capability; now the NetWare client included with Daytona visibly exploits it.)
Under WFW, I redirect to an NT drive like this:
net use h: \\EVEREX\EVEREXCD
but to a NetWare drive like this:
map root t:=OURTOWN\VOL1:TEMP
In Chicago (or Daytona), it's all done with a consistent UNC (Universal Naming Convention) syntax, so the NetWare mapping becomes the following:
net use t: \\OURTOWN\VOL1\TEMP
Under WFW, GUI-based drive and printer redirection works one way for Windows network resources and another way for NetWare resources. Chicago's Explorer treats both flavors of resources identically.
Although Chicago defaulted to the real-mode ODI-based (Open Data-Link Interface) NetWare client I had been using under WFW, I then used the Networks applet in the Control Panel to switch to the
protected-mode NDIS-based NetWare client that comes with Chicago. It's still unfinished, but the NetWare client is fast and very functional. Although support for protected-mode ODI isn't part of the current plan, the recent Microsoft/Novell detente raises hopes that Chicago's already-strong NetWare support will get even stronger.
Both Chicago and Daytona have the ability to run essential NetBIOS- and RPC-based (remote procedure call) networking services over any of three transport protocols: NetBEUI, IPX/SPX, and TCP/IP. I've used all of these protocols successfully. (The Chicago and Daytona remote-access services can both use PPP, which extends this protocol's flexibility to asynchronously connected systems, too.)
Since the Chicago and Daytona TCP/IP stacks support DHCP and WINS (Windows Internet Naming Service), administration of TCP/IP is a lot easier than before (see ``Automating TCP/IP in NT'' on page 189). I'm running DHCP on a Daytona Advanced Server system, which automatically allocates
IP addresses to my Chicago and Daytona clients, as well as to my WFW 3.11 system running the new VxD-based (virtual device driver) TCP/IP stack.
What about WINS? It isn't a factor on BYTE's single-subnet LAN. It comes into play only during the mapping of NetBIOS names across TCP/IP subnets, as an automatic and dynamic substitute for the cumbersome and static LMHOSTS file that maps NetBIOS names to IP addresses.
Despite significant TCP/IP improvements, both Chicago and Daytona default to the NetWare standard, IPX/SPX. Why? It's routable, unlike NetBEUI, and works right out of the box, unlike TCP/IP, which minimally requires that you set up DHCP (and possibly WINS) servers and keep them running all the time. Since IPX/SPX is required to connect Windows to NetWare in most corporate LANs anyway, it makes great sense to accommodate Windows to it. Multiprotocol networking is neat, but not just for its own sake. Microsoft's agnostic approach to network transports is a laudable achievement.
Two i
mportant new features, user-level security keyed to NTAS (NT Advanced Server) and NetWare servers and a so-called master key authentication service, weren't quite cooked in beta 1. When you share a Chicago resource, you'll be able to specify share-level security, which challenges all users to unlock it with a password you assign to the resource, or user-level security, which admits only those users you select from lists authenticated by NTAS or NetWare. The latter is a great way to control the anarchy of peer networking, and I wanted to see it in action, but beta 1 Chicago couldn't find NetWare binderies and hung trying to access an NTAS user database.
Chicago's master key is another bright idea, intended to enable you to unlock a set of password-protected network, mail, and other services with a single password. In beta 1, a single password did work for both network providers and mail, but the Networks->Security->Set Passwords dialog box, where you'll administer the master key, didn't reflect that.
Managing Devices
Users' experiences with Chicago will vary wildly depending on the hardware they put it on. There's a vast difference, for example, between Chicago on a conventional system and Chicago on a Plug and Play system. Chicago can also behave very differently from one conventional system to another.
Consider the thorny problem of ISA/EISA hardware detection. Chicago tries hard, and you can read in DETLOG.TXT the record of its heroic struggle to identify motherboard, video, SCSI, network, and other devices by sniffing and poking. Results vary. When I tried it on four different machines, detection always succeeded with video, usually with SCSI, sometimes with network adapters, and, for some reason, never with modems.
Of course, knowing that a Future Domain 1660 or an NE2000 is present isn't the same as knowing how that card is set. In my tests, Chicago almost always punted and took the defaults, even though my hardware often wasn't set that way. So I had to use the new Device M
anager to configure boards, and in the end, detection was mostly a waste of time.
On one system, the Everex Step DX2/50, it was a disaster. Trolling for SCSI cards, Chicago kept poking I/O address 300 (used by the NE2000), hanging the system each time. Setup is restartable, but this routine gets old in a hurry: ``BusLogic, are you there at 300?'' Wham! ``UltraStor, are you there at 300?'' Wham!
Intriguingly, Daytona sailed through hardware detection on the very same Everex machine. Microsoft says that Chicago and NT share detection code and data, but it sure doesn't look that way. I've found Daytona's detection to be less ambitious than Chicago's, but more reliable. If you plan to deploy both operating systems on the same hardware, be certain to study the hardware compatibility lists carefully.
Don't assume that a Chicago machine is by definition an NT machine or vice versa. For example, I've got Daytona happily humming along on a Compaq ProLiant, giving both 66-MHz Pentium CPUs a workout
. When I installed Chicago on the ProLiant, its protected-mode disk driver threw an exception and suggested that I try a real-mode substitute. In real life, you'd never waste a classy multiprocessor system like the ProLiant on Chicago. But while Chicago and NT may someday share a common pool of Win32 applications, they're further apart, in terms of device support, than Microsoft originally led us to believe.
Does Chicago's device management add any value to today's non-Plug and Play PC? Yes. Like Daytona, Chicago keeps all configuration data in the registry. Once you help it figure out what the configuration is, you can review it using the Device Manager or RegEdit (see the screen shot on page 139). And, as with Daytona, Chicago's RegEdit is RPC-enabled, so system managers can review and edit configurations on remote PCs. Furthermore, Chicago will export configuration data to system management consoles by way of DMI and SNMP agents.
Given the state of conventional hardware, your Chicago experien
ce also depends a lot on whether your device support comes from DOS, Windows 3.x, or Chicago itself. I've tried it all different ways. Working with an unsupported SCSI controller and CD-ROM drive, it was nice to be able to fall back on DOS, but it was depressing to have to fiddle with CONFIG.SYS, AUTOEXEC.BAT, MSCDEX, SmartDrive, and more.
Working with a Future Domain 1660 cabled to a Plextor CD-ROM drive, however, life was wonderful. Using the Win32 version of Martin Heller's image3 GIF viewer, images leaped from a CD to the screen, following a 32-bit path through the SCSI driver, the disk cache, and the CD-ROM file system. All I had to do was configure the Future Domain card in Device Manager. Chicago (like Daytona) just takes care of details that DOS and Windows expect the user to handle.
Chicago won't be the only PC operating system to support Plug and Play; OS/2, PC versions of Unix, and (I hope) NetWare will, too. But with its Plug and Play-ready drivers, setup and configuration tools, and
shell, Chicago currently leads the pack in readiness.
Meet the Chicago Shell
As promised, Chicago can log in to and log out from NetWare on the fly, correcting a Windows flaw that has caused endless wailing and gnashing of teeth in the corporate world. The method of access to these functions nicely demonstrates one of the principles that Chicago borrows from IBM's Workplace Shell: You right-click on shell objects to expose their properties and methods. In the case of an object that represents a NetWare server, a right-click pops up a menu from which you can directly invoke NetWare commands, such as LOGIN, LOGOUT, and WHOAMI. Right-clicking on objects that represent files reveals properties such as size and modification date, and methods such as QuickView, which invokes a viewer to show the contents of the file.
Workplace Shell users will find the Chicago shell eerily familiar. Both shells make extensive use of right-click-activated property editing and method activation, tabbed property p
ages, aliases (called shadows in OS/2, shortcuts in Chicago), and fully nestable folders. Both also exhibit the same fundamental design flaw: namely, failure to unify the file system with the desktop object system. In other words, the file system depends on one root (C:\), while the desktop object system depends on another (C:\DESKTOP for OS/2, or C:\WINDOWS\DESKTOP for Chicago).
What's wrong with this arrangement? It overloads the notion of a top-level folder. For example, the first thing I did with the Chicago shell was to create a top-level folder called Jon and drag some files into it. Later, browsing with the Explorer, I opened what I thought was a top-level folder called Jon and discovered those files were missing.
Where had they gone? From the shell's perspective, the top-level Jon folder was C:\WINDOWS\DESKTOP\JON, and that's where it put my files. While browsing with the Explorer, I expected to find a top-level Jon folder at the root of the C drive, where in fact I did find one: C:\JON.
Which is the real top level? Either, really, depending on how you think about it. As Apple's user-interface guru Donald Norman could have told both IBM and Microsoft, this kind of conceptual overloading is a dangerous thing.
It gets worse. In some situations (e.g., the File Open dialog box), Chicago hides the desktop's root, C:\WINDOWS\DESKTOP, while in other situations (e.g., the DOS C: prompt) it doesn't. This inconsistency yields weird results. For example, I put some Visual C++ project subdirectories into the file system's top-level Jon folder, and others into the desktop's top-level Jon folder. All projects were accessible from Explorer, but only the C:\JON folder was accessible from the Visual C++ File Open dialog box. However, from a DOS window I was able to change directories to C:\WINDOWS\DESKTOP\JON and then load Visual C++ projects stored there by typing start project.mak.
True Chicago applications are supposed to call a version of File Open that respects the desktop's notion of hier
archy, not the file system's, and so will behave differently than legacy Win16 applications in this respect. Confused? I sure was.
I can hardly imagine what novice users will make of all this. On a Mac, there's no disconnection between physical and logical storage. Users know that the desktop is a view of the hard disk and that the window system and the file system are synonymous. In Windows 3.x, the File Manager/Program Manager split presents physical and logical views of storage, but Program Manager's logical view is not too ambitious and doesn't invite confusion with File Manager's overtly physical view. In OS/2, Workplace Shell, and the current Chicago shell, the logical view is very ambitious and always at war with the physical view.
A logical view of storage can be very powerful. The question is how to implement it. I think Microsoft has the right idea: Insert a high-level API between programs and their data. OLE 2.x structured storage is such an API. In Daytona's successor, Cairo, OLE-str
uctured storage will be able to attach to, and extend, the file system. As the Explorer navigates from a file store into an object store, control will be transferred from Explorer's viewer to an object-supplied viewer. Object internals won't be stored in user-visible directory structures, so users won't trip over them.
The OLE 2.x strategy is an ingenious bridge between today's world of file-based storage and tomorrow's world of object storage. Microsoft hopes that users lured by compound documents and in situ editing will voluntarily commit more and more data to object storage. As that shift occurs, Windows will be able to sustain more comprehensive and more seamless logical views of storage.
The InfoCenter
One excellent example of how this can work is the Chicago InfoCenter, which appears as a top-level desktop folder when you install MAPI 1.0 and the Chicago mail system. There is, to be sure, a directory called C:\WINDOWS\DESKTOP\INFOCENT, which corresponds to the InfoCenter. But it's v
irtually empty. All you'll find is the OLE 2.x interface ID that the shell uses to invoke Chicago's mail client. It, in turn, creates a logical view of the InfoCenter as a structure of nested folders containing objects (i.e., messages) that, when right-clicked, invoke methods that are used to edit, address, send, forward, or delete messages.
This brilliant idea deserves some careful study. How can developers implement it? The mechanism is still being invented and is, like everything on the cutting edge of OLE, fairly obscure. It's not nearly as accessible as the straightforward SOM (System Object Model) hierarchy that underlies the Workplace Shell. If Microsoft follows true to form, however, a future version of MFC (Microsoft Foundation Classes) will probably encapsulate it sufficiently for the average programmer's use.
As promised, the MAPI 1.0 subsystem included with Chicago unifies message handling across multiple mail providers--a neat trick. To test it, I installed the beta CompuServe mail
provider alongside the Microsoft Mail provider that's included with Chicago and configured it to share the Microsoft Mail message store and private address book. Getting things to work took some persistence because the CompuServe provider wouldn't talk to my modem at first. After much poring over its script files, I found the problem. Chicago's RAS (Remote Access Service) was listening on the same COM port that the CompuServe driver needed.
Contention for that port wasn't a problem for HyperTrm, Chicago's telecommunications tool, because HyperTrm and RAS both comply with the TAPI (Telephony API) rules for shared access. Once I shut down RAS, things worked fine. CompuServe and Microsoft Mail messages mingled happily in my inbox, and I could send a single message to users on both systems with one mouse-click.
Easier Windows?
When Microsoft user-interface researchers polled a group of Windows 3.1 users, they found that most ran one program at a time. How, then, to expose Chicago's more formid
able multitasking to novice users? The shell team's answer is the Taskbar, which combines the functions of an application launcher with those of a task switcher.
Always visible unless you explicitly hide it and dockable to any edge of the screen, the Taskbar's cascading launcher puts programs and recently used documents within easy reach. Once launched, applications minimize to the Taskbar, which in turn provides a constant visual summary of what's running on the system and reactivates minimized programs with a single mouse-click. The most visible emblem of Chicago, the Taskbar serves its purpose and may help sell multitasking to the masses, but I miss the old Task Manager's handy list of running applications.
Microsoft also touts the ease-of-use benefits of Chicago's help system. Specifically, the new help system is supposed to take you to the scene of the action it describes. When you're trying to set up remote access, for example, the help topic should provide a link to the RAS configuration
dialog box. That's a good idea, but not nearly the brilliant innovation that appeared in Apple's System 7.5. Because the System 7.5 Finder is Apple Event-aware, the new Mac help system can not only take the user to the scene, it can also enact the whole drama, driving the shell under script control and coaching the user along the way.
The Windows way to achieve this effect would be to OLE-automate all aspects of shell operation. Chicago will not work that way, but it should. Desktop operating systems are complicated, and no matter how you organize their knobs and levers--in dialog boxes, menus, or tabbed notebooks--there's a ton of procedural lore for users to absorb. For example, when I am configuring RAS, do I take the path Network Neighborhood->Remote Access->Connections->Dial-in Options or the path Control Panel->Network->Configuration? And which settings on which property pages found in these places do I tweak to get the results I want? Making the system the coach would be a great use of OLE 2.x a
utomation.
Users on the Move
Chicago's so-called mobile services include single-port dial-in and dial-out remote access and a special desktop folder, called the Briefcase, that synchronizes sets of files across Chicago systems. For multiport service, you need Daytona Advanced Server, which quadruples to 264 the dial-in capacity of NT 3.1 Advanced Server.
Eventually I got both Chicago and Daytona to work as both RAS clients and servers, but fiddling with communications settings was a tedious chore. If Chicago, in particular, is going to be something that you can just hand over to a busy field-sales force, it ought to get smarter about this sort of thing. Once I was connected to the office from a Chicago PC at home, though, the view was breathtaking. For the first time as an asynchronously connected user, I could see both Windows and NetWare resources simultaneously.
In fact, there are two ways to achieve this effect. You can run multiple network clients on the remote PC, or you can r
un only the Windows network client and use Daytona Advanced Server on the office LAN as a gateway that republishes NetWare resources for local or remote Windows network clients.
A problem with WFW's RAS was that it tended to hog the system when communicating. Chicago's threading alleviates this problem in some cases. A file search, for example, ran nicely on a background thread. But browsing with Explorer was painfully slow in beta 1, and it monopolized the system. Click on the wrong remote folder, and you can be in for a long wait as Explorer fetches dozens--or even hundreds--of filenames. Microsoft, which has been urging Chicago developers to write network applications that work intelligently on slow links, should heed its own advice and make remote browsing incremental and more interactive.
The Briefcase is intended to help you synchronize Chicago systems using either RAS or floppies to transfer data. With RAS, you can synchronize a Briefcase that lives on your home system with a set of files
back at the office, updating from office to home at the start of an evening work session, and vice versa at the end of the session. That's less useful than it sounds, though, because it requires two phone calls. I find it easier and quicker to simply drop a floppy disk into my real briefcase.
Here, though, Chicago's Briefcase metaphor failed me. I thought I could just drag it from home PC to floppy, and then from floppy to office PC. But Briefcases synchronize with sets of files, not with other Briefcases. The second step of the floppy shuffle triggered a sharing violation: You can't smash one system's Briefcase on top of the Briefcase belonging to another PC and expect them to somehow merge.
From Chicago to Daytona
Even in its current rough state, Chicago can do a lot of useful work. On my 16-MB Everex, I already prefer it to WFW 3.11. Daytona, however, now much slimmer than NT 3.1, is making a bid for dominance on this machine. The trade-offs are vexing. Chicago is snappier, especially
when running demanding Win16 applications. For example, I've been building a lot of Folio Views infobases lately on this machine, and while I'd prefer to use Daytona, Chicago gets the job done quicker.
Chicago is also cleverer in some ways. For example, its new printing subsystem, which spools to an enhanced metafile that renders on a background thread, really does speed up return-to-application time. But Chicago isn't yet immune to those annoying ``The system has become unstable'' messages, and, given its heritage, it likely never will be. Daytona, on the other hand, has the stability I cherish. Its sophisticated performance-monitoring and event-logging services also make it inherently far more manageable than Chicago.
Other Daytona improvements include OLE 2.0 support, Chicago-compatible long filenames on FAT (file allocation table) file systems, the ability to run VDMs (virtual DOS machines) in separate address spaces, smaller and faster network transports, and OpenGL 3-D graphics. The beta v
ersion I tested ran Win16 programs somewhat faster than NT 3.1 did on x86 hardware, and dramatically faster on Mips and Alpha systems, thanks to an improved Insignia emulator and WOW (Windows on Windows) subsystem.
Because Windows 3.x is the cash cow, these extensions get built first in 16-bit form. Then they migrate to the Win32 platforms, but not necessarily in lockstep. Win16 applications on Chicago or Daytona need 16-bit services, Win32 applications need 32-bit services, and 16- and 32-bit flavors must be made to interoperate.
If you're thinking about a staged upgrade from Windows 3.x to Chicago, Daytona, or both, you will need to verify that the components you need are available and will work in the combinations you require. Is there light at the end of this tunnel? Not, I think, until Win32 becomes the preferred platform for new Windows extensions.
Daytona's multi-VDM Win16 capability works well, protecting Win16 applications from one another. Microsoft says that Daytona would ensur
e reliable DDE and OLE traffic across VDM boundaries, and my tests bear out that claim. This feat is easier for NT than for OS/2 because NT can use its Win32 DDE and OLE engines to route the traffic, while OS/2 has to use its own special-purpose router.
The advent of OpenGL graphics bolsters NT's claim on the scientific workstation market. The OpenGL SDK (Software Development Kit) demonstrations and the way-cool new 3-D Pipes screen saver appear very much at home running on an SGI/Mips R4400-based Magnum. Microsoft says the Daytona implementation can exploit accelerated OpenGL hardware.
Daytona does not, however, deeply integrate OpenGL with Win32. OpenGL is a separate library that owns regions of the screen bounded by Win32 frames. Win32's imaging model, which works in only two dimensions, could make excellent use of the third, but for now, Win32 applications and OpenGL applications inhabit different worlds.
The Win32 Horizon
The first beta version of Excel for NT has just arrived,
for x86 and Alpha CPUs. It's a Win32 application, so it should run on Chicago, right? Well, someday it probably will, but not yet. Excel for Chicago (if it exists yet) would also be a Win32 application, so it should run on NT, right? Well, maybe not, if it binds tightly to Chicago shell services that are not available on Daytona.
At the moment, it's sometimes hard to predict what won't run where, or to explain why. Of course, the Microsoft Visual C++ 2.0 beta version that's now circulating can generate x86 Win32 binaries for both Chicago and Daytona, and its version of MFC can even render some user-interface details in a context-sensitive manner. So, there's hope from that quarter for source-compatible, if not binary-compatible, Chicago and Daytona applications.
Some Win32 applications that are available today do run on Chicago or Daytona--MicroEdge's Visual SlickEdit, for example. Even if such applications show up in significant numbers, there will still be a performance gap between Chicago an
d NT. A lightweight operating system will always get more out of a given set of hardware than an industrial-strength one. So, on uniprocessor x86 hardware, if you want flat-out speed above all else, run a Win32 application on Chicago--not NT--if you can. Given multiprocessor or RISC hardware, though, only NT can take that Win32 application to full throttle.
I favor security, reliability, and manageability over raw speed, as long as the performance is adequate. Daytona's performance will be good enough for more desktops than NT 3.1's performance was; however, for Win16 applications, it still likely won't match Windows 3.x, Chicago, or the latest version of OS/2 (see the text box ``IBM Engages Warp Drive for OS/2'' on page 138). For Win32 applications as well, Daytona likely won't outrun Chicago. On smaller systems, NT isn't even an option.
The upshot is that we'll be living with the whole Windows clan for the foreseeable future. CONFIG.SYS and SYSTEM.INI wizards can now branch out into new realms
of registration-database esoterica. I guess this is progress, but could somebody please pass me the ibuprofen?
Illustration: The browsing of NetWare resources (e.g., servers Ourtown and Rhapsody) using Chicago's Explorer works just like the browsing of Chicago (e.g., Everex, PS/2) and Daytona (e.g., Viper) resources. Right-clicking on a NetWare icon gives direct access to NetWare commands, such as LOGIN and WHOAMI.
Illustration: Once automatically detected or manually configured, Chicago's Device Manager summarizes installed devices (a) and their settings (b). The registration database is the configuration viewer/editor of last resort.
Illustration: The Taskbar serves as a cascading program launcher and task switcher. Any programs or subdirectories that you place in C:\WINDOWS\PROGRAMS are available from Taskbar's launcher. Single-clicking on any task shown on the Taskbar activates it.
Jon Udell is a BYTE senior technical editor at la
rge. You can reach him on the Internet or BIX at
judell@bix.com
.
Exploring Chicago and Daytona
