* UPLOADING

- INTRODUCTION

We recommend that you use YA-NewsWatcher version 4.2.6 for uploading
binaries, or else YA-NW 3.1.8 if your Mac doesn't meet the minimum
system requirements for 4.2.6. The following instructions assume
that you are using YA-NW to upload. Note that MT-Newswatcher
(Multi-Threaded Newswatcher) versions earlier than 3.0 cannot be used
for uploading binaries; they don't provide that feature.

######################################################################
# --- R E A D M E --- #
######################################################################
### VERY IMPORTANT WARNING ### [22 Apr 2000]: Several people have
reported in ABMA that binaries that were uploaded with YA-Newswatcher
versions 5.0 and 5.0.1 appear to be somehow corrupted and are not
decodable after downloading, no matter what decoding program is used.
This is definitely a problem. It's being caused by a bug in YANW that
corrupts BinHex uploads when two upload streams are active at once.
Until a new 5.x release of YA-NW (5.0.2) has replaced the old ones,
PLEASE DO NOT USE YA-NW VERSION 5 FOR UPLOADING BINARIES.
USE VERSION 4.2.6 INSTEAD. This does not affect downloading, so if
you don't do any uploading of binaries at all, then it's OK to install
YANW 5.0 or later.
######################################################################

MT-NewsWatcher (MT-NW) version 3.0 and later can be used to upload
attached binaries. However, we recommend that you do not use MT-NW
for uploading. This is because MT-NW uses a different method of
putting together the Subject headers in the articles with attached
binaries that it posts. YA-NW always puts the file name first,
preceded by a hyphen and a space. This convention has been in use
for years; users of ABMA are accustomed to it, and many of them
have newsreader filters in place that will highlight or sort articles
with attached binaries based on that leading substring. MT-NW
interferes with this by putting the file name last and putting the
hyphen and space between the subject information and the file name.
The result is that many ABMA folks are inconvenienced and might not
notice binaries whose Subject headers don't follow the convention.
So if you want your uploads to reach as many people as possible,
then please use YA-NW for posting.

Please be careful. When you post, often you may be breaking the law
of some country. Software copyrights are a serious issue to software
publishers, software developers, and many government institutions.
ABMA is a very small and almost insignificant drop in the pirating
bucket, but much of what happens here is illegal. There is no polite
way to say this: COVER YOUR ASS. I strongly recommend that you NEVER
use your real name when posting; USE A NICKNAME INSTEAD! The other
rule is: NEVER e-mail stuff to anyone unless you absolutely trust
that person. Even then, it is best to avoid e-mailing. It leaves
a very clear and specific trail, right to YOU. Also, if your ISP
and/or newsreader is putting your IP address in your posted messages,
don't even THINK about posting binaries. An IP address and a host
name are all that anyone needs to find out exactly who and where you
are. You have to understand that posting commercial, copyrighted
software for public use is ILLEGAL, especially if you are in the USA.
So please watch out for yourself! IF YOU ARE IN DOUBT ABOUT YOUR
ANONYMITY, DO NOT UPLOAD BINARIES; think of your own security first.
Your contributions are definitely appreciated by the ABMA community,
but we don't want the price that *you* pay for those contributions
to be a big legal hassle.


- SETTING UP YA-NEWSWATCHER

In YA-NewsWatcher's preferences, go to 'Message Files'. Set the 'News
Part Size' in KB to between 200 and 495. Most news servers will only
accept attachments that are less than 1000 KB, many even less. It has
been mentioned in the group that MediaOne/AT&T/RoadRunner cable servers
have a 512K part-size limit, and that some ISPs' servers have a limit
of 500K. Therefore, if you want to make sure that as many people as
possible can download your posts, it's best to use a part size that's
slightly under 500K, like 485 or so.

Set the 'News Encoding' to BinHex, *NOT* UUencode. (This is very
important!) Go to the 'Miscellaneous Options', and make sure that
the 'Are You Sure Alert on Posts' is unchecked. Go to the 'Message
Options' and be sure to enter an alias or nickname for yourself under
the 'Full Name'. It is also advisable to enter alias information for
'Mail Server' and 'Email Address'.


