Thu 2003-01-16 18:56, Bob Jones (1:343/41) wrote to Andrew Clarke:

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

Good.

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

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

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

The EMX code probably relies on the OS/2 API rather than EMX's POSIX libraries...

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

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

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

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

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

 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?

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

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

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

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

-- mail{at}ozzmosis.com

--- Msged/NT 6.1.1