whitney@think.COM (David Whitney) (05/31/88)
I've started working on a possible EXECUTIONER replacement. It uses
6-bit codes, but it won't barf on the ascii-ebcdic conversion as it
uses only alphanumeric codes. It won't make EXEC files, so it will
work more in the likeness of BINHEX on the mac. I don't see it being
any more complicated to use than executioner currently is, and it will
be more reliable, as I'll put CRC error checks into the output file.
The propsed name for it will be BINSCII, unless too many people find
that to be silly. Do you all approve, or should I just punt it? I've
already worked out the major parts of the program, I just need to
perfect the user interface. I'm also trying hard to make it
compatabile for use on all //s. (jeez it's hard to avoid those 65c02
codes!)
thanks for any opinions...
David Whitney, MIT '90 Still learning about my Apple //GS
{the known universe}!ihnp4!think!whitney and all of its secrets. Any and all
whitney@think.com technical info appreciated.
DISCLAIMER: If they only knew what I was doing and saying here...SEWALL@UCONNVM.BITNET (Murph Sewall) (06/01/88)
>I've started working on a possible EXECUTIONER replacement. It uses >6-bit codes, but it won't barf on the ascii-ebcdic conversion as it >uses only alphanumeric codes. It won't make EXEC files... HURRAY for you! While 4bit coding works, it takes up more space than should be necessary. It would be nice if the "decodeing" procedure can be built into something EXECable so Ted Medin can incorporate it in his EZ Install (that 57K KER3xx.2 file causes some people problems). > ...Do you all approve, or should I just punt it? Surely you jest? You KNOW it's a good idea. --------------------- Disclaimer: The "look and feel" of this message is exclusively MINE! (subject to change without notice; void where prohibited) ARPA: sewall%uconnvm.bitnet@mitvma.mit.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut
JDA@NIHCU.BITNET (Doug Ashbrook) (06/01/88)
> Yes, one is going to need binscii to un-convert files. Not a real hardship, > I'll distribute binscii in executioner format. eventually, it will replace > executioner. Those who don't have it could send me mail, and i'll send them a > copy. I think that this means that BINSCII format would have a very serious disadvantage over EXECUTIONER format. One of the nice things about EXECUTIONER format is that you do not need to have the EXECUTIONER program just to unpack a file. However, if I receive a file in BINSCII format, I must first have the BINSCII program before I can unpack the file. Maybe once BINSCII becomes as popular as BLU, everyone will have a copy of BINSCII and this will be a moot point. But until then, it will not be nearly as convenient. Maybe the additional compression (while avoiding the ASCII-EBCDIC translation problems) will make it all worthwhile. I will keep my fingers crossed. Give some consideration to whether you could design the BINSCII files so that they could unpack themselves (as EXECUTIONER files can do). That sounds like a good challenge for a bright student :-) ------------------------------------------------------------------- J. Douglas Ashbrook (301) 496-5181 BITNET: JDA@NIHCU ARPA: jda%nihcu.bitnet@cunyvm.cuny.edu National Institutes of Health, Computer Center, Bethesda, MD 20892
wack@udel.EDU (Andrew Wack) (06/01/88)
In article <8805311708.aa19483@SMOKE.BRL.ARPA> JDA@NIHCU.BITNET (Doug Ashbrook) writes: >> Yes, one is going to need binscii to un-convert files. Not a real hardship, >> I'll distribute binscii in executioner format. eventually, it will replace >> executioner. Those who don't have it could send me mail, and i'll send them a >> copy. > >if I receive a file in >BINSCII format, I must first have the BINSCII program before I can >unpack the file. Maybe once BINSCII becomes as popular as BLU, >everyone will have a copy of BINSCII and this will be a moot point. >But until then, it will not be nearly as convenient. Maybe the Better yet, how about incorporating the unpacking into blu? Then everything could be done in one step, sort of like the way blu separates binary II files and automaticaly unsqueezes them if necessary. I would find this much more convenient since I usually have to use blu anyway. This would also be easier for anyone running a "shell" program other than basic. For instance, everytime I down load something I have to start up basic from APW so I can unpack the file. Being able to do all this with one program would be great! ------------------------------------------------------------------------------- ARPA: wack@udel.edu Gravitation cannot be held responsible for people falling in love -- Albert Einstein. -
neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) (06/01/88)
In article <8805311328.aa13074@SMOKE.BRL.ARPA> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: >>I've started working on a possible EXECUTIONER replacement. It uses >>6-bit codes, but it won't barf on the ascii-ebcdic conversion as it >>uses only alphanumeric codes. It won't make EXEC files... > >HURRAY for you! While 4bit coding works, it takes up more space than >should be necessary. It would be nice if the "decodeing" procedure >can be built into something EXECable so Ted Medin can incorporate it >in his EZ Install (that 57K KER3xx.2 file causes some people problems). > What we really need is EXECUTIONER in 5-BIT packing mode, that is 32 combinations. That can be done with just letters and numbers. Now no mailer should choke on that. 5-BIT is better than 4-BIT but not as good as 6-BIT. I think 5-BIT would be a good compromise. Maybe the original EXECUTIONER can be modified to handle the 5-BIT scheme. It might not be too much work to get it done. What you think about that? neighbor@csd4.milw.wisc.edu _______________________________________________________________________________ | arpanet: neighbor@csd4.milw.wisc.edu | | UUCP: ihnp4!uwmcsd1!csd4!neighbor | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
whitney@think.COM (David Whitney) (06/02/88)
In article <5936@uwmcsd1.UUCP> neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) writes: > >What we really need is EXECUTIONER in 5-BIT packing mode, that is 32 >combinations. That can be done with just letters and numbers. Now >no mailer should choke on that. 5-BIT is better than 4-BIT but not >as good as 6-BIT. I think 5-BIT would be a good compromise. > >Maybe the original EXECUTIONER can be modified to handle the 5-BIT scheme. >It might not be too much work to get it done. > >What you think about that? Is your complaint the fact that the files won't be EXECable, or that you mistrust my 6-bit codes? I'll be using the upper and lower-case alphabet, the ten digits, and two more common chars (say, "<" and ">") which makes 64 codes. I see no trouble in this. By not making the files EXECable, I can make it easier for the user to deal with the files. Each file will have a start mark and an end mark. This way, you don't have to delete headers/trailers. EOLs don't have to exist in any particular way (they'll be ignored). Files will not be restricted to fit in the 48k address space of ProDOS 8 (no, this isn't going to be a ProDOS 16 prgm, it just deals with things in a better way). Multiple files could be sent in the same piece of mail as each file is seperated by a start/end mark. Beginning to see the advantages? For those who use a command shell (such as APW, Davex, or whatever), Binscii will be no more of a pain to use than Executioner is, as one has to run BASIC.SYSTEM in order to EXEC the file. The only thing is, one will need Binscii to un-code a file, but I see no disadvantage to that. Lots of people are going to want Binscii to post (lots want Executioner - I for some reason get requests to mail it off to people an awful lot) their files... Of course, since Executioner is free, this will have to be free. If I should even ask for 10 cents, nobody would buy it. I have no problem with this. David Whitney, MIT '90 Still learning about my Apple //GS {the known universe}!ihnp4!think!whitney and all of its secrets. Any and all whitney@think.com technical info appreciated. DISCLAIMER: If they only knew what I was doing and saying here...
denbeste@bgsuvax.UUCP (William C. DenBesten) (06/02/88)
From article <8805311708.aa19483@SMOKE.BRL.ARPA>, by JDA@NIHCU.BITNET (Doug Ashbrook): > Give some consideration to whether you could design the BINSCII files > so that they could unpack themselves (as EXECUTIONER files can do). > That sounds like a good challenge for a bright student :-) But, as the current virus scare has pointed out, it is better not to use self unpackers, since you are then creating a perfect chance for someone to do something unexpected to your machine. Unix folks use SHAR archives to to transfer files. Every once in a while, someone will make one that automatically invokes the compiler, and installs the program. This tends to bother people, as they usually want to look things over before giving any CPU time up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- William C. DenBesten | denbeste@bgsu.edu Dept of Computer Science | CSNET denbeste%andy.bgsu.edu@relay.cs.net Bowling Green State University| UUCP ...!cbosgd!osu-cis!bgsuvax!denbeste Bowling Green, OH 43403-0214 | ------------------------------+---------------------------------------------- There is no difference between theory and practice in theory, but there is often a great deal of difference between theory and practice in practice.
lwv@n8emr.UUCP (Larry W. Virden) (06/03/88)
In article <21475@think.UUCP> whitney@godot.think.com.UUCP (David Whitney) writes:
-->
-->Is your complaint the fact that the files won't be EXECable, or that you
-->mistrust my 6-bit codes? I'll be using the upper and lower-case alphabet,
-->the ten digits, and two more common chars (say, "<" and ">") which makes
-->64 codes. I see no trouble in this.
-->
My only 'complaint' is wondering why you just dont change executioner to user
your new set of characters? I have talked to Bredon and HE doesnt care - he
says that is why he released the source code to executioner - so that others
could do with it what they wanted. This is the best of all worlds in my mind.
-->By not making the files EXECable, I can make it easier for the user to deal
-->with the files. Each file will have a start mark and an end mark. This way,
-->you don't have to delete headers/trailers. EOLs don't have to exist in any
-->particular way (they'll be ignored). Files will not be restricted to fit in
-->the 48k address space of ProDOS 8 (no, this isn't going to be a ProDOS 16 prgm,
-->it just deals with things in a better way). Multiple files could be sent in
-->the same piece of mail as each file is seperated by a start/end mark. Beginning
-->to see the advantages?
I can see advantages to ignoring headers and trailers, but you dont HAVE to
delete them - you can say exec file,r15 and the first 15 lines will be
skipped, etc. What WOuLD be nice is a small interface to run which figures
out how many lines to skip and then does the exec.
As for linefeeds vs carriage returns vs both - I dont know how to rectify
that one - I wish floyd would add a few more options to his pgm previous
known as TEX to cover all the alternatives.
If you are going to set this thing up, how about making an include capability,
so that folks who post multipart postings can not worry about forcing folks
to glue pieces back together.
-->
-->For those who use a command shell (such as APW, Davex, or whatever), Binscii
-->will be no more of a pain to use than Executioner is, as one has to run
-->BASIC.SYSTEM in order to EXEC the file. The only thing is, one will need
-->Binscii to un-code a file, but I see no disadvantage to that. Lots of people
-->are going to want Binscii to post (lots want Executioner - I for some reason
-->get requests to mail it off to people an awful lot) their files...
-->
-->Of course, since Executioner is free, this will have to be free. If I should
-->even ask for 10 cents, nobody would buy it. I have no problem with this.
-->
How about making this thing a system type pgm - one that can be exec'd from a
shell? Also, how about allowing command line arguments? Then Davex/ECP8
users can use it just a little more nicely. Talk to David Lyons and Don Elton
for details...
--
Larry W. Virden 75046,606 (CIS)
674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817
osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET)
We haven't inherited the world from our parents, but borrowed it from our children.whitney@think.COM (David Whitney) (06/09/88)
Everything has been put on hold as I have been informed that something
like this already exists. It's called BINHEX (yes, for the //) and it
apparently already does a lot of what has been suggested here. I've sent a
request to the author of BINHEX for a copy of the program - we'll see what it's
like when I get it.
David Whitney, MIT '90 Still learning about my Apple //GS
{the known universe}!ihnp4!think!whitney and all of its secrets. Any and all
whitney@think.com technical info appreciated.
DISCLAIMER: If they only knew what I was doing and saying here...