earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/11/89)
The application startup code supplied with Aztec C v 3.6c in
crt0.o violates at least two of the compatibility guidelines in
TechNote 212, "The Joy of Being 32-Bit Clean."
Specifically:
a) It loads the address of the start of application code into a
data register, masks out the high byte, and then uses the
result as an address, which will not be valid under 32-bit
operating systems. The code should check for the presence
of StripAddress before doing this, and use it if present.
b) It reads resources from the application directly by "walking"
the resource map. This is bad because TN 212 implies that Apple
may change the format of resource files in the future. Resource
manager calls (e.g. GetResource) should be used to access the
contents of resource files.
c) It writes to memory imbedded in the middle of its code. This
is risky in terms of possible future memory protection systems
implemented by Apple. (Hi, Tim.)
I found this out when I was debugging one of my programs compiled
with Aztec C. I don't have the library source license, so I wrote my
own crt0.asm to fix it. This is a crucial piece of code to the
development system, and I am shocked that it is in such a primitive
state. Aztec has been a real good development system so far, and I am
assuming that this is an anomaly.
If you have Aztec C, and you care whether programs you compile
today will run under future 32-bit operating systems, then please
submit a bug report to Manx. If enough of us complain, they might
just fix it.
Earle R. Horton
Graduate Student. Programmer. God to my cats.