[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help with a new //gs...(me too!)
Jeff Blakeney writes ...
>
> On Sat, 06 Sep 1997 12:27:05 +0000, Rubywand <rubywand@swbell.net>
> wrote:
>
>>
Suppose, however, that you do not yet have a utility to do filetype
changing on the GS? Downloading one of the usual filetype changer
utilities may not be much help because it also ends up on the GS
with the wrong filetype. No way to change filetype means your GSHK.SEA
with the wrong filetype cannot be executed, and, once again, you're
stuck.
<<
>
> If all files that were uploaded were in Binary II wrappers, this
> wouldn't be such a big problem.
>
> If the person is using a communications program on their Apple II and
> sending files via a null modem then there are two possibilities. 1)
> The communications program might automatically strip the Binary II
> wrapper and set the file's name, type, auxtype, etc. 2) The person
> runs the BINARY.DOWN program to strip the wrapper and set the file's
> info.
> ....
All of this was considered. The problem with binary-II is that it
introduces another level of processing along with opportunities for error.
In return, there is virtually no gain. ShrinkIt (e.g. .SHK) files already
retain all filetype, etc. information of contained files; and, .SHK files do
not need to retain their filetype in order to be unpacked.
If we need to make assumptions about an Apple2 user's system, isn't it
at least as reasonable to expect the presence of ShrinkIt and/or GS-ShrinkIt
as it is to expect that a binary-II prefix will be handled correctly? Since
practically all A2 files are now uploaded in .SHK form, an Apple II user
must have some version of ShrinkIt if he/she expects to benefit from
downloads.
On today's net, about the only rationale for binary-II is to preserve
filetype for the GS-ShrinkIt self-extracting archive. Even so, it would
still be necessary to maintain a non-binary-II version because a user in the
process of 'bootstrapping' his/her system might well have no way to remove a
binary-II prefix.
The rationale for a BRUN-able filetype-changer program is that it makes
no special assumptions about a user's system. If the user can get the file
to his/her Apple2 and boot ProDOS, the user can get the filetype-changer up
and running. Once you can set filetype, you can handle the one or two cases
(like GHSK.SEA) where binary-II might have been an alternative.
Granted, in many cases it does no great harm to add a binary-II prefix;
but, then, it seldom does any good. Besides, there are some fairly common
situations where there will be problems.
One is the descriptive Text files commonly uploaded along with .SHK
files to ftp sites. Practically all net access software is going to expect
these to be plain text; the binary-II prefix would corrupt the files.
Another situation is disk image files. These are created on Apple2's,
but, typically, download via software which knows nothing about binary-II to
non-Apple2 machines. Again, the result is file corruption.
Perhaps, there was once a place for binary-II. Had Apple, Inc.
not 'dropped the ball' fifteen years ago, we would, today, be dealing with
an Apple-dominated Internet and, again, binary-II might make sense. As
things stand, binary-II is a questionable solution for a problem which does
not exist.
Rubywand