Hi,
This is a question on the structure of the image.  In my work to port 
Squeak to BeOS I've run into a problem where references to longAt(x) 
and longPutAt(x,y) fall outside valid memory addresses.  Ok, longAt() fetches 
an integer from the image, and longPutAt() replaces an integer in the stream.  
I get thru the initializeFirstFreeMemory routine ok and then once I get into 
the core of InitializeInterpreter I trap out when I try to execute:
 nilObj = longAt(((((char *) specialObjectsOop)) + 4) + (0 << 2));

under BeOS specialObjectsOop = 2094925144 (which is the value 
of bytesToShift).  bytesToShift = startOfMemory() - oldBaseAddr where
startOfMemory = 2147553280 under BeOS (0x80011000).
oldBaseAddr = 52628136 read from the image and matches the the value I get 
on the Mac.

My question is what is the meaning of bytesToShift and oldBaseAddr (both 
in the image header).  

And secondly, anyone see a quick fix for this off the top of their heads so 
I don't have to wade thru it myself? ;-)

Thanks for any sage advice or thoughts,
Serg

PS - FYI for anyone interested or who cares, right now I have an OO 
structure (BeOS requires everything to be an object/class (C++) pretty much...no way 
to write console apps or do printfs or whatever.)  The basic structure so far is:

 BApplication (base BeOS application class)
 - BWindow    (main BeOS style window)
 - BMenuBar   (main BeOS style menubar)
 - squeakImage     (a subclassed BFile object to manipulate the image file)
 - - squeakMemory  (a subclassed BMemoryIO object (OO-style 
non-dynamic malloc) to hold the contents of the file image and which has the operations 
on the image...such as initializeObjectMemory, etc. and corresponds to 
the "memory" buffer in the normal C code.)


All printfs and "error" statements are passed to a "printf" override 
method I've written that actually launches another OO standalone BeApp that 
displays windows and errors strings via the inherent Be-messaging protocol.  I 
felt this was more useful since other BeApps can use this.  I may redo 
this eventually to do dedicated error/printfs windows from within the app itself.
 
(everything else is stubbed out right now).

I plan on having an "interpreter" object which I've started on, but right 
now I need to get past debugging loading and initializing the image.  The 
nice thing about BeOS is that most things run in their own threads 
(windows, menubars, etc.) the downside is that  although things are portable to 
it; porting out of it will probably be difficult.  In any event, it's not 
a straight recompile ;-)  But BeOS is amazingly clean and fun to code in 
once you get past the learning curve.

S




-------------------------------------------------
VisualNewt Software: http://www.VisualNewt.com/
Maker of Newt'sPaper(tm) the Premier Newton(R)
MessagePad(tm) News Reader.

-----------Sent by BeOS--------------------------