Re: [Openexr-devel] Mac stuff

[Paul Schneider]

Forgot to CC the list, sorry...


Hi, Jo,


> It looks like I'm probably the only person here with an interest in 
> supporting OpenEXR on OS 9 :-).

OS 9 isn't officially supported by OpenEXR, but I'm interested in 
keeping it running on that platform as well. I know that some people 
have "unofficially" gotten the code to run on 9, and I tried to make 
the CFM project OS 9 compatible.


> It is interesting why it doesn't work, because I haven't yet come 
> across
> anything ( not platform dependant ) that just flat out won't work on OS
> 9. To my mind OS 9's big disadvantage all these years ( really, I mean
> classic Mac OS rather than simply OS 9 ) has been memory related 
> issues.

Actually, it is a memory-related issue: It looks like the problem is 
that IlmImfTest is running out of stack space on OS 9.  If you look at 
the HalfLut class, it has a 65K array of halves inside of it.  The 
testLut code creates a HalfLut object on the stack, which overflows the 
stack and causes it to spill into the heap.  With the heap corrupted 
like this, it's only a matter of time before the app dies, and it will 
most likely take the OS with it.  Stack-heap collisions are the most 
common cause of old-style OS 9 lockups in my experience, although 
they're usually caused by infinite recursion rather than large one-time 
stack allocations.

I was able to get IlmImfTest to run successfully on OS 9 by changing 
the stack size from 64 K to 128 K in the "PPC Target" tab in 
CodeWarrior.  I think that this is just an issue with the confidence 
test program.  We actually removed all of the very large stack-based 
arrays from the PowerPC build of the EXR library awhile ago, because 
they were causing problems with the PPC's fixed stack size.  If you're 
building a standalone application, the linker can figure out the 
maximum stack size you'll ever use, and just use that value all the 
time - I believe this is what gcc does, and CodeWarrior must be doing 
it on OS X as well, because IlmImfTest doesn't crash there.  However, 
if you're building a plug-in for a host application, you're constrained 
to the host app's stack size, which is usually 64 K.


> I could spend more time looking into this, but it'll take a little 
> while
> to figure out basically just what's going on. It's a pretty time
> consuming process. I don't know how much interest there is in OpenEXR 
> on
> OS 9 in any case, I won't really be sad if I end up making the OpenEXR
> output in my app just work on OS X and Windows. I must say I do
> appreciate the CFM Carbon project targets though, and as I intend to
> stick with CFM on OS X for the time being it would be a shame to see
> them go.

Hopefully, I've provided a solution.  If you don't want to change the 
stack size, you could change testLut.cpp to allocate the HalfLut in the 
heap using a std::auto_ptr - this is the approach we took in the core 
EXR library (see IlmImfPizCompressor.C).

The CFM targets will stick around for awhile, I think - many popular 
image processing programs are still CFM on the Mac.  I would think that 
more people are interested in CFM CodeWarrior projects than Mach-O 
CodeWarrior projects anyway - most Mach-O developers are using 
ProjectBuilder, as far as I'm aware.  Anyone care to correct me?

- Paul