file: MSDOS.TXT G. Moody 6 September 1989 Last revised: 24 May 1997 DB software installation notes for MS-DOS users Copyright (C) Massachusetts Institute of Technology 1997. All rights reserved. Standard installation --------------------- 1. From within the parent of this directory, type install and follow the instructions that are presented on-screen. This installs precompiled binaries generated from the sources in this directory. 2. To recompile the DB library, see `lib\makefile.dos'. Set the site-specific variables in that file as appropriate for your C or C++ compiler, then type make (or `nmake' if you are using a Microsoft C or C++ compiler.) This command compiles and installs the small and large memory model libraries for MS-DOS, and a large model MS Windows DLL. 3. To recompile any of the DB applications, see `app\makefile.dos'. As above, set the site-specific variables in that file as appropriate, then type make APPNAME.exe (or `nmake APPNAME.exe'), where APPNAME is the name of the application you wish to recompile. If you omit `APPNAME.exe', all of the applications are recompiled and installed in the directory specified by BINDIR in the file `app\makefile.dos'. 4. Other applications can be found in `convert', `examples', and `psd', and can be recompiled using the same technique as for those in `app'. Cross-compiling MS-DOS binaries under Linux ------------------------------------------- Most of the DB Software Package, with the exception of `sample' (see below) and `view', can be cross-compiled for MS-DOS while running Linux. To do this, first install the `gcc-dos' cross-compiler (it may be freely obtained from ftp://sunsite.unc.edu/pub/Linux/devel/msdos (get gcc-2.7.2.go32.tar.gz). Check the settings in `Makefile-dos-gcc', adjust them as necessary for your system, and type make -f Makefile-dos-gcc to cross-compile. When `make' finishes, follow the instructions it prints on-screen in order to transfer your binaries to MS-DOS and use them. Note that the binary DB library created this way can be linked with your own programs, provided that you compile them with either gcc-dos under Linux, or with djgpp (the native MS-DOS version of the GNU C/C++ compiler). The binary library format created by gcc is not compatible with any of the `.lib' formats used by most commercial C compilers for MS-DOS. (This is the reason why you cannot recompile `view' or `sample' using these compilers, since they require commercial libraries available only in various `.lib' formats.) An advantage of using gcc (whether as a cross-compiler under Linux, or as a native MS-DOS compiler) is that it produces 32-bit binaries that can make use of all available memory in your PC. (There is also the matter of cost and code quality -- gcc is free and usually produces faster, smaller executables than the commercial alternatives.) The (slight) disadvantage is that you need at least a 386SX to run these binaries, and you must use a DPMI server for memory management. MS-Windows (3.x, 95, and NT) all provide DPMI services to processes running in DOS windows. If you don't use any version of MS-Windows, you can load (in your config.sys) 386Max, QDPMI, or a freeware DPMI server such as CWSDPMI (included on this disk in ../msdos/cwsdpmi; for more information about these alternatives, visit http://www.delorie.com/djgpp/). Troubleshooting --------------- Many of the programs in the `app' directory must be compiled using the large memory model when using Borland C/C++ 4.x, which produces significantly larger executables than previous versions. If you are using Borland C/C++, you may wish to experiment with changing the compiler's optimization options (COFLAGS in `app\makefile.dos'). Do a `make clean' between experiments to force recompilation after changing COFLAGS. If you are using another compiler, you may be able to compile many of these programs using the small model, which generally results in somewhat smaller and faster executables. Although it is often not documented, MS-DOS C compilers (including those from Borland and Microsoft) generally accept the standard `/' directory separator in preprocessor `#include' statements. Treatment of `\' in the same context varies: most compilers treat it as a C escape character (UNIX, VMS, and Macintosh C compilers, as well as some MS-DOS compilers, are in this group), while others (including the popular MS-DOS compilers) treat it as a directory separator; the ANSI C specification allows implementation-dependent behavior for `\', but not for `/'. The most portable approach is therefore to use `/' as a directory separator in `#include' statements, which has been done in this package. If you find a C compiler for which this doesn't work, please send a note to the author. The software on this disk has been compiled successfully under MS-DOS versions 3.1, 3.2, 3.3, 4.0, 4.01, 5.0, 6.0, and 6.2, using Microsoft C versions 5.0, 5.1, 6.0, Microsoft C/C++ 7.0 and 8.0 (MS Visual C++ 1.0), Turbo C versions 2.0 and 2.01, Turbo C/C++ versions 1.01 and 3.0 (in ANSI C mode), and Borland C/C++ versions 3.1 and 4.0 (in ANSI C mode). (Not all combinations of operating systems and C compilers were tested.) You should not encounter compilation errors using any other ANSI C compiler; if you use another compiler, however, you should read the comments on USE_FREAD in `lib\signal.c' and consider defining USE_FREAD when compiling the DB library. If your compiler's standard C library does not include the (almost universally available) functions read(), write(), and fileno(), you must define USE_FREAD and USE_FWRITE to avoid linker errors. Program `sample' ---------------- If you have Microsoft C, Turbo C/C++, or Borland C/C++, and a Microstar Laboratories DAP 1200- or 2400-series analog interface board, you can instruct the `install' procedure to compile `sample' (a program for creating database records from analog signals, and for replaying them in analog form). To do so successfully, you must first have installed the Microstar `#include' files and DAP interface library on your system. Specifically, files `c_lib.c', `clock.h', and `ioutil.h' must be installed in your `include' directory, and file `cdapl.lib' must be installed in a directory in which libraries are found by your linker. (If you are using Microsoft C, copy `cdapl5.lib' from the Microstar software distribution diskette into your library directory, and rename it `cdapl.lib'.) Note: the function `set_params' in `app\sample.c' may be easily modified to accomodate newer models of the DAP boards, including the 800-, 2400e-, and 3200-series boards; `sample' should be usable with these boards, but it has not been tested with them. Please send a note to the author if you are able to use `sample' with any of these boards (or if you discover any incompatibilities). Compiling without `make' ------------------------ If you do not have a `make' program to manage the compilation and installation, you will need to perform those steps manually. In most cases the contents of the files named `makefile.dos' in each subdirectory of `db', together with your compiler's manuals, should give you enough information to figure out how to proceed. In outline, you need to create an `ecg' subdirectory in your `include' directory, install the *.h files from the `lib' directory there, build the DB library of object modules from the *.c files in `lib', and then compile each of the *.c files in `app' into a corresponding `.exe' executable file. With the exception of `plotstm' and `vsetup', each of the programs in `app' must be linked with the DB library (usually the last step in the compilation). Note that the programs `view' and `vsetup' (in `app') require the Microsoft C graphics library; this package includes precompiled copies of `view' and `vsetup', however (in the `bin' directory). As noted above, `sample' requires Microsoft, Turbo, or Borland C or C++, although it should be easy to port to other MS-DOS C environments. The programs `dbplot' and `dbtool' are UNIX-specific. Your comments are requested --------------------------- I would greatly appreciate a report of any problems you encounter in installing or using this software, if possible by e-mail to george@hstbme.mit.edu, or to: George B. Moody MIT Room 20A-113 Cambridge, MA 02139 USA