PDCurses 3.9 - 2019-09-04

768 colors, single-process X11, copy-and-paste for all, and more.

New features

Bug fixes and such

See the git log for more details.

PDCurses 3.8 - 2019-02-02

It’s that time again.

New features

Bug fixes and such

See the git log for more details.

PDCurses 3.7 - 2018-12-31

New features

Bug fixes and such

See the git log for more details.

PDCurses 3.6 - 2018-02-14

Tidying up some loose ends from 3.5, and trying to bring all platforms up to the same level, as much as possible.

New features

Bug fixes and such

See the git log for more details.

PDCurses 3.5 - 2018-01-15

So, it’s been a while, eh?

This release is an attempt to bring PDCurses mostly up to date, without breaking too many things in the process.

New features

Bug fixes and such

See the git log for more details.

PDCurses 3.4 - 2008-09-08

Nothing much new this time, but I’ve been sitting on some bug fixes for almost a year, so it’s overdue. Apart from bugs, the main changes are in the documentation.

New features:

Bug fixes and such:

PDCurses 3.3 - 2007-07-11

This release adds an SDL backend, refines the demos, and is faster in some cases.

New features:

Bug fixes and such:

PDCurses 3.2 - 2007-06-06

This release mainly covers changes to the build process, along with a few structural changes.

New features:

Bug fixes and such:

PDCurses 3.1 - 2007-05-03

Primarily clipboard-related fixes, and special UTF-8 support.

New features:

Bug fixes and such:

PDCurses 3.0 - 2007-04-01

The focuses for this release are X/Open conformance, i18n, better color support, cleaner code, and more consistency across platforms.

This is only a brief summary of the changes. For more details, consult the CVS log.

New features:

Bug fixes and such:

PDCurses 2.8 - 2006-04-01

As with the previous version, you should assume that apps linked against older dynamic versions of the library won’t work with this one until recompiled.

New features:

Bug fixes and such:

PDCurses 2.7 - 2005-12-30


Hello all. As of a few weeks ago, I’m the new maintainer for PDCurses. Here’s a brief summary of changes in this release. (More details are available in the CVS log and trackers on SourceForge.)




and of course, MARK HESSLING, for his over 13 years of service as the maintainer of PDCurses. Plus, thanks to all who’ve reported bugs or requested features. Apologies to anyone I’ve forgotten.

I’ve tested this version on Turbo C++ 3.0 and Borland C++ 3.1 for DOS; DJGPP 2.X; Open Watcom 1.3 for DOS (16 and 32-bit), Windows and OS/2; EMX 0.9d and the “newgcc” version of EMX; Borland C++ 5.5 for Windows; recent versions of MinGW, Cygwin, LCC-Win32 and Microsoft Visual C++; and gcc under several flavors of Linux, Mac OS X, *BSD and Solaris.

– William McBrine

PDCurses 2.6 - 2003-01-08


This release of PDCurses includes the following changes:




PDCurses 2.5 - 2001-11-26


This release of PDCurses includes the following changes:



PDCurses 2.4 - 2000-01-17


This release of PDCurses includes the following changes:




ACKNOWLEDGEMENTS: (for this release)

PDCurses 2.3 - 1998-07-09


This release of PDCurses includes the following changes:

The name of the statically built library is pdcurses.lib (or pdcurses.a). The name of the DLL import library (where applicable) is curses.lib.





PDCurses recognizes two environment variables which determines the initialization and finalization behavior. These environment variables do not apply to the X11 port.

PDC_PRESERVE_SCREEN - If this environment variable is set, PDCurses will not clear the screen to the default white on black on startup. This allows you to overlay a window over the top of the existing screen background.

PDC_RESTORE_SCREEN - If this environment variable is set, PDCurses will take a copy of the contents of the screen at the time that PDCurses is started; initscr(), and when endwin() is called, the screen will be restored.

ACKNOWLEDGEMENTS: (for this release)

PDCurses 2.2 - 1995-02-12


This release of PDCurses has includes a number of major changes:





One difference between the behavior of PDCurses and Unix curses is the attributes that are displayed when a character is cleared. Under Unix curses, no attributes are displayed, so the result is always black. Under PDCurses, these functions clear with the current attributes in effect at the time. With the introduction of the bkgd functions, by default, PDCurses clears using the value set by (w)bkgd(). To have PDCurses behave the same way as it did before release 2.2, compile with -DPDCURSES_WCLR

