-*- Text -*- $Header$ MIT Scheme/DOS Alpha Release Note --------------------------------- Copyright (c) 1992 Massachusetts Institute of Technology This material was developed by the Scheme project at the Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science. Permission to copy this document, to redistribute it, and to use it for any purpose is granted, subject to certain restrictions and understandings. Please read the standard Scheme copyright notice at the beginning of every Scheme source file. Introduction ------------ This release note describes the DOS version of MIT Scheme for Intel i386+ processors. MIT Scheme is an interactive programming environment developed at the Artificial Intelligence Laboratory at MIT. The system implements most of the Scheme programming language as specified by the IEEE and ANSI Scheme standards and the Revised^N Reports on Scheme. The only incompatibility with the IEEE standard is that in this implementation #f (the false object) and '() (the empty list) are currently the same object, while the standard requires them to be distinct. Future releases may be compatible with the standard. Versions of this system run on Unix, VMS, DOS, HP9000s200 p-systems, and processors such as the MC680x0, i386+, HP-PA, Mips, Sparc, etc., and some of these versions have been widely distributed. It is used by many in the research and academic communities. This is the first alpha release of the DOS version. In fact, this release is preliminary in two ways: 1) the DOS port originated from a yet unreleased version of the system; 2) the port was freshly completed and have been used neither intensively nor extensively. Also, similar to all releases of MIT Scheme software, we assume no warranties or commitment to support the code. What this means is that although your comments and bug reports are certainly solicited and most welcome (more on how to do that later), we make no guarantees that they will be acted on quickly, if at all. Use this software at your own risk. The DOS version requires at least a 386sx. It should run under all versions of DOS by Microsoft and others since 3.30, although it has only been tested under MS-DOS 5.0 . It will run as a DOS application under Microsoft Windows 3.0 and 3.1 . Parts of the system were compiled using the Zortech C++ compiler Version 3.0r4 using their DOSX 32-bit extender, and accordingly their bugs and quirks are inherited. We include in this release executables for almost all parts of the system, in addition to all of the source code. Using these, you can regenerate all of the auxiliary files as you need them. More on how to do this and the disk requirements later. The distribution is done via ZIP format files. We provide a public-domain unzip program for your convenience. Since the DOS version inherits heavily from its Unix counterpart, most of the documentation that applies to the Unix version is also usable for the DOS version. In fact, most software developed for use on the Unix version will run on DOS as is. Description ----------- The MIT Scheme system is divided into subsystems described below. They are listed along with the ZIP files they are distributed in, what they expand to, and the usual directory structure they fall under. Assume in the following that $SCHEME is the root directory (on our system it is usually c:\scheme). This brief description covers all of the directory hierarchy; only part of the hierarchy may be present, depending on what part of the distribution you install. Under $SCHEME/bin: SCHEME.ZIP -> SCHEME.EXE (executable) BCHSCHEME.ZIP -> BCHSCHEME.EXE (executable) $SCHEME/bin contains the C executables for the microcode. SCHEME.EXE emulates a microcode interpreter for the SCode, the intermediate opcodes used by MIT Scheme. A lot of the primitives and all of the operating system interface is provided here. BCHSCHEME.EXE is a version of SCHEME.EXE that uses a disk file as it's second heap in it's copying garbage collector, and is useful on systems without a lot of RAM. One of the two executables is necessary to run any version of the system. Under $SCHEME/lib: 387RUN.ZIP -> RUNTIME.COM (runtime band) NO387RUN.ZIP -> RUNTIME.COM (runtime band) RUNTIME.COM is a binary dump (a "band", or a saved world image) of the runtime system. This is the runtime environment, written in Scheme (and compiled to native 386 code), providing the read-eval-print loop and a rich set of runtime utilities. The version in 387RUN.ZIP contains floating point instructions, so you need to have a 387, 487, or a 486 (not an SX!) to use it. Use the one in NO387RUN.ZIP if you don't have a floating point coprocessor. You need at least one of the two runtime system bands to use Scheme. Under $SCHEME/scmdbg/runtime: BCIRUN1.ZIP -> Debugger info (binaries) BCIRUN2.ZIP -> Debugger info (binaries) The debugger info files augment the compiled runtime code with symbol and stack-use information so that the Scheme debugger can intelligently handle compiled procedures and stack frames. The info files are required only if you plan to examine the runtime system code and data structures using the Scheme debugger and pretty-printer. You will need to set the MITSCHEME_INF_DIRECTORY environment variable correctly (to $SCHEME/scmdbg) for the system to find the info files. Under $SCHEME/lib: EDDEL.ZIP -> EDDEL.COM (runtime delta) Under $SCHEME/edwin: SRCEDWIN.ZIP -> Edwin sources (sources) Edwin is an Emacs-style editor written in Scheme. EDDEL.COM is a collection of all the individual binaries necessarily to build Edwin starting from a bare runtime system. The version we distribute does not have every Edwin feature loaded. Edwin is optional. Under $SCHEME/lib: COMPDEL.ZIP -> COMPDEL.COM (runtime delta) Under $SCHEME/compiler: SRCCOMP.ZIP -> Compiler sources(sources) This is Liar, the native-code Scheme compiler. The delta file can be loaded into a bare runtime system to regenerate the full i386 compiler. The compiler is optional. Under $SCHEME/microcode: SRCUC.ZIP -> C sources (sources) $SCHEME/microcode contains the C sources for the microcode. It also contains some utility programs. This is where scheme.exe and bchscheme.exe are built. Under $SCHEME/runtime: SRCRUN.ZIP -> Runtime system (sources) $SCHEME/runtime contains the Scheme sources for the runtime system. This is where the runtime.com file is built, and where the runtime .bci files are usually kept. In the release they are stored in a different directory to make selective installation simpler. Under $SCHEME/sf: SRCSF.ZIP -> Scode optimizer (sources) SF is the SCode optimizer, also known as the Cross Syntaxer. SCode is the tree-structured intermediate opcodes the Scheme interpreter executes and the Scheme compiler translates. SF is preloaded into the compiler delta described above, and you need the sources only if you don't want to keep the compiler or wish to regenerate the system. Under $SCHEME/cref: SRCCREF.ZIP -> Cross referencer (sources) CREF is an experimental packaging system that is used in the construction of MIT Scheme. You need this only if you plan to regenerate the system. It is probably not advisable to use this in your projects, as we have plans to replace it with a very different system in the future. Under $SCHEME: unzip.exe unzipall.bat unzipflp.bat Utilities for unpacking the distribution. UNZIP was written by Info-ZIP and distributed by us only for your convenience. UNZIPALL.BAT is a script that builds directory structure and invokes UNZIP repeatedly to restore the compressed files. UNZIPFLP.BAT is the same installation script but with prompts and pauses for floppy insertions. Under $SCHEME readme.txt alpha.txt Documentation for the alpha release. Memory Requirements ------------------- The memory requirements vary depending on various factors: - How fast you want garbage collection to be. - How featureful you want your system to be. We provide two executables (scheme.exe and bchscheme.exe) that differ only in the garbage collector and related support. scheme.exe uses a pretty standard two-space garbage collector, with both spaces in simultaneous use only at garbage collection time. bchscheme.exe uses a two-space collector, but windows the second space into a disk file, so that only one of the spaces (and some space for the windows) needs to be in memory at any given time. It is somewhat slower, but it is frequently perfectly adequate. On the other hand, you will need enough disk space to hold the spare heap during GC. The amount of memory allocated can be controlled by using the -heap and other options. The arguments to these options are in thousands of scheme objects (4 bytes each). Thus ``-heap 500'' implies 4 MB for scheme.exe and 2 MB for bchscheme.exe. -constant controls the space allocated to constant space, a permanent region where system code resides and that does not need to be moved at GC time. You should not need to change this, unless you move your own code or data into constant space. -stack controls the space allocated to the Scheme stack (different from the C stack). The default should be sufficient. The numbers below assume that appropriate -heap arguments are given. The defaults (particularly for edwin and the compiler) are much larger. The requirements for plain scheme are ~4 MB if using scheme ~3 MB if using bchscheme The requirements for running edwin are ~6 MB if using scheme, 8 MB desirable ~5 MB if using bchscheme, 6 MB desirable The requirements for running the compiler are ~8 MB if using scheme, 12 MB desirable ~6 MB if using bchscheme, 8 MB desirable The compiler needs lots of memory to compile large files, so you will only be able to compile small-ish files in a minimal configuration. You can have both edwin and the compiler loaded (that's the way we use it, but we have lots of memory), the memory requirements are greater. A machine with 16 MB of memory should be able to deal with both easily while running scheme, and a machine with 12M should be able to do the same when running bchscheme. Building edwin or the compiler is a different matter. Due to a design shortcoming of the memory manager, they need significantly more memory to build than they do to run. This may be fixed later this summer, but in the mean time, you need at least 8 MB to build either. Disk Requirements ----------------- The disk requirements vary depending on how full you want your system to be. For the installation you will need about 500K more than the size required by the parts of the system you want to install. The minimal system (scheme.exe or bchscheme.exe and runtime.com) takes up about 2.2 MB. edwin.com is about 3.8 MB compiler.com is about 4.4 MB eddel.com is about 1.9 MB compdel.com is about 2.6 MB You don't need both the del (for delta) files and the images. If you have enough memory, but not enough disk space, you can keep the del files and load them when necessary (assuming that you started scheme with sufficient memory, e.g. with the -large option). The del files are just the collection into a single file of all the files that would be loaded to construct the appropriate system. If you have enough disk space you can keep the images around and use -edwin or -compiler to start scheme with those images instead of the default. If you want the ability to debug runtime system code, you will need the .bci files for the runtime system. They take up about 3 MB on disk. If you want the ability to examine the sources or rebuild the system from scratch, the sources for the following subsystems take up the following space: microcode 3.1 MB runtime 1.3 MB edwin 1.7 MB compiler 1.3 MB + 200 KB + 80 KB Note: the compiler is made up of three subsystems called compiler, sf, and cref. The three sizes correspond to the sources of the three subsystems, respectively. You will need quite a bit of space (~60 MB) to rebuild the complete system from scratch and hold the resulting binaries and debugging files. Running Scheme, etc. -------------------- Once you have scheme installed, you can run scheme as follows scheme -band band-name where band-name is the complete pathname to the runtime.com image file. To avoid typing -band ... on every invocation, you can set the MITSCHEME_LIBRARY_PATH environment variable. For example, if you typed set MITSCHEME_LIBRARY_PATH=d:\cscheme\lib;e:\tmp scheme would look at the current directory (always implicitly in the path), d:\cscheme\lib, and e:\tmp in that order for bands. The default image is called runtime.com, and the default value of MITSCHEME_LIBRARY_PATH is c:\scheme\lib If you have built the edwin.com file, then scheme -edwin will start scheme (with larger default memory options) and load edwin.com. To start the editor, you can type either of (edit) (edwin) Note that before you run edwin you will need to have the ansi.sys (or compatible) TSR loaded (in your CONFIG.SYS file), and you will have to define the environmnt variable TERM to be ansi.sys, i.e. SET TERM=ansi.sys Before starting scheme, you can change the number of lines in your display (e.g. "mode con: lines=50") and notify Scheme/Edwin by appropriately setting the LINES and COLUMNS environment variables. If you have built the compiler.com file, then scheme -compiler will start scheme (with larger default memory options) and load compiler.com. The compiler can be invoked as follows (cf "filename") Note that if you do not have a floating-point coprocessor (or a 486DX processor), and you compile code that explicitly uses the floating-point operations (flo:+, flo:-, etc.), you will need to evaluate the following expression before compiling any such sources. (set! (access compiler:open-code-floating-point-arithmetic? (->environment '(compiler))) #f) If you have not built edwin.com or compiler.com, but would like to run them, follow the procedure used in building the images (except that if you have enough memory, you should not limit the stack or the the gc-window-size). Instead of DISK-SAVEing the images, you can proceed to use them as specified above. Note that Scheme and Edwin (under DOS) accept both forward slashes (/) and backward slashes (\) in filenames as directory separators. However, since backward slash is a quoting character for Scheme strings, you will have to type it twice within string quotes as in the following expressions: (load "c:\\scheme\\project\\foo") (open-input-file "c:\\scheme/project\\foo.scm") Installation Instructions ------------------------- We are providing three files that have not been compressed into ZIP format. They are unzip.exe # uncompressor unzipall.bat # script to install from hard disk unzipflp.bat # script to install from floppies UNZIP.EXE can be used to unzip the rest of the files (so can dezip and pkunzip, if you have them). unzip foo.zip extracts all the compressed files in the foo.zip archive. UNZIPALL.BAT can be used to build the directory structure and unzip all the files if you have enough space to do so. Otherwise you can edit it to disable those parts that you do not want to install. UNZIPALL.BAT assumes that all the files in the distribution have been unloaded into a hard disk (taking up about 8.5 MB) and that the current working directory is the location where you want the scheme directory structure to be built. It takes as an argument the name of the directory where the distribution files reside. UNZIPFLP.BAT is the same installation script but with prompts and pauses for floppy changes if you are installing from floppies. It takes as an argument a floppy drive name (e.g. B:). Thus d:\scheme> c:\zipped\unzipall c:\zipped would unzip the files in c:\zipped into directories under d:\scheme UNZIPALL.BAT and UNZIPFLP.BAT assume that your computer can execute Intel 486 floating point instructions (i.e. it has a 486DX processor or 387/487 coprocessor). If it does not, you can change 387run.zip into no387run.zip in the .BAT file before executing it. The installation scripts are divided into sections with comments describing what each part is unzipping. If you do not want the whole thing, you should disable (comment out or remove) the appropriate sections. You need not have on your hard disk the .ZIP files mentioned in the disabled sections. For a minimal installation, you only need to unzip either SCHEME.ZIP or BCHSCHEME.ZIP and 387RUN.ZIP or NO387RUN.ZIP. The first two are unzipped into a directory called BIN, although anywhere in your PATH would be fine and the latter are usually unzipped into a directory called LIB. If you want to be able to debug (and pretty-print) the procedures in the runtime system, you will also need to unzip the runtime-system debugging information files. The installation scripts place them in a directory called SCMDBG\RUNTIME. If you are going to install the runtime system sources, you can change this to be the same runtime subdirectory where the sources will be installed. If you install the debugging information files, you will need to use the MITSCHEME_INF_DIRECTORY environment variable so that the system can find the files when running. If you want to run Edwin or the compiler, you will need to unzip EDDEL.ZIP and COMPDEL.ZIP, respectively. These files are independent and you do not need both for either subsystem. If you want to examine or modify the sources, you will need to unzip the SRC*.ZIP files. Note that you will need the compiler binary, the cref sources and the runtime system sources to rebuild ANY part of the system. Once you've unzipped all the parts that you want, you can build the compiler and edwin images as follows: To re-build the edwin image, invoke bchscheme as follows (the parameters reduce the memory requirements. If you have enough memory, you can ignore them and use scheme instead of bchscheme). cd lib ..\bin\bchscheme -constant 846 -heap 913 -stack 19 -gc-window-size 1 At the prompt, type (begin (load "eddel") (disk-save "TARGETDIR/edwin.com")) Where TARGETDIR is the directory where you want edwin.com to reside. It should probably be placed in the same directory as runtime.com, but by adjusting the MITSCHEME_LIBRARY_PATH environment variable, you can have them in different places. Once DISK-SAVE finishes, you can get out of scheme by typing (exit) To re-build the compiler image, make sure that you do not have the environment variable MITSCHEME_LIBRARY_PATH set (there is a minor bug in the unpacker for the delta files), and invoke bchscheme as follows. Of course, if you have more than 8 MB of memory, you can increase the parameters. cd lib ..\bin\bchscheme -large -heap 769 -stack 23 -gc-window-size 1 -band fname Where fname is the full pathname (e.g c:\cscheme\lib\runtime.com) for the runtime image. At the prompt, type (begin (load "compdel") (disk-save "TARGETDIR/compiler.com")) Customization ------------- You can customize your setup by using a variety of tools: - bat files. If you do not have enough memory to run edwin or the compiler with its default memory parameters (it will print something like "Not enough memory for this configuration" and halt when started), you can write a .bat file that will invoke scheme with the appropriate -heap parameters. - init files. Scheme loads the file scheme.ini from your home directory every time it starts up. In addition, when it starts up, edwin loads the file edwin.ini from your home directory into the edwin environment. You can use both of these files to define new procedures, commands, or change defaults in the system. - environment variables. Most microcode parameters, and some runtime system and edwin parameters, can be specified by means of DOS environment variables. The following is a complete list of the environment variables that scheme (and edwin, etc.) look for. Many must be defined in DOS before you start Scheme, and are tagged with an asterisk. Others can be defined or overwritten within scheme by using the SET-ENVIRONMENT-VARIABLE! procedure, e.g. (set-environment-variable! "EDWIN_FOREGROUND" "32") Environment variables that affect the microcode: * MITSCHEME_LIBRARY_PATH Semi-colon separated list of directories where scheme should look for image files. E.g. c:\cscheme\images;d:\tmp Default: c:\scheme\lib * MITSCHEME_BAND File name of plain runtime image file. Used when none of -band, -edwin, or -compiler are specified. E.g. myband.com, or d:\obscure\runtime.com Default: runtime.com (in the library path) * MITSCHEME_COMPILER_BAND File name of compiler image file. Used when -compiler is specified. E.g. ncomp.com Default: compiler.com (in the library path) * MITSCHEME_EDWIN_BAND File name of edwin image file. Used when -edwin is specified. E.g. editor.com Default: edwin.com (in the library path) * MITSCHEME_UTABMD_FILE File name of microcode description file. It is only necessary when re-building runtime.com. E.g. d:\cscheme\microcode\utabmd.bin Default: utabmd.bin (in the library path) * MITSCHEME_LARGE_HEAP Default -heap parameter when -large, -edwin, or -compiler are specified. E.g. 800 Default: 1000 * MITSCHEME_LARGE_CONSTANT Default -constant parameter when -large or -compiler are specified. E.g. 845 Default: 1010 * MITSCHEME_LARGE_STACK Default -stack parameter when -large, -edwin, or -compiler are specified. E.g. 500 Default: 100 * MITSCHEME_SMALL_HEAP Default -heap parameter. E.g. 200 Default: 250 * MITSCHEME_SMALL_CONSTANT Default -constant parameter. E.g. 550 Default: 430 * MITSCHEME_SMALL_STACK Default -stack parameter E.g. 75 Default: 100 * MITSCHEME_GC_FILE Default GC file for bchscheme (-gc-file). E.g. d:\tmp\gcfile Default: GCXXXXXX * MITSCHEME_GC_DIRECTORY Default directory where to write the GC file for bchscheme (-gc-directory). The directory should be in a partition or drive with a few Megabytes free. E.g. d:\temp Default: \tmp * MITSCHEME_DPMI_EXT_KBD Boolean option specifying whether Scheme should insert its own keyboard handling routine when running under DPMI/Windows. E.g. true Default: false * MITSCHEME_DOSX_EXT_KBD Boolean option specifying whether Scheme should insert its own keyboard handling routine when _not_ running under DPMI/Windows. E.g. true Default: false Environment variables that affect the runtime system * HOME Directory where to look for init files. E.g. c:\users\joe - TEMP/TMP Directory for various temporary files. TEMP is given preference to TMP. - MITSCHEME_INF_DIRECTORY Directory containing the debugging information files for the system. It should contain subdirectories corresponding to the subdirectories in the source tree. For example, if its value is f:\random, then runtime system debugging files will be expected in f:\random\runtime, while edwin debugging files will be expected in f:\random\edwin. Default: c:\scheme Environment variables that affect edwin - EDWIN_BINARY_DIRECTORY Directory where edwin expects to find files providing autoloaded facilities. E.g. c:\scheme\edwin Default: edwin\autoload in the library path. - EDWIN_INFO_DIRECTORY Directory where edwin expects to find files for the `info' documentation subsystem. E.g. c:\random\info Default: edwin\info in the library path. - EDWIN_ETC_DIRECTORY Directory where edwin expects to find utility programs. Currently not supported under DOS. E.g. c:\etc Default: edwin\etc in the library path. - EDWIN_FOREGROUND ANSI foreground color specifier. Must be a two-digit sequence in the range 30-37. E.g. 32 (green) Default: none (white) - EDWIN_BACKGROUND ANSI background color specifier. Must be a two-digit sequence in the range 40-47. E.g. 40 (black) Default: none (black) * TERM Terminal type, should be ansi.sys for DOS. * LINES Number of text lines on the screen, depending on the video adapter and support software. E.g. 43 Default: 25 * COLUMNS Number of text columns on the screen, depending on the video adapter and support software. E.g. 132 Default: 80 Regenerating the Full Scheme Distribution ----------------------------------------- The entire Scheme system can be regenerated using the limited set of binaries and full sources shipped with this distribution. Reasons for regenerating the system include: 1) you want to make changes to the system; 2) you want some of the unsupplied debugging info files for parts of the system; 3) you want to fine tune the installation parameters; 4) you have a 2Gbyte disk and have nothing to put on it - when completely built, the Scheme directory hierachy uses almost 60M of disk space. To regenerate the system you must have all the sources of the distribution and a working compiler image under the hierachy suggested. To regenerate the microcode you will need the Zortech C/C++ compiler, and the Microsoft Assembler (MASM). There is a makefile included with the C sources that rebuilds scheme.exe and bchscheme.exe from the sources. Follow the installation instructions above to obtain a compiler band. Then, start Liar by typing something like (depending on your setup): C>scheme -compiler -constant 1100 After Scheme starts up, type the following: => (cd "$SCHEME/cref") ; or whereever you have the CREF sources loaded => (load "cref.sf") ; Translate sources to SCode. Takes a few ; minutes => (load "cref.cbf") ; Compile CREF SCode At this point, the cross referencer is built. We can generate the runtime system. => (cd "../runtime") ; go to runtime system directory => (load "runtim.sf") ; syntax runtime => (load "runtim.cbf") ; compile runtime, takes up to 2 hours After the runtime system is complete, we need to generate the file describing the linkage between the Scheme runtime code and the C microcode. => (sf "../microcode/utabmd.scm" "../lib/utabmd.bin") Now, we can either leave Liar and proceed to rebuild the runtime system band, or continue regenerating the remaining parts of the system. To generate the runtime band, exiting Scheme into DOS. Get in the runtime directory (with all the newly generated binaries): C:/SCHEME/RUNTIME>scheme -fasl make.com This will "cold load" all the runtime binaries. At completion, we are left at the Scheme prompt again: => (disk-save "../lib/runtime.com") will save out the band. If you have modified the runtime system, you may wish to regenerate the compiler (and edwin) bands before proceeding to compile the rest of the system. Follow the installation instructions to do that. You will need to be back in Liar to do further compilation: C>scheme -compiler -constant 1100 -heap 2000 The large heap is only needed when regenerating the compiler (one of the sources, namely compiler\machines\i386\instr1.scm is very big and should be split). First thing to do is complete the generation of a full CREF system: => (cd "$SCHEME/cref") ; Go to cross referencer directory => (load "cref.sf") ; Generate full package constructors Next comes the Scode optimizer: => (cd "../sf") ; Go to SF sources => (load "sf.sf") ; syntax => (load "sf.cbf") ; compile Same for Edwin (2 hours+): => (cd "../edwin") ; Go to Edwin sources => (load '("edwin.sf" "edwin.cbf")) ; Syntax and compile Also for the compiler (2 hours+): => (cd "../compiler") ; Go to Liar sources => (load '("comp.sf" "comp.cbf")) At this point, all the binaries are recompiled. You can load up these subsystems (and perhaps save out the image as bands) by connecting to the various directories and loading a file called make. For example, to build Edwin from the binaries: C:\SCHEME>scheme -large => (cd "edwin") ; go to where edwin is => (load "make") ; load the file that builds everything => (disk-save "../lib/edwin.com") ; save out the band Before generating the compiler image, you will need to make an OPTIONS subdirectory under LIB, and copy RUNTIME/CPRESS.COM (plus FORMAT.COM, NUMINT.COM, HASHTB.COM, KRYPT.COM if you so desire) so that LOAD-OPTION can find it. Then start scheme as above (i.e. ``scheme -large'') and type => (cd "../sf") ; go to where the scode optimizer lives => (load "make") ; load the scode optimizer => (cd "../compiler") ; go to the compiler => (load "make") ; load the compiler => (disk-save "../lib/compiler.com") ; save it out Where to find more documentation -------------------------------- There are two pieces of documentation that you may find useful. They are not complete and currently out of date (they apply to version 7.1), but not terribly. They are - The MIT Scheme Reference Manual. - The MIT Scheme User's Manual. You can order a printed version of the reference manual from the MIT AI Lab publications office. Alternatively you can get the tex/texinfo sources (as well as the DVI and PostScript versions) of these and other documents by Internet FTP from altdorf.ai.mit.edu:archive/scheme-7.1 (IP address 18.43.0.152). The README file describes what's where. Known Bugs ---------- 1) The Scheme microcode takes great pains to intercept the PC keyboard so that all the chorded keys are available. Unfortunately, we have found that under some combination of memory managers and BIOS, the intercept mechanism does not work. Since the intercept code can cause very strange problems, it is disabled by default. You should install Scheme and run it for a while, and once you are confident that it is working properly, you can enable keyboard interception and see whether it continues to work. On some machines it works reliably from within DPMI/Windows and causes problems outside. To enable it outside of DPMI/Windows, set the following environment variable before starting Scheme. set MITSCHEME_DOSX_EXT_KBD=true To enable it within DPMI/Windows, set the following environment variable before starting Scheme. set MITSCHEME_DPMI_EXT_KBD=true 2) There is no support for graphics yet. We tried Zortech's Flash Graphics library, which seems unreliable at best. Send in a request if you really need to use our graphics code. Send us yours if you get your own running reliably. 3) Floating-point exceptions (e.g. underflow, divide-by-zero) are not currently trapped. Not all PC hardware is capable of reliably trapping them, and we have not yet spent any energy in trying to trap them. 4) Processor exceptions (general protection, invalid page fault, etc.) are only trapped under DPMI/Windows. Outside DPMI/Windows, if you get one of them, Scheme will halt and often you will need to reboot your machine. Reporting Bugs -------------- The best way to submit a bug report is to use Internet electronic mail. Send bugs to: bug-cscheme-dos@zurich.ai.mit.edu To send/request general information about the system, use: info-cscheme-dos@zurich.ai.mit.edu As in all (properly maintained) Internet mailing lists, the way to get on is to send mail to: info-cscheme-dos-request@zurich.ai.mit.edu As we have tried to emphasize, this distribution is an alpha release and we make no commitment to fix bugs reported. However, we solicit and appreciate your reports, and will in fact from time to time fix some of the problems.