> 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).

 ac> Great.  That makes sense.  Probably far less work too.

That was the thought....  I'll know more as I dig into the code....

 > 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> The EMX code probably relies on the OS/2 API rather 
 ac> than EMX's POSIX libraries...

Ah....  A point I had not considered.  But any part of the OS/2 API that
Max uses should be able to be re-pointed to routines that are coded to run
under a Unix based system.  Ok, there may be more of this than I would
like.

 > 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.

 ac> Good luck.  ;-)  I had enough trouble trying to get SquishMail to compile.

Ok.  You are validating my reason to get the code to compile with open
watcom / DMake first.....

 > 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.

 ac> You could probably say the same about GNU Make.  ;-)

  Yes, now....  It wasn't the case back when Max was first
started.  The ports of GNU compilers and tools really didn't happen until
one could run 32 bit code on DOS / Windows based machines.....  

 ac> I should check out DMAKE again.  It's been about 7 years since I used it. 

I don't think it has changed in that time.  I believe Scott's archive of
DMake 4.0 is older than that.  So....  If you find a good pointer to DMake,
let me know.  If you need access, I have an old release of DMake 4.0 on my
BBS, in addition to the copy that shows up in the Max 3.02 source tree....

 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?

 ac> The code will be far easier to maintain if it's 32-bit 
 ac> clean.  The problem with much of the original MSGAPI 
 ac> was that it was littered with things like:

 ac> #ifndef __DOS__
 ac> #define farmalloc malloc
 ac> #define farread read
 ac> #define farfree free
 ac>   /* etc */
 ac> #define far
 ac> #endif

 ac>   char far *ptr = farmalloc(20);
 ac>   rc = farread(fd, ptr, 20);

 ac> or similar.  It's just ugly.  More importantly, if you 
 ac> forget to put "far" somewhere important, you can spend 
 ac> years tracking down lockups. It's better for your 
 ac> health just to yank out all of that stuff eventually.

Thanks for that reminder.  :(

It has been some time since I've had to deal with the C extensions that
were forced on us to use the interesting (segmented) memory model
(non-flat) that Intel used to extend the original 8088 / 8086 design..... 
Hmmmmm.....  We shall see how long I leave such items in the code.....

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01