Touring Chicago/Previewing a Windows 4.0 Prototype-Jan 1994


Touring Chicago/Previewing a Windows 4.0 Prototype-by John Ruley
Copyright (c) 1993  CMP Publications  All Rights Reserved

A Revolutionary Interface Graces the Next Version of Windows

Chicago? Isn't that a city on the shores of  Lake Michigan? Sure, but Chicago
is also the code name for a stunning new version of Windows. Windows 4.0 is
no mere incremental upgrade; we're talking about something truly
revolutionary here. Its heart is a brand-new 32-bit operating system kernel
(DOS is gone!), and its visual personality comes from a completely
redesigned, thoroughly object-oriented interface. Chicago delivers
capabilities and ease-of-use beyond those Mac afficianados have long boasted
of, and incorporates a surprisingly large chunk of the functionality found in
Windows NT, Microsoft's high-end OS.

Imagine yourself sitting down, as I did, to a private sneak-peek at a PC with
the Chicago (Windows 4.0) "alpha'' prototype installed. You flip the power
switch, and the first thing you see is a "splash screen'' that shows a
Chicago logo over a graphical sunrise; but that stays up only for a second.
What comes up next depends on whether or  not you press the Esc, F5 or F8
key. If you do, you next see a character-mode prompt that shows some very
familiar-looking CONFIG.SYS and AUTOEXEC.BAT execution lines. Chicago uses
these to get path information and properly set up any real-mode device
drivers before kicking itself into graphics mode. Don't be fooled, all this
may look like DOS, but it's actually a 32-bit operating system that's more
like Windows NT (or, dare we say it? OS/2 2.1!) than any creaky old DOS
version.

After the CONFIG.SYS and AUTOEXEC.BAT messages have been and gone, the
monitor flashes and the Chicago graphical interface comes up.  And it sure
doesn't resemble Windows 3.1.

Folders, Folders, Everywhere 
In fact, if you've ever seen a Macintosh running Apple's System 7, you'll get
a strange sense of deja vu. Like the Mac, Chicago's interface is made up of
icons and folders, lots and lots of folders. They have a very Mac-like 3-D
look, and they sit within an interface that's graphically one of the best
designs we've ever seen. Everything is 3-D, buttons, icons, menus, you name
it. Clearly, it was designed by some very artistic people.

Looking closer, you'll recognize some of the icons in the folders and on the
desktop itself. There's the Windows File Manager icon, for instance, though
it's now called a File Cabinet. You see others that look a whole lot like the
icons for Notepad, Clock, and other old Windows 3.1 friends. You'll also see
some new icons. Some are obvious, like the Recycle Bin, while others are a
bit more cryptic. What in the world could a globe icon possibly represent?

Double-clicking on a folder pops open a window full of icons, and more
folders. Unlike Program Manager in Windows 3.1, the Chicago desktop allows
you to nest folders inside folders inside folders, ad infinitum. In fact,
it's quite possible (as any Mac user can tell you) to get lost in those nests
of folders!

Of course, you can drag icons out of their folders and place them inside
other folders, or onto the desktop itself, but this gets messy and can be
dangerous. You see, dragging icons between folders in Chicago is just like
dragging files between directories in Windows 3.1's File Manager; you don't
really want to drag the Word 6.0 icon onto the desktop. If you do, you'll
have moved WINWORD.EXE from the WINWORD directory to the DESKTOP directory,
and it won't run. You also can move a copy by holding down the Control key as
you drag, but that gives you two separate WINWORD.EXE files.

What's a poor, confused, Chicago user to do?
Fortunately, Chicago's designers thought of that. They've provided a feature
called a link, that's functionally the same as OS/2 2.1's shadow. These
linked icons let you have as many entry points to files and programs as you
wish, and they can be placed in folders just as their parent icons can.
Moving a linked icon, or even deleting it, will have no effect on its parent.

This rich functionality lets you use the Chicago desktop exactly the way
you've used Program Manager in Windows 3.1. In fact, when Chicago installs
over an existing Windows 3.1 installation, it creates folders representing
all the existing Program Manager groups, and creates linked icons in those
folders for all the Program Manager icons. That makes life much much easier
for Windows 3.1 users. Once you find these folders, you can go straight to
work.

The Chicago prototype we saw uses this very powerful, folder-based metaphor
in some interesting ways. Instead of Windows 3.1's Control Panel, for
example, Chicago has a Controls folder, and the icons in it are the same ones
you're used to seeing in the Control Panel, plus some new ones. The prototype
has a Usability Test Settings control that lets you change how minimized
programs are represented, for instance.

Why would you want to change how minimized programs are represented? In
Windows 3.1, such programs are iconized. The icon representing the running
program is displayed on the Windows 3.1 desktop. But in Chicago, you can
place icons not only for programs but also for files and whatnot directly on
the desktop. How are you supposed to tell which icons represent running
programs, and which represent programs or files that will open up when you
click on 'em?

