Support loading Dreamcast games from 7z archives

[richstokes]

Dreamcast .7z files are currently hidden from the game list or routed to the arcade loader. This adds loading for archives containing one GDI, CUE, CDI, or CHD image and its referenced tracks, while preserving named arcade ROM sets.

The existing disc readers now accept a storage provider. The archive provider caches required members in exclusively created temporary files, keeps independent reader positions, and removes the files when their last reader closes. Archive paths stay inside the archive; multiple disc images are rejected with a clear error. Game scanning inspects archive metadata without extracting disc data, and Libretro uses the same platform detection.

This also fixes sequential reads, UTF-8/long filenames, failed-open cleanup, undefined CRC lookup, and concurrent CRC initialization in the existing 7z reader. No new runtime dependency is required. README documents archive layout, temporary disk space, and the memory cost of solid archives.

Validation on Ubuntu 24.04 / Linux ARM64:

• Standalone Debug test build and full Debug Libretro build succeeded.
• All 27 focused archive/disc tests passed, including 16 new tests. Synthetic fixtures cover all four disc formats, solid/non-solid archives, nested Unicode paths, reads beyond 64 KiB, shared track files, malformed archives, traversal attempts, arcade detection, and cleanup after success/failure.
• Broader suite: 151 tests passed with seven existing failures excluded. AicaArmTest.LogicOpsTest, TimerTest.smallTCOR (abort), and all five SDLControllerMappingTest cases reproduce on unchanged upstream 59ed35a7e in this environment. Filter: -AicaArmTest.LogicOpsTest:TimerTest.smallTCOR:SDLControllerMappingTest.*.
• The seven low-level archive tests also passed under ASan/UBSan, with alignment checks disabled for the bundled LZMA SDK's existing unaligned loads.
• Windows/UWP and other platform runtime behavior have not been tested locally.

[flyinghead]

As this is a new feature, this should go to the dev branch.
This has been requested by some users. However I wonder if this should be limited to .7z archives. Can this be done for .zip files too or is there a limitation somewhere?

[JoeMatt]

As this is a new feature, this should go to the dev branch. This has been requested by some users. However I wonder if this should be limited to .7z archives. Can this be done for .zip files too or is there a limitation somewhere?

this would actually be nice for a pretty simple reason, if all archive containers that multi-file MAME style roms also support single file formats, a lot of "is this archive a container for a rom folder or just a single file compression convenience" type logic can be removed.

If you can just mount the compressed arcvhice as a VFS then it really doesn't matter, just scan the contents as if a folder.

At least that's my impression. In iFly I had to resort to this, since iOS users are so used to local file management and lack knowledge on uncompressing archives on-device, I pre-process files before handing off to the default flycast importer to handle various container formats that confuse the core importer logic, so I decompress in place and then hand off the path, but I can see the core logic also benefitting from an agnostic approach to compressed containers.

Additionally, you could support a single archive for all BIOS files and just read with on-the-fly decompression if the archives are treated as VFS's.

Perhaps that's beyond the scope of this ticket, but on the topic of archive support in general, I could see full support agnostic of use (rom, bios, virtual folder, rom pack), extending and simplifying other file parsing code paths.

[richstokes]

If y'all want to take this and move it on to the dev branch/expand with regular .zip files, feel free! I would personally suggest land-and-expand here; get these 7z changes in as its a quick win (and a real quality of life improvement) and then look at adding zip/revisiting the compressed archive logic holistically.

FWIW, I mainly added this as my GDEMU drive can already read .7z files, but I had to extract them every time I wanted to load them on Flycast :-)

I tested these changes on latest macOS, and seems to work as expected for me.