jon@cit-vax.arpa (Jonathan P. Leech) (11/28/85)
> > See net.micro.amiga and net.micro.atari for more info. It is no > > longer acceptable to assume that windows==macintosh (actually it > > never was, but you slobs got away with it). > > 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. > > Tim Smith > ihnp4!cithep!tim > ima!ism780!tim Are you saying you want to write different programs to accomplish the same thing on all these machines? -- Jon Leech (jon@cit-vax.arpa) __@/
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/29/85)
> Are you saying you want to write different programs to accomplish the > same thing on all these machines? Why not? Is that too idealistic or something?
henry@utzoo.UUCP (Henry Spencer) (12/01/85)
> > Are you saying you want to write different programs to accomplish the > > same thing on all these machines? > > Why not? Is that too idealistic or something? No, it's just too much (silly, unnecessary) work. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jdb@mordor.UUCP (John Bruner) (12/04/85)
>>> Are you saying you want to write different programs to accomplish the >>> same thing on all these machines? >> Why not? Is that too idealistic or something? >No, it's just too much (silly, unnecessary) work. The biggest difficulty that I see with regard to writing portable programs for many different window environments is the diverse system interfaces involved. I have always tried to code in a portable fashion (even to the extent that I still consider some factors which many people have long abandoned, like the number of significant characters in variable names). It isn't difficult to write a large number of useful programs in C which operate in a tty or "glass tty" environment. The standard I/O library is a useful common denominator (although not as common as it once was, unless you resist the temptation to use any of the enhancements that have been added in some implementations). I have no idea how to approach the corresponding task in a bit-mapped display environment. The user interfaces of two machines I use frequently -- a Sun and a Macintosh -- are significantly different. I haven't written window-oriented programs for the Sun, but I would expect its program interface to be significantly different from the Macintosh's Toolbox. The Macintosh event-driven interface has a significant impact upon the design of Macintosh software. (At least, it has an impact upon software that is designed to follow the Macintosh user interface guidelines.) I would expect the interfaces on the Amiga, Atari ST, IBM PC, Sun, BLIT, to have a similar effect on programs. It isn't clear to me how to encapsulate system-dependent code so that a program could be easily ported from -- say -- curses on an Ann Arbor Ambassador to a Macintosh. There is no stdio-like common denominator for this sort of environment. Going the opposite direction is even harder (I notice, for instance, that "dbxtool" only runs under Suntools, although one could conceive of an implementation for cursor-addressible terminals). I do agree with the stated goal that programs should be portable. It just isn't clear to me how to accomplish this when the output device isn't constrained to be compatible with a printing terminal or (perhaps) cursor-addressible CRT. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
WEBBER@red.rutgers.edu (Bob Webber) (12/05/85)
>I do agree with the stated goal that programs should be portable. >It just isn't clear to me how to accomplish this when the output >device isn't constrained to be compatible with a printing terminal >or (perhaps) cursor-addressible CRT. actually how to accomplish this is the issue that is addressed by most graphics standards. using a standard like GKS will go a long ways toward solving this problem, but, like everything, at a price that many won't want to pay. this is the crux of the portability issue: different architectures and operating systems make different cost/benefit assumptions and people that use the machines end up making similar assumptions only to get burned when they move to a different machine. actually, instead of making programs portable, people should make programming easier. --------------- BOB (webber@red.rutgers.edu ; topaz!webber) -------
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 ***