Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!ULKYVX.BITNET!RDROYA01
From: RDROYA01@ULKYVX.BITNET.UUCP
Newsgroups: comp.sys.atari.st
Subject: Uemail source (12 of 12)
Message-ID: <8702061927.AA06344@ucbvax.Berkeley.EDU>
Date: Fri, 6-Feb-87 12:48:00 EST
Article-I.D.: ucbvax.8702061927.AA06344
Posted: Fri Feb  6 12:48:00 1987
Date-Received: Sun, 8-Feb-87 01:41:54 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of Louisville
Lines: 83


 
I just wanted to tell everyone who is receiving or has received the
source to uemail that the numbering scheme ("Uemail source (X of 12)")
was inaccurate, but all of the files went through as far as I can
tell.  However, you may have received two versions of the main.c (one
in posting 2 and another in posting 7).  That was a mistake on my part
in running the batch mailer on this end.  Also you may have received
two versions of parts 3 and 4.  Those are two versions of four
different files despite what the subject line says, again caused by my
ineptness with the batch mailer.  To make it easier for everyone to
check what you have I enclose the lnk file:
 
[tem[m:]]e:xemacs.68k=gemsnew,
m:main,
m:basic,
m:buffer,
m:file,
m:fileio,
m:line,
m:random,
m:misc,
m:region,
m:search,
m:word,
m:wc,
m:kermit,
m:kertrans,
m:kerrec,
m:kertty,
m:page,
m:print,
m:window,
m:display,
m:termio,
m:ttgetc,
m:tty,
m:shell,
m:path,
m:macros,
m:keybrd,
gemlib[in[_nobinary],in[_nofilesz],in[_nottyin],in[_maxfiles],in[_nowildc]],
libm
 
I hope all of these files have come through unscathed, but I know that
BITNET wrapped some of the code.  If you get errors in compilation,
check the file for wrapped strings.  Also, you will get one warning in
word.c about short assigned to pointer.  Ignore that warning if you
have Alcyon.  Fixing the code defeats the word wrap, and since I
didn't write that code, I'm not that sure how to fix it properly.  The
program runs fine with that warning and word wrap does too.
 
When you compile this source DO NOT compile with the -f floating
point.  On v. 4.14 that option produces code that c168 cannot understand
(probably because Alcyon has case sensitive command options and TOS
upcases everything), and on the earlier Alcyon version it produces code
identical to the -e option.  You will have to link with libm, not libf
because the program uses floating point.  Also the code will not
compile on a compiler that does not support unsigned char or unsigned
long.  The break function (kermit.c) requires unsigned char, and the
rettpa function (misc.c) uses unsigned long.  I have not used
structure assignment or passing in the code.
 
You will also need the new gemstart file that Allan Pratt wrote, the
one that uses mshrink.  You will need to set the STACK equate to 4.
Shell.c define _STKSIZ as 256K.  You can reduce that, but you won't be
able to run the compiler or linker (safely) while in the editor if you
do.  On CP/M-68K you can batch the whole compile/link process and run
it in a 128K buffer while inside the editor without any problems, but
on the ST you'll crash the system if you try this with the same
compiler and linker.
 
Hope you find some use for this software,
 
Robert Royar
Department of English
University of Louisville
Louisville, KY 40208
 
BITNET: RDROYA01@ULKYVX.BITNET
ARPA:   rdroya01%ulkyvx.bitnet@wiscvm.arpa
CIS:    72347,2767