MultiMail compilation and installation procedure ================================================ These instructions assume that you're compiling MultiMail from source. For precompiled binaries, see the README files that accompany them instead. 1. Make sure any needed packages are installed -- In addition to the MultiMail package itself, you'll also need InfoZip or PKZIP (and/or LHA, ARJ, etc.) to uncompress the packets and compress the replies. InfoZip is available from: ftp://ftp.info-zip.org/pub/infozip/ PKZIP is at: ftp://ftp.pkware.com/ (PKZIP is the default for DOS; InfoZip is the default for other platforms.) The programs should be installed somewhere in the PATH; otherwise, the full path must be specified in ~/.mmailrc. To compile MultiMail, you'll need curses -- either ncurses, SysV curses (e.g., Solaris curses), or PDCurses. You can get ncurses from: ftp://dickey.his.com/ncurses/ PDCurses is available at: http://www.lightlink.com/hessling/PDCurses/ (If you're using Linux, odds are that you already have ncurses and InfoZip.) Also, bear in mind that MultiMail needs the C++ standard libraries, not just C. Note that although DJGPP 2.01 comes with PDCurses 2.2, I've made some changes that depend on 2.3. The 16-bit MS-DOS port also uses Ralf Brown's SPAWNO library: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html 2. Configure it (for compilation) -- Check the options and paths in the Makefile. If your curses header file is not in /usr/include/ncurses/curses.h, change CURS_INC and/or CURS_DIR as appropriate. (CURS_DIR may need to be set even if curses is installed in /usr/include/ncurses.) If the curses library is not in the linker's search path, specify the directory in CURS_LIB. 3. Compile MultiMail -- At the base directory, type: make 4. Run it -- Type: ./mm (For DOS, OS/2 or Win32, set the MMAIL or HOME variable, then run mm.) 5. (Optional:) Configure it (for end user) -- Edit the ~/.mmailrc file. (For DOS, OS/2 or Win32, mmail.rc.) 6. (Optional:) Install it system-wide -- Type: make install to install the manual and binary under /usr/local (requires root access). (This doesn't work in DOS, OS/2 or Win32.) See the man page (mmail.1) and README for more information. This package includes some example color schemes, in the "colors" directory. How or whether you install these is up to you. (If you want to use them, I suggest putting them in your "mmail" directory. To select one, alter the "ColorFile" keyword in .mmailrc to point to it.) Support for XCurses (PDCurses) ============================== When MultiMail is compiled with XCurses, you can use the X resource database to set certain startup options. Here are some example resources: MultiMail.normalFont: 9x15 MultiMail.boldFont: 9x15bold MultiMail.lines: 30 MultiMail.cols: 80 For details, see the PDCurses documentation. If you're using a non-X text editor with an XCurses version of MultiMail, it will work better if you set MultiMail's editor variable to "xterm -e $EDITOR" instead of just "$EDITOR" (the default). Be sure to try out the window resizing; the SIGWINCH handling in XCurses is much smoother than under an xterm (with ncurses or another implementation). You should use PDCurses beta 2.4 or later. Earlier versions don't support the use of a black (or dark grey) foreground color on a black background (the default color for the shadows, also found in many ANSI pics). Compile notes: Win32, MS-DOS, and OS/2 ====================================== In the MultiMail source, separate makefiles are provided for these ports. Makefile.dj - DJGPP (32-bit MS-DOS) Makefile.emx - EMX (32-bit OS/2) Makefile.rsx - RSX/NT (Win32) Makefile.bcc - Borland C++ (Win32) Makefile.tcc - Turbo C++ (16-bit MS-DOS) Edit the appropriate makefile to point to your installation of PDCurses, and compile with, e.g.: make -f Makefile.rsx The RSX/NT port is technically a port of the EMX OS/2 port. :-) To compile with RSX/NT, you first need a working curses library. There's no direct support for RSX/NT in PDCurses; but you can use the EMX support in the *OS/2* directory. Just edit "gccos2.mak" as appropriate, and compile it with the EMXVIDEO option, like so: make -f gccos2.mak EMXVIDEO=Y The compilation will fail once it gets to the demos, but the library will work OK. (You can alter the makefile to compile the demos, too.) Compile notes: Warnings to ignore ================================= In some environments, certain warnings may occur which you can safely ignore. Any others should probably be reported to me. With many versions of curses, warnings similar to this: /usr/include/curses.h:80: warning: abstract declarator used as declaration will appear for each file in the interfac/ section. These result from a conflict between the C++ definition of "bool" and the definition in curses.h. However, the operation of the compiled program is unaffected. More recent versions of curses avoid this by ifdef'ing the bool defintion. This one looks more serious: In file included from /opt/local/lib/g++-include/new:5, from main.cc:14: /opt/local/lib/g++-include/std/new.h:26: warning: declaration of `operator delete(void *)' throws different exceptions <internal>:26: warning: previous declaration here /opt/local/lib/g++-include/std/new.h:27: warning: declaration of `operator delete [](void *)' throws different exceptions <internal>:27: warning: previous declaration here But as far as I can tell, it too is harmless. Apparently it arises on systems with mismatched header files. Newer versions of gcc (2.7.2.3 or later?) give the following warning in an attempt to alert you to possible Y2K problems: qwk.cc: In method `void qwkreply::enterLetter(class letter_header &, const char *, int)': qwk.cc:696: warning: `%y' yields only last 2 digits of year (This refers to an invocation of strftime() with that parameter.) In this case, the two-digit year is mandated by the QWK format. Don't worry; it still works in 2000. :-) This warning will also appear for the OPX module. When I link under NetBSD, I get a warning that reads, in part, "tmpnam() may be used unsafely". However, it says this for *any* usage of the tmpnam() function; and its suggested substitute is not really relevant to the way MultiMail works. On an Alpha-based Red Hat 6.1 system, the Compaq C++ compiler spews out a lot of "conversion to integral type of smaller size could lose data" warnings. The conversions are as they should be. It also says "On command line, message tag noansi is invalid, ignored". I didn't actually put "noansi" on the command line, but I assume it's implied by "-Wall" or "-pedantic". And it complains that the destructors for base classes Win and ShadowedWin aren't virtual, which they shouldn't be. Finally, some versions of the system header files (notably, those included with Red Hat 6.0) define toupper() and tolower() as multi-statement macros, resulting in warnings like: misc.cc: In function `const char * findBaseName(const char *)': misc.cc:98: warning: ANSI C++ forbids braced-groups within expressions for every place where one of them is used. (What this means is that it _does_ work with gcc, but doesn't conform to strict ANSI.)