BJ> Since I plan to take the code forward with support 
 BJ> for long file names,
 BJ> etc., would anyone object to removing the 16-bit (DOS and OS/2)
 BJ> compiled versions from future development?

 WM> I would object, not on the grounds that I actually use 
 WM> or want to use those
 WM> versions, but because I doubt that it's really necessary. I myself took a
 WM> program that was originally 32-bit-only (MultiMail), and got it working
 WM> first on 64-bit systems, and then on 16-bit. The #ifdefs are really pretty
 WM> minor, and the 16-bit compatibility does not present an 
 WM> obstacle to future 
 WM> development. Plus, many of the adaptations for 64-bit are the same as are 
 WM> needed for 16-bit -- and you'll surely want 64-bit compatiblity for the 
 WM> future.

Well...  the 16-bit code may break with some of the porting attempts.  I
agree with you that judicious use of #ifdefs should solve the problem in a
"nice" way.  [I had been thinking about that after I posted the
message that started this discussion....]  And 32->64 bit issues are
also going to surface at some point in time, but I'm not planning on
directly addressing those type of issues at this time.  

Question: What platforms currently have a freely available 64 bit clean C
compiler?  Can that be turned into a cross-compiler with the compiler
hosted on a Linux or FreeBSD based system?

 WM> Maximus is larger and more complicated than MultiMail, and is written at a
 WM> lower level, with less attention to portability; so I 
 WM> have no doubt that it
 WM> will be more difficult to deal with. However, I suspect that (as with
 WM> MultiMail) much of the 16-bit- and 32-bit-specific code could be rewritten
 WM> in a cleaner way that will work on both. Library- and compiler-specific
 WM> code, as well as OS-specific code, is probably a much bigger issue than
 WM> 16-bit code per se.

Initially I'm not after rewriting more than is needed.  Max is already
segregated concering OS-specific code.  I am hoping that the OS specific
issues are (for the most part) already clean... and just need Unix based
implementations....

 WM> I would be happy to help, if I can, though I don't yet have even a working
 WM> compilation environment for Maximus.

Thanks.  And todate, I still don't have a clean working compilation
environment for Maximus -- at least using the methods Scott used.  I'm
still working on getting tools setup.  Looks like I'm going to have to
hybernate from this conference for a while till I get the development
environment setup.

I would appreciate help with code changes.   If you are interested, either
e-mail me through the source forge site, send fidonet netmail to Bob Jones
at 1:343/41 or leave me a logout message on my BBS (
telnet://tophat.darktech.org ) with your contact information.

 BJ> I'll also have to look at the option of 16-bit 
 BJ> version using the large
 BJ> (or similar) memory model,

 WM> I wouldn't consider any other model. There are no "far"s
in my code.

.....  In a review of a small amount of the existing Maximus
code and build scripts, it looks like all four (or five) segmented memory
models were supported for compiling the code -- at least at one point in
time....

 BJ> In any case, I believe the overlay 16-bit versions are on the way out
 BJ> for new code development due to the compilers I plan on using.

 WM> Chuck 'em.

Thanks for your input.

Bob Jones, 1:343/41


--- Maximus/2 3.01