ACKNOWLEDGEMENTS: (for this release)

Pieter Kunst, David Nugent, Warren Tucker, Darin Haugen, Stefan Strack, Wade Schauer and others who either alerted me to bugs or supplied fixes.

PDCurses 2.1 - 1993-06-20


The current code contains bug fixes for the DOS and OS/2 releases and also includes an alpha release for Unix. The Unix release uses another public domain package (mytinfo) to handle the low-level screen writes. mytinfo was posted to comp.sources.unix (or misc) in December 1992 or January 1993. Unless you are a glutton for punishment I would recommend you avoid the Unix port at this stage.

The other major addition to PDCurses is the support for DJGPP (the DOS port of GNU C++). Thanks to David Nugent davidn@csource.oz.au.

Other additions are copywin() function, function debugging support and getting the small and medium memory models to work. The testcurs.c demo program has also been changed significantly and a new demo program, tuidemo, has been added.

Some people have suggested including information on where to get dmake from. oak.oakland.edu in /pub/msdos/c


Under DOS, by default, screen writes to a CGA monitor are done via the video BIOS rather than by direct video memory writes. This is due to the CGA “snow” problem. If you have a CGA monitor and do not suffer from snow, you can compile private_queryad.c with CGA_DIRECT defined. This will then use cause PDCurses to write directly to the CGA video memory.

Function debugging: Firstly to get function debugging, you have to compile the library with OPT=N in the makefile. This also turns on compiler debugging. You can control when you want PDCurses to write to the debug file (called trace in the current directory) by using the functions traceon() and traceoff() in your program.

Microsoft C 6.00 Users note: —————————-

With the addition of several new functions, using dmake to compile PDCurses now causes the compiler to run “out of heap space in pass 2”. Using the 6.00AX version (DOS-Extended) to compile PDCurses fixes this problem; hence the -EM switch.

Functional changes ——————

Added OS/2 DLL support.

A few curses functions have been fixed to exhibit their correct behavior and make them more functionally portable with System V curses. The functions that have changed are overlay(), overwrite() and typeahead.

overlay() and overwrite()

Both of theses functions in PDCurses 2.0 allowed for one window to be effectively placed on top of another, and the characters in the first window were overlaid or overwritten starting at 0,0 in both windows. This behavior of these functions was not correct. These functions only operate on windows that physically overlap with respect to the displayed screen. To achieve the same functionality as before, use the new function copywin(). See the manual page for further details.


This function in PDCurses 2.0 effectively checked to see if there were any characters remaining in the keyboard buffer. This is not the behavior exhibited by System V curses. This function is intended purely to set a flag so that curses can check while updating the physical screen if any keyboard input is pending. To achieve the same effect with typeahead() under PDCurses 2.1 the following code should be used.

In place of…

	/* do something until any key is pressed... */


/* getch() to return ERR if no key pending */
while(getch() == (ERR))
	/* do something until any key is pressed... */

ACKNOWLEDGEMENTS: (in no particular order)

Jason Shumate, Pieter Kunst, David Nugent, Andreas Otte, Pasi Hamalainen, James McLennan, Duane Paulson, Ib Hojme

Apologies to anyone I may have left out.

PDCurses 2.0 - 1992-11-23


Well, here it finally is; PDCurses v2.0.

PDCurses v2.0 is an almost total rewrite of PCcurses 1.4 done by John ‘Frotz’ Fa’atuai, the previous maintainer. It adds support for OS/2 as well as DOS.

This version has been tested with Microsoft C v6.0, QuickC v2.0 and Borland C++ 2.0 under DOS and Microsoft C v6.0 and TopSpeed c v3.02 under OS/2 2.0. Also the library has been compiled successfully with emx 0.8e, C Set/2 and Watcom 9. Most testing was done with the large memory model, where applicable. The large memory model is probably the best model to use.

The amount of testing has not been as extensive as I would have liked, but demands on releasing a product have outweighed the product’s quality. Nothing new with that !! Hopefully with wider circulation, more bugs will be fixed more quickly.

I have included just 1 makefile which is suitable for dmake 3.8 for both DOS and OS/2. The makefile does not rely on customization of the dmake.ini file.

If you discover bugs, and especially if you have fixes, please let me know ASAP.

