[net.micro.amiga] An OS for MAC, Amiga, AND ST!

rb@ccird1.UUCP (Rex Ballard) (05/08/86)

In article <1040@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
>In article <162@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>>In article <794@ccird2.UUCP> rb@ccird2.UUCP (Rex Ballard) writes:
>>>with translaters to go Atari-> Mac, and Atari -> Amiga.  Another possibility
>>>is that a third party such as DRI, MicroWare, Metacomco or ??? could come up
>>>with operating systems which would provide the best functionality of all 
>>>these machines and still be tranparent to application software.  Possible
>>>candidates include Concurrent GEMDOS (is it coming?), OS-9 68K,  Tripos, 
>>>GNU with VDI, Windows, UNIX, or ???.  At this point, it looks like OS-9 
>>>will be the first contender.
>
>I'm not at all convinced that OS-9 has much chance here.  And, I don't think
>it has anything to do with how good of an OS it is (unfortunately).  I would
>expect that GEM may have the best chance.  Why?  You can get off the
>shelf applications for GEM of the sort that most people are interested in.  

Funny, the only GEM-68K stuff I've seen is the stuff written for the ST.
I agree that the GEM part of GEMDOS could be a good "upper level" interface,
but GEM can be put over a number of other operating systems such as
MS-DOS, CP/M-86, CP/M-68K, and GEMDOS, why not OS-9?  GEM makes a good
supplement to any other OS, but that other OS does not HAVE to be GEMDOS.

Also, I have discovered that Micro-Ware also has a VDI for OS-9, supporting
bitmapped systems or CRTC type devices such as the 7220 or 63484.  My
main reason for suggesting that OS-9 would be the FIRST contender is that
it is already available, and people are doing the ports now.  Other candidates
might be better, but OS-9 is so easy to port.

>Languages are not applications.  Spreadsheets, Word processors, painting
>packages, DBMS programs, games, THOSE are applications.

How about things like Tandy's Desk-mate?  There are a number of applications
which were written for OS-9 (6809/CoCo) that could easily be ported to
OS-9 68K.  Many of these are even in public domain.

>People want to buy
>PeeCee DOS emulators for their machine, NOT OS-9, and certainly NOT because
>PeeCee DOS is a better OS. 

Actually, I'd rather see a PC-DOS -> 68K translator.  Even the emulators
are painfully slow.  Besides, there are no real graphics STANDARDS for
PeeCee DOS.  Which cards to you emulate, how do you keep the application
from "Capturing" a multi-tasking operating system.  You don't!

>GEM is not owned by one of the hardware
>manufacturers, who would probably want to keep you locked in to their
>hardware and not let their OS run on other machines. 

Neither is OS-9, in fact, the port is also being done by a third party
who is doing the port for all three machines.

>This is what will rule
>the MAC OS out.  TRIPOS would only have a chance if Amiga would consider
>selling Intuition (their graphics/windowing software) to go with TRIPOS.

I agree in part, actually, Metacompco (sp?) wrote most of the graphics
package, Amiga had to write the "Graphics BIOS", or drivers.

>This would actually be in Amiga's best interest, TRIPOS and INTUITION running
>on a ST would sell a lot of Amigas, both by expanding the attractiveness to
>developers of developing Amiga compatible packages, and by magnifying the
>performance and feature differences of Amigas vs STs.

Actually, it would work well for BOTH companies.  Those who wanted the
extra performance and features, and could afford it, would buy the Amiga.
Those who needed a less expensive machine for taking their work home at
night, could buy the ST.  If both machines could run the same applications,
you wouldn't have sheer numbers of ST owners trying to get their companies
to go with the lower performance machines.  Look at the Apple II vs. C-64
problems in the schools.  Most schools have Apple II's, many parents have
C-64's because they are cheap.  When teachers start assigning "Apple-only"
home-work, parents get upset.  The end result, "computer home-work" cannot
be assigned.  If parents were given a "vote" on the computers that schools
purchased, Apple would probably NOT be the winner.

>Otherwise, TRIPOS
>has the same problems as OS-9.  GNU might have a chance, because it's free.
>There is no way I am going to BUY an OS for my machine even if it is a great
>OS, if there are no (or almost no) applications that run under it.  If it's
>a FREE OS, (public domain or similar) THEN I might be inspired to run it on
>my machine.

You mean you wouldn't pay $60 for an operating system if you knew that you
could get several hundred applications off of Compuserve, net.sources, and
hundreds of BBS's?  You might still want to run Intuition or GEM at certain
times, but you COULD run OS-9 to feed data into the other OS.

>If Atari, Amiga, Apple or some Alternate manufacturer produces
>a machine that comes with OS-9 plain vanilla, and developers decide to get
>behind it, then OS-9 has a chance.  Until then, OS-9 is at the level of the
>8-bit CP/M systems, because there will be no applications that will use any
>graphics, windows, or other neat stuff that you need to sell applications
>these days.  I don't need OS-9 to run 'C', assemblers, Modula, Pascal, Lisp,
>Basic, Forth, etc. on my Amiga, or to be able to print stuff while I'm
>editing or compiling now do I?

No, but if you have a 'C' compiler for OS-9, you will be have access to
several hundred "free" programs.  When you got them compiled, you could
take the SAME FLOPPY, and plug it into the ST, the Amiga, and the MAC.  You
could even post the uuencoded binary, and we could ALL use the binary.
In addition, because the libraries are so similar to UNIX, you could also
compile most of what's in net.sources without modification.  Again, you
could post the binaries, share the floppies, ftp, and distribute, to anyone
with any of the three machines, along with any others that might come out
in the future.  You can't even do THAT with UNIX (which trap/vector is
to UNIX?, what are the DEFINES?, which "a.out" format is this?,...).

