Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1187

Re: Archiver Project for the 8 Bit Apple II - Request for Comments

Show all headers | View raw

"Antoine Vignau" <antoine.vignau@laposte.net> wrote:
>will you support Prodos extended files (those with a resource fork)?
Hi Antoine,

If I do an Orca C Version,  it may; one way at least. But I can't think of a 
single use case where files coming from the Apple //e and ProDOS 8 or DOS 
3.3 would have resource forks, nor where files going to the Apple //e would 
need them. So doing so would be scope creep at this time.

This is not an installer nor a conversion utility. Nor is it meant to 
replace NuLib:

http://www.nulib.com/

or something else Andy has done:

http://www.fadden.com/dl-apple2/index.htm

And like the years it took to develop Convert3200, it would take years of 
dedicated development to build a competitive product to NuLib. The 
programmer would need to be a gifted expert; not your average Apple II 
enthisiast.

The primary goal behind the resurrection of Aztec C was always to simulate 
the perspective of the MS-DOS programmer of the 1980's building programs for 
MS-DOS, CP/M, the Commodore 64 and the Apple //e. Native mode compilers like 
Aztec C68000 for the Amiga are interesting for those whose history is on 
those platforms, and for purists who wish to experience native mode 
development rather than cross-development, or for me in particular as a 
collector.

The primary target user for Aztec C is the Windows User of today, but with 
the ready availability of MS-DOS emulators like DOSBox (and DOSemu on 
Ubuntu) users of other less popular desktops can also have access to the 
Aztec C MS-DOS cross-development retro-experience.

As a work in progress to continue to pursue this primary goal of targeting 
the Windows retro-computing enthusiast who specifically wants to work with 
the Apple //e, I continue to develop and provide 8 bit 6502 demo and example 
programs and code for ProDOS 8 and DOS 3.3 that the average enthusiast can 
easily read, build, and expand on. And documentation. The converters and 
utilities that I write are fundamentally targeted at this living museum 
concept, and obviously they also can be useful on other platforms, or in 
their own right.