Instead of representing minimized programs as icons, Chicago's default is to
show them as 3-D panels at the bottom of the desktop window. Their location
and behavior are basically the same as in Windows 3.1, but they're visually
very different from the icons you move (or link) onto the desktop. With all
those icons and folders everywhere, it can be very tough to figure out where
things are located, especially when you start dealing with linked icons.
Chicago helps you with this by showing a set of flashing ``projection'' lines
that go from the icon to the open window (or vice-versa). This gives you a
visible indication of where the window comes from, and where it goes to.

What about the Recycle Bin and World Globe icons? Well, the former is the
long-awaited trash can, with a new face. Like the Macintosh trash can (and
unlike OS/2's Shredder), you can put things in Recycle Bin and get them back
out until you click on the Empty Trash menu item in Recyle Bin's Properties
menu. Then, whatever was in Recycle Bin doesn't get recycled at all, but goes
to that great landfill in the sky instead. Recycle Bin accepts folders as
well as icons.

The less obvious world globe icon represents the Network folder, Chicago's
link to the outside world. Double-clicking on the globe opens a window with
icons that represent whatever networks you have installed. Novell NetWare,
perhaps, or Microsoft Windows-for-Workgroups-compatible networking (built
into the Chicago prototype, either built-in or available in an add-on ``plus
pack'' in the shipping version). Opening one of those icons gives you a
window into that network, with icons representing the servers. Opening a
server gives you a window with folders representing shared directories. You
can manipulate the icons in those folders in the same way you use the icons
in other folders on your desktop. Go ahead and move them, copy them or even
create links.

Now that's a real improvement in the user interface, no more "assigned
drives'' and arbitrary limiting of network access to unused disk letters, no
more "connect net drive'' buttons and cryptic commands. Just click on the
icon and move it around. Curiously enough, this happens to be very similar to
the way IBM presents network resources in OS/2 2.1's Workplace Shell.

OLE! OLE!
This seems like a good point to back up a step and talk about the technology
underneath Chicago's folders and icons. In a word, that technology is OLE
(object linking and embedding), specifically OLE 2.0, the very same
technology that's used in the latest versions of Microsoft Word and Excel.
Aside from extending the basic linking-and-embedding technique used in OLE
1.0 to in-place editing, the new version provides some extremely interesting
capabilities, including OLE Automation and drag-and-drop support. OLE
Automation allows programs to expose their internal functions so that other
programs can take advantage of them. For instance, instead of using its own
calculation engine to handle tables, WinWord 6.0 can use Excel 5.0's
calculation engine. Drag-and-drop support means that applications can accept
the dropping of an icon onto them as a form of input. Drop a file onto the
Word icon and WinWord opens the file.

If this all sounds dull, consider that in Chicago the desktop itself is an
OLE 2.0 application!

What does this mean? For starters, it puts an end to years of trouble with
Microsoft's half-documented drag-and-drop interface in File Manager. There
will now be just one form of drag-and-drop: OLE 2.0 drag-and-drop. And any
application that supports it can play alongside the Chicago desktop as an
equal partner. This probably means we're going to see conveniences like the
ability to minimize a document in a word processor, drag the document's icon
onto the desktop, and in so doing save the file without ever going near
anything resembling a file selector dialog box (although one will still be
available). OLE automation on the Chicago desktop will finally make it
possible to write real batch files for Windows, and that's just the
beginning. As an OLE 2.0 application, the Chicago desktop will be fully
programmable from Visual Basic. Want a custom backup program? Just write a
Visual Basic application that manipulates the desktop's properties. Can you
spell

r - e - v - o - l - u - t - i - o - n - a - r - y - ?

But what about all my non-OLE 2.0 apps?
Okay, okay, we get a little carried away thinking about the OLE 2.0 desktop.
But how will Chicago work with today's applications?

Quite well, actually. The Chicago prototype cheerfully runs most DOS and
Windows 3.1 applications, though it has trouble with apps that need private
device drivers. The main problem will be with DOS and Windows programs that
make use of private protect-mode device drivers, particularly Windows 3.1
VxDs. If you have any such programs, you will need a true 32-bit Chicago
device driver for use with them. Fortunately, most NT device drivers should
work with Chicago as well.

Chicago also runs most NT applications. In this restricted sense you really
can think of Chicago as Windows NT "lite.'' General-purpose 32-bit
applications, such as the NT versions of MS Mail and Notepad, run just fine
from Chicago. There are specialized server and high-performance graphics
applications that won't run with Chicago, but the vast majority of
general-purpose 32-bit desktop applications won't know or care whether
they're running on Chicago or on NT. 

You will have trouble with apps that are very closely tied to a low-level
interface that Chicago doesn't support. Like OS/2 2.1 (and unlike NT),
Chicago virtualizes all device access for 16-bit DOS and Windows
applications, so the vast majority of those apps will work, even most
low-level disk utilities. Like NT, Chicago supports long filenames, but it
uses a very clever extension to the standard DOS File Allocation Table
directory structure. So most DOS programs will work fine with it; they will
simply see short versions of the file names.

It's also interesting at this point to look back at Chicago's command-line
interface, the one we saw briefly as Chicago booted. As we said then, it
looks like DOS, but isn't. Chicago's kernel is a true 32-bit multithreaded,
multitasking virtual memory operating system. Architecturally, it's something
of a cross between OS/2 2.1 and NT. Like OS/2, it's optimized for
Intel-architecture CPUs, and isn't portable to RISC machines or symmetric
multiprocessors. Like NT, it's built on a layered-architecture model that
makes development easier. Indeed, some of the layers, in particular most
device drivers and network transports, are exactly the same as in NT, so
Chicago should start its life with all of NT's device driver and network
transport support.

To command-line users, Chicago feels a lot like Windows NT, it looks like DOS
but acts like OS/2 (or UNIX). You can start programs, whether they're DOS,
Windows or NT/Chicago native 32-bit applications, from the command line. You
can run multiple command lines simultaneously, and the system will switch
among them preemptively. It also does this with the native 32-bit
applications, and with Virtual DOS Machines for DOS programs. As in Windows
NT, the Chicago prototype runs all 16-bit Windows applications in a single
Virtual DOS Machine. It doesn't appear to have a separate session capability
like OS/2 2.1.

Any resemblance is strictly coincidental
Have you noticed that we've been talking about OS/2 a lot? That's because the
feature set of Chicago is very, very close to that of OS/2 2.1. Both are true
32-bit operating systems optimized for desktop use, both have excellent
support for most DOS and Windows applications, and both have object-oriented
user interfaces. Naturally, there are differences. In our opinion, however,
they're almost all in Chicago's favor. IBM continues to dither and hedge over
whether OS/2 will support 32-bit Windows applications, and how it will do so.
Chicago, of course, is 32-bit Windows, and supports most NT applications (and
all Win32s applications) out of the box. 

Likewise, Chicago is bad news for the Apple Macintosh. For years now, the
Mac's been living on two basic advantages, a user interface that
intelligently uses folders, icons and long file names; and much easier setup.
Chicago's OLE 2.0-based user interface neatly matches the Macintosh desktop
in look-and-feel, and exceeds it in power. Chicago is also the first
Microsoft operating system designed for the new plug-and-play architecture,
which promises to make PC setup easy.

What About NT?
To understand the relationship between Chicago and NT, it's important to look
at which of NT's features are not provided (or planned for, to the best of
our knowlege) in the Chicago prototype. These include the New Technology File
System that lets NT provide fault-tolerant access to high-capacity disk
drives (important on file servers), the Service Control interface used by
Windows NT to provide back-end services and manage them across networks
(important on application servers), Windows NT's integrated security
(important in mission-critical applications) and network-wide management
features (ditto), full two-dimensional graphic transforms (important for
high-end CAD and other workstation-level graphics applications) and Unicode
support (important for international use). NT also remains the only system
Microsoft has announced that fully supports scaling up to RISC and
Multiprocessor systems.

