Re: 8-bit unzip utility

[pausch@saaf.se (Paul Schlyter)]

In article <1182335566.934403.229400@o11g2000prd.googlegroups.com>,
mdj  <mdj.mdj@gmail.com> wrote:

>>> Then there's the hassle that there's no command line interpreter on
>>> the Apple II,
>>
>> REALLY?   So you mean I cannot type e.g.
>>
>>     BRUN UNZIP
>>
>> on the Apple II ?????   <g>
>>
>> There is a command line on the Apple II, but it doesn't take arbitrary
>> arguments.  Any argument which doesn't follow the prescribed syntax
>> are treated as syntax errors - and those arguments which do follow the
>> prescribed syntax aren't passed by the program, but are consumed by
>> the "shell" (i.e. DOS 3.x or ProDOS).
>>
>> But something like:
>>
>>     BRUN MYPROGRAM,S5,D2,A$5000
>>
>> *is* a command line, and it's interpreted by DOS 3.x.  Or do you think
>> it's a GUI?  <evil grin>
> 
> I'm sorry, I had assumed the readers of c.s.a2 would understand my
> meaning, which was that the standard interpreter extension to BASIC
> does not support a DOS/CPM/Unix style environment,

....ooops!  Be careful here .... note that "DOS" is an ambiguous term.
And I think you'll agree with me that Apple DOS certainly supports an
Apple DOS environment !!!!!!

Don't take so much for granted.....   ;-)

> and thus the tool
> would either have to provide its own, or be compatible with one of the
> many 'shell' environments available for ProDOS 8. Unfortunately for
> user of !x, it's likely to be compatible with x :-)
> 
> 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.....   ;-)


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.

> 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.....

>>> More luck may be had with the WDC's 65xx toolchain, which is
>>> supposedly an ANSI C implementation, but it more than likely produces
>>> 65C02 code, and quite possibly uses the Rockwell/WDC extensions as
>>> well.
>>
>> That should be runnable on the IIe, which also is an 8-bit computer.
> 
> IIe's and IIc's generally shipped with NCR 65C02's, which won't
> support the BBR/BBS instructions, and those should be considered
> vetoed on the Apple II.
> 
>> Also: if WDC's 65xx toolchain is any good, it ought to have some
>> compiler switch which makes it generate working code also for the
>> original 6502.  But maybe WDC's 65xx toolchain isn't any good?
> 
> Dunno. I'd not be surprised if it was designed specifically for CMOS
> generation 6502s, considering how much simpler the 'C02 instructions
> and addressing modes make the compiler writers life, and considering
> it's offered as a toolchain to support current generation WDC
> products.
> 
> Of course, this doesn't address the fact that you'll need further code
> to translate files that most likely contain ASCII text into TXT files
> on the Apple II. Since there is already available tools to do this
> job, the "port Unzip" option is a pretty poor one.

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.


-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/