The source to the library is distributed as a zip file made with zip 1.9. You will need Info-ZIP unzip 5.0 to unzip. Follow the directions below to compile the library.


  1. Create a new directory in which to unzip pdcurs20.zip. This will create a curses directory and a number of subdirectories containing source code for the library and utilities and the documentation.

  2. Make changes to the makefile where necessary: Change the MODEL or model macro to the appropriate value (if it applies to your compiler). Use model for Borland compilers.

    Change any paths in the defined macros to be suitable for your compiler.

  3. Invoke DMAKE [-e environment_options] [target]

    where environment_options are:

    OS (host operating system)
    COMP (compiler)
    OPT (optimized version or debug version) - optional. default Y
    TOS (target operating system) - optional. default OS

    see the makefile for valid combinations

    targets: all, demos, lcursesd.lib, manual…

    NB. dmake is case sensitive with targets, so those environments that use an upper case model value (eg MSC) MUST specify the library target as for eg. Lcursesd.lib

    The makefile is by default set up for Borland C++. The use of -e environment_options override these defaults. If you prefer, you can just change the defaults in the makefile and invoke it without the -e switch.


The documentation for the library is built into each source file, a couple of specific doc files and the header files. A program is supplied (manext) to build the manual. This program gets compiled when you build the documentation.

To generate the library response file correctly, I had to write a quick and dirty program (buildlrf) to achieve this. Originally the makefiles just had statements like: “echo -+$(OBJ)$* & » $(LRF)” which appended a suitable line to the response file. Unfortunately under some combinations of makefiles and command processors (eg. nmake and 4DOS) the & would get treated as stderr and the echo command would fail.

The original source for PDCurses that I received from the previous maintainer contained support for the FLEXOS operating system. Not having access to it, I could not test the changes I made so its support has fallen by the wayside. If you really need to have PDCurses running under FLEXOS, contact me and I will see what can be arranged.

Under DOS, by default, screen writes to a CGA monitor are done via the video BIOS rather than by direct video memory writes. This is due to the CGA “snow” problem. If you have a CGA monitor and do not suffer from snow, you can compile private_queryad.c with CGA_DIRECT defined. This will then use cause PDCurses to write directly to the CGA video memory.

Added System V color support.


Microsoft C ———–

It is possible with MSC 6.0 to build the OS/2 libraries and demo programs from within DOS. This is the only case where it is possible to specify the value of TOS on the command line to be OS2 and the value of OS be DOS.

C Set/2 ——-

I have only tested the library using the migration libraries. I doubt that the demo programs will work without them.

emx —

Testing has been done with 0.8e of emx together with the 16_to_32 libraries. The emx\lib directory should include the vio32.lib and kbd32.lib libraries from the 16_to_32 package.



– Mark Hessling

PDCurses 2.0Beta - 1991-12-21

Changed back from short to int. (int is the correct size for the default platform. Short might be too short on some platforms. This is more portable. I, also, made this mistake.)

Many functions are now macros. If you want the real thing, #undef the macro. (X/Open requirement.)

Merged many sources into current release.

Added many X/Open routines (not quite all yet).

Added internal documentation to all routines.

Added a HISTORY file to the environment.

Added a CONTRIB file to the environment.

PDCurses 1.5Beta - 1990-07-14

Added many levels of compiler support. Added mixed prototypes for all “internal” routines. Removed all assembly language. Added EGA/VGA support. Converted all #ifdef to #if in all modules except CURSES.H and CURSPRIV.H. Always include ASSERT.H. Added support for an external malloc(), calloc() and free(). Added support for FAST_VIDEO (direct-memory writes). Added various memory model support (for FAST_VIDEO). Added much of the December 1988 X/Open Curses specification.

– John ‘Frotz’ Fa’atuai

PCcurses 1.4 - 1990-01-14

In PCcurses v.1.4, both portability improvements and bugfixes have been made. The files have been changed to allow lint-free compilation with Microsoft C v.5.1, and with Turbo C v.2.0. The source should still compile without problems on older compilers, although this has not been verified.

The makefiles have been changed to suit both the public release and the author, who maintains a special kind of libraries for himself. In the case of Microsoft C, changes were done in the makefile to lower the warning level to 2 (was 3). This was to avoid ANSI warnings which are abundant because PCcurses does not attempt to follow strict ANSI C standard.



