[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: what are .sdk archives?

mdj wrote:

On Dec 29, 5:30 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:



The key issue is that ProDOS-8 doesn't support a file with the
"extended" storage type.


This is, of course, correct--a pox on the designer who even made
such a choice representable in the ProDOS environment!  Let those
who need forks use HFS!



A bit harsh perhaps - there are other storage types (Pascal areas for
example) that ProDOS utilities correctly avoid, and leave up to the
'owners' to deal with. It's a feature, not a flaw.


You're right, I was harsh--but the total suffering caused by this
somewhat arbitrary choice has far outweighed any suffering it saved.

For one experienced with the Apple II but unexperienced with the
Mac, this is a problem that they will likely work through after
several frustrating attempts.

But for a relative newcomer to the Apple II who tries to get started
using a Mac as an intermediary, the liklihood of them working through
the issue is much less.  I'd guess that a lot of Apple II's sit unused
because their owners couldn't figure out how to get past this problem.


It is only an imprecise (but understandable) expression to refer
to a ProDOS extended file as a forked file.  However, the error
message delivered by 8-bit ShrinkIt is that it cannot open a
"forked file".

For one who inhabits the 8-bit Apple II world, extended/forked
files are inconvenient at best and useless at worst.  It is
reasonable to refer to a file rejected as being "forked" as
a "forked file" even though its non-data fork is null.



LOL, it's certainly a "forking" mess ...


;-)


A standard ProDOS file (storage type of sapling, seedling or tree) has a
directory entry which points to a single data bock (sapling), single
index block (seedling), or second level index block (tree).



An extended ProDOS file (supported by GS/OS and the Mac) adds an
extended key block between the directory entry and file data. The
extended key block contains two partial directory entries to define the
data fork and resource fork of the file (either of which may be empty,
or a seedling, sapling or tree), plus it can store extended information
about the file, which is used for Mac-specific directory information.



Anything claiming that a file is "forked" on ProDOS-8 might be
misleading. It really means the file is extended, which might or might
not have a resource fork.



The extended storage type and extra block are sufficient to prevent
ProDOS-8 from doing anything useful with the file (short of third-party
utilities which do block-level access to the volume).


And this is why I wish that MacOS did not create such files by default
when it doesn't know the type of the file.

Perhaps someone in Mac-land envisioned a world in which 8-bit Apple II's
would be happily juggling ProDOS extended file types--or maybe they just
thought of ProDOS 16 and forgot completely about the myriad users of
Prodos 8.

Adding the extended type to the ProDOS file system was a silly thing
to do, since it breaks every 8-bit utility, sometimes in a "silent",
data-corrupting way.

It would have been perfectly fine for MacOS to default the type of an
"unknown" file to TXT, and any 8-bit application could have easily
interpreted the content of the file or copied it, etc.  The worst
thing that could have happened is that someone could have attempted
to view it or print it as a TXT file, and seen gibberish or screen
weirdness.  ShrinkIt, and every other application that looks inside
a file to assess whether or not it is compatibly formatted, would
have been perfectly happy.



I'd much prefer anything unrecognised be BIN ...


That would be fine, too.  (I'm afraid I still think of the way that
DOS inserted what we now call "auxtypes" into BIN files...)


The mentioned utilities work well for what they were designed for -
principally being shifting AppleWorks and ASCII files back and forth.
The biggest issue I have is ProDOS's view that Filetype $00 (untyped)
being treated as 'bad' was tremendously shortsighted (and/or arrogant)
on the designers behalf. Perhaps we can blame the Apple III design
team for that :-)


Perhaps.  It was certainly appropriated later as an "extended" file
type.  I think it shows the value of reserving a type for files of
"unknown" type, to be treated completely neutrally.

And thinking that files sourced from foreign file systems (like Unix
and MSDOS) would not be a major issue by the early 1990's, even as
the Mac was implementing a FAT file system (along with ProDOS) seems
pretty shortsighted.  Of course, the Internet pushed file exchange
over the edge...


As for 'forked' files, post Apple IIgs (8-bit) system software should
have dealt with such files gracefully. It's the responsibility of any
system with a 'wacky' metadata system to handle foreign content, not
vice-versa.


But to change the file system specs in a non-compatible way _post facto_
is a violation of "Robot's Rules of Order".  ;-)  Architecture evolution
is a foreseable necessity, and there are ways of walling off areas for
future expansion.  The trick is not arbitrarily walling off things that
have significant utility--like moving files from foreign file systems
so that they can be processed by newer applications on older systems.

ProDOS doesn't have any idea what a MIDI file is, but Apple II
applications can certainly recognize and process them usefully--
unless they were downloaded!


I see such problems as a microcosm of a much larger issue which the
industry is only just beginning to deal with.


Compatibility, forward and backward, are issues we have always dealt
with, and formal architectural design of interfaces is one of the
proven techniques for putting off the inevitable ultimate failure.  ;-)

Ultimately, data/code *conversion* is required--usually with far too
little information to guide it.  But in the mid-term, designers should
always aim to minimize the harm for "normal" uses.

One superior way:  allow the *user* to choose the default action when
file type is unknown or unrepresentable.

One of the things I have always found useful on *every* OS except
MacOS is the ability to feed *any* file to almost any application,
so I can, for example, look at an executable as a text file if I
wish.  The notion that the OS should *enforce* associations between
files and applications is one that I've never appreciated.

In a world of standards-based data representations, files are the
currency for conveying information *between* applications, not just
the holder of information for one application.  Many workflows involve
massaging files and passing them on to other applications.  The notion
of an implicit (not just default) association between files and the
applications that created (or last closed) them is less than helpful.

Come to think of it, this is why I like the idea that the "type" of
a file is just part of its name, rather than some magic attribute.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."