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@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@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 | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >>> On September 24, 2025 2:26:08 AM Mark Waddingham via use-livecode >>> <use-livecode@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 ~ m...@livecode.com ~ http://www.livecode.com/ >>> LiveCode: Build Amazing Things >>> >>> _______________________________________________ >>> use-livecode mailing list >>> use-livecode@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