The definitions for OK and ERR in curses.h were exchanged. This was done to be more consistent with UNIX versions. Also, it permits functions like newwin() and subwin() to return 0 (=NULL) when they fail due to memory shortage. This incompatibility with UNIX curses was pointed out by Fred C. Smith. If you have tested success/failure by comparisons to anything other than ERR and OK, your applications will need to be be changed on that point. Sorry… but presumably most of you used the symbolic constants?


Fred also pointed out a bug in the file update.c. The bug caused the first character printed after ‘unauthorized’ screen changes (like during a shell escape, for example) to be placed at the wrong screen position. This happened even if the normal precautions (clear / touch / refresh) were taken. The problem has now been fixed.

PCcurses is currently also being used on a 68000 system with hard-coded ESCape sequences for ANSI terminals. However, ints used by the 68000 C compiler are 32 bits. Therefore ints have been turned into shorts wherever possible in the code (otherwise all window structures occupy twice as much space as required on the 68000). This does not affect PC versions since normally both ints and shorts are 16 bits for PC C compilers.

At some places in the source code there are references made to the 68000 version. There are also a makefile, a curses68.c file, and a curses68.cmd file. These are for making, low-level I/O, and linking commands when building the 68000 version. These files are probably useful to no-one but the author, since it is very specific for its special hardware environment. Still in an effort to keep all curses-related sources in one place they are included. Note however that PCcurses will not officially support a non-PC environment.

The file cursesio.c, which was included in the package at revision level 1.2, and which was to be an alternative to the cursesio.asm file, has been verified to behave incorrectly in the function _curseskeytst(). The problem was that the value of ‘cflag’ does not contain the proper data for the test that is attempted. Furthermore, neither Turbo C or Microsoft C allows any way to return the data that is needed, and consequently you should not use cursesio.c. The best solution is to simply use the ASM version. In v.1.2 and v.1.3, the user could edit the makefile to select which version he wanted to use. The makefiles in v.1.4 have removed this possibility forcing the use of the ASM file, and cursesio.c has been dropped from the distribution.

A bug in the wgetstr() function caused PCcurses to echo characters when reading a keyboard string, even if the echo had been turned off. Thanks to Per Foreby at Lund University, Sweden, for this. Per also reported bugs concerning the handling of characters with bit 8 set. Their ASCII code were considered as lower than 32, so they were erased etc. like control characters, i.e. erasing two character positions. The control character test was changed to cope with this.

The overlay() and overwrite() functions were changed so that the overlaying window is positioned at its ‘own’ coordinates inside the underlying window (it used to be at the underlying window’s [0,0] position). There is some controversy about this - the documentation for different curses versions say different things. I think the choice made is the most reasonable.

The border() and wborder() functions were changed to actually draw a border, since this seems to be the correct behavior of these functions. They used to just set the border characters to be used by box(). These functions are not present in standard BSD UNIX curses.