Aztec C65 was no longer being developed when the GS was introduced. The 
decline and extinction of Aztec C (and many other C compilers of the 1980's) 
overlapped the release of the Apple IIgs (and the VOC). My work with the 
Super Hi-Res Demos and utilities is in support of that part of history, and 
of course the current history of the Carte-Blanche and the Kegs32 emulator.

I regard each utility and project, program, or demo that I write in Aztec C 
to be what that programmer could have done relatively easily then with the 
tools we Windows users have now, but I shape the scope of this somewhat 
realistically... I don't think resource forks would have been something that 
an MS-DOS programmer working in the Aztec C65 cross-compiler would have 
attempted. Not if he had any brains to put it bluntly.

By the time the GS came along, and ByteWorks Orca Development environment 
became available, the MS-DOS Programmer could not have possibly competently 
developed anything really robust for the GS in Aztec C65; in my view the GS 
supporting ProDOS 8 and DOS 3.3 is like Windows XP supporting MS-DOS 
applications... arguably both systems are emulators for legacy OS's.

A word about Orca C; this is a "next-generation" compiler, and really a 
modern compiler more than a retro-compiler. But was never available in a 
cross-development version. By that time, or shortly thereafter, MS-DOS was 
also dead, 16-bit Windows began to dominate as the World's Most Popular 
Desktop with 90% of Market Share by the mid-90's. A guy was either a Windows 
developer or an MS-DOS developer. Cross-Development shortly reached a very 
specialized level... not for the average developer. Pakages like XVT Design 
and ProGraph appeared. It was a full-time job these GUI's!

The short answer is that memory is extremely tight on the Apple //e so 
additional code not needed for proper archiving of 8 bit ProDOS files and 
DOS 3.3 files will not be included in this project.

Go back to the primary specific purpose of this archiver itself:

1. To pack files together in a HUF Ball to save Apple II disk space and 
increase transfer speed for upload or downloads between Apple II and other 
computers.

The archiver code is derived from the C source for lzhuf compression, by 
Haruyasu Yoshizaki

LZHUF, the algorithm of Haruyasu Yoshizaki's archiver LHarc, replaced 
LZARI's adaptive arithmetic coding with adaptive Huffman.  LZHUF encodes the 
most significant 6 bits of the position in its 4096-byte buffer by table 
lookup.  More recent, and hence more probable, positions are coded in less 
bits.  On the other hand, the remaining 6 bits are sent verbatim.  Because 
Huffman coding encodes each letter into a fixed number of bits, table lookup 
can be easily implemented.

Though theoretically Huffman cannot exceed arithmetic compression, the 
difference is very slight, and LZHUF is fairly fast.

References
  [1] J. Ziv and A. Lempel, IEEE Trans. IT-23, 337-343 (1977).
  [2] J. A. Storer and T. G. Szymanski, J. ACM, 29, 928-951
      (1982).
  [3] T. C. Bell, IEEE Trans. COM-34, 1176-1182 (1986).
  [4] J. Ziv and A. Lempel, IEEE Trans. IT-24, 530-536 (1978).
  [5] T. A. Welch, Computer, 17, No.6, 8-19 (1984).
  [6] J. A. Storer, Data Compression: Methods and Theory
      (Computer Science Press, 1988).
  [7] D. A. Huffman, Proc IRE 40, 1098-1101 (1952).
  [8] R. Sedgewick, Algorithms, 2nd ed. (Addison-Wesley, 1988).
  [9] R. G. Gallager, IEEE Trans. IT-24, 668-674 (1978).
 [10] I. E. Witten, R. M. Neal, and J. G. Cleary, Commun. ACM
      30, 520-540 (1987).

What I have to start with is a fully functional MS-DOS archiver based on 
Yoshi's archiver code noted above with a small memory footprint. Since I did 
the original code I can port it with certainty.

The work buffers will fit into auxiliary memory. The trick will be to page 
these in and out as needed.

I may have to split the Apple II Sys Program into UnHuf2.sys and Huf2.sys to 
get the code to fit with with the buffers. It is tight. The proof of concept 
will compress and decompress one file only, and will be written for the 
Apple II only. It is easy to port from the Apple II after porting from 
MS-DOS to the Apple II. It is also easy to expand functionality after 
getting the basic archiving routines in place.

Simply finishing this, documenting it, and distributing it will be enough 
for me to handle in my spare time, and so for that reason alone, as well as 
the other reasons noted above, GS resource forks will not be supported in 
this project's scope, nor will creating Microsoft Windows File Associations 
or anything of a GUI nature.

There are 3 tiers in this development:

1. The System Layer
2. The Data Layer
3. The UI Layer

The system layer is ProDOS 8 or DOS 3.3 or Win32 or MS-DOS, or other systems 
supported by gcc.

The data layer is not object oriented. It is data only and does not support 
links like resource forks or unix linked files either. The operating system 
takes care of that, and if not it ain't there, nor should behaviour beyond 
what Ansi C provides be supported, because it is non-portable. Data is Data 
and it is binary, period.

File attribute preservation tags in systems that support long filenames are 
portable. My utility CiderTag does support tagging files with File Attribute 
Presevation Tags, so can be used on the Windows or Unix-like command line to 
prepare files for archiving, but this is beyond the scope of this archiver.

There is no GUI in the UI. Two-tiered applications that link to a GUI 
through an API are non-portable. This is a command line utility or 
equivalent only. If the ProDOS 8 or DOS 3.3 versions have a UI, it will be 
because there is no equivalent command-line for these systems.

Those are some of my thoughts. Please take me to task on any of this if you 
wish... especially you Mr. T.

All the Best,

Bill

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Archiver Project for the 8 Bit Apple II - Request for Comments "Bill Buckels" <bbuckels@mts.net> - 2014-03-06 14:54 -0600
  Archiver Project for the 8 Bit Apple II - Request for Comments Antoine Vignau <antoine.vignau@laposte.net> - 2014-03-06 23:30 -0800
    Re: Archiver Project for the 8 Bit Apple II - Request for Comments "Bill Buckels" <bbuckels@mts.net> - 2014-03-07 07:20 -0600
      Re: Archiver Project for the 8 Bit Apple II - Request for Comments gids.rs@sasktel.net - 2014-03-07 09:35 -0800
        Re: Archiver Project for the 8 Bit Apple II - Request for Comments "Bill Buckels" <bbuckels@mts.net> - 2014-03-07 17:31 -0600
          Re: Archiver Project for the 8 Bit Apple II - Request for Comments gids.rs@sasktel.net - 2014-03-07 16:58 -0800
  Re: Archiver Project for the 8 Bit Apple II - Request for Comments Jurai <Jurai@WhereTheHellAmI.???> - 2014-03-08 09:10 -0700
    Re: Archiver Project for the 8 Bit Apple II - Request for Comments "Bill Buckels" <bbuckels@mts.net> - 2014-03-08 20:32 -0600
      Re: Archiver Project for the 8 Bit Apple II - Request for Comments Dagen Brock <DagenBrock@gmail.com> - 2014-03-22 22:27 -0700
        Re: Archiver Project for the 8 Bit Apple II - Request for Comments "Bill Buckels" <bbuckels@mts.net> - 2014-03-23 04:28 -0500

csiph-web