- ENCODING THE FILE FOR POSTING

The ideal here is to have all of the required files needed to install
the application you are posting in a form that other people can use
with the least amount of effort. The format to use is indicated to
the right of the = sign, with the stuff in () as optional.

A word of warning: If you use StuffIt version 5.x to compress your
uploads, then be sure to use the "Fast Compression Mode" and not the
"Maximum Compression Mode". Otherwise, the resulting compressed
files may be corrupted. Decompression on pre-G3 machines will also
be *very* slow. If you can, please try to refrain from using
StuffIt 5 to compress the files that you're going to post;
StuffIt 4 is better.

The following is a list of the possible formats that an application
installation will come in:

Folder = Sit or Disk Image
As is. This form is common with most shareware and small, simple
programs. There is no installer. The application is ready to run as
it is.

Installer = None
This is a common format for all sorts of applications. It is a simple
installer application that can be run from any place; on the desktop,
from a floppy, from a CD, from a disk image, etc. Most installers are
already compressed, so compressing them further with StuffIt is mostly
a waste of time and a minor annoyance to the downloaders.

Disk Image = None (or Sit)
A pre-made disk image. You will find this on CDs and it is a common
form on the Internet. It is possible that you will want to compress
this into a StuffIt file. Many times disk images are already
compressed, so that further compressing them is a waste of time.
Be conservative about compressing a large disk image. Often it takes
a very long time to stuff/unstuff and yields very little space savings.
The rule of thumb is to test first: compress the image to see if any
significant space is saved.

Installer w/files or CD = Disk Image
This is one of the most common formats for all sorts of applications.
It is an installer and one or more associated files, often with lots
of files and folders. Usually these are run from a disk image.
Rarely, they are run from a folder.

'K, this is tricky...

The deal with CDs is that sometimes you have to have an EXACT duplicate
in order for them to work. That can sometimes be accomplished with a
disk image, but not always. This will usually mean a VERY large upload
(600 MB). There are now plenty of folks with cable and DSL lines who
can easily afford to upload entire CDs in a night without batting an
eyelash. There is also a group just for entire CDs called
. And there are plenty of CD
installers that will work IF you have the right files and pathnames
on them. Knowing what files/folders are needed is very tricky and
comes with experience, educated guesses, and luck. Sometimes (rarely)
you can simply drag the files off the CD to a folder on your hard disk.

There is no set way to do this. You can ask the group or go with trial
and error:

Make a guess at which files and folders are needed for the installation.
(Obviously Chicken Eyeball 5.7 should install just fine without the
302 MB movie file called "Demo of our office party".)

Make an empty disk image that will accommodate all of the files you
think are required.

Copy all of the files to the disk image. Make sure to match file names
and paths exactly.

Remove the CD and try to install the application with a full install.
If it works, and if you can use the installed app, then it will
probably be fine.

Although DiskCopy works great for almost all disk images, it will not
make a bootable CD copy. This is very important, since certain CDs
need to be bootable to use the software properly. For instance,
if your machine won't start from a hard drive, you may need to boot
from a CD. In order to make bootable CDs, we recommend that you
use Toast or CD-Copy (which makes a Toast image file, also an *exact*
duplicate, which Toast is generally not able to produce). You can
install either Toast or CD-Copy without needing a burner, and save
the entire CD as a "Disk Image".

Some posters will segment a disk image or StuffIt file, then compress
the segments. This has been known to save many MB of space on CD
images that are mostly empty space. Note that if you recompress
segments it is advised that you state so somewhere in your posting,
as this can lead to much confusion among new members who are trying
to decode your post.

Floppy = Image and Sit
Make images of each floppy. I recommend putting all of the image files
in one Sit archive.


- MAKING A DISK IMAGE

