Stuart.Lynne@van-bc.UUCP (Stuart Lynne) (08/17/87)
>From uucp Wed Aug 12 02:50 PDT 1987 >From slynne Wed Aug 12 02:50:14 1987 remote from slmac Received: by van-bc.uucp (smail2.3) id AA17682; 12 Aug 87 02:50:14 PDT (Wed) Received: by slmac.vnet.van-bc.uucp (pcmail) Wed Aug 12 02:38:57 1987 Date: Wed Aug 12 02:38:57 1987 From: Stuart Lynne - test a mac <slynne@slmac.vnet.van-bc.uucp> Message-ID: <151@slmac.vnet.van-bc.uucp> To: sl@van-bc Subject: shar/uupc.read.8.1 #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # README.DCP # README.UUPC # README.PORT # README.INFO # This archive created: Wed Aug 12 02:02:28 1987 # By: Stuart Lynne - test a mac () export PATH; PATH=/bin:$PATH if test -f 'README.DCP' then echo shar: will not over-write existing file "'README.DCP'" else cat << \SHAR_EOF > 'README.DCP' uupc/dcp June 8, 1987 Stuart Lynne For Beta implementors only. This is the very first release of my version of Richard H. Lambs uucp program dcp. See README.UUPC for overview of how everything is stitched together. Summary of Changes: - eliminated references to all protocols except for the 3 window g protocol - streamlined dcp and condensed into four files - moved host dependant stuff to one file uuXXX - bug fixes to get 3w g protocol to send at full speed dcp.c - dcp pseudo main, high level stuff dcp.h - header file dcpxfer.c - file xfer dcpsys.c - connection stuff dcpgpkt.c - g packet protocol For more information, bug fixes, more commands etc: Stuart.Lynne@van-bc.uucp 604-937-7532 Fixes Jun 8/87 Added FOPEN and CREAT to recursively create directory trees if they don't exist when a file is opened for writing or appending Jun 8/87 Found bug in getting file name in initial protocol sequence Need to read more than one packet. Jul/87 Added Hayes dialer to dcpsys SHAR_EOF chmod +x 'README.DCP' fi # end of overwriting check if test -f 'README.UUPC' then echo shar: will not over-write existing file "'README.UUPC'" else cat << \SHAR_EOF > 'README.UUPC' July 29/87 Stuart Lynne UUPC is now running on Macintosh, Atari-ST, Amiga, and IBM-PC with MS-DOS. These versions will constitute my first release of uupc and pcmail. Please see the README files in each shar file for appropriate instructions. As is, uupc sends and receives files quite well. Still unimplemented is the reverse direction file transfers, i.e. send a file to a remote host while in slave mode, receive a file while in master mode. These are not needed to support news and mail. A proper uucp command is need too. The user agent mail program is a very simple hack to simply allow you to read and send mail. Hopefully someone will work on replacing this! The message transfer agent pcmail program is fairly robust. It does need to have some more intelligence to allow for more intelligent routing of outgoing mail. Currently ALL outgoing mail is forward to a single remote site for processing. This will actually handle the needs of a large number of users but for those lucky ones who can actually get access to several large uucp sites better routine would be nice. Other things which are needed: news unbatcher news reader Currently the news is simply spooled to a directory with a unique file name. You can read this with a normal text editor. If you wish to have outgoing mail the easiest way is to have your news feed set up alias's like: comp.sys.amiga "| /usr/local/lib/news/recnews comp.sys.amiga" Then simply mail your article to: comp.sys.amiga@newsfeedhost.uucp Please feel free to port this code to other environments. I ask only that you try and limit changes to the machine independent code. Things have been setup so that you shouldn't have to modify dcp, uupc, mail or pcmail if you are simply porting to a new environment. Please send me any new versions, diff's to get old versions working better, bug fixes etc. Have fun and enjoy. I would suggest that questions and comments about uupc/dcp/mail be directed to comp.mail.uucp on Usenet. This group is about "Mail in the uucp network environment." which describes uupc pretty well. Questions, bug fixes etc uupc, mac version, information Stuart Lynne stuart.lynne@van-bc.uucp {{seismo,ihnp4!alberta}!ubc-vision,uunet}!van-bc!Stuart.Lynne 604-937-7532 Amiga version Jeff Lydiatt jl@jlami.vnet.van-bc.uucp {{seismo,ihnp4!alberta}!ubc-vision,uunet}!van-bc!jlami!jl Atari ST version Lawrence Harris lawrence@nvanbc.uucp {{seismo,ihnp4!alberta}!ubc-vision,uunet}!van-bc!nvanbc!lawrence IBM PC - MS-DOS version Samuel Lam skl@sklpc.vnet.van-bc.uucp {{seismo,ihnp4!alberta}!ubc-vision,uunet}!van-bc!skl uupc mailing list uupc@van-bc.uucp Automatically forwarded to mailing list uupc-request@van-bc.uucp For requests to be added to mailing list {{seismo,ihnp4!alberta}!ubc-vision,uunet}!van-bc!nvanbc!uupc {{seismo,ihnp4!alberta}!ubc-vision,uunet}!van-bc!nvanbc!uupc-request NB. Rurrently UUNET is only polled twice per week, you may wish to send any messages via both paths to ensure delivery. UUNET is probably more reliable, ubc-vision may be faster if you can reach them from your site. uupc June 8, 1987 Stuart Lynne For Beta implementors only. uupc incorporates a streamlined version of dcp to implement a uucp mail and news delivery system. See README.DCP for dcp info. By moving the host dependant code into one file the other four dcp files can hopefully be maintained easily. It should be possible to maintain one version of them which compiles and runs on all machines without conditional compilation flags. The host file should contain: - serial I/O - BSD compatible directory routines - system call stuff This all goes to implement a command called uupc. It is similiar to the uucico command under unix. uupc [-xn] [-shost] There is also two mail source files. Pcmail is the MTA part of the mail system. It compiles in two ways, one for rmail (add only From and Received: headers), define a simple rnews; and for lmail (add all headers). Pcmail will effect delivery of mail to local and remote users. Currently all remote mail is directed to one smart host for forwarding. Mail is a simple UA. It allows you to send mail and read your mailbox. It needs lots of work but is servicable. mail -s "subject here" user user@remote.site.domain < message mail -f =mailbox mail will all do the obvious. Mail will append a .signature if it can find one, and will keep a copy of your outgoing mail in =mail.sent. ToDo: uucp command mail improvements bug fixes to uupc/dcp ports to Atari, Amiga, IBM PC, VMS Makefile - sample Makefile (Macintosh Aztec C) getargs.c - library routine lmail.c - define LMAIL; include pcmail mail.c - mail program (UA) pcmail.c - mail program (MTA) rmail.c - define RMAIL; include pcmail lib.c - misc library routines, FOPEN, CREAT, getargs, printmsg host.h - prototype for host.c, includes "local/host.h" mailhost.c - ditto for mailhost.c, includes "local/host.c" mlib.c - ditto for mlib.c, includes "local/mlib.c" ulib.c - ditto for ulib.c, includes "local/ulib.c" uuhost.c - ditto for uuhost.c, includes "local/host.c" pcmail in general Pcmail provides MTA functionality. It delivers the mail. Currently it is very dumb about forwarding mail. Local deliveries always succeed if there is room and the mail spooling directory exists. No "/etc/passwd" file list of users is used to determine if there really is a mailbox for an incoming message. Also outgoing mail is assumed to go to one smart host for processing. This is determined by scanning for "!" or "@" in the address. Both local and remote delivery algorithms could be souped up. Locally we should maintain a list of mailboxes. For remote we should attempt to build a path to the most reasonable host for forwarding a specific message. This will require a small version of the paths database most likely. If your only talking to one host anyway the current scheme is not all that bad. Pcmail has one additional capability which is not currently being exploited. It can add additional message length header lines and spool mail into a mailbag. This mailbag could then be sent intact to your host for processing. The host must run rpcmail (availble from sl@van-bc.uucp) to unbatch the messages to rmail. This corresponds to the AT&T Mail protocol for uploading mail from PC's. Most likely the converse capability would be more suitable. Have the host batch incoming mail and news. Unbatch it on this side. pcmail / LMAiL The mail UA is composed of the mail.c program and pcmail.c compiled without defining RMAIL (LMAIL). The LMAIL version of pcmail adds rfc822 headers to all mail, copies mail to =mail.sent etc. pcmail / RMAIL The uu program contains the RMAIL version of pcmail. It only adds the From Received: headers to incoming mail. For more information, bug fixes, more commands etc: Stuart.Lynne@van-bc.uucp 604-937-7532 Directory tree /usr /usr/lib /usr/lib/uucp /usr/lib/uucp/SEQF - sequence numbers /usr/lib/uucp/systems - host connection information /usr/spool /usr/spool/mail - mail directory /usr/spool/mail/XXXX - user mail files /usr/spool/rnews - rnews spool/file /usr/spool/uucp - spool directory /usr/spool/uucp/C.YYYYYNNNN - copy control files /usr/spool/uucp/D.YYYYYNNNN - uucp data files /usr/spool/uucp/dcp.log - log file /usr/spool/uucp/X.YYYYYNNNN - execute control files /usr/XXXX - user directories /usr/XXXX/.signature - signature file /usr/XXXX/Mail - user mail directory /usr/XXXX/Mail/mail.sent - sent file /tmp - temporary files Systems File NB. I have split the lines, in the real file they should be one line for each entry. This entry uses the built in Hayes dialer. van-bc Any a HAYES TD939-4782 g ogin:--ogin: uuslmac sword:-\c-sword: uuslmac Connect to van-bc using HAYES dialer with phone number 939-4782 with protocol g. Wait for ogin: if timeout send \n and wait for ogin:. Send uuslmac (login ID). Wait for sword:, if timeout send nothing, wait for sword: Send uuslamc (login ID). I use this entry to connect via a DC Hayes Smartmodem 2400, dialing explicity. van-bc Any a DIR 2400 g "" ATZ OK-\d+++\dATZ-OK ATS7=12 OK ATTD939-4782 CONNECT \d\c ogin:--ogin: uuslmac sword:-\c-sword: uuslmac Connect to van-bc at 2400 on port a with protocol g. Expect nothing, send ATZ to reset the modem, Expect OK, if not received send pause +++ pause to try and get modems attention and wait for OK. When OK received, send ATS7=12 to shorten connect timeout on modem. Expect OK, send ATTD939-74782. Expect CONNECT, send nothing but pause (\c is needed). Expect ogin:, if not received send newline. Send login name. Expect sword:, send password. This entry is used to connect directly to my Callan at 9600. It is complicated due to the Callan running a special mgetty program which thinks it is talking to a Hayes Smartmodem. So we fake it out, then tell it the connection has been made at 9600, then switch to 9600 ourselves. van-bc Any a DIR 2400 g "" OK\r\d\dRING\r\dCONNECT\s9600\d\z9600\ ogin:-\r\r-ogin: uuslmac sword:-\c-sword: uuslmac "" \d\d\d\d\d\d\c Connect to van-bc at 2400 on port a. Expect nothing, send OK, pause, RING, CONNECT, 9600, and change to 9600 bps. Expect ogin: send login id. Expect sword: send password. SHAR_EOF chmod +x 'README.UUPC' fi # end of overwriting check if test -f 'README.PORT' then echo shar: will not over-write existing file "'README.PORT'" else cat << \SHAR_EOF > 'README.PORT' uupc Porting Information August 3, 1987 uupc Development This writeup is aimed at programmers intending to port uupc to machines and operating systems which it don't currently run on. If you only want to install uupc on a system where a uupc port exists, this writeup might also provide some insights to the internal working of uupc and make the installation of uupc on your machine a more interesting task. Since I did part of the IBM-PC/MS-DOS port for uupc, what I will describe here is actually closely related to the structure of this particular port. (I also did part of the port of uupc's mailer to AIX (SVR1) on the RT-PC.) What is shown here is *by no mean* the only way things could be done, it's just some tips and hints that I can think of after doing one-and-a-half port of uupc. The purpose of this writeup is to try to make the life of programmers doing uupc ports for other machines/operating systems easier. However, the best sources of information on how new ports should be done is still by reading the system-dependent code of the existing uupc ports. (This is how I learnt how to do my ports.) It would also be useful to have a listing of the system-dependent code of the IBM-PC/DOS port handy while reading this writeup. To compile uupc, the C compiler and linker on your system must be able to differentiate between upper and lower cases in external names. The C run-time support on your system should use '\n' as line separator for *text* files. If your system uses other sequences or methods to delimit text file lines, the C run-time support must perform the appropriate translation functions for mapping in both directions when a file is opened in text mode. In order to port uupc to a new machine/operating system, you have to come up with a new version of six system-dependent files in the the "local" directory. The names of these six files in the local directory are host.h, host.c, mlib.c, ulib.c, ndir.h and ndir.c. Note that theses files could in turn #include other *.c and *.h files if you wish to separate the system-dependent code into more small files. The important thing here is that they must collectively provide the same set of routines, global variables, and environment to the common code. What should be contained in these six files are describe below: host.h - Host dependent file virtual #included everywhere else. Almost every file in both the common and host-dependent code include this header file. So it should contains all the #includes, #defines, and externs that everybody would need. Parts of the uupc common code assume Berkeley-style index() and rindex(), so if your system supports only SysV-style strchr() and strrchr(), they need to mapped using #define here. Declarations for "library" routines in host.c, mlib.c and ulib.c should also be make here to made them known to the rest of the world. However, declaractions for the directory scanning routines should be put into ndir.h instead. If your system requires that text file and binary fiies be opened differently, you should map the name 'FILEMODE' into 'filemode' with a #define here. Otherwise, 'FILEMODE' should be mapped to the null string. host.c - Generic main program and library routines for both parts. This file includes a generic main program that simply starts up and call the procedure MAIN. More importantly, the definition of all the library routines that are needed by both uu and mail are also here. This generic main program is used to start up both uu and mail, by having the preprocessor symbol MAIN #defined to different procedure names in the files which include host.c. This generic main program should perform all the necessary start up and wrap up functions as required by the host operating system and call the routine MAIN while the host environment is established. If the preprocessor symbol CWDSPOOL is #defined by the file that #includes host.c, the main program should change the current working directory to the spooling directory before calling MAIN, and switch back to the orginal directory after MAIN had returned. The following are the other routines residing in host.c and used by the others parts of both uu and mail: importpath - A deterministic function which maps a canonical file name to a local file name. This function must be deterministic (i.e. always return the same local name when given the same canonical name) because it is used on each canonical file name several times in various part of the code to obtain the corresponding local file name. A canonical file name has the same format as a UNIX pathname, and the format of a local file name is defined by your local file system. This function should at least preserve the first 6 and last 2 characters of the canonical file name, since this parts of the canonical file name usually contain the site name and the sequence number, which is critical to the successful operation of uupc. Perferably the last 4 characters of the canonical file name should be perserved, since that is the number of digits in the sequence number, but if that is not possible, an attempt should be made to preverse the last 3 characters before resorting to only preserve the last 2 characters. (With only the last 2 characters preserved, the spool file sequence number cycle will become only 100 before it goes around again.) mkfilename - Build a local path name out of a given local directory path and local base name pair. It usually just concatenates the two parts together with the local system's directory path separator between them. loadenv - Retrieve certain configuration parameters from the user's "environment" and make them available to the program. This involves filling in the appropriate global (char *) variables to point to the appropriate strings which contains the character value of the desired configuration parameters. If your system requires the differentiation of text file and binary files, you should also supply the following routine. filemode() - If this routine is passed the character 't' as parameter, any subsequently opened file in the program should be opened in text mode. Similarly, if the parameter is the character 'b', all subsequently opened file should be opened in binary mode. mlib.c - Library of routines used only by the mail part. Currently there is only one routine in this library. get_one - Wait for a single character to be typed on the console keyboard and return to the caller with the character read as soon as it is pressed. It short, this is a routine that detects and returns a keypress. This routine is used when you reach the bottom of a page while paging through your mail. The single character read by this routine should not be echoed to the console screen. ulib.c - Library of routines used only by the uu part. login - The logger which verifies logins and passwords for incoming UUCP connections. You only need to have this routine functional if you plan to ever run your node in slave mode. i.e. Waiting on the phone line for other nodes to call you to make UUCP connections. shell - Perform an UNIX command sent from a remote site via uux. To support incoming remote mail you need to emulate the UNIX 'rmail' command, which can be easily done using the pcmail package (compiled as rmail) which is part of this uupc distribution. If you want to also support incoming USENET news-feeds, the UNIX 'rnews' command will need to be supported as well. If your system is capable of invoking another program within a program, you might want to dispatch rmail and rnews as a separate program here. Otherwise, you might need to compile, or link, them into uu as routines. sleep - Wait a specified number of seconds in real-time. You could either use a busy wait loop or a timer alarm here, depending on if your system has other (e.g. background) jobs competing for CPU time at the same time. On mutli- tasking or multi-users systems, you would likely *not* want to busy wait even if that's easier to implement. The rest of this library consists of routines to deal with the communications line (serial port). openline - Open a communications line as the active line. The name of the serial line device and the speed to open the line at are *both* specified as (char *) type parameters. These value are just the corresponding values in the systems file entry of the site being called. sread - Read a specified number of bytes from the active serial line and return with *no* input characters consumed *if* the specified number of bytes is not available after the specified timeout period. This is basically a non- blocking read that waits up to an user-specified amount of time before returning. swrite - Write a specified number of bytes out to the active serial line. No timeout mechanism needs to be provided by this routine. closeline - Close the active communications line. SIOSpeed - Change the line speed of the active communications line on-the-fly. The new line speed is given as (char *) rather than (int). Note the mixed-case nature of this routine name. ndir.h - Header file for the directory scanning routines. At least the following needs to be defined in this file. -- The constant 'MAXNAMLEN' declared with "#define". This is the maximum length of a file name in your system. Note that a file name does not include a directory path prefix, it is only the maximum length of a file name within a directory. -- The structure 'direct' declared with "struct". This structure is a public data structure and its fields are examined directly by uu, so your declaration needs to provide at least the following fields: struct direct { short d_reclen; short d_namlen; char d_name[MAXNAMLEN + 1]; }; d_reclen is the length of the structure minus the size of the unused portion of d_name at the end of the structure. d_namelen is strlen(d_name). d_name is the name of the next file in the scan, with a terminating '\0'. It is important for the structure 'direct' to be defined using "struct" insted of "typedef". -- The type 'DIR' declared with "typedef". This is a private structure used by the ndir routines and should contain all the static data related to a single invocation of the ndir routines. It is important for 'DIR' to be defined using "typedef" instead of "struct". (Note this is the *reverse* of the structure 'direct' above.) -- The routines opendir(), readdir(), and closedir(). Which opens a specified directory, read the next file entry from an opened directory, and close an opened directory, respectively. ndir.c - "Berkeley-style" directory scanning routines. This file contains a set of routines similar in functions to the Berkeley-style directory scanning routines. These routines are used only by uu, not mail, and only the opendir(), readdir(), and closedir() routines are used, and therefore need to be implemented. Eventhough the ndir routines should be capable of mutliple concurrent invocations using separate (DIR *)'s, uu only uses one invocation of it at a time. If your system's file name is mono-case, then your readdir() routine should always return the file name field (d_name) in all lowercase. Any questions about porting uupc to other machines/operating systems, and comments and suggestions about this writeup should be directed to one of the e-mail addresses listed at the end of this file. If you do decide to start porting uupc to a new machine/operating system, please drop us a line as well. We might even be able to save each other some duplicated efforts! UUCP: {seismo,ihnp4!alberta,uw-beaver,uunet}!ubc-vision!van-bc!uupc Internet: uupc@van-bc.UUCP ------- -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532 SHAR_EOF chmod +x 'README.PORT' fi # end of overwriting check if test -f 'README.INFO' then echo shar: will not over-write existing file "'README.INFO'" else cat << \SHAR_EOF > 'README.INFO' August 9, 1987 uupc Questions and Answers uupc Development The following is some commonly asked questions about uupc and, of course, the answers to these questions. 1. What does "uupc" stands for? It is an acronym for "UUcp for PC's", but it is also a pun on uucp, which is in turn an acronym for "Unix to Unix CoPy". 2. What does uupc do? It gives a personal computer the capability to become a "node" in the UUCP (or a similar) network and exchange information such as electronic mail and USENET news with other computers on that network. 3. What personal computers does uupc runs on? Currently it is available for the Apple Macintosh, Atari ST, Commodore Amiga, and IBM PC (and compatibles) with DOS. More computers and operating systems will be able run uupc in the near future. (IBM PC with MINIX is a likely next candidate.) 4. Does uupc require me to leave my computer on all day to wait for incoming mail? No. Most people only use uupc to call up their neighbouring system to send and/or pickup mail at times convenient to them. Outgoing mail are also spooled to disk and do not need to be send immediately to your neighbouring system after it is composed. However, uupc can also be set up on a personal computer to wait for incoming call continuously and act as a "mail-hub" to relay messages for other systems if you choose. 5. What do I need to have to get uupc up and running on one of the above personal computers? You need a neighbouring system to communicate with. This system can be either a UNIX system, another personal computer running uupc, or any other system that can talk UUCP's 'g' protocol. You would also need to have the appropriate C compiler for your personal computer if you have received only the source for uupc. 6. Is the source to uupc publicly available? Yes. It was posted to the USENET newsgroup comp.sources.misc in August 1987 and is available from (at least) any site which archives this newsgroup. If you have trouble locating a copy of the uupc sources, please drop uupc Development a note through one of the e-mail addresses listed at the end of this file. 7. What does the uupc software consists of? It consists of two programs, uupc and pcmail. uupc is an automated files transfer program, similar to /usr/lib/uucico in UUCP, and mail is a mailer user-interface, like mail(1) in UNIX. 8. What are the typical use of these programs? uu is used to accept incoming file relayed to you through your neighbouring machine and deliver outgoing file to your neighbouring machine for forwarding to other machines. In most cases these "files" contain electronic messages which are to be used with the mail program. pcmail is used to read incoming mail delivered by uu, and compose outgoing mail for delivery with uu. However, it can also be used to transfer files to/from other systems that is reachable through electronic mail. 9. What do I need to do to get uupc running on my personal computer? You would need to obtain the binaries of uupc for your computer by either compiling the uupc sources on your machine or obtaining the uupc binaries from someone who has a copy. You would also need to arrange to have your neighbouring system to recognize your system as one of their neighbouring systems in the network. The procedures for this varies, you should contact the people who manage your neighbouring system for about details. 10. Does uupc supports more than one neighbouring systems? Yes, it can support multiple neighbouring systems. The mail software will currently always route outgoing mail through one of these systems, but a future version of this software will allow multiple forwarding machines for outgoing mail. 11. Is uupc the same program on all systems it runs on, or is it actually a different program for each of the systems? It is the same program across all systems, with the exception of the system-dependent code, which is different from system to system. The user-interface and command line options for uupc are also uniform across all the systems it runs on, so there is no need to learn a new program when you use uupc on a different computer. The uniform user-interface also makes it easier to use uupc on different computers at the same time. 12. If I don't like the mail program's simple user-interface, are there any alternatives? Since a mailbox can be easily converted to a simple text file, alternative mailer can be easily written to accomodate different needs. At the very least, you will be able to use your favorite text-editor to read your incoming message and compose your outgoing message. Future release of uupc will include mailers for the different systems which will take advantage of special features only availabe on the systems they run on (e.g. window and mouse). 13. What if I want to port uupc to another personal computer not presently support by uupc? First you should read the file UUPORT.INF, which should be available from the same source you obtained this file from. If you cannot locate a copy of this file, then please send a request for it to uucp Development at one of the e-mail addresses listed at the end of this file. After you have read the above file and decided that you still want to do a port of uupc to a new machine/operating systems, please drop uupc Development a note at one of the the e-mail addresses listed at the end of this file. This way we will at least be able to save each other from duplicated efforts. Who knows? We might even have a version for ready for your system when you call to tell us that you are about to begin your port. 14. Who/what is the "UUPC Development Team"? The original software (dcp) was done by Richard H. Lamb. Modified to run on the Mac by Stuart Lynne. Atari ST by Lawrence Harris. Amiga by Jeff Lydiatt. IBM PC by Samual Lam VMS (not available yet) Lawrence Harris 15. What is the copyright status and distribution policy of uupc? The dcp portions of uupc are Copyright (c) Richard H. Lamb. Modifications Copyright (c) Stuart Lynne Mail, PCMail Copyright (c) Stuart Lynne Mac software Copyright (c) Stuart Lynne Amiga software Copyright (c) Jeff Lydiatt Atari software Copyright (c) Lawrence Harris IBM software Copyright (c) Sam Lam In general we are promoting the use of this software on a "public domain" basis. You can use for your own use, and can give copies of the source code to anyone, provided you provide this information to them. 16. If I have more questions, comments, or suggestions about uupc, where should I send them? Please send them all to us at uupc Development at one of the e-mail addresses listed below. We also welcome any bug fixes and improved/new code for uupc that you might want to share. uupc Development can be reached at the following e-mail address: uupc@van-bc.UUCP This is routed to the uupc mailing list and a local news group for discussion of uupc software. To join the mailing list send a request to: uupc-request@van-bvc.uucp 17. Can I get Binary Versions of uupc mailed to me. Yes and no. No we cannot email binaries to you at this time. Yes, if you send a self addressed / stamped (international coupon) mailer with appropriate diskettes (2) we will attempt to return them to you with the appropriate version of the software. We plan to make a binary posting to the appropriate Usenet comp.binary newsgroups in the late fall, or early next year when the software is a bit more functional, better documented and easier to install and operate without the source. Mail your disks to: UUPC Request C/O Stuart Lynne 225B Evergreen Drive Port Moody, BC, Canada, V3H 1S1 -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532 SHAR_EOF chmod +x 'README.INFO' fi # end of overwriting check # End of shell archive exit 0 -- {ubc-vision,uunet}!van-bc!sl Stuec/*/*/upc.a: ' dou