kim@amdahl.amdahl.com (Kim DeVaughn) (12/23/87)
In article <15998@watmath.waterloo.edu>, ccplumb@watmath.waterloo.edu (Colin Plumb) writes: > > In article <139@imagine.PAWL.RPI.EDU> lunge!jesup@beowulf.UUCP writes: > >In fact, the custom OS (called CAOS) was spec'ed by the person who wrote > >Exec, Karl Sassenrath. I have been told by Andy Finkel that CAOS actually > >somewhat existed on a Sage for a while, before it was scrapped. > > Weel, the question everyone's asking is: > Where do I get it? At a recent FAUG meeting, it was mentioned by "someone who should know", that there was still a lawsuit pending between CBM and the individual who left C-A holding the bag WRT the original Amiga OS (CAOS). [I don't believe this was Karl, and don't mean to imply that at all.] Since the issues are in the hands of lawyers, you *might* be able to get ahold of it near the year 9595 ... but I doubt it! Too bad! If it was as well done as Exec, Intuition, etc, it would've been a real killer ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
ccplumb@watmath.waterloo.edu (Colin Plumb) (01/04/88)
I've heard various people say that Intuition isn't "really" a device. Can someone describe how it's not? I seems that AmigaDOG opens it to provide a CLI window, at which point it opens the WB screen and the input.device and grabs sprite 0 and the copper. Is any of this forbidden to a device? How could (as I have heard) another six months of software development time have fixed this? Can it be retrofitted? More on the subject of deficient system software: In article <19975@amdahl> kim@amdahl.amdahl.com (Kim DeVaughn) writes: > In article <15998@watmath>, ccplumb@watmath.waterloo.edu (I) write: > >> Well, the question everyone's asking is: >> Where do I get it [caos]? > >At a recent FAUG meeting, it was mentioned by "someone who should know", >that there was still a lawsuit pending between CBM and the individual >who left C-A holding the bag WRT the original Amiga OS (CAOS). [I don't >believe this was Karl, and don't mean to imply that at all.] > >Since the issues are in the hands of lawyers, you *might* be able to get >ahold of it near the year 9595 ... but I doubt it! > >Too bad! If it was as well done as Exec, Intuition, etc, it would've been >a real killer ... My thoughts exactly. I've been exploring the innards of AmigaDOG and grown to loathe the BPTR. I've been dreaming about a replacement for it. Since the most complex thing AmigaDOG seems to do is overlays (please correct me if I'm terribly misguided - other than that, it seems to do less than Minix), which isn't *that* hard, I've also been toying with the idea of starting to consider perhaps beginning to contemplate the possibility of implementing this hypothetical DOS. Of course, I somehow suspect that Karl's spec is better than mine, and would dearly love to steal ideas. I don't really see how the lawyers could care who sees the spec. All parties concerned with the lawsuit know it intimately. Can anyone at C-A add some information, even to explain why you can't say anything? Failing that, does anyone know of an address for anyone not at C-A (Karl, maybe?) who could describe what it does, even in general terms? Resource tracking sounds like a job for Exec, not Caos, but I'd be fascinated to hear how to do it well at that level. Reading spec sheets is my idea of fun, and this would probably be much more intersting than most I've ploughed through. -- -Colin (ccplumb@watmath)
jimm@amiga.UUCP (Jim Mackraz) (01/05/88)
In article <16076@watmath.waterloo.edu> ccplumb@watmath.waterloo.edu (Colin Plumb) writes:
)I've heard various people say that Intuition isn't "really" a device.
)Can someone describe how it's not? I seems that AmigaDOG opens it to
)provide a CLI window, at which point it opens the WB screen and the
)input.device and grabs sprite 0 and the copper. Is any of this
)forbidden to a device? How could (as I have heard) another six months
)of software development time have fixed this? Can it be retrofitted?
)
)
)I've been exploring the innards of AmigaDOG and
)grown to loathe the BPTR. I've been dreaming about a replacement for
)it. Since the most complex thing AmigaDOG seems to do is overlays
)(please correct me if I'm terribly misguided - other than that, it
)seems to do less than Minix), which isn't *that* hard, I've also been
)toying with the idea of starting to consider perhaps beginning to
)contemplate the possibility of implementing this hypothetical DOS.
)
)
)Can anyone at C-A add some information, even to explain why you can't
)say anything?
) -Colin (ccplumb@watmath)
Well, I've got a little insight on this stuff.
Intuition is not a device, it is a library. You interface to it
by function calls, not by sending a request block. So there is
no standard way to choose whether you want to wait until it's done
or check later if it's done.
It also means that it was a hard job (a VERY hard job) in 1.2 to
go back and make the parts of it which weren't re-entrant safe
(since two tasks can be calling the functions at once).
You describe some of things that happen in rapid order, when Intuition
library is initialized and when the first workbench window is opened.
Very little of this has to do with being a library or device. It's more
of a synchronization and serialization issue, as I described.
I don't know if another six months would have mattered. I think it took
more than that to realize that a device might provide a better model.
It is very likely not retrofittable, at least not without breaking a lot
of programs. Now that the grunt work has been done and it is reasonably
safe, there isn't a lot to be gained making it a device, especially if you
ask the old "how many Amigas would it sell?" Don't expect it.
As for rewriting DOS, it's a concept, but here are two things to think about:
1) Lots of programs handle BPTRs, so even if you replace all of the BCPL
code, we'll be stuck with the screwy data structures.
2) Dos does a fair bit more than handle overlays. Among other things,
it is multi-threaded (more or less), handles volumes well, and is
no small piece of change, from a technical standpoint. The worst
parts (file handler) are being enhanced.
In all of these discussions, I sense that people don't appreciate the
"compatibility nightmare" that systems programmers must live with if
they are to provide backward compatibility. The real trick is to
provide support for a future that one cannot even imagine yet, which is
a fair step harder than supporting every creative thing you can think of.
The modules of the Amiga OS vary in the acheivement of this goal.
The ARP people are beginning to appreciate this kind of problem, as
the discussions on BIX illustrate.
Of course, if you think compatibility is not an issue, and that Minix or
anything like it is preferable, port away. I can't see that such a thing
makes sense for Commodore to spend time on. Clearly (now), the key
ingredient to a successful computer is application software. The world
doesn't need a lot of new DOS's, as I'm sure we'll be seeing again with
OS/2 (half-OS).
And for you CAOS lovers, Andy Finkel is reportedly writing an article
on CAOS, including its short length limit on path names and all. The
road not taken is often not worth lamenting.
So, we all live with what we've got, and the compatible enhancements
that there are time for. The ARP project has some promise to relieve
some of the nonsense, and Steve Beats' work on the file system will
make a big difference.
Try again in six months. Maybe I'll come in nights (hah) and make Intuition
a device for practice.
Cheers
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are NOT to be taken as Commodore official policy.peter@sugar.UUCP (Peter da Silva) (01/06/88)
> [CAOS] [Minix does more than AmigaDOS] ...
I have a perfectly weird idea.
How about just grabbing the filesystem part of Minix, writing an interface
package, and replacing AmigaDOS with that?
I don't want to do this, but if it was done right I'd certainly use it. Sing
hosannahs to the name of whoever did it. Maybe even pay money for it!
Am I getting hysterical or what?
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.dpvc@ur-tut.UUCP (Davide P. Cervone) (01/12/88)
In article <16076@watmath.waterloo.edu> ccplumb@watmath.waterloo.edu (Colin Plumb) writes: >I've heard various people say that Intuition isn't "really" a device. >Can someone describe how it's not? Intuition is not a device at all. It is a library, as Jimm pointed out. (A device and a Library have a lot in common, but they are not the same). A device has code that runs as a separate process; you use messages to send it information about what you want the device to do (e.g., you send the serial.device a Standard IO Packet when you want to read a character from the serial port). A library, on the other hand, contains routines that are called by the programs that use the library. These routines are run from the context of the CALLING program (as opposed to a device, where they are called from the device process) which means they must be reentrant. A library also can have a set of global variables that are common to ALL the programs that are calling it. For example, the Intuition library has it's own global variables: they are in fact the ones pointed to by IntuitionBase, and described in intuition/intuitionbase.h. When you open a library (or device), you get a pointer to its global data variables. The routines in a library are called by the library vector table, which is a jump table that sits in memory just below the library's global data. That's why the LVO variables are all negative, they point to memory IN FRONT OF the library pointer. In order to call an Intuition routine, you need the library base pointer, that's why AmigaDOS must open Intuition: to get access to OpenWindow(), etc. One thing that is unusual about Intuition is that it also runs part of its code as an input handler. That is, it runs in the context of the Input.Device. That's why things like ClickUpFront work, they are called by the input.device before it calls intuition. If you look in the Intuition manual, you will see a routine called Intuition() that takes an input event chain and returns a (modified) input chain. That's the routine that the input.device calls, just like it calls myHandler in ClickUpFront. Intuition() just does a LOT more than myHandler. If you've ever looked at the contents of an IntuiMessage, you'll see that the reply port is NULL. That is, there is NO INTUITION TASK TO SIGNAL. It's really "running" as part of the input device. Anyway, that's a whole different story. I don't have my manuals or notes with me, so I may have mis-remembered some of that, and some of it is only speculation anyway, but I think it is largely correct. I'd be interested in knowing if anyone has a different view of how Intuition works. Davide P. Cervone dpvc@tut.cc.rochester.edu dpvc@ur-tut.UUCP DPVC@UORDBV.BITNET P.S., if anyone want to verify this, you can probably do it the following way: set up a dummy input handler, and send a message to the input device to add your handler into the chain. See ClickUpFront or HeliosMouse for a sample of how to do this. You will need an Interrupt structure, as I recall. This is linked into the input device's list of handler that it calls. If I'm not mistaken, this is a standard exec LIST structure, so your interrupt structure will contain a NODE structure. You can use this to "peek" at what other routines will be called by the input device. You should be able to match these against the pointer to the Intuition() routine in intuition. You may have to get the actual address from the library jump tables, otherwise you may just get the pointer to the glue routine in the amiga.lib library. If anyone does this, let me know what you come up with.