BS>>> Okay.. A bigger one?

 MK>> No, but hopefully a more capable one.

 BS> Hmm.. you cuted to mutch, what bigger?

 MK> The brand spanking new Linux partition.  I hope to 
 MK> continue on with framebuffer development on there.  My 
 MK> goal is digital mapping all on the console with no need 
 MK> for a GUI.  I am a commandline freak and gosh darn 
 MK> proud of it!

Good that you are very comfortable with command line / console based stuff....

 BS> Well at some time, maximus should be reverse engeeriered to Windows.

 MK> Why?  Don't they already have a 32-bit DOS version?  
 MK> Doesn't OS/2 have a working Maximus version?  I think 
 MK> we're behind Linuxie speaking.  That's what needs to be 
 MK> dealt with first as far as I am concerned.  As for 
 MK> portability there are other, and perhaps even better, 
 MK> ways to deal with compatibility issues.

No, there is not a 32-bit DOS version.  The dos version is 16 bit with
overlays.  Now, there is a 32 bit version for OS/2 and a (beta?) 32-bit
version for Win32 environments.  But no one (to the best of my knowledge)
has compiled the full maximus source code for OS/2 or Win32 environments
since Scott released the GPL'ed version.  When we implement stuff for the
Linux / Unix version, we should not deliberately break OS/2 or Win32
stuff....  And we have implemented a fix or two that should be put in to an
OS/2 and/or Win32 compile (such as a FTSC standard correction in like the
time stamp Squish puts into a kludge line in messages).....  

 MK>> Same ccan be said for OS/2 except that Linux has
 MK>> trouble writing to OS/2 partitions.  All other 
 MK>> networking works great
 MK>> though.

 BS> Indeed.

 MK> Exactly!  I say we get on with it.

 MK>> Yep.  That and many other issues.  I want a Linuxed Maximus.
 MK>> Personally I don't care if it's portable to OS/2 or Windows.

 BS> It would be nice if it is..

 MK> It could be but I honestly believe we need a different 
 MK> approach to this issue.

Before implementing a different approach, please discuss your ideas here. 
Wes and I (and even Scott) have had at least a little discussion on this. 
And it has an impact on the code Wes has been working on to get both TCP/IP
connectivity support and Serial (modem) support that Wes has been working
on.  Basically, we need to get the interprocess communication working under
Unix / Linux, like it was running under OS/2.  [This is *not* DOS
think.....]  Mex needs fixing so that it can run under Linux / Unix.  And
yes, there are areas of the code that need working.  Maybe we can off load
something Wes was working on to you....

Basically, once a single Maximus BBS session is running properly (either
TCP/IP and/or Serial) we should be able to hook it up to something like
inetd and/or getty for spawning additional user sessions.  To do that, we
will need to virtualize the Sysop console.  Expanding on the maxpipe
support that was available under OS/2 might do this trick.....  And might
be usefull when ported back to OS/2 environment....  Now, Wes's initial
code for this may not support these types of ideas.....  But any change in
this area will impact what Wes has been working on and thinking about
concerning Maximus.

Just thoughts.....  Have you played with Max under OS/2 at all?

Yes, the multi-user aspect still needs to be worked on in the Linux / Unix
environment.  

I think we also still need to work on interprocess locking that squish uses
to keep only one process running at a given time.  This works under OS/2,
but I don't think we have it implemented yet under Linux / Unix.  This is
needed to allow Squish to safely be run from multiple starting points.....

I'm sure you can come up with additional items to discuss and ideas about
where we want to head....

Take care....

Bob Jones, 1:343/41

--- Maximus/2 3.01