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.