Changes between Version 1 and Version 2 of Ticket #14753


Ignore:
Timestamp:
Dec 15, 2023, 11:34:54 PM (5 months ago)
Author:
dwatteau
Comment:

Actually, the crash when reading an original resource fork (which is not macbinary-encoded, but just copied as-is to the local HFS+/APFS volume) is there on modern macOS, too.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #14753

    • Property Summary SCUMM: OSX PPC crash with misread local Macintosh resource forks → SCUMM: OSX crash with misread local Macintosh resource forks

  • Ticket #14753 – Description

    v1 v2  
    11Both an Engine-SCUMM and Port-OSX issue, I'd say...
    22
    3 On branch-2-8 on OSX PPC. The original Indy3 and Monkey1 Macintosh binaries have been copied "as-is" from the HFS disks to the local HFS+ filesystem, so the resource forks are still there. But, strangely, upgrading from ScummVM 2.7.1 to ScummVM 2.8.0pre, it looks like the resource fork is not properly read by ScummVM on OSX PPC anymore (it does work on modern macOS).
     3On branch-2-8 on OSX PPC. The original Indy3 and Monkey1 Macintosh binaries have been copied "as-is" from the HFS disks to the local HFS+ filesystem, so the resource forks are still there. But, strangely, upgrading from ScummVM 2.7.1 to ScummVM 2.8.0pre, it looks like the resource fork is not properly read by ScummVM on OSX anymore.
    44
    55The original Macintosh releases of Monkey1 and Indy3 now trigger crashes on this port, which didn't happen on 2.7.1. 2.8.0 now makes use of the original Macintosh binaries (for original GUI and improved sound), but (AFAICS) the engine doesn't check for the proper format of those resources, so if invalid content is read, the engine crashes.
    … …  
    1414}}}
    1515
    16 Of course, users should follow our guide about preserving the resource forks, but the crash is probably "not nice" (we could maybe at least check for a 0-byte file?). Moreover, on OSX PPC, reading the local resource fork used to work (without any need to macbinary-encode it).
     16Of course, users should follow our guide about preserving the resource forks, but the crash is probably "not nice" (we could maybe at least check for a 0-byte file?). Moreover, on OSX, reading the local resource fork used to work (without any need to macbinary-encode it).