> Since no one else stepped up to help with future Maximus source code 
 > development through the Source Forge site, I have.....

 ac> ...

 > After reviewing the source code on a Linux based system, it will take 
 > some work to get it to compile there.  I believe all make files will 
 > need editing due to the '\' vs '/' issue.

 ac> I'm interested in helping out, but what you propose 
 ac> requires more than just a few patches.  I suspect 
 ac> you'll have a lot of work ahead just translating the 
 ac> video and comms routines to Linux/FreeBSD.  Have you 
 ac> done this before?

Video may be interesting, but shouldn't be hard.  After all, Max can run in
both a console mode and remotely.  On a Unix based system, one should be
able to access a term cap (or similar definition) or use NCurses to
accomplish all needed items that Max is using for video.  One should be
able to get rid of any direct video hardware addressing in a Unix based
environment.  And I've had modems running in DOS, OS/2 and Unix based
environments.  So, the Comm port issues don't bug me either.  Grant it, I
am likely to have max run more as a "shell" under getty (for
dial-up / IP access) that relies on getty (or other routines that are part
of the OS's setup) to handle the modem stuff, possibly as a configuration
optional (vs Max totally controlling the "com" port).  So, I
don't expect it to be as hard as you think it will be.  There again,
remember, I have a two year goal for getting this running in the Unix based
environment.  Because Max is already setup for three environments (DOS,
OS/2 and Win32), the OS specific areas such as video should already be
segregated to specific sections of code and should allow for writing a
limited set of routines for a Unix (possibly two sets, one System V [Linux]
and one BSD) based system.  There are a number of options.  I'll look at
them as time 
permits and I get down to those aspects.  I'm still needing to spend time
getting my development enviornment setup.....  Also, there are references
to compiling the Max code with the EMX (i.e. GNU C compiler ported to
OS/2), so some things you mentioned may already be done.

 ac> Also, personally I'd dump DMAKE altogether.  Just write 
 ac> your own makefiles for GNU Make.  The less dependencies 
 ac> on things people don't have the better, eg. there is 
 ac> really no good reason why Scott Dudley couldn't have 
 ac> used Watcom's WMAKE for building the DOS/OS2/NT 
 ac> versions, instead of DMAKE.

I have been considering that.  Short term I am just interested in getting
the existing compilation to work.  Once I understand what is going on, I
may just do what you suggest.  On the other hand, DMAKE is released with
source code and claims support for all the environments Max currently
handles or I intend to extend it to (i.e. DOS, Win32, OS/2 and several
flavors of Unix).  So, the DMAKE solution is ALREADY a portable solution. 
I just need to see why the re-compile of the code failed....  And any
patches needed to DMAKE 4.0 to run the existing system could become part of
the Maximus build routine for a Unix environment, building DMAKE as the
first step in compiling the rest of the code....  As long as things
"work" end users shouldn't really care....  I doubt that all the
code currently compiled for Debian or other Linux releases use the standard
make setup.  Most probably do, but there will be exceptions....

 ac> Also, you should probably decide early on whether or 
 ac> not you want to drop support for the 16-bit DOS version 
 ac> of Maximus.

Well, aren't folks currently running the 16-bit DOS version of Maximus in
DOSEMU windows of Linux?  If so, for the short term, the 16-bit version is
still needed....  Long term, the DOS side is dead...  But why scrap support
of the 16-bit version if there is no cost to leaving the code in?

If I read the Open Watcom documentation right, I probably won't be
compiling versions of Max for use in an overlay environment, which in
itself will kill off one version of the 16-bit DOS version, unless someone
else steps up with a compilation environment to allow for such binaries to
be built.

Thanks expressing your interest in the future of the Maximus BBS code....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01