By: Bob Arnson
Abstract: Or three or four. The quest for the biggest monitor follows the road to very expensive credit card bills. Does size really matter? By Bob Arnson.
Or three or four. The quest for the biggest monitor follows the road to
very expensive credit card bills. Does size really matter?
The one things geeks can never get enough of is pixels. Walk down the aisles
of many software development cube farms and you'll see 21-inch monitors running
at 1600×1200 resolution. Developers need a lot of desktop real estate, not so much for single large
windows but for lots of little different windows: code editors, resource
editors, form editors, watch windows, call stack windows, online documentation,
database monitors, and so forth are all commonly required -- usually
simultaneously -- while coding and debugging a typical application.
The traditional approach to getting more pixels is to grow out: get a bigger
monitor and if necessary, a video card capable of higher resolution. 21-inch
monitors are increasingly common on new systems and increasingly inexpensive, to
the point where it's possible to get a good quality 21-inch monitor for under
$1000. But even 21-inch monitors can hold only so many pixels. For
example, the 21-inch monitor on my system can handle up to 1600×1200 without a problem. My eyes, on the
other hand, are more comfortable at 1280×1024.
And that's the crux of the matter: There's an upper limit as to how many
pixels you can squeeze on a monitor comfortably, even with large monitors and
young eyes. It doesn't help that most video cards and monitors jump from 1280×1024
to 1600×1200 -- an almost 50 percent jump. The typical jump from 1024×768
to 1280×1024 is even worse: 67 percent more pixels. An intermediate jump
might help you get the number of pixels you need without eyestrain or headaches.
(The Matrox Millennium card on my home system supports 1152×864, which for
my eyes is just right on a 17-inch monitor.)
So if expanding out isn't the answer, what about expanding up or sideways?
Multiple monitors have been common on Macs and CAD workstations for years.
Microsoft finally added multiple-monitor support to Windows 98...but wait, you
say. Only a crazy person would use Windows 98 as a development platform. Well,
you might have a point. Though Windows 98 is more stable than Windows 95, it's
still not a system I'd recommend for development.
Nevertheless, Windows 98's multiple-monitor support is about as easy as it
gets. Adding a second monitor is usually as simple as plugging in the second
video card and hooking it up to a monitor. If drivers for the card on the
Windows 98 CD, they'll be automatically installed and you'll be able to
configure the second monitor from Display Properties. Sometimes you'll have to
get an updated driver from the manufacturer -- not all the video drivers on the
Windows 98 (or Windows 98 Second Edition, for that matter) CD are
Windows 98 goes to great lengths to ensure that applications stay usable with
multiple monitors. For example, the GetSystemMetrics API function returns the
dimensions of the primary monitor instead of the dimensions of the whole virtual
desktop covering all the monitors. (That's why you might have seen tooltips for
a window on a secondary monitor appearing on the primary monitor.) Windows
maximize within the monitor they're on, not over all monitors. You can even run
each monitor at its own resolution, color depth, and refresh rate.
Windows 2000 has multiple-monitor support too and it works much the same way
Windows 98's support works. Rumors that it was one of the features cut from
Windows 2000 after RC1 are false.
Until Windows 2000 ships (and maybe a service pack has been released), what
do you do? Windows NT 4.0 does not support multiple monitors. However, some
video card manufacturers have written drivers for Windows NT that support
multiple monitors. Diamond's Viper V330
supports multiple monitors under Windows NT, each running off one V330. Matrox's
drivers for its Millennium and Mystique lines also support
There are some drawbacks to multi-monitor support being solely in the driver
rather than in both the OS and the driver. On my personal system, which runs
Windows NT 4.0, service pack 4, and two Matrox Millennium cards, I frequently
see windows and dialog boxes appear in the middle of the virtual desktop -- in
other words, with the left half appearing on one monitor and the right half
appearing on the other. Maximized windows don't behave exactly the same as they
do under Windows 98 and Windows 2000. Matrox's driver has options to try to fix
those problems, but they're not always successful.
Because Windows NT doesn't support multiple monitors, the tricks Windows 98
and Windows 2000 use don't exist. For example, a call to GetSystemMetrics on
my system returns 2304×864 -- two monitors each at 1152×864 -- which
means that some things pop up split across the two monitors. Also, each monitor
must run the same resolution, color depth, and refresh rate.
Multi-monitor support under Windows NT is a hack, but I'll take it over beta
Windows 2000 or released Windows 98 any day.
For everyday e-mail and newsgroups tasks, two monitors work well. I run my
e-mail client on the right monitor and my browser on the left. Clicking a link
in an e-mail message opens the browser without obscuring the message. I run my
newsreader spread across both monitors -- the newsgroup list at the left and the
message list taking up the rest of the left monitor, with the message preview
pane taking up about three-quarters of the right monitor.
With development tools, it's even better because they tend to have more
docking and child windows that can be moved around. For example, using Delphi
5's desktop support, I fill both monitors. On the left monitor, I have the
Delphi toolbars and menu bar and a single edit window, with a docked Code
Explorer. On the right monitor, I have the Object Inspector, Delphi's component
palette, and the form I'm working on at the time. When I need to open a help
file or the Microsoft Developer Network Library, it stays over on the right
monitor, so it doesn't obscure the edit window. The debug desktop is set to
replace the Object Inspector with the Watch, Local Variables, and Call Stack
Though I hated Delphi's multiple top-level windows for a long time, they make
it easy to adapt to a multi-monitor environment.
There are two reasons I sought out multiple-monitor support under Windows NT:
Sometimes, size doesn't matter.
Server Response from: ETNASC01