Release 1.6d wasn't in the original plan for Repertoire's evolution, 
but it's a significant step in the right direction.  We realized about 
a year ago that it was going to be impossible to maintain separate 
DOS and OS/2 versions.  I tried for several months to do it the C way 
(i.e., with a preprocessor and conditional compilation), and I tried 
using vmerge and vdiff to maintain two independent sets of files, but 
nothing worked.  We had to have a single version.  

It was also clear that we couldn't stop supporting real-mode-only
executables.  Few of our customers have access to Microsoft's BIND.EXE
and the MS and compiler-specific libraries that it requires, at least
one of the M2 compilers we have to support generates executables that 
cannot be bound, and we knew DOS developers would object to the size 
of bound executables, even if their load sizes didn't exceed those of 
real-mode-only executables. We thought about requiring DOS developers 
to use Microsoft's API.LIB, which contains real-mode emulations of 
OS/2's Family API subset, but of course there were access problems, 
and API.LIB turned out not to be a linkable library anyway; it is 
full of assumptions that are satisfied only by the BIND.EXE link 
postprocessor.

So I convinced Chuck to do a clean, linkable, real-mode, 
assembly-level emulation of the parts of the OS/2 API that Repertoire
depends on.  Its interface is identical to OS/2's DOSCALLS.LIB, but
you can link it into a DOS executable with a normal linker.  It means
that we can have a single version not only of the source, but of
the object code as well.  Link it with OS/2's DOSCALLS.LIB and the
executable runs in protected mode with unlimited memory; link the
same program with our FAPI.LIB and you get a native real-mode DOS 
executable that runs identically.  That makes it easy to develop and 
debug real-mode applications in protected mode, and it lets DOS-only 
developers hedge their bets by using the OS/2 API to communicate with 
DOS.

The main purpose of this release is therefore to consolidate the DOS 
and OS/2 versions.  Upgrading to it from the DOS version of release 
1.5 should be painless.  Very few argument lists or procedure names 
have changed.  We did change some module names to prevent conflicts 
with compiler-provided modules:  FileIO is now HandleIO, and Speaker 
is now Spkr.  The StringIO.ErrorMessage type is now CARDINAL.  
FindFirstFile and FindNextFile now have additional DirectoryHandle 
parameters.  We've added a very nice NumInput module written and 
contributed by Mike Carter and Jonathan March.  There are a lot of new 
string- and list-handling routines, but they won't get linked in if 
you don't use them.

The best reason to upgrade is to begin protected-mode debugging of
your DOS application.  The protected mode version of CodeView works
fairly well with both Stony Brook and JPI.  It lets you forget about
memory limits and bugs in the debuggers themselves, and finally get 
on to real work.

Cole Brecheen

Changes 1.6f  8/22/91

For JPI version 3 is now the version suported. Instead of objs its included
as a library repjpi3.lib. This way you do not have to put the mods on
your hard disk, and also makes are faster. Example project files are
included os2.pr and dos.pr. You can use rdoslib.pr or ros2dll.pr to rebuild
the library.

Bugs fixed

MakeFrame.mod: fixed problems with scrncomp had with comments.

EnvironUtils.Mod: fixed problem where GetDate returned garbage for 
mmddyy.	  Same for GetTime.

WindowPrims.mod  Fixed problem that could cause overflow when setting
the cursor height.

FramePainter.mod line 572 Changed to fix problem with writing captions.

VStorage.mod Made change to DosAval always is TRUE for os/2. Also 
removed many un-needed calls to DosAval through out.

FAPI.LIB: Changed because of an error in JPI's linker that caused
overlaping procedures.

Fixed problems with CrunchNdx.

It' recomended that you turn alias optimization off for both jpi and stonybrook 
compilers

John McMonagle