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.  
 WG>  
 WG> Oh, you raise a VERY valid point, which quite frankly, 
 WG> hadn't crossed my mind. If I can't get the data 
 WG> structures compatible, I may just bump the version 
 WG> number. My goal *is* compatibility though.

We should be able to get a way to at least read the old structures. 
Writing the old structures on 64 bit systems might have some issues that I
expect will force a data structure update.  I expect it to only be a speed
issue using the old data structures on 32 bit platforms that aren't little
endian....

 WG> You raise an interesting idea with the OpenStep file 
 WG> numbering, though. FWIW, Windows also does something 
 WG> similar with endian-checking in OLE2 files; it writes 
 WG> "FEFF" into the OLE2 header -- if it gets read back as 
 WG> "FFFE", it flips the endianess of all scalar types in 
 WG> the data file before the application has at 'em. (I 
 WG> think -- I've only read OLE2 files from UNIX :)

I believe this is the same type of thing OpenStep did.  If I remember
correctly, at least some of the binary data files have a version number
burried in them, so we should be able to use that to use this in the
future....  We may need to introduce a new (sub) version number field so
that when the "version number" is bumped to the next number, it
indicates to kick in the compatiblity issues....  That way we don't every
raise the version number so high that we have problems determining byte
order by reading the old version number.....

 WG> If we *do* bump the version numbers, we can gain some 
 WG> speed, though, particularly on big-endian hardware. I 
 WG> don't know if we need it, though, I'll worry about 
 WG> 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....
 WG>  
 WG> Yeah -- one of the reasons I'm suggesting sticking with OpenWatcom at 
 WG> this point is because at least some of scooter's asm 
 WG> code is to deal with bugs in the compiler (oh joy), 
 WG> such as te ordering of function calls during the 
 WG> atexit() sequence. If you switch compilers (and 
 WG> hopefully OW doesn't count as much of a switch), you'll 
 WG> have to pick through it and figure out which code is 
 WG> for work (i.e. FOSSIL calls) and which is for other 
 WG> stuff. Yucky.

:(

Let's see...  FOSSIL (or serial port issues) calls, console read &
write, trapping interupts (such as control-c (DOS, OS/2, Win32 and Linux),
etc....  I may have to start a list and start sorting out what does
what....

 WG> As long as EMX can call the native OS/2 API (16 and 32 
 WG> bit with appropriate.. what do you guys call those.. 
 WG> plonks?), I think it would be possible to do a port 
 WG> (although GCC is not the most optimized compiler out there!)

Good question on what it is properly called.  I picked OS/2 because I could
use it as a user and it supported the application I wanted in a true
pre-emptive multi-tasking environment......  And I had hopes to see the
source code for my applications, so that they could be ported some day if /
when the need arised.  With the code running on Linux, that should be the
last major port I have to make.  Yes, there will be some minor issues
(including clock issues), but once running under Linux, the upgrade path to
future hardware should become clear....

 WG> FWIW, changes I've made which are GCC-specific, I've 
 WG> tried to tag as such,to differentiate from UNIX-
 WG> specific changes; originally planning to help a djgpp 
 WG> porter, but it would help an EMX porter just as well.

Good.  That should work.....  Did you take advantage of any EMX code that
Scott may have already had?  In looking through the source code, I spotted
items that looked like there was atleast an attempt at getting Maximus to
compile under the GNU EMX port.

 WG> As for the bison changes -- I used a version of bison 
 WG> from '95 and it built out of the box. Only when I went 
 WG> to my solaris box (with "real" yacc) did it whine. And 
 WG> for no really good reason, the grammar was creative but 
 WG> I couldn't spot anything blatantly illegal. All I did 
 WG> was add some intermediate productions to shut the thing 
 WG> up (essentially, syntatic sugar in compiler compiler 
 WG> code. Yay!)

Ok.  That's probably to be expected with using the real yacc vs using
bison.  I haven't had to deal with those issues, just remember hearing of
them....

Thanks for the note....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01