[net.micro.mac] Windows

tim@ISM780C.UUCP (Tim Smith) (12/07/85)

Note: I am adding net.micro.{mac,amiga,atari} to this, because this article
is really about portability between the Mac, the ST, and the Amiga.

[I am >>]
In article <-13400@brl-tgr.UUCP> jon@brl-tgr.UUCP writes:
>>> [compaint that Mac programmers are not writting portable code.
     Mentions that other machines have windows besides the Mac]
>> Are you saying my Mac programs should easily port to the Amiga, the Atari
>> 520ST, the Sun , V8 Unix ( if you have a BLIT ), System V ( if you have
>> a Teletype 5620 ), the IBM PC and Clones ( with GEM ), the AT&T PC7300,
>> and a few random Xerox machines?  They all have windows.
>>
>    Are you saying you want to write different programs to accomplish the
>same thing on all these machines?

Of course not.  What I mean is that just because N machines all 
support windows, or similar user interfaces, that does not mean 
that they are alike in other details of the operating system.  

Portability depends a lot on what the program does.  For example, 
a V8 program that makes heavy use of streams probably take a bit 
of work to run on a non V8 Unix.  Or a BSD program that depends 
on the 4.2 behaviour of signals might have problems.  Or look at 
all the problems with tty drivers and time functions between 
various Unix implementation.  These Unixes are a lot closer to 
each other than the Macintosh and the Amiga and the ST are!  

Good implementations of stdio can do a lot to help.  An example 
is the MegaMax implementation on the Mac.  If you attempt to 
printf or putchar on stdout, and you have not initialized 
QuickDraw and the window manager yet, it will notice this, do it 
for you, and create a window called "stdout", which looks a lot 
like a TTY in cooked mode.  For example, echoing, ^S, ^Q, and 
backspace work, and there is a way to kill the program with a key 
sequence.  ^D generated EOF.  So most programs that just want to 
interact with a user, and do some computation will port just 
fine.  I believe that the other Mac C systems do similar things.  
I don't know anout the ST and the Amiga, but if they don't 
already, they can certainly be made to.  

But when I write a program on the Mac, I want to use menues, 
graphics, dialogs, etc.  In short, I want to use the Mac 
interface.  If I had an ST or an Amiga, I would want to use their 
interfaces.  

It should be possible to develop a graphics library that is 
implementable on the Mac, Amiga, and ST, so that one could write 
portable programs that do graphics.  It would probably not fully 
utilize each machine, e.g., collision detection on the Amiga, but 
most programs would be able to use the library.  

I suppose one could also come up with menu libraries, window 
libraries, text libraries, etc, so that one could write portable 
programs that make use of the user interface available on the Mac 
and Amiga and ST.  

Until someone actually writes those libraries, I don't think one will
see a lot of portable code between these machines, except for programs
that use a simple command line user interface.

This specs for the above mentioned libraries could be a fun topic
to discuss ( certainly more interesting than curly braces and bouncing
balls! ).

Sounds like a job for an ANSI committee! :-)
-- 
Tim Smith       sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
			  ^
			  ^-- Not ISM780C, ignore the header!

briand@tekig4.UUCP (Brian Diehm) (12/10/85)

>Until someone actually writes those libraries, I don't think one will
>see a lot of portable code between these machines, except for programs
>that use a simple command line user interface.
>
>This specs for the above mentioned libraries could be a fun topic
>to discuss ( certainly more interesting than curly braces and bouncing
>balls! ).
>
>Sounds like a job for an ANSI committee! :-)

Unfortunately, the ANSI bureaucracy has done just that, and called the result
GKS.  If anything it serves only to show the futility of the effort.  In order
to be all things to all people in all ways, any such implementation must be
huge, slow, unwieldy, and generally unusable.  Guess what?  GKS is huge, slow,
unwieldy, and generally unusable.  It is appropriate only for those with
giant machines, the likes of which the world doesn't use much any more.

-Brian Diehm
Tektronix, Inc. (In this case, my opinions directly oppose the official Tek
                 policy - Tektronix is publicly committed to GKS, and must
                 be to support a portion of its customer base.  But really,
                 if you probe deep enough, some of the people in charge don't
                 really like it . . .)

papa@uscvax.UUCP (Marco Papa) (12/13/85)

> >Until someone actually writes those libraries, I don't think one will
> >see a lot of portable code between these machines, except for programs
> >that use a simple command line user interface.
> >

The new issue of AmigaWorld has an ad by Lattice that mentions the "Lattice
MacLibrary with more than sixty C functions for those who feel close to
the Mac".  Has anybody tried this?

