Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.sys.mac
Subject: Re: Multiple monitors (was: Xerox sues
Message-ID: <126900139@p.cs.uiuc.edu>
Date: 5 Jan 90 17:30:10 GMT
References: <2938@infmx.UUCP>
Lines: 31
Nf-ID: #R:infmx.UUCP:2938:p.cs.uiuc.edu:126900139:000:1475
Nf-From: p.cs.uiuc.edu!gillies    Jan  4 11:56:00 1990


In article rewing@Apple.COM writes:
> Essentially, the two (or more) monitors combine together to produce
> one *big* virtual space in which windows can be dragged to and fro, or
> even overlap from one screen to another (or more) without any
> complaints or special configuration from the application.

> Most PC setups in which I have seen multiple moniTors involve weird
> or custom situations in which the application must know how to deal
> with both screens.  

You must be joking.  Have you ever programmed the Mac for multiple
monitors?  It's no cakewalk.  I am just beginning to write code for
multiple monitors, and it seems to be the same old stupid story:

1.  Check if you have multiple monitors.  
2.  If so, then invoke all sorts of special-case software to deal with
them (like the size a window may zoom, and the way you paint the
desktop).

Furthermore, the mac provides no way to "simulate" multiple monitors
on a single monitor, so it's just one more way to make your code
undebuggable for the entire macintosh line.  In a more general sense,
Apple has found that by twiddling the software in each Macintosh model,
software companies must buy one of each for testing.  This must be
wonderful for sales, and for keeping small-scale developers from
entering the Mac-Software market.

Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,harvard}!uiucdcs!gillies