lwv27@CAS.BITNET (11/21/90)
Now that comp.sources.apple2 is begining activity, I am sure that the amount of source code will increase. What is needed is a port of the programs provided by the moderator and friends into a format which is compatible with the entire Apple II line: Apple II thru Apple IIgs. C code is not going to make it - too many folks stuck with too many options. Either a .system type program, or an Applesoft program is likely to be the most portable. While someone is at it, a similar type thing for uuencode/uudecode would probably be useful until a Unix/MSDOS/VMS/other version of a BINSCII encoder is available. -- Larry W. Virden Business: UUCP: osu-cis!chemabs!lwv27 INET: lwv27%cas.BITNET@CUNYVM.CUNY.Edu Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614 America Online: lvirden
gwyn@smoke.brl.mil (Doug Gwyn) (11/22/90)
In article <9011211229.AA29386@lilac.berkeley.edu> lwv27@CAS.BITNET writes: >Either a .system type program, or an Applesoft program is likely >to be the most portable. >While someone is at it, a similar type thing for uuencode/uudecode >would probably be useful until a Unix/MSDOS/VMS/other version of >a BINSCII encoder is available. I have both of these on my "to do" list. The AppleSoft version is not needed yet, since there hasn't been anything other than archivers and UNIX-based code posted at this point, all of which so far require that the user have a C environment, but you're right about the need for a version that Apple IIs without a viable C environment can use. The sources newsgroup was not expected to have any binaries posted to it, thus no need for uuencode/uudecode. However, there may be a SLIGHT use for those in cases such as an Apple II emulator, where some of the associated data files simply MUST be provided in binary form. This is discouraged unless absolutely necessary..
msuacm@plains.NoDak.edu (MSU ACM Student Chapter) (11/22/90)
I'm probably putting a foot or two in my mouth in saying this but I think the reason a UNIX or MSDOS version of Binscii doesn't exist is that it needs to know the start and ending addresses of the files along with the filetypes and some other stuff. Unix doesn't really have filetypes to speak of, it has links, directories, files, and some other strangeness, but they don't really have a filestart attribute that you (maybe it's just me) can read. The file length attribute is no problem for either PC's or Unix's but I think it's the lack of relevent data that's stored in Unix/PC directories that makes a Unix/PC binscii just vaporwear for the time being. Eric Ondler <msuacm@plains.nodak.edu>
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (11/24/90)
In article <6893@plains.NoDak.edu> msuacm@plains.NoDak.edu (MSU ACM Student Chapter) writes: >have a filestart attribute that you (maybe it's just me) can read. The >file length attribute is no problem for either PC's or Unix's but I think it's >the lack of relevent data that's stored in Unix/PC directories that makes >a Unix/PC binscii just vaporwear for the time being. The fact that UNIX and MeSsy-DOS don't use true filetypes is irrelevant. I have NuLib running on a Sun-3. When you create a NuFX (read: ShrinkIt) archive with NuLib, you can specify the filetype (and auxtype, I think) that gets stored in the archive. You can even set an environment variable to provide a default; a "setenv NULIBOPT filetype=TXT" will tell NuLib to archive files as text files unless you tell it otherwise. (BTW, I noticed one funny thing about NuLib: it runs under UNIX (in my installation, anyway), but it makes the archive look as if it was created under ProDOS. Will ShrinkIt only work with archives that were created under ProDOS?) ----------------------------------------------------------------------------- Scott Alfter _/_ / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/
v38611d@taltta.hut.fi (Tero Korento) (11/25/90)
In my home directory I have sciibin, a version of binscii written in C. I have no idea where I got it from and I dont have the source code left. It has during the last years unpacked hundreds of postings, so that I could read them with nulib,(a C version of shrinkit) and determine wether I was going to download them to my apple or not. I don't see the problem? --- Tero Korento ---