Most Windows users will probably want to just use the pre-built binaries, However, if you want to build Mup yourself from source, download the Mup source package ftp://ftp.arkkra.com/pub/dos/mup67src.exe then execute it, to unpack all the Mup source files:
mup67src -dA directory called "mup-6.7" should be created. Go to that directory.
To compile with
you can use the included .bat files:
cd mup makemup cd ..\mupdisp makemupd
It may be possible to compile Mup with the Borland Turbo C/C++ MS-DOS compiler, but because of memory limitations it runs rather slowly and can only handle a few pages of input. The use of extended character sets (for letters with diacritical marks, etc) is turned off to save memory. If you want to turn it back on, remove the #ifndef __TURBOC__ line above the #define EXTCHAR.
To compile using the Borland Turbo C/C++ compiler for MS-DOS:
tcc -A -w-rch -w-pia -mh -Yo -a -G- -O -emup *.c We never got mupdisp to compile with the Borland compiler; it just doesn't have enough memory.
A Mup user has reported successfully compiling Mup with Visual C++, but reported that the /J option was needed.
You can look at the included Unix-style makefile for ideas on how to compile with other compilers. Mup can be compiled using the gcc compiler from http://gcc.gnu.org and the mingw libraries from http://www.mingw.org. Typically you can build in the mup directory with something like
gcc -o mup *.c -lmin the mkmupfnt directory with something like
gcc -o mkmupfnt mkmupfnt.cand in the mupmate directory with something like
i386-mingw32msvc-windres -i mupmate.rc -o icon.o g++ -o mupmate.exe -I../mup *.C -Wl,--subsystem,windows \ -lfltk -lfltk_images -lfltk_jpeg -lfltk_png -lfltk_z \ -lcomdlg32 -lgdi32 -luuid -lole32 -lws2_32You may need to add additional -I and -L options to point to where you have your header files and libraries. You will need the FLTK toolkit to build mupmate, available from http://www.fltk.org Get the latest version in the 1.1.x series (we built with 1.1.8); don't get from the 2.x series.
Once Mup is compiled, copy it to c:\mup or whatever directory you choose.
The directory needs to be in your PATH. If it is not in your PATH, edit
your autoexec.bat file to add
;c:\dos (or whichever directory you used) to your PATH command, then reboot.
You will need a way to view the Mup PostScript output. If you already have some means of viewing PostScript files, you can use that. If not, probably the best option is to use Ghostscript, which is free. You can download it from http://www.cs.wisc.edu/~ghost, or http://www.ghostscript.com/. You can get it pre-compiled and ready to run, or as source code.
If you choose not to use either Mupmate or Mupdisp,
you can view Mup output using a batch script something like this:
rem *** arrange so Ghostscript can find its files.
rem *** You may need to adjust path to match
rem *** where Ghostscript files are on your system
rem *** run Mup, adjust path to where you put Mup
c:\dos\mup %1 %2 %3 %4 %5 %6 %7 %8 %9 > mupxxx.tmp
rem *** run Ghostscript on the output of Mup.
rem *** adjust path to match where Ghostscript is on your system
if not errorlevel 1 c:\gs\gs mupxxx.tmp > mupgs.tmp
rem *** clean up temporary files
There is a batch script called "mupprnt.bat" that can be used to print
Mup files using Ghostscript. Edit the file if necessary, and
copy it to a directory in your PATH.
copy mupprnt.bat c:\mup\mupprnt.bat
Once you get Mup to compile successfully, try running it on the sample input files (sample.mup and star.mup). Verify that the output you get matches the corresponding sample output files (sample.ps and star.ps). You will find differences in some of the numbers, comments, timestamp, filenames, etc, but otherwise, in general the PostScript output you get should be similar to the sample output files provided, and if you display them, the results should look pretty much identical.
If Mup fails to run properly on the sample files, first make sure you are not in a write-protected folder. If you are, try copying the file to a folder that isn't write protected, and run it from there. If it still fails to run properly on the sample files, perhaps either your system has uncovered a bug that we haven't seen yet or your machine has some incompatibility. You can turn on debugging, by running with the -dN option, where N is a bitmap of debugging flags, to help pinpoint where bugs may be. The Mup User's Guide explains the bits of the debugging flags. If you get stuck, you may contact us email@example.com and we will try to help.
If you need to make any changes in order to get Mup to compile and run successfully, please let us know. If you find anything confusing, we'd like to know that too. We want Mup to be as solid, portable, useful, and easy to use as possible.
Also, please let us know if there are ways we can improve the Mup documentation.
If you receive messages beginning with "internal error" this usually indicates a program bug, so we'd like to know about them. An exception is when you get a message about being unable to allocate memory when there really isn't any memory left. If you get other internal errors, please send us a copy of an input file and any other information that may help us reproduce the problem, so we can try to fix it in the next Mup release.
Provide feedback (bugs reports, comments, suggestions, questions) to:firstname.lastname@example.org