From - Tue Sep 9 22:51:37 1997 Path: netaxs.com!news-out.microserve.net!news-in.microserve.net!zdc-e!super.zippo.com!lotsanews.com!feed1.news.erols.com!howland.erols.net!news2.digex.net!swbell!not-for-mail From: Rubywand Newsgroups: comp.sys.apple2 Subject: Re: Help with a new //gs...(me too!) Date: Tue, 09 Sep 1997 04:34:52 +0000 Organization: Southwestern Bell Internet Services, Richardson, TX Lines: 73 Message-ID: <3414D1EC.1A8C@swbell.net> References: <5uiu2j$s43$2@opal.southwind.net> <340DEFD2.609D@swbell.net> <34114C19.5FCF@swbell.net> <34142d06.1465745@news.bconnex.net> NNTP-Posting-Host: ppp-207-193-9-61.hstntx.swbell.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02E (Win16; I) Xref: netaxs.com comp.sys.apple2:122007 Jeff Blakeney writes ... > > On Sat, 06 Sep 1997 12:27:05 +0000, Rubywand > 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