The subwin() function previously did not allow the subwindow to be as big as the original window in which it was created. This has now been fixed. There was also the problem that the default size (set by specifying numlines or numcols (or both) as 0 made the resulting actual size 1 line/column too small.

There were a few spelling errors in function names, both in the function declarations and in curses.h. This was reported by Carlos Amaral at INESC in Portugal. Thanks! There was also an unnecessary (but harmless) parameter in a function call at one place.

PCcurses 1.3 - 1988-10-05

The file ‘border.c’ is now included. It allows you to explicitly specify what characters should be used as box borders when the box() functions are called. If the new border characters are non-0, they override the border characters specified in the box() call. In my understanding, this functionality is required for AT&T UNIX sV.3 compatibility. Thanks for this goes to Tony L. Hansen (hansen@pegasus.UUCP) for posting an article about it on Usenet (newsgroup comp.unix.questions; his posting was not related at all to PCcurses).

The only other difference between v.1.2 and v.1.3 is that the latter has been changed to avoid warning diagnostics if the source files are compiled with warning switches on (for Microsoft this means ‘-W3’, for Turbo C it means ‘-w -w-pro’). Of these, the Turbo C warning check is clearly to be used rather than Microsoft, even if neither of them comes even close to a real UNIX ‘lint’. Some of the warnings in fact indicated real bugs, mostly functions that did not return correct return values or types.

The makefiles for both MSC and TRC have been modified to produce warning messages as part of normal compilation.

PCcurses 1.2 - 1988-10-02

The changes from v.1.1 to v.1.2 are minor. The biggest change is that there was a bug related to limiting the cursor movement if the application tried to move it outside the screen (something that should not be done anyway). Such erroneous application behavior is now handled appropriately.

All modules have been changed to have a revision string in them, which makes it easier to determine what version is linked into a program (or what library version you have).

There is now a ‘cursesio.c’ file. That file does the same as ‘cursesio.asm’ (i.e. it provides the interface to the lower-level system I/O routines). It is written in C and thus it is (possibly) more portable than the assembler version (but still not so portable since it uses 8086 INT XX calls directly). When one creates new curses libraries, one chooses whether to use the assembler or the C version of cursesio. The choice is made by commenting out the appropriate dependencies for cursesio.obj, near the end of the makefiles.

There is now a ‘setmode.c’ file. That file contains functions that save and restore terminal modes. They do it into other variables than do savetty() and resetty(), so one should probably use either savetty()/resetty() or the new functions only - and not mix the both ways unless one really knows what one does.

Diff lists vs v.1.0 are no longer included in the distribution. The make utility still is. PCcurses v.1.2 still compiles with Microsoft C v.4.0, and with Borland Turbo C v.1.0. There is as far as I know no reason to believe that it does not compile under Microsoft C v.3.0 and 5.x, or Turbo C v.1.5, but this has not been tested.

There are two makefiles included, one for Microsoft C, one for Turbo C. They are both copies of my personal makefiles, and as such they reflect the directory structure on my own computer. This will have to be changed before you run make. Check $(INCDIR) and $(LIBDIR) in particular, and make the choice of ASM or C cursesio version as mentioned above (the distribution version uses the C version of cursesio).

The manual file (curses.man) has been changed at appropriate places.

I would like to thank the following persons for their help:

Brandon S. Allbery (alberry@ncoast.UUCP)
	for running comp.binaries.ibm.pc (at that time)
	and comp.source.misc.

Steve Balogh (Steve@cit5.cit.oz.AU)
  		for writing a set of manual pages and posting
	them to the net.

Torbjorn Lindh
	for finding bugs and suggesting raw
	character output routines.

Nathan Glasser (nathan@eddie.mit.edu)
  		for finding and reporting bugs.

Ingvar Olafsson (...enea!hafro!ingvar)
  		for finding and reporting bugs.

Eric Rosco (...enea!ipmoea!ericr)
  		for finding and reporting bugs.

Steve Creps (creps@silver.bacs.indiana.edu)
  		for doing a lot of work - among others
	posting bug fixes to the net, and writing
	the new cursesio.c module.

N. Dean Pentcheff (dean@violet.berkeley.edu)
  		for finding bugs and rewriting cursesio.asm
	for Turbo 'C' 1.5.

Finally, Jeff Dean (parcvax,hplabs}!cdp!jeff) (jeff@ads.arpa) has had a shareware version of curses deliverable since about half a year before I released PCcurses 1.0 on Use- Net. He is very concerned about confusion between the two packages, and therefore any references on the network should make clear whether they reference Dean’s PCcurses or Larsson’s PCcurses.

PCcurses 1.1 - 1988-03-06

The changes from v.1.0 to v.1.1 are minor. There are a few bug fixes, and new (non-portable) functions for verbatim IBM character font display have been added (in charadd.c and charins.c). The manual file (curses.man) has been changed at appropriate places.

In the file v10tov11.dif there are listings of the differences between version 1.0 and 1.1. The diff listings are in UNIX diff(1) format.

Version 1.1 compiles with Turbo C v.1.0, as well as Microsoft C v.3.0 and v.4.0. On the release disk there is a make.exe utility which is very similar to UNIX make (If the package was mailed to you, the make utility will be in uuencoded format - in make.uu - and must be uudecoded first). It is much more powerful than Microsoft’s different MAKEs; the latter ones will NOT generate libraries properly if used with the PCcurses makefiles.

There are three makefiles:

makefile		generic MSC 3.0 makefile
makefile.ms		MSC 4.0 makefile
makefile.tc		Turbo C 1.0 makefile

To make a library with for example Turbo C, make directories to hold .H and .LIB files (these directories are the ‘standard places’), edit makefile.tc for this, and type

make -f makefile.tc all

and libraries for all memory models will be created in the .LIB directory, while the include files will end up in the .H directory. Also read what is said about installation below!

PCcurses 1.0 - 1987-08-24

