BJ> Ok.  Concerning binary data structures and word 
 BJ> alignment:  If we have to change the datastructures 
 BJ> that are written to the disk, we need to bump the 
 BJ> version number from 3.x to 4.0 and provide a 
 BJ> process to upgrade the data structures.  This is 
 BJ> one of the reasons for the bumps from 1.x to 2.0 
 BJ> and 2.x to 3.0.  
 
Oh, you raise a VERY valid point, which quite frankly, hadn't crossed my
mind. If I can't get the data structures compatible, I may just bump the
version number. My goal *is* compatibility though.
 
You raise an interesting idea with the OpenStep file numbering, though.
FWIW, Windows also does something similar with endian-checking in OLE2
files; it writes "FEFF" into the OLE2 header -- if it gets read
back as "FFFE", it flips the endianess of all scalar types in the
data file before the application has at 'em. (I think -- I've only read
OLE2 files from UNIX :)
 
If we *do* bump the version numbers, we can gain some speed, though,
particularly on big-endian hardware. I don't know if we need it, though,
I'll worry about speed optimization when I've got everything else happy.  
 BJ> That's the advantage of EMX -- it is GCC running 
 BJ> under OS/2.  My other option is OpenWatcom under 
 BJ> OS/2.  Max was compiled for DOS, OS/2 and Win32 
 BJ> using an older Watcom compiler, before it was 
 BJ> turned into the free version available now.  
 BJ> Unfortunately, some items were deleted to make the 
 BJ> free version.....  So, I'll probably hit some 
 BJ> things when trying to go back to that 
 BJ> environment....
 
Yeah -- one of the reasons I'm suggesting sticking with OpenWatcom at this
point is because at least some of scooter's asm code is to deal with bugs
in the compiler (oh joy), such as te ordering of function calls during the
atexit() sequence. If you switch compilers (and hopefully OW doesn't count
as much of a switch), you'll have to pick through it and figure out which
code is for work (i.e. FOSSIL calls) and which is for other stuff. Yucky.
 
As long as EMX can call the native OS/2 API (16 and 32 bit with
appropriate.. what do you guys call those.. plonks?), I think it would be
possible to do a port (although GCC is not the most optimized compiler out
there!)
 
FWIW, changes I've made which are GCC-specific, I've tried to tag as
such,to differentiate from UNIX-specific changes; originally planning to
help a djgpp porter, but it would help an EMX porter just as well.
 
As for the bison changes -- I used a version of bison from '95 and it built
out of the box. Only when I went to my solaris box (with "real"
yacc) did it whine. And for no really good reason, the grammar was creative
but I couldn't spot anything blatantly illegal. All I did was add some
intermediate productions to shut the thing up (essentially, syntatic sugar
in compiler compiler code. Yay!)
 
Wes

--- Maximus/2 3.01