🚀 go-pugleaf

In article <2003@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes:
> In article <776@apple.UUCP> rpd@apple.UUCP (Rick Daley) writes:
> >In article <1995@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes:
> >> In article <6186@dartvax.UUCP> earleh@dartvax.UUCP (Earle R. Horton) writes:
> >> >In article <1953@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes:
> >> >> 
> >> >> All programs compiled with LightSpeed C WILL BREAK, GUARANTEED 100%,
> >> >> when Apple comes out with a 32 bit operating system for the Mac II or
> >> >Is this a general compiler problem, or is it, rather, specific to some
> >> >of the runtime libraries?
> >> 
> >> When I said "all" I meant "all."  Even if you don't even include MacTraps.
> >> The problem is in that little bit of code in segment 1 that gets prepended
> >> to all (that means every one without exception) applications.
> >
> >The claim that all LSC applications execute code that assumes a 24 bit
> >addressing model is simply not true.
> 
> Forgive me, you are right.  I was able to construct a small program
> which skipped over the code which BSET's handles.  Here is a program
> which will fail:
> 
> main()
> {
>       char *p = "test";
> }
> 
> Any application which has a CREL resource in it will fail.
> ...
> It's right there, at CODE0001+$78, BSET #7, (A3), where A3 is a handle
> to the code resource being loaded.

Ok, here's what's happening.  Your sample program does, in fact, run under
the A/UX Toolbox.  Here's why...  The LSC startup code does do the horrible
nasty bset instruction you described.  Then, later on, they probably do a bclr
instruction to unlock the block.  However, they never use the invalid address
they created by doing the first bset.  It turns out that addresses in the A/UX
heap will end up having their high bits clear (at least for now).  So, this
code will work under A/UX, even though it is not really 32-bit clean.
The only ways this could could fail would be:
        1) If something uses the screwy master pointer before the LSC code
    does the bclr.  I don't think that this can happen in this case.
	2) If a heap compaction occurs, and the offending block gets moved.
    Since LSC sets the wrong bit, the Memory Manager still considers the block
    to be relocatable.
        3) If a future implementation moves the heap to a high enough address
    such that the high bits are actually set.
Don't get the idea that I am defending the LSC code.  They should (and will,
according to an article posted recently) clean this code up.  In fact, it
was pointless of me to correct your original statement.  It just irritates
me when someone uses absolute-sounding statements that aren't correct.
I think it was the "100%" that got to me.  According to rumors floating on
the net, LSC actually does much worse things than this.  People have posted
claims that LSC produces self-modifying code.  This is not guaranteed to work
on any Mac II, even if you aren't running A/UX.  I hope that everyone out
there who owns LSC gives Think a call about this.

> Now I'm REALLY worried!  Surely you are doing more testing???
> Please don't tell me that this is typical of development on A/UX Toolbox...

I'd like to make a few points here...
	1) I suspect that you could test every LSC app available under A/UX
    without finding one that crashes as a result of this glitch.  As an aside,
    the "Scarab of RA!" shareware program which was recently posted to the net
    runs fine under the A/UX Toolbox.  The about box in this program says that
    it was developed with LSC.  This program takes up nearly 200K!
	2) Very early into this project, it was decided that A/UX would not
    support 24 bit addressing.  This means that the A/UX Toolbox cannot be
    highly compatible with "ill behaved" applications.  The idea is not that
    we are supporting a virtual Macintosh environment which will run all of
    your old mac binaries.  The main thrust of this product is to provide
    the ability to put a Macintosh user interface on UNIX programs.  Since
    it turned out to be easy to support mac binaries too, we did it.
    Unfortunately, most commercial applications are not 32 bit clean.  These
    apps will have to be cleaned up before they will run under A/UX.  The
    changes tend to be quite trivial, although a few programmers really
    bought into the whole 24 bit idea.  Anyway, the point of my mumblings
    is that we are testing mainly to see if the A/UX Toolbox works the way
    it should, not to try to support every slimy trick a programmer can get
    away with on the mac.  Therefore, we do most of our testing using special
    test software, not commercial products.
	3) We are hoping that developers will respond to the A/UX Toolbox
    by releasing new versions of their software that work cleanly.  This
    finally gives them incentive and a testing vehicle to follow more of
    the advice given in various Tech notes.  If this happens, everyone
    wins.  When Apple finally produces a version of the native mac OS that
    uses 32 bit addressing, hopefully compatibility with cruel apps will be
    less of an issue.  Users will win by getting software that is designed,
    rather that taped together.  An awful lot of the work involved in
    producing new versions of system files and ROMs is dealing with
    backwards-compatibility with screwy apps.

All this talk about A/UX compatibility has probably got people wondering.
Unfortunately, the documentation for the A/UX Toolbox is still in alpha
draft.  When that stabilizes, I will (if the powers that be say ok) post at
least the section on compatibility.  Until then, I can give a few hints...
	1) The main problem will definitely be 24-bit assumptions.  Like the
    Tech notes say, don't use bset instead of HLock.  Also, don't use data
    structures that pack pointers and bytes into a common 32 bit field.
    Finally, if you ever want to use Lo3Bytes to mask flag bits off a
    dereferenced handle, use the new StripAddress trap instead.
	2) Also like the Tech notes say, don't use privileged instructions.
    If you want to look at the sr, use "move ccr" instructions, not "move sr".
	3) Don't mess with the hardware yourself.  A/UX could not be robust
    if applications were allowed arbitrary access to hardware.
	4) Try to avoid playing around in the data structures described in
    inside Macintosh.  Most of them are supported, but some won't be.
    Example:  The event queue is manipulated by the A/UX kernel and will
    not be directly accessible to an application.
	5) You will be able to check a flag to see if you are executing
    under A/UX.  If you really want to save some time by breaking the above
    rules, you can still run (slower) under A/UX by doing things cleanly
    only when you need to.
	6) I have yet to see a program produced by MacApp that failed to run
    under the A/UX Toolbox. (As long as the built-in debugger is not used)
	7) If anyone has software that they would like to have tested under
    A/UX, I'm willing to give it a try.  If I get buried with requests, I'll
    have to give it up.  Just send me a copy and I'll try it.  Please note:
	    a) Please try to test it on a generic Mac II first.
	    b) If you want me to destroy my copy after testing, say so.
	    c) If it does something weird that you think might cause trouble,
	tell me.  That will save me the trouble of trying to figure out what
	is happening.
	    d) Please give me a full e-mail address.  This Vax is pretty messed
	up and can't deal with foo@bar stuff.
	    e) If you don't trust e-mail, send me a disk.  If you want it back,
	include a pre-paid self-addressed whatchamacallit.
	    f) My e-mail address is:
		rpd@apple.UUCP
		    or
		...!ucbvax!sun!apple!rpd
	    g) My US mail address is:
		Rick Daley
		Apple Computer
		MS 27 AJ
		10500 North DeAnza
		Cupertino, CA 95014

Since some of the above is quite opinionated, I'll suspend my usual distaste
for disclaimers...
The above opinions are mine, not necessarily Apple's.
Apple will just have to get their own.