Re: 8-bit unzip utility

[mdj <mdj.mdj@gmail.com>]

On Jun 21, 5:12 pm, pau...@saaf.se (Paul Schlyter) wrote:

> > Clearly BRUN UNZIP ZIPFILE.ZIP will issue a syntax error under ProDOS
> > or DOS 3.3. I assumed everyone here knew what I meant. Obviously I was
> > mistaken ;-P
>
> You are in error as well.....
>
> Perform this experiment:
>
> 1. Rename some binary Apple DOS file to   "UNZIP ZIPFILE.ZIP".  Yes, that's
> a legal Apple DOS filename, which can contain embedded spaces and dots.
>
> 2. Now, issue the command "BRUN UNZIP ZIPFILE.ZIP".  Surprise!  It won't give
> you a syntax error, instead it will run your binary file "UNZIP ZIPFILE.ZIP".
>
> 3. The next time you want to claim something - test it first!   That's an easy
> way to avoid making erroneous claims.....   ;-)

LOL! I think I'm (finally) beginning to grok your sense of humour :-)
Sorry for the delay...

> Commandline arguments in the Apple DOS environment would have to follow the
> syntax:
>
>     BRUN UNZIP,ZIPFILE.ZIP
>
> The comma is here important - it informs the CLI that the filename ends after
> "UNZIP", and that "ZIPFILE.ZIP" is an extra argument.  Of course the Apple DOS
> CLI doesn't recognize "ZIPFILE.ZIP" as a valid commandline argument, and will
> therefore issue a syntax error.
>
> However the command
>
>     BRUN UNZIP ZIPFILE.ZIP
>
> will, by Apple DOS's CLI, be interpreted as if "UNZIP ZIPFILE.ZIP" was the name
> of the binary file to be run.  If that file doesn't exist, Apple DOS's CLI
> will of course issue an error - not a syntax error, but instead a "file not found"
> error.
>
>
>
> >> Apple DOS 3.x contains three parts:
>
> >> 1. The command-line interpreter
> >> 2. The File Manager
> >> 3. RWTS
>
> >>> so you'd need to construct some sort of wrapper program
> >>> that handled argument passing, etc.
>
> >> That ought to be included in cc65 already -- how else can the runtime
> >> library of cc65 manage to fill the argv[] array with proper contents?
> >> Quite naturally, unzip uses argc/argv to fetch its input arguments.
>
> >> (I'm here making the optimistic assumption that cc65 will produce
> >> executable binaries for the Apple II, but maybe that assumption is false).
>
> > I assume it treats the declaration as int main(void) on the Apple II,
> > which is perfectly acceptable under the C standard(s).
>
> No it's not -- a declaration  "int main(int argc, char *argv[])"  should
> not be treated as if it had been  "int main(void)",  or else main() will
> pop some garbage value from the stack believing it's argc, interpreting
> it as the number of cmdline arguments supplied, and then go on getting
> a lot of garbage argv's as well.   It's never a good idea to not supply
> parameter values to a function which expects them....
>
> Instead, a zero should be pushed on the stack so that "int main(int argc, char *argv[])"
> will consider argc to be zero.   Perhaps another zero can be pushed so that main()
> also will consider argv to be NULL.  THAT is acceptable according to the C standard.

That's what I meant, and I'm relatively sure that's exactly what the
INIT phase of a cc65 binary does.

> > I'm sure it could be modified *easily* to supply such parameters should
> > the environment actually support it.
>
> The easiest way would be to write your own main wrapper.  First you rename your
> original main() to e.g. main2(), then you write a new main():
>
> int main()
> {
>     /* Code which fetches cmdline parameters, by a dialog with the user */
>     /* or in some other appropriate way.  This code should of course    */
>     /* also define, and assign suitable values to, argc and argv        */
>
>     /* Now, call your original main() */
>     return  main2( argc, argv );
>
> }
>
> Doing this will take perhaps half an hour.....

Yep, that would work fine.

> FYI:  ZIP files are binary files.....
>
> Translating from ASCII text to Apple II text is a matter of flipping the
> high bit.  That should go into the library routines for reading/writing files
> while in text mode only, not in binary mode.  The text mode should also take
> care of translating the end-of-line character between LF and CR, as needed.

What I meant, was recognising and translating the numerous file
extensions used to denote files that will contain ASCII text, which
will need to be saved as TXT files. Easily done with regexp if that
library is available on the C implementation in question.

Matt