Marco Papa
USC - Computer Science Dept.

UUCP:   ...!{decvax,ucbvax,hplabs}!sdcsvax!sdcrdcf!uscvax!papa
        ...!{allegra,trwrb,trwspp,ism780,cithep,oberon}!uscvax!papa
CSNET:  papa@usc-cse.csnet
ARPA:   papa%usc-cse@csnet-relay.arpa

skinner@saber.UUCP (Robert Skinner) (12/13/85)

> >Until someone actually writes those libraries, I don't think one will
> >see a lot of portable code between these machines, except for programs
> >that use a simple command line user interface.
> >
> >Sounds like a job for an ANSI committee! :-)
> 
> Unfortunately, the ANSI bureaucracy has done just that, and called the result
> GKS.  If anything it serves only to show the futility of the effort.  In order
> to be all things to all people in all ways, any such implementation must be
> huge, slow, unwieldy, and generally unusable.  Guess what?  GKS is huge, slow,
> unwieldy, and generally unusable.  It is appropriate only for those with
> giant machines, the likes of which the world doesn't use much any more.
> 
> -Brian Diehm

To the best of my knowledge, GKS was never intended to solve the
problems of windowing software.  It is Device Independent Graphics
Application Utility.  It supports output to multiple devices, in
multiple viewports and Graphic windows, but only from one process.  It
never attempts to address overlapping windows belonging to different
processes.  I suppose one could build a window manager on top of GKS
and treat different windows as different devices (workstations) and
using segments to restore obscured windows.  But that is just using a
good program badly.  It just doesn't apply.

ANSI X3H3 met in October to discuss the issues of display management
(such as window assignment and priority), color table arbitration
(which window controls the color table), and communication between
mouse, keyboard, and icons.  "We won't be standardizing the user
interface, but we'er looking to standardize ways the programmer tells
the operating system what he wants to happen on the screen", Peter
Bono.  I haven't heard the results of this meeting.

Every window manager has different syntax for defining a window,
moving it around, creating subordinate windows.  Whether a window is
updated implicity or explicitly after a change.  Where the graphics
information is stored that restores obscured windows (is it a BitBlt, or
a display-list?).  How the graphics information is defined is the job
of GKS, or CGI.  Both of those standards have features which are
applicable to the window problem, but they are not intended to be
solutions to it.


I have cross-posted this to net.graphics, I believe the discussion
should continue there.  I think it should be removed from net.lang.c.


------------------------------------------------------------------------------

Name:	Robert Skinner
Snail:	Saber Technology, 2381 Bering Drive, San Jose, California 95131
AT&T:	(408) 945-0518, or 945-9600 (mesg. only)
UUCP:	...{decvax,ucbvax}!decwrl!saber!skinner
	...{amd,ihnp4,ittvax}!saber!skinner

miner@ulowell.UUCP (Richard Miner) (12/15/85)

  There are window standards being worked on by ANSI! At the last X3H3
  meeting there was a small subgroup X3H3.win that spun of to start 
  specification of this standard. On of my Prof's here at U Lowell is
  on this committe. I will try and get a brain-dump from him, and post
  the status of this standard to the net.

  I must agree with previous note, GKS and CGI are NOT window standards,
  nor do they specifiy how to interface withh windows. CGI might be a 
  nice base for a window system/standard but GKS ugg to big, with to
  many layers (in most cases) to add Wind managment on top of. I speak
  after a summer of so a GKS implementation on top of a (pseudo)CGI.

					Rich Miner
					decvax!wanginst!ulowell!miner

  /**
   * From Ulowell - (soon to be) Home of a cheap GKS w/source.
   */

johnd@kvvax4.UUCP (John Dibble) (12/17/85)

> 
>   There are window standards being worked on by ANSI! At the last X3H3
>   meeting there was a small subgroup X3H3.win that spun of to start 
>   specification of this standard. On of my Prof's here at U Lowell is
>   on this committe. I will try and get a brain-dump from him, and post
>   the status of this standard to the net.
> 
>   I must agree with previous note, GKS and CGI are NOT window standards,
>   nor do they specifiy how to interface withh windows. CGI might be a 
>   nice base for a window system/standard but GKS ugg to big, with to
>   many layers (in most cases) to add Wind managment on top of. I speak
>   after a summer of so a GKS implementation on top of a (pseudo)CGI.
> 
> 					Rich Miner
> 					decvax!wanginst!ulowell!miner
> 
>   /**
>    * From Ulowell - (soon to be) Home of a cheap GKS w/source.
>    */

*** REPLACE THIS LINE WITH YOUR MESSAGE ***