This is the release notes for the PCcurses v.1.0 cursor/window control package. PCcurses offers the functionality of UNIX curses, plus some extras. Normally it should be possible to port curses-based programs from UNIX curses to PCcurses on the IBM PC without changes. PCcurses is a port/ rewrite of Pavel Curtis’ public domain ‘ncurses’ package. All the code has been re-written - it is not just an edit of ncurses (or UNIX curses). I mention this to clarify any copyright violation claims. The data structures and ideas are very similar to ncurses. As for UNIX curses, I have not even seen any sources for it.

For an introduction to the use of ‘curses’ and its derivatives, you should read ‘Screen Updating and Cursor Movement Optimization: A Library Package’ by Kenneth C. R. C. Arnold, which describes the original Berkeley UNIX version of curses. It is available as part of the UNIX manuals. The other source of information is ‘The Ncurses Reference Manual’ by Pavel Curtis. The latter is part of Curtis’ ncurses package.

The only other documentation provided is a ‘man’ page which describes all the included functions in a very terse way. In the sources, each function is preceded by a rather thorough description of what the function does. I didn’t have time to write a nice manual/tutorial - sorry.

PCcurses is released as a number of source files, a man page, and a make file. A uuencoded copy of a ‘make’ utility, and a manpage for the ‘make’ is also provided to make it easier to put together PCcurses libraries. Even if you are not interested in PCcurses, it may be worthwhile to grab the make.

The makefile assumes the presence of the Microsoft C compiler (3.0 or 4.0), Microsoft MASM and LIB, plus some MS-DOS utilities. The reason for supplying MAKE.EXE is that the Microsoft ‘MAKE:s’ are much inferior to a real UNIX make. The supplied make is a port of a public domain make, published on Usenet. It is almost completely compatible with UNIX make. When generating the curses libraries, the makefile will direct make to do some directory creating and file copying, and then re-invoke itself with new targets. The workings of the makefile are not absolutely crystal clear at first sight… just start it and see what it does.

For portability, the curses libraries depend on one assembler file for access to the BIOS routines. There is no support for the EGA, but both CGA, MGA, and the HGA can be used. The libraries are originally for Microsoft C, but all C modules should be portable right away. In the assembler file, segment names probably need to be changed, and possibly the parameter passing scheme. I think Turbo C will work right away - as far as I understand, all its conventions are compatible with Microsoft C.

There are some parts left out between ncurses and PCcurses. One is the support for multiple terminals - not very interesting on a PC anyway. Because we KNOW what terminal we have, there is no need for a termcap or terminfo library. PCcurses also has some things that neither curses nor ncurses have. Compared to the original UNIX curses, PCcurses has lots of extras.

The BIOS routines are used directly, which gives fast screen updates. PCcurses does not do direct writes to screen RAM - in my opinion it is a bit ugly to rely that much on hardware compatibility. Anyone could fix that, of course…

One of the more serious problems with PCcurses is the way in which normal, cbreak, and raw input modes are done. All those details are in the ‘charget’ module - I do raw I/O via the BIOS, and perform any buffering myself. If an application program uses PCcurses, it should do ALL its I/O via PCcurses calls, otherwise the mix of normal and PCcurses I/O may mess up the display. I think my code is reasonable… comments are welcome, provided you express them nicely…

To install, copy all files to a work directory, edit ‘makefile’ to define the standard include and library file directory names of your choice (these directories must exist already, and their path names must be relative to the root directory, not to the current one). You must also run uudecode on make.uu, to generate MAKE.EXE. You can do that on your PC, if you have uudecode there, otherwise you can do it under UNIX and do a binary transfer to the PC. When you have MAKE.EXE in your work directory (or in your /bin directory), type make.

Make will now create 4 sub-directories (one for each memory model), copy some assembler include files into them, copy two include files to your include directory, CHDIR to each sub-directory and re-invoke itself with other make targets to compile and assemble all the source files into the appropriate directories. Then the library manager is run to create the library files in your desired library directory. Presto!

If you only want to generate a library for one memory model, type ‘make small’, ‘make large’, etc. The name of the memory model must be in lower case, like in the makefile.

I think the package is fairly well debugged - but then again, that’s what I always think. It was completed in May-87, and no problems found yet. Now it’s your turn… Comments, suggestions and bug reports and fixes (no flames please) to

– Bjorn Larsson