This source code compiles using Manx 5.2a.  

In regular UE, ue10.c is used for typing and wordwrapping etc.  In UEP,
module ue20.c is used in place of ue10.c.  makefile takes care of this.

About 60% of Uedit's source is or was in embedded asm.  The asm modules were
created using the "asm" execute-file and hand optimized.  I never liked asm
and anyone could create far better asm versions than mine, but I left in the
embedded asm versions anyway so that you could optimize them further.
(Typically I'd spend only about five minutes trimming the asm listings
produced by the Manx compiler.)


Every asm function in Uedit has always had a working C counterpart in the
same module.  The only exceptions are glue routines for Rexx and the file
requester and the text warping function.

The text warping function NewWarp in ue16.c was originally written by Bill
Kelly, 2507 Caminito La Paz, La Jolla, CA 92037.  He graciously allowed me to
use it in Uedit.  I modified it to allow size 11 fonts and made some other
minor changes at the front end.  But in essence it is his routine.

Ue17.asm, the only asm module, can be assembled using the Manx assembler.
The C counterparts for its routines (FrunKey() and unpackArgs()) are in
ue9.c.  This is the only instance where the asm version of something isn't in
the same module as its C counterpart.

executable files:
cx - compiles any ue*.c module
ax - assembles ue17.asm
asm - produces a file.asm assembly listing of any C module (used for creating
embedded asm versions of C functions which can be hand optimized.)

user-cmd:  Use it to clean up asm listing produced by the Manx C compiler,
making them somewhat easier to deal with.

Trust the C versions of everything.  They are the "fallback" position, when
an asm routine is suspect.

I will leave in my asm versions of many other C routines if they are in
critical places, even though I'm sure that any good asm coder could optimize
them far better than I did.  



Lattice/SAS never would produce a Uedit that wouldn't crash, unfortunately.
And this was after working extensively with their tech support people who
were as helpful as they could be. 

Manx:  I have had trouble with Manx also, but it has been far more reliable
for me, even though it doesn't optimize much at all.  Earlier there was a
case or two where it was necessary to move an array and some functions from
ue1.c to ue2.c in order for them to work again.  This was after they had been
working perfectly for a very long time.  Recently the embedded asm versions
of the C functions in ue3.c started causing the computer to hang up during a
config compile.  After trying a lot of tricks, it was found that the only way
Uedit's compiler would work reliably, as it always had in the past, was to
stop using the embedded asm versions of the functions in ue3.c.  Shortly
after it was discovered that Uedit was not compiling at least one complex
boolean expression correctly.  (I believe it was the complex boolean used in
the SAC-z load-files-with-wildcards command.)  I found that if I first got an
asm listing of the two relevant functions in ue3.c and then embedded that asm
in ue3.c, the booleans were compiled correctly.  Strange.  Ideally, all of
ue3.c ought to be in asm for the best compiling speed.  I left all the
embedded asm functions in ue3.c so that you might resurrect them.  An #ifdef
causes them to be ignored at present.

-----------------------------------------------------------------------------

Notes on differences between Sharware and Public Domain version of Uedit.

Sep-92

Removed all conditional code and any targets in makefile that are associatted
with the compilation and linking of "UES" the old share-ware release of UE.

Oct-92

Moving all source code for any Uedit related executable into one directory
called source under the main Uedit directory.

Added additional targets in the makefile to build USpell UFind and UdBuild.

I cannot recompile UdBuild.c and Uspell.c into running executables so I
am including the original supplied binaries and not changing the source
files. NOTE: there are makefile targets for these two but neither of
them compile at the moment.

It is necessary to have the file "arpbase.i" in the libraries directory
in your assembler includes directory to recompile Uedit. arpbase.i can
be gotten from the ARP programmers support material that is included
with Aztec C 5.2a.

I cannot find the source for S-U so I cannot recompile this.

It was necessary to cast some of the parameters to DOS functions in
the source for UHC because it would not recompile.

Bumped the revision number to V4.0 to avoid any confusion with the V3.0
shareware releases.

Moved the source to "F" executable for printing proportionally
editted docs [thats what UEP is for] into this source directory and
added it to the Makefile.