Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!oliveb!pyramid!voder!apple!rpd From: rpd@apple.UUCP (Rick Daley) Newsgroups: comp.sys.mac Subject: Re: Broken compilers Message-ID: <780@apple.UUCP> Date: Sun, 17-May-87 17:00:46 EDT Article-I.D.: apple.780 Posted: Sun May 17 17:00:46 1987 Date-Received: Mon, 18-May-87 03:40:24 EDT References: <949@batcomputer.tn.cornell.edu> <746@apple.UUCP> <1953@husc6.UUCP> <2003@husc6.UUCP> Organization: Apple Computer, Inc., Cupertino, USA Lines: 142 Keywords: IMPORTANT WARNING LIGHTSPEED C Summary: It's not that simple 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.