🚀 go-pugleaf

In article <342@apple.UUCP> dgold@apple.UUCP (David Goldsmith) writes:
>You are welcome to try this; however, you will find that 50% of the existing
>applications break, because they rely on features of the ROM above and
>beyond those documented in IM, including those which are not "features"
>but actually implementation details.

Well, the best estimates I've seen were that 50% of the existing
applications either broke under HFS, or just barely limped along under it,
so that new versions were neccessary.  The conversion process overall took
less than six months, and would have taken even less time if Apple had made
HFS more widely available for compatibility testing before its release.  So
this is not really an unsustainable burden.  Converting to HFS has, if
anything, accelerated the speed at which applications are produced; there
has been no perceptible drag.

A similar phenomenon might be associated with cleaning up the operating
system.  In addition, if the re-implementation had available source code,
there would be a lot of desire by developers to use it instead, accelerating
the conversion process.  I think you're overestimating the market power of
your ill-defined compatibility hacks.

Finally, this attitude seems like it must itself be rather a large drag on
OS improvement.  Why not just say that you will continue to be compatible
with correct applications?  If you can't re-implement, then you can't find
and implement faster and/or smaller algorithms, for instance.

>  Many commercial applications:
>- Rely on undocumented low memory variables which are in fact internal to
>  the ROM's implementation.  If it's not in IM, you're not supposed to do
>  anything but look at it when debugging.

There are low-memory globals defined and even recommended in the Tech Notes
that are not mentioned in Inside Macintosh.  So this is not quite true.
In any case, I don't see this as a problem.  If one developer could figure
out the low-memory global's use using the list in the Software Supplement,
then the re-implementer can figure it out and use it the same way.

>- Rely on behavior specific to the ROM's implementation rather than its
>  interface.

This is a serious programming error.  If someone does that, then tell them
to take a hike.  they are risking their future compatibility; you don't make
guarantees about future behavior of this sort, so for all they know you
could blow them away with the next System file.

>- Depend on values coming back in registers which are not part of a ROM
>  call's interface, or depend on the global state (such as current GrafPort)
>  being set a certain way which isn't part of the interface, and so on.
>  The 128K ROM has many places where it specifically sets a certain register
>  to a certain value before returning so a specific application won't break.

See previous answer.  This will also wind up presenting you problems when
you go to multitasking with the 68020 Mac.  Furthermore, the Mac
documentation has insisted that you not do this for a long time, and again,
the person is risking their future compatibility if they do it.  The future
compatibility notes released (twice) in the Software Supplement say so.

>- Some applications do things which are incorrect and just happen to work,
>  and changing one tiny thing makes them break.

There is no way that you can maintain compatibility with every case of doing
this and make any improvements to your OS.  Once again, I really think that
supporting incorrect applications is not a serious problem, because it
doesn't have to be done.  Anything which breaks under a re-implemented Mac
OS might just as easily break in the next Apple ROM release.

>Maintaining and enhancing the ROM is hard because so many applications go
>beyond IM in what they do.  Of course, if you'd rather have a machine which
>didn't run any of your existing software, implementing the ROMs would be a
>snap.  You're welcome to try.

I thought you said 50%?  If half of those are a result of semi-documented
low-memory globals, then the figure is more like 25%, and all those would be
applications which contained glaring errors.  Given that 50% of applications
broke under HFS, this does not seem like such a huge problem; particularly
if developers have access to the new system before its release to users.

Still, thanks for your quick and well-informed reply.  You brought up some
interesting points.  There are some things on the Mac that just can't be
done within the bounds of the future compatibility guidelines, Inside Mac,
the Software Supplement, and the Tech Notes.  I'd like to hear more
discussion of these things here.  To start off, has anyone discovered a way
of accessing globals at the interrupt level without using writes into code
resources (which may be marked read-only in a hypothetical memory-managed
Mac)?  There are tricks if you are running inside a completion routine
(putting the globals register in an unused field) or a vertical retrace task
(stick it in the VRQ element), both involving the semi-documented fact that
the address of the parameter block or retrace task will be in a0, but this
trick is not available in every case where code runs at the interrupt level.
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)