BJ> You took a different approach that I was 
 BJ> considering for my initial work.  I didn't want to 
 BJ> try compiling on Linux until I had stuff compiling 
 BJ> under OS/2.....  
 WG>  
 WG> Thanks!  Not knowing anything about OS/2, and having one goal (get it 
 WG> running under Solaris) made my decision pretty easy. 
 WG> Linux was chosen as an intermediary port because I knew 
 WG> my Alpha CPU would be easier to get running with 
 WG> Maximus than a Sparc. The Alpha is little-endian, and 
 WG> under Linux it is tolerant of mis-aligned access 
 WG> (although that tolerance is VERY expensive, because it 
 WG> is via a hardware trap intercepted by the kernel and 
 WG> "adjusted" there).

Ok.  Concerning binary data structures and word alignment:  If we have to
change the datastructures that are written to the disk, we need to bump the
version number from 3.x to 4.0 and provide a process to upgrade the data
structures.  This is one of the reasons for the bumps from 1.x to 2.0 and
2.x to 3.0.  

As to the little/big endian issue, I'd like to see us adopt an idea similar
to how OpenStep 3.2 / 3.3 handles this.  As a user of that OS, it was very
nice that we coded our interface routine(s) once (using a NextStep/OpenStep
based library) that allowed us to just open stuff up between any the four
different types of supported systems (Motorol 68000 series, Intel I386 and
later series, HP RISC and Sun Sparc hardware).  I was running (in real
time) open binary TCP/IP connections between Motorol 68000 based, Intel
I386 based and HP RISC based hardware with out any further concern than
using the provided library routine.....  For backward compatiblity, I'll
have to see if current squish and maximus databases have a version number
burried in thier header.  If so, we should be able to do this fairly
easily.  On some systems, support the current data structures this way may
cost some CPU cycles, but in the long run, I think it is worth it to keep
compatibility and provide a modified, new data structure for new
implementations and provide an upgrade path to convert older databases to
get the faster speed.....

 BJ> After finding I had the user libraries for ncurses 
 BJ> installed, but not 
 BJ> the development support, I installed the additional 
 BJ> related ncurses packages....  After messing around 
 WG>  
 WG> I've added ncurses detection in configure to the TODO 
 WG> list. Actually, curses works too, but I don't think 
 WG> that's available under Linux.

Understand.  A minor issue, but something "regular" users that
aren't developers will eventually hit....

 BJ> that far along, I need to setup my user and group 
 BJ> for the bbs development, copy over a number of 
 BJ> files from the running (os/2 based) system and see 
 BJ> where things go.  
 WG>  
 WG> That will be a particularly interesting exercise, as 
 WG> I'm not sure all struct sizes have been correctly 
 WG> preserved. That said, since you're running Intel arch, 
 WG> you at least have a good chance of having the files 
 WG> work.

Thanks for the warning.  As mentioned above, if we have to break this (for
cross platform compatability / speed issues), I'd like to see use have an
upgrade migration path.  I have several years of squish message bases on
CD-ROM for archives.....

 WG> Also, you mind compiling a mex file under OS/2 and 
 WG> Linux, and seeing if the binary output is the same? 
 WG> (diff will tell you)

I would not expect it to be the same.  (1)  I believe the version of GCC
used for the OS/2 EMX port is an older compiler than we are using under
Linux.  Also, I'm not sure what the config differences will be.....  Need
to get the development stuff setup for EMX under OS/2.  I know I have an
alpha or beta version of the OpenWatcom compiler installed under OS/2.....

 BJ> With some slight configure file changes, we should be able to get 
 BJ> this to compile for OS/2 under the EMX setup (a 
 BJ> ported version of GCC with a runtime DLL that hooks 
 BJ> unix type system calls back to the OS/2 equivalent 
 BJ> code) and see if I can get this running there 
 BJ> also......  Could be interesting to have three 
 BJ> versions running in parallel (OS/2 max 3.01, OS/2 
 BJ> max 3.02b and Linux max 3.02b).....  It will be a 
 BJ> bit before I unleash the 3.02b versions (or later) 
 BJ> for live user testing here.  I notice there are 
 BJ> still some configuration issues to work out.....
 WG>  
 WG> Being able to run under all OSes properly will 
 WG> certainly be interesting, especially if they can share 
 WG> files like the squish bases, user records, etc. 

The sharing of the binary data files is just a manor of good planning.  It
worked under DOS, OS/2 and Win32, but those platforms have a common CPU
type.  A better example is how NeXTStep went to OpenStep and support binary
file compatibility over four different hardware platforms.  It can be done.
 Just takes some planning (and probably a version number at the beginning
of the file) that can be checked....

 WG> If you can come up with a replacement for the Dos* 
 WG> semaphore routines under OS/2 which interoperate with 
 WG> mine (in the unix directory), that would be super 
 WG> interesting, then we could synchronize things a little more safely.

I'll need to look at how BinkD and BinkleyXE handle the semephores.  I'm
assuming you are talking about the file semephores that squish uses to keep
other processes from clobbering files it is using while it is processing
(such as those in the outbound area being processed to be sent, but
shouldn't be sent yet).  Or do you mean some internal program semephores?  
If so, please point me to an example in the code so I can look at what you
are referencing.

 WG> As for porting via EMX -- If I were doing the OS/2 port 
 WG> (or back port, or whatever you want to call it), I'd 
 WG> run GNU Make, but native compilers. You can construct 
 WG> implicit makefile rules to run any compiler you want, I 
 WG> can help there. You'll also want to pull the 
 WG> makefile.mk files out of the CVS "attic" and see what 
 WG> objects are required for building under OS/2. For 
 WG> example, I left out all of the assembler code..

That's the advantage of EMX -- it is GCC running under OS/2.  My other
option is OpenWatcom under OS/2.  Max was compiled for DOS, OS/2 and Win32
using an older Watcom compiler, before it was turned into the free version
available now.  Unfortunately, some items were deleted to make the free
version.....  So, I'll probably hit some things when trying to go back to
that environment....

You're lex / YACC / BISON changes were proably needed, because I didn't
have the older versions of the program for OS/2.....

Take care......

Bob Jones, 1:343/41


--- Maximus/2 3.01