The manual approval process checks just one thing - the screenshot. When
the stack is converted into a disk image, it is then loaded into Mini vMac
and a screenshot is taken. This screenshot is used as a poor-man's verifier
that the stack will work in the online emulator. In some screenshots, there
are error messages explaining why the stack cannot be opened (more RAM
required, needs a color display, needs AppleScript, etc) and these give a
pretty good indication that the stack will not work in the online emulator.
If the screenshot is of a seemingly-perfectly working stack, then I take
the assumption that the stack will work.
With time, I hope that the online emulator will improve. The Internet
Archive are always experimenting with different ways to improve the
emulation. One particularly interesting one that I think is being talked
about is WebAssembly, which will supposedly improve things quite a bit. In
one of their emulators for another system (think it was a games console)
they recently got saving to work, where it would store changes you made
locally on your machine, and then automatically load them into the emulator
when you went back to play again. So there is definitely progress...
Oh, and if anyone in this group has uploaded a file and it is still
processing days later, email me the ID (given at the end of the upload
process) or filename of the stack, and I'll give it a poke.
On 7 September 2017 at 07:46, DTS daretospam@[redacted].com[HyperCard] <
> Wow Andrew, thanks for putting these tools and files together!! I hope it
> inspires more people to get stacks out of archives and preserve them.
> Having the screenshots is really useful. I found the online emulator is a
> bit slow and buggy, but I guess that will change in time. At least if it is
> something interesting, it is easy to download a disk image and open it in
> mini vMac.
> I am curious, what does the manual approval process entail?
> On Tue, Aug 15, 2017 at 5:52 AM, Andrew Ferguson
> andrewferguson500@[redacted].com[HyperCard] <HyperCard-Mailing-List> wrote:
>> Hi Uli,
>> Thanks very much for that (didn't realise it was so easy!). I've updated
>> the system so it now supports raw HyperCard stacks, as well as stuffit
>> expander-archives and disk images. The backend all runs on Linux, but there
>> is a handy utility called hattrib (part of the hfsutils package) that can
>> edit the type/creator code of files in HFS disk images - the syntax is
>> identical to the setFile utility you mentioned, but with hattrib in place
>> of setFile.
>> On 14 August 2017 at 20:13, Uli Kusterer Witness.of.TeachText@[redacted].net>> [HyperCard] <HyperCard-Mailing-List> wrote:
>>> On 14. Aug 2017, at 20:26, Andrew Ferguson andrewferguson500@[redacted].com>>> [HyperCard] <HyperCard-Mailing-List> wrote:
>>> > Oh, and does anyone know if there is a way to force HyperCard to open
>>> a stack that is missing its resource fork? I've had quite a few uploads of
>>> raw stacks missing their resource forks, and this would be very useful.
>>> You mean HyperCard just won't recognize them as stacks? Set their file
>>> type/creator code to STAK/WILD using ResEdit, that should make HyperCard
>>> recognize a file as a stack.
>>> Of course, the resource fork contains icons, cursors, XCMDs, XFCNs,
>>> AddColor information and sounds, so if the stack had those originally, the
>>> stack will still not work, but really setting the file type and creator
>>> should be all that's needed.
>>> I think there were a few XCMDs for setting a file's type/creator (check
>>> the Developer Stack 1.3r, ISTR that contained an external to do that, and
>>> Rinaldi likely had one as well), or alternately you can look for FTyper and
>>> MakeFTyper, which let you create a little droplet that changes type and
>>> creator of files that are dropped on it. You can also use the SetFile
>>> command line tool that comes with macOS X (Or maybe it requires Xcode to be
>>> installed), like SetFile -c WILD -t STAK /path/to/file
>>> -- Uli Kusterer
>>> "The Witnesses of TeachText are everywhere..."