Re: WANTED: Information on Apple II copy protection-- .SDK & archiving

[Rubywand <rubywand@swbell.net>]

tward@XXXXenteract.com writes ...
> 
> Rubywand <rubywand@swbell.net> wrote:
> >      An .SDK file is an .SHK file. Even so, there is some reason for
> > using the ".SDK" extension.
> 
> They are very different formats, assuming the suffixes are being used
> properly. SHK is a file archive, SDK is a disk archive. On the Apple II
> platform itself, the only time SDK should be used is for non-ProDOS disks
> or in cases such as the Apple Installer or Print Shop where certain disk
> naming conventions must be followed that would be lost in a file archive. ....

     There are cases where these guidelines will fall short. A DOS or
ProDOS game, etc. may incorporate storage features which would be lost
were just the files to be saved. For example, parts of the program or
blocks of data may be recorded on tracks without being included in any
file. There are many ways in which a 'ProDOS' game or whatever can be
'disk-copiable' or, even, 'sector-copiable' without being successfully
'file-copiable' to a standard ProDOS diskette.

     Another consideration is that de-protected (i.e. copiable) 5.25"
ProDOS wares were, after all, designed to run from 5.25" diskette. An
.SHK file implies that the software can be transferred to any ProDOS
media, including hard disk. If, however, a game believes it is okay to
write its High Scores directly to Block $00F, the user's hard disk could
have its directory trashed.

     An .SDK file says "this game runs from diskette". Unless a README
file says transferring to HD is okay, users have some warning that the
transfer involves some risk. 

     Of course, if you may _know_ that a particular game works fine when
just the files are copied, there is no need to save the entire diskette.
Otherwise, especially with de-protected 5.25" wares, it is best to save
'the whole thing' in an .SDK file or a disk image file.


> 
> SDK archives will almost always be larger than equivalent SHK archives,
> even if you zero the unused tracks, because the whole disk is being
> archived, not just the individual files.
>
> Then there are those evil SEA self-extracting archives. Did you ever
> notice that GSHK will =not= recognize one of these unless its filetype is
> correct?

     Not sure. It's one of those things you tend to 'discover' and,
then, forget. As you say, GSHK will refuse to unShrink an .SEA file
with, say, a TXT filetype.



> GSHK will recognize SHK and BXY archives regardless of filetype
> (as long as you tell it to do so.)

     The same is true for ".SDK" archives of ProDOS diskettes and
GSHK-created ".SDK" archives of DOS 3.3 diskettes.


> So if a newbie downloads a SEA and has
> no idea he's supposed to set the proper filetype, he won't be able to
> unpack the archive. Binary II helps here, but again the newbie must know
> how to handle it.
>

     The problem with the above is that, if all goes well, you are
obtaining a small bit of convenience-- the .BXY file will arrive as an
.SEA type file and auto-unShrink on the GS when executed-- for a rather
high overhead.

     Mainly, the cost is confusion and botched uploads and downloads.
Over the past few years there have been several threads which dealt with
nothing but problems with .SEA downloads, A2 vs. Mac .SEA formats,
mixing up Binscii with Binary II, and "corrupted" downloads of Binary II
prefixed files by emulator users.

     It is interesting that the only case in which a Binary II prefix is
needed is for preserving filetype for an .SEA self-extracting archive.
The only ShrinkIt archive which needs to be self-extracting is GSHK
itself. And, the only reason for preserving filetype is to avoid having
to click File Manager from the NDA menu, and change the filetype to $B3.

     In your example, the file could just as well have been a plain .SHK
file with no Binary II prefix. The file arrives with whatever filetype,
the user runs GSHK, the file is unShrinked and that's that.



Rubywand