🚀 go-pugleaf

Rebecca and Rowland <real-address-in-sig@flur.bltigibbet> wrote:

> That, I didn't know (what I'd heard on the subject had confused me
> greatly).  Having read some more stuff, it seems that what MacOS X will
> have is this:
> 
>     Hardware
> (PPC only; maybe
> only 603 and above)
>         |
>  Kernel and stuff
>   |            |
> Carbon       Yellow box (Rhapsody/OpenStep API sort of thing)
>   |
> transparent
> blue box

Very close, traditionally the diagrams are drawn from User layer down to
Hardware layer. The MacOS X diagrams that I have seen look like this;

   ----------------------Improved MacOS GUI-------------------
   |                |                     |                  |
Carbon          Yellow Box              Java            Max OS 8.x
   |                |                     |                  |
   ----------------Mac OS Core services (See later)-----------
                                |
                          Mach 3.0 Kernel
                                |
                Power PC Hardware (603 upwards)

> 
> In other words, Carbon and Yellow Box are peers, sat directly on top of
> the kernel (or whatever layer sits directly above the kernel), and the
> blue box sits on top of Carbon, *but* the user has no indication of
> this: it's transparent, and all applications (Carbon, blue box, and
> yellow box) appear to be running on equal terms: no mucking about with
> special blue box/yellow box windows.

The Blue box has been rename to the 'MacOS 8.x compatibility layer', and
runs in parallel to the other main systems (Java, Carbon and Yellow
Box). All systems have access to a core set of services for drawing,
printing and disk access etc.

The Carbon API's are for the most part close/identical to the current
API's that developers are using at this moment. What Apple has had to do
is make the functions re-entrant to allow for a system with pre-emptive
multitasking. Currently you cannot load two file-save dialogues at the
same time, the system would fall down. This is why some dialogues are
still modal and don't allow application switching in mid function. A
re-entrant version of the API would allow multiple copies of the
dialogue to be present on screen at the same time, and there fore allow
you to 'switch' to another application without problems.

In the process of rewriting the Carbon API Apple have discarded a great
number on legacy API's that were bogging down the system (QuickDraw GX,
DAL, PowerTalk AOCE etc.). They have also withdrawn certain access
methods that were dependent on 68k architecture (either physical or
emulated) and most of the file access API's have been rewritten.

> I *guess* that the big difference is that when an old MacOS application
> crashes, it only brings down the transparent blue box rather than the
> whole machine (or there wouldn't be much point to the snazzy new
> protected memory/pre-emptive multi-tasking scheme, would there?).  For
> the same reason, I *guess* that the pre-emptive multi-tasking will apply
> to the transparent blue box, so while applications running in it *think*
> they're running in a co-operative multi-tasking environment, they're
> actually only getting a certain fraction of `real' processor time, as
> allowed to the blue box as a whole by the OS kernel's pre-emptive
> multi-tasking mechanism.  Maybe.

This is along the lines I have heard. The OS 8.x Compatibility layer
will be as fragile (relatively) as the current version of OS 8. As far
as the larger system is concerned, the compatibility layer is like any
other application, and get's it fair share of the hardwares resources.
One possibility that does arrise, however, is that you could run
multiple copies of the compatibility layer, all of which would therefore
be protected from each other. This would not allow two OS 8 applications
to contact each other dynamically, but otherwise would stop a
compatibility layer cascade crash.

> > (A;though how long Apple will maintain it is
> > anybody's guess).
> 
> I reckon Apple will maintain it for a very long time.  Why not?  All
> Apple has to do is *maintain* it: no new development is needed, so the
> job is relatively cheap.  Apple can hardly miss the point that *one*
> reason people like Macs is that they last for ages and things `just
> work'.  If Apple suddenly dropped blue box from the MacOS, an awful lot
> of people would suddenly find that half their applications suddenly
> stopped working when they upgraded the OS, which means lots of people
> would decide that the best thing to do would be to *not* upgrade the OS,
> thus reducing Apple's sales and hence income and profits.

Since the compatibility layer does not have to advance, all new
development will happen on the Carbon or Yellow Box API, all Apple has
to do is get the compatibility layer 'right' the first time, and leave
it around until it becomes a problem to support. Apple has a good track
record for backwards compatibility. When everything went PPC all those
years back they wrote a 68040LC emulator to get the OS software working.
Apart for various speed tweaks that core is still present up to this
date. MacOS X will be completely PPC so this mechanism will be finally
dropped (apart from the fact it will be emulated in the 'compatibility
layer').



-- Kate

Catherine Ferris                kate@tycho.demon.co.uk
Director                        Tycho Consultants Limited

'This above all: to thine own self be true,
 And it must follow as the night the day
 Thou canst not then be false to any man.'   -- Hamlet