home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.amiga.programmer:16153 comp.sys.amiga.hardware:20022
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!rutgers!cbmvax!spence
- From: spence@cbmvax.commodore.com (Spencer Shanson)
- Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
- Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
- Message-ID: <37189@cbmvax.commodore.com>
- Date: 21 Nov 92 00:04:55 GMT
- Organization: Commodore, West Chester, PA
- Lines: 29
-
- In article <Bxxr22.EoA@acsu.buffalo.edu> jcmurphy@acsu.buffalo.edu (Jeff Murphy) writes:
- >In article <37138@cbmvax.commodore.com> spence@cbmvax.commodore.com (Spencer Shanson) writes:
- >>In article <Bxvrpv.31E@acsu.buffalo.edu> jcmurphy@acsu.buffalo.edu (Jeff Murphy) writes:
- >>I am no UNIX expert, but is there a reason why the display side of a UNIX port
- >>could not sit on top of the graphics.library? After all, to bring up a UNIX
- >>screen would involve duplicating the work that has already gone into the A4000
- >>kickstart.
- >
- > Hmm. At best that would most likely be a kludge, since the graphics
- >library would have no way of knowing that it was working in a multi-user
- >environment and would therefore not know how to behave. Also: is the
- >graphics.library stand-alone... or does it depend upon other OS code that
- >might not be as easily ported?
-
- The graphics.library works fine in a multitasking system, so there is no
- problem. It relies on the exec, utility and layers libraries.
-
- >--
- >jcmurphy@acsu.buffalo.edu cit network installation and repair
- >opnsmurf@ubvms.cc.buffalo.edu standard disclaimers apply. sunyab
-
-
- --
- ---------------------------------------------------------------------------
- Spencer Shanson - Amiga Software Engineer | email: spence@commodore.COM
- | or uunet!cbmvax!spence
- All opinions expressed are my own, and do not | Bix: sshanson
- (necessarily) represent those of Commodore. | I want a tube of
- | orange Smarties!
-