Hallo!

 ac> MS-DOS:

 ac> Watcom C++ 11.0c (16 & 32-bit) (free) (2000)
 ac> Borland C++ 3.1 (16-bit) (1992)
 ac> Turbo C++ 1.0 (free) (1991)

16-bit DOS is only working with smapi+msged. All other programs, especially
hpt, are written with a philosophy about allocating buffers and so on that
they won't work in 16-bit mode. As for 32-bit mode, only Watcom C++ and
DJGPP (you forgot that one) are relevant.

As for 16-bit Msged: I was making the last release with Borland C 3.1
(which is farily identical with Turbo C for what that matters), but I won't
make any DOS releases any further except for 32-bit ones done with DJGPP.
So if you want to become binary maintainer for DOS - just select the 16-bit
compiler that suits you.

 ac> FreeBSD:
 ac> gcc version 2.95 (free)
 ac> Linux:
 ac> gcc version 2.7.2 (free)


Well, both under FreeBSD and unter Linux you'll meet gcc 2.7, 2.8, 2.9, 3.0, 3.1.

 ac> OS/2 32-bit:

 ac> Borland C++ 1.0 (1993)
 ac> Watcom C++ 11.0c (2000) (free)
 ac> Metaware High C++ 3.2 (1995)

Only Watcom is relevant of these. The High C patches presumbably don't work
at all. But the most relevant of all is EMX, which you forgot.

 ac> And I don't use BeOS, so BeOS users will have to continue using 
 ac> the current SMAPI stream (ie. not my version).

It's fairly Unix. As well as Mac OS.

 ac> And I don't know about Mac OS X users.  Presumably they can use 
 ac> the FreeBSD port, but there may be endianness problems, at least for 
 ac> a while, unless they've already been fixed.

Presumably I am the only Mac OS X user at present :-). 6 months ago there
were no endianness problems - I once spent a month to fix them all. You can
share a message base between OSX and DOS without problems. Husky compiles
on OS X with gcc without major problems, though presently only with
DYNLIBS=0.


But there is one basic thing I want you to understand. The way you are 
talking about it, especially about the BeOs thing, makes me think you
pursue the wrong path to "portability2. Methinks you want to make a
list of compilers you support, and on other compilers you simply will say
the thing does not work. This is an approach to portability that is OK in
the Windows+DOS world, but that is utterly wrong in the Unix world, because
in the UNIX world, everytime that you think you have captured all compilers
and operating systems, a new user appears that digs out yet another
operating system and yet another compiler, and you will never manage to get
as many test systems as to cover them all. I, as mor myself, have been
using Husky not only on DOS, OS/2, Windows, Linux, FreeBSD, MacOS X, and
BeOS, but also on RS/6000 and DEC Workstations under AIX, Tru64 Unix,
NetBSD and on Solaris, i even did a test run on a S/390 mainframe running
64-bit-Linux under VMS, I compiled the stuff not only with gcc, but with
DEC CC (which gives faster code by factor 2), with IBM CC, and with beasts
you would never like to know, and I'll happily dig out a dozen more
operating environments where I would like to run a fido point or node, just
to prove that your way of getting portability is wrong.

The only way of getting portable code is to write code that, by the specs
(e.g. I recommend the book by Kernighan and Ritchie, 2nd Edition about ANSI
C) will work on any beast that calls itself computer and has a C compiler. 

If you encounter situations where you say "ah, with compiler X I need
that command, but with compiler Y I need that command - but I don't know
how to do that with compiler Z, so I will just say my program does not work
with compiler Z - then you are making an serious error.

All programs in the Husky suite (with the exception of a mailer, that
handles the phone line or TCP/IP, which admittedly is not part of any basic
standard - but that is one reason why Husky does not include a mailer) are
of a kind that the CAN be written in ANSI C. And I once spent really much
time to make sure, that Husky compiles on any compiler, and I would like to
see that this situation is not fundamentally changed.

I don't object if you will make ADDITIONALY functionatlity inside #ifdef
statements that only works on certain compiler. I understand that DLL
features are desirable, and as under Windows they cannot be realized
without fuddling the code without #ifdefs , then well, go ahead and insert
#ifdefs. But please almays make sure that it looks always like this:

#ifdef COMPILERA
code for compiiler A
#elif defined (COMPILERB)
code for compiler B
#else
default solution
#endif

The default solution may have less features then the compiler specific
solutions, e.g. simply no DLL support, or it may be slow and ugly, but the
program should compile and should do what it is supposed to so.

For example, to test if a file exists, you can use the "access"
function inside a #ifdef UNIX, and you can use FindFirst or something
inside a #ifdef WIN32, but obligatory you must use "fopen" and
check for the  return code checking" in the "#else" clause
to make sure that the code really works anywhere, because that is the only
portably way to do it.

If you don't believe that anything can be done without thinking about a
particular compiler, you are wrong. Anything that Husky requires can be
done without knowing a bit about the compiler. If you don't know how to do
that, look into the Husky porting guide I place somewhere inside huskybse,
and if the answer is not there, then ask. But never ever write any piece of
code without that #else fallback, never ever write anything that by
definition does not work on BeOS or on whatever OS that you don't use
yourself.

Husky right know works on any OS with any compiler (well, ideally - there
are always small bugs, when you try to first compile it on a new OS - but
these are bugs, Husky is not DESIGNED to be that way), and I am strongly
opposed against anything that would fundamentally change that situation.

Regards,
Tobias.

--- Msged/MAC 6.1.2