BJ> The new future targets in this case would be Win32, 
 BJ> OS/2 (32-bit), Unix based (Linux, FreeBSD, maybe NeXT 
 BJ> Step / Open Step / Mac OS/X), and possibly a 32-bit 
 BJ> DOS extender (if someone is willing to help in this 
 BJ> area).

 ML> Particularly if the 32 bit DOS extender is involved.  
 ML> If the 32 bit extender is involved, it would be 
 ML> particularly interesting if the Rational 4G extender 
 ML> were to be used in that it's the same one which is used 
 ML> for the Btrieve 6.15 code which has upward portability 
 ML> into all the Pervasive stuff that sprang from it.  That 
 ML> all the way into LINUX now as well with SQL and all 
 ML> that too.

If any DOS extender is used, it would be what the code currently supports
or one that another developer steps forward to help with.  I do not have
the interest to deal with this area at this time.  

 ML> On another thought.. but related to what will come ..

 ML> ARRL is going forward with a complete press for Ham 
 ML> Radio WI-FI using 802.11 whatever.  Hams are *NOT* 
 ML> limited to the power levels of the public stuff,thus as 
 ML> it was noted tonight in the ARRL bulletin, the future 
 ML> for experimentation may really be "Hinternet" at 2400 
 ML> Mhz and a lot of exeperimenation.

Interesting comments.....  I know I've seen some folks discuss a Wi-Fi
network in my local area.  I didn't think they were taking advantage of HAM
licenses, so the "usage" of the devices is probably not
licensed.....  

 ML> They forecast a rather large offering of everything 
 ML> from pix, to video links, to massive audio channels and 
 ML> so on from the technical experimentation from this 
 ML> group.  If MAX is to be moved into the future for what 
 ML> it could become, then the first choice needs to be to 
 ML> line it up for handling far more than just messaging 
 ML> and message bases and files as well,no?

No.  If the Ham side wants to use BBS software / technology to support some
of there wishes, Max could become part of that.  While I would like to see
integration of Maximus message and file areas into http, https and/or ftp
protocol support, it is not what will happen to start with.  But, I would
lean in that direction after I get the initial BBS porting done.  Please
note that such extesions would probably be handled by add on programs /
procedures that are able to use the Maximus (and Squish) control files for
configuration information.

 ML> If compiler cross platform tools and techniques exist 
 ML> to do a really demonstrable job on things that had 
 ML> potential interfaces from common source code to all 
 ML> this .. that might really get interesting.  I guess the 
 ML> idea is not to paint one's self into a corner which is 
 ML> convenient, yet limited in future view!

The initial port will not be convenient....  And it may be uglier than I
would like....  I am still considering ideas on how best to take what is
there and add what is needed to allow it to be also used in a Unix based
system....

 ML> I for one would LOVE to see a simply defined and common 
 ML> source video code operation come out of this which 
 ML> could be used for other programming as well in cross 
 ML> platform development.  I need to learn as much as I can 
 ML> out of this and would be studying how this is done, 
 ML> even if I'm not good enough to actually be a part of 
 ML> the compilation and creation crew.  It'll be a real 
 ML> chance for me to learn from you and the crew.

Unfortunately, the video technology for Maximus is ANSI terminal based. 
Unix based systems have had a reasonable way to handle that for some time. 
See TERMCAP and NCURSES for more information....  These items have been
superceeded on "modern" systems by various GUI's, with X11 being
the primary GUI for most (but not all) Unix based systems....

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01