Use DiskCopy 6.3.2 or later, or ShrinkWrap 3.5 or later. Reportedly,
versions of ShrinkWrap much earlier than 3.5 may have some serious
flaws, including not being able to handle the HFS-Plus file-system
format.

You will have to decide what format: Read/write, Read-only, or Read-
only/compressed.

If there are many smaller files on a CD and/or it is not a single
installer file only, then go ahead an use Read-only/compressed. This
can take a long, long time, so be patient. Otherwise use Read-only.

In the Preferences, make sure that 'Verify Checksums' is checked.
Also make sure that 'Zero Blocks' and 'Mount Afterwards' are unchecked.

Make sure that you have enough room on your hard drive to save the
image files.

Drag and drop the disks onto DiskCopy's floating window.

If you are making an image from scratch, follow the above procedures,
except instead of dragging a physical disk onto a window, go to
DiskCopy's menu and select Image: Create New Image.


- NAMING THE POST

There is much debate in ABMA about this. If you leave the actual file
names intact, that makes it very easy for casual onlookers (software
developers, search engines, and feds) to find your posts (and maybe
you yourself). Renaming them with phonetic spelling, abbreviation,
or loopy names (such as Pigital Deformer instead of Digital Performer)
can protect you and ABMA, but it also makes it harder to know what
the file really is. If you rename your post, be sure to include the
real information in a "Read Me" file, not in the message area of the
post. There is no right or wrong here, though I [LuvBunny] personally
do not like to make it too easy. I don't want every lurker coming
through our doors to instantly figure out what's going on. It's too
risky. What I do like is people who get excited about all the software
and participate in ABMA rather than just passing through.

[Editor's note: Remember that you can Rot-13 any selection of clear
text in your message---for instance, in "part zero" of a multi-part
binary post---before posting it. In YA-NW, Rot-13 is in the Edit
menu; just select the sentence or paragraph that you want to
hide, and choose "Edit->Rot-13". This will effectively hide that
particular text from search and archival engines, but the rotation
can easily be undone by anyone reading the message.]


- SEGMENTING THE FILE

If your post is larger than 1 to 3 megabytes, then you should segment
the file into smaller pieces before doing the upload.

Use DropSegment 4.0 from the StuffIt Deluxe 4.0 package, or DropSegment
from a later version of StuffIt Deluxe if you're using one.

The size of the segments should be between 1 and 3 MB each. You can
set the size of the segments in DropSegment's preferences.

Go ahead and drop the file onto DropSegment. (If you want to change
the prefs temporarily, for one run of the program only, you can hold
down the Option key as the program launches; that will take you into
a one-time Preferences dialog in which any changes that you make will
be temporary.)

When you are done, you might want to change the file names a little.
I like to pad single digits with a zero so that the order of the files
in the Finder window is correct.


- INFORMATION TO INCLUDE WITH YOUR POST

It is strongly recommended that you include some information with your
post in a separate post or even as a text-file attachment to a separate
post (readme). Alternatively, you can include this in the "part zero"
of the post if your newsreader creates one (but also see the above
recommendation about using Rot-13 to hide sensitive information in
the body of a message). Here are a few suggestions about what to
include:
- Serial numbers
- CRCs
- Total number of segments
(StuffIt segments, *not* article parts made by NewsWatcher)
- Segment size
- Full application name and publisher
- Application name and version used to make the archives
- Archive format: e.g., installer, disk image, or .sit
- Notes regarding the application and any particulars about
installing it


- UPPING THE DAMN THING!

Fire up YA-NW.

Select alt.binaries.mac.applications in your saved groups or full
group list window.

From the menu, go to 'News' and select 'New Posting'.

Enter 'alt.binaries.mac.applications' in the 'Newsgroups' if it is not
already entered there.

Enter a 'Subject'. The (altered) post name is good to put here.

Enter some contents in the message window. I always put "Please see the
'Read Me' for more information regarding this post."

In the message window, select the button that has an icon of a document
with ones and zeros on it, meaning "binary attachment".

