On Sat, 19 Oct 2002, Info MCL Digest wrote:

> ----------------------------------------------------------------------
>
> Date: Thu, 17 Oct 2002 23:21:58 -0700 (PDT)
> From: Erann Gat <gat@...>
> Subject: Why is native OSX so hard?
>
> I'm at a bit of a loss to understand why getting MCL to run in OSX native
> mode should be so hard given the existence of OpenMCL.  Can someone
> explain this to me?
>
> Erann Gat
> gat@...   gat <at> jpl.nasa.gov
>

I'd like too try to add to some of the points that Takehiko Abe made
in respose to Erann's question.  I don't know whether it'd be
appropriate (or even interesting) to go into a great deal of detail;
I'm familiar with some of the technical issues that have delayed a
native OSX MCL, and think that it's fair to characterize some of those
issues as hard problems.  If anyone finds any of this too vague to be
convincing, please let me know and I'll try to find a tactful way to
go into greater detail.

MCL relies - at a fairly deep, fundamental level - on low-level
OS services (mostly, the ability to handle exceptions that occur
during its own execution and the ability to control the protection of
its own memory pages.)  These OS services are provided by most (if not
all) mainstream general-purpose OSes (including MacOS [789X]), though
the details and level of support differ.  I think that it's fair to
say that the vast majority of Macintosh C[++] programs don't use
these facilities or don't push them very hard; MCL pushes them very
hard ...

To sidestep and review a bit: one of Apple's original goals in defining
the Carbon framework was to offer an OSX<->OS9 portability layer; one
of the tecnologies offered by OSX was and is support for running programs
that use traditional MacOS shared library technology (based on the "Code
Fragment Manager" (CFM)).  I don't think that it's a secret that Digitool's
been working on a CFM Carbon version of MCL for quite some time.

To return to the near-present: as recently as December 2000, Apple
didn't provide support for the MacOS Exception Manager in Carbon.  As
I understand it, some (presumably rather shrill) protests from Alice
were a signigicant factor in persuading Apple to correct this
oversight.  If I understand and recall correcty, support for the
Exception Manager in Carbon made it into MacOS X as of version 10.1
(September or October 2001.)

I believe (from having spent a few days stepping through machine code
in GDB) that there are some serious bugs in the OSX Carbon implementation
of the Exception Manager; once I understood the issues, I was able to
write small, self-contained C programs that demonstrate the problems,
and filed bug reports with Apple.  That was a few months ago; I still
hope to hear back from them, but haven't so far.

MCL pushes pretty hard on the exception handling primitives that the
OS provides; the OSX Carbon Exception Manager falls over in a strong
breeze, and if Apple's interested in fixing it they don't seem to have
communicated that interest too well.

[In at least one case that I know of, code used by OpenMCL was
incorporated into MCL to work around an Exception Manager problem.]

One might gather that I'm trying to blame the OSX Carbon Exception
Manager for all problems related to getting MCL running natively on
OSX.  That impression wouldn't be too far from the truth, but my
opinion's (at best) only partly correct.  I've had some involvement
in trying to resolve some Exception Manager-related issues, but
that involvement's been relatively minor and relatively recent.
I think that identifying and trying to work around those problems
has been hard, and tend to believe Alice when she characterizes
other, earlier problems the same way.

OpenMCL on OSX uses the exception handling facilities provided by the
Mach kernel (the BSD exception/signal facilities in OSX 10.1 were
broken and useless; the situation's much better in Jaguar.)  It is
very difficult to use those Mach primitives and callbacks from a CFM
application.  I'd like to eventually see MCL drop CFM (and OS9)
support and use the OpenMCL kernel; as recent traffic on this list
indicates, there are many users who believe OS9 Carbon support is
important (though that does seem to be a polarizing issue.)  Even if
Digitool thought that dropping OS9 compatibility was a desirable and
expedient means of getting an OSX product out the door (and I'm fairly
sure that they don't think that it's all that desirable), it would
take a while to do so (SAVE-APPLICATION knows a lot about CFM, the
native OSX C calling sequence is a little different from the CFM C
calling sequence ...) and it's not clear at this point that that
strategy would yield results faster than the strategy of trying to
find and work around remaining exception-handling bugs.

It's easy to look at this situation in hindsight and suggest ways
that things could have been done differently.  I'm not trying to
do that and hope that this doesn't come off that way.

I think that Erann's question deserved an answer (ideally, a more
concise one) and I hope that I've been able to at least give an
impression of the issues involved as I understand them.  Some people
might prefer to believe that Alice woke up lazy one day a few years
ago and hasn't quite gotten over it, or that this is part of a clever
Digitool plan to delay release of a product for which there seems to
be significant demand.  I suppose that they could be right, but I find
the explanation that Digitool gives - that they're working on an OSX
native MCL and that they hope to release it as soon as it's
releasable, and that difficult technical issues have delayed its
release so far - easier to believe.

I'm not an entirely neutral third party, but I'm not speaking on
behalf of any other party here either.

Gary Byers
gb@...