NT is superior as a server, as a platform for high-end client/server
applications, such as database services, and for use as a UNIX replacement in
workstation applications. On the other hand, for traditional desktop use,
Chicago offers a lot of NT's bang in a much more reasonable package. 

How Can You Best Prepare yourself for Chicago?
Which brings us to our final point, what can you do today to prepare for
Chicago?

To begin with, you can start planning to upgrade your hardware. Chicago will
definitely require at least a 386 processor. It will also work better with a
386DX, 486 or Pentium than with a 386SX CPU. We don't know the memory
requirements. Some say 4MB, some say 8MB, but keep in mind that we don't
recommend less than 8MB for any version of Windows. We also suspect that
Chicago will run faster with secondary CPU cache memory than without, just as
Windows NT, OS/2 and Windows 3.1 benefit from it today (see the review in
this issue.)

Since Chicago will use Windows NT's 32-bit device drivers, a good way to
assure yourself of compatibility with Chicago is to make sure your system and
accessory cards are listed in the Windows NT Hardware Compatibility List.
Download it from the WINNT forum on CompuServe, or request it from Microsoft
sales.

Finally, we suggest that you consider investing in 32-bit versions of your
Windows programs as they become available. Any program that runs with the
Win32s subset libraries for Windows 3.1 (for example, MathCAD 4.0) can be run
as a native 32-bit application under Chicago or Windows NT. Buying Windows NT
programs for use with Chicago, on the other hand, doesn't make much sense,
unless you happen to have Windows NT (in which case, you might want to wait
for Cairo, the next verson of Windows NT, rather than switch to Chicago when
it first comes out).

A Final Word
What we've seen of the Chicago prototype impresses us. This looks like a very
substantial improvement over today's Windows in user-friendliness,
productivity and raw power. Bear in mind, though, that what we've just
described is the behavior of a prototype, and our look at it was not
authorized or facilitated in any way by Microsoft. The prototype may change,
and it probably will. Still, it looks like '94 will be a vintage year for
Windows users.

John D. Ruley is editor-at-large for WINDOWS Magazine.


Transmitted:  93-12-02 13:27:48 EST

