HC stack with no resource fork

[Mark Clark]

emulators—here’s an easy one to try 

mac getutm .app

> On Sep 24, 2025, at 1:12 PM, Randy Hengst via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I used to do a lot with HyperStudio…and have many old stacks. Has he tried the free trial of HyperStudio 5? … I’m not sure it will work with current MacOS. I’ve not tried it on windows. In my basement, somewhere, I have an old mac that should run HyperStudio. I can do some checking next week when I have some time.
> 
> take care,
> randy
> 
>> On Sep 24, 2025, at 12:57 PM, J. Landman Gay via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> I think I figured it out. The stack has an extension ".stk" which I shouldn't have ignored. It appears that's a HyperStudio stack. When viewed in a text editor there are no decipherable words, it's all gibberish. That's why when I added a creator and type so I could open it in HyperCard in an emulator, HC also said it wasn't a HyperCard stack.
>> 
>> Even if I could find a copy of HyperStudio to run in the emulator, I wouldn't know what to do with it. I feel sorry for the guy, there are 9 stacks containing his entire family history. All gone.
>> 
>> If anyone here thinks they could help I'm sure he'd appreciate it.
>> 
>> --
>> Jacqueline Landman Gay | jacque at hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>>> On September 24, 2025 2:26:08 AM Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
>>> 
>>> On 2025-09-24 05:36, J. Landman Gay via use-livecode wrote:
>>>> Actually, maybe the resource fork isn't the problem. What are the usual
>>>> reasons a stack isn't a stack?
>>> 
>>> So I don't think the engine has ever looked at the resource fork of
>>> hypercard stacks when it tries to load them...
>>> 
>>> The only reason a stack isn't considered a stack is if the engine can't
>>> load it - i.e. there's an error while parsing the binary data.
>>> 
>>> Its possible the stack has been compressed with Stuff-It or similar
>>> (which was quite common as doing so allowed the resource fork to be
>>> preserved alongside the data fork, but without the resulting file having
>>> a resource fork) - if that is the case here then that would be why the
>>> engine doesn't like it.
>>> 
>>> If you send the stack to support we can take a quick look :)
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> --
>>> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
>>> LiveCode: Build Amazing Things
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode