-=> Bob Jones wrote to All 16-bit (DOS) Max users <=-

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

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

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

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

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

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

 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.

Chuck 'em.

... This message released to public domain.  Use at your own risk.
--- MultiMail/Linux v0.44