A window called 'Attached File Settings' will open. Double-check to
be sure that you are using BinHex encoding and an appropriate part size
(not too small). Then select the 'Set' button.

Navigate to the folder containing your segments and select the first
one, then press the 'OK' button.

Repeat these steps for each binary segment until you have the entire
post ready to go.

Select the 'Post' button in the upper right corner for each of your
message segments, or use Command-E. This will send the messages to
YA-NW's queue. Make sure that when you are done, the queue is not on
hold (paused), or else your files will not be sent!

There are auto-posting programs that you can use after you get the hang
of the basics. Some of these are TrickyPost, YA-Autoposter,
sQuidOmatic,
and Poster Child. Ask about them in the group if you want more
information about them.

P.S. Go slow. CHECK YOUR FIRST POST BY DOWNLOADING IT AND DECODING
IT, TO MAKE CERTAIN THAT IT HAS BEEN DONE CORRECTLY. (This is
important; you can catch a lot of errors this way.) Often, there can
be all sorts of problems that you have no control over. Usenet is
frequently subject to entropy. It's just the way it is, so save
yourself some frustration and be prepared for things to go wrong
or misbehave. It takes practice. Go with small posts first as you
learn. Be polite to the ABMAites; if you're rude, the safety comes
off the flame-throwers and you've got to start ducking fast. Ask for
help and watch how others do it. Once again, remember that test posts
should be sent to or ,
not to ABMA.


- HOW FILE CORRUPTION OCCURS

(This section was provided by xxx. This is an explanation of what can
happen if you select anything other than "BinHex" as the encoding method
when uploading a Mac binary to a Usenet newsgroup.)

Where the corruption occurs is that half the file is missing. Many Mac
files, e.g., apps, have two parts: one is called the data fork, and the
other is called the resource fork. Resource forks contain modular
data that can easily be altered, removed, added to, or replaced.
You need a special program such as ResEdit [RESource EDITor] to view
or modify resource forks.

For 8-bit binary data to survive transfer via the 7-bit Usenet system,
it must be encoded. Resource forks are Mac-only; other systems neither
use nor recognize them, as all of their files are essentially one big
data fork. If you use a non-Mac encoding system to encode a Mac file
that contains a naked (unencoded, unstuffed) resource fork, then the
information in the resource fork will not be seen, copied, encoded,
transferred, or preserved. It's as though you were to send a pair
of shoes to a friend via mail order, but only the left shoe is packed
and sent. It doesn't do your friend much good.

UUencoding is a non-Mac (UNIX) encoding scheme. It doesn't preserve
resource forks. BinHex IS a Mac-based encoding scheme. It preserves
resource forks. Sometimes it doesn't matter. For example, JPEG and
MP3 files are data-only; they contain no resource forks. UUencoding
works fine for them. Mac installer files usually contain resource
forks, and using UUencoding will delete the resource fork whereas
using BinHex encoding will preserve it.

A grey area is StuffIt files and segments. Stuffing a file with a
resource fork puts both parts of the file into a single data-fork-only
archive. The resource fork of a StuffIt file contains no essential
data. It is perfectly possible to transfer a StuffIt archive, even
if it contains a file with a resource fork, using uuencoding, base64,
or any Usenet encoding scheme. However, once decoded, the files will
generally lack the proper type and creator codes, and will usually
appear as text files (which of course they are). For single-archive
".sit" files, simply dropping the file onto StuffIt Expander should
cause it to expand correctly. For multi-part archives (Seg1, Seg2,
etc.), the type and creator codes of the individual segments need
to be changed before StuffIt will recognize and join them. This is
easily done. The problem is that this process can mask corruption.
When a BinHexed StuffIt file is properly processed, the corresponding
file type, creator, and icons are attached to the decoded file. If
they fail to appear, it is a sign that something went wrong. This is
not a foolproof check for corruption, but it is usually accurate.
Uuencoded Stuffit files always decode as plain text, whether they are
good or corrupt. There is no early warning of corruption. This can
be dangerous.