No, but if your company decides it wants to replace it's 1000 burned out
VT-100's with ST's, you won't be able to do work at home either.  As it is,
your children can't "turn in a floppy" from your Amiga, because the schools
only have Apples (which can be upgraded to accept OS-9 68K).  If your child
learns to use AppleWriter, that knowledge will be hard to practice on
MacWrite, AmigaWrite, or even Micro-Emacs.

Appearantly, there is a little confusion here.  Any OS is a collection of
modules.  Typically, you have the "drivers" or "BIOS" which convert hardware
dependancies into a uniformly contollable format, usually something very
simple, the "Kernal" which manages organization of storage, scheduling
of tasks, and semaphores.  In addition, there are often upper "layers"
such as GEM which can use a graphical BIOS, and the OS.  These "Graphical
Operating Systems" also come in "layers".  There is usually, the BIOS,
which determines how to get objects displayed, the "Graphics Kernal" which
lets graphics be put on the screen or even to disk for that matter, and
the VDI, which makes "widows, disks, and comm-lines" appear to the application
to be "generic, self contained devices".

In other words, if I say circle(fd,x,y,r), to a VDI device, the call
will be treated differently depending on which device "fd" describes.
To a disk, it might just write tokens, or postscript text, to the disk
file. To a window, it might draw what can be described in the window,
or draw it off screen, and let another part of the kernal Bit-Blt the
off screen image onto the "window".  The principles are no different
that those of UNIX, MS-DOS, or CP/M, even though the implementations
might be quite different.

One of the advantages of MS-DOS or OS-9 over CP/M or UNIX, is that device
drivers can be "mounted" rather than having to be linked into the kernal.
This means that if I want to add a hard disk, SCSI graphics display, or
ethernet, I only need a new driver, not a new BIOS or Kernal.  If I don't
need a driver any more, it doesn't eat up 20K of memory.

Ideally, if all the "componants" could be "Installed", I could change to
a new VDI that had features such as "rotate figure", or a Kernal, that
included Bi-directional pipes, or a driver that included "remote file
systems".

Before anyone starts flaming about how you would have to give up functionality,
look at "Inside Mac", "The GEM programmers guide", and the Amiga Kernal
manual.  Also, look at books on RT-11, CP/M, MS-DOS, UNIX, and OS-9.  When
you've gotten past the various different vocabulary differences, you will find
that such a "generic system" would actually be better than the "proprietary"
ones. 

Look at how effectively UNIX hides the "disk format" compared to
CP/M.  All we are doing when we add graphics to such systems is extending
the "stream of objects" to a wider range of objects than chars, words,
lines, paragraphs, pages, files, directories, devices.  On all of the
popular graphics systems, a "picture" is described as a stream of objects
or stream of packets of objects.  In addition to the above objects, we've
added lines, circles, arcs, rectangles, polygons, rounded rectangles, and
fonts, many of these could actually be broken down to simpler objects, or
extended into more complex ones.

Actually, there may be some real advantages to a generic operating system.
As terminology becomes uniform, interchange formats, editors, filters,
and applications will be easier to support, and become more general in
nature.  For example, I might be able to use a DBMS language like prolog,
or an associative data base, to produce a graph or structure chart,
use and editor similar to "MacProject" to move boxes and their connecting
lines to create a more readable chart, use another editor to add additional
boxes, feed the output to a compiler, and end up with an updated data base.

The hardware engineer three cubicles down, could use the same tools to
feed in his wiring list, edit the schematic, come up with printed circuit
board film, or gate-array programming logic, and get a bid over the phone.
He might even feed the "compiler output" to the CAD/CAM film plotter on site,
and have a negative by that afternoon.  Compare this to hand drawing the
circuit, "mousing in" the picture, and "hand analysing" the timing
characteristics.

The company president could use the same tools on his organizational chart.
The systems analyst could use the same tools on his DFD's.  The project
planner could use the same tools on his "critical path" charts.  The
archetect could use the same tools on his pluming blueprints.  The
civil engineer could use the same tools on his "traffic maps".  In fact,
anyone who "connects black boxes" could use the same tools.

More importantly, they could use information they already have
(compiler source, wiring lists, spreadsheet data, text, data in a
DBMS,...) rather than having to manually "mouse in" the information in
some abbreviated form.  If you think software is an investment, think
about the Gigabytes of DATA that currently has to be interpreted in the
reader's mind.  Don't you think that anyone would JUMP at the ability
to "see" things like bibliographies, wiring lists, maps, and even
source code that has been "hidden" for years?

On of the common "complaints" about UNIX is that there are not a lot
of "vertical market" applications for it.  In reality, there are more
than anyone could imagine.  The biggest problem is that they are also
so "trivial" to create, that they are usually found sitting in someone's
personal "bin" directory.  Often, it is simply a matter of taking an
existing shell script, and changing or adding a line or two to produce
a DBMS as powerful as DBASE-II.  One can do some really perverse things
by simply examining the shell portion of tools such as lorder, cflow,
tsort, lint, or diff.  Many of these tools have useful "byproducts" which
can be used by other tools as well.

The Mac/SmallTalk concept of One "super application" which will do "anything
you might want to do" to a particular "resource" or "object" is good in
theory, but then such a program, if it cannot produce by-products and
accept as input, by-products, is quite limited in it's usefulness. You
can't even imagine what I might want to do with your "does everything"
application.