[REQ] Support for InstallShield v3 Archives (".Z")

[vmlemon]

Is your feature request related to a problem? Please describe

It may be useful, to support extracting InstallShield v3 archives, since some installers which use these, only have 16-bit runtimes, which won't run with CrossOver/WINE, on ARM64 Macintosh systems. These archives aren't supported by the "unshield" utility, or Keka, at present.

Examples of these archives are available, in the Windows subdirectory, of the ISO from https://www.macintoshrepository.org/6896-webobjects-4-0-1.

Describe the solution you'd like

It should be possible to extract files from these archives, to a directory, with a name matching the archive.

Describe alternatives you've considered

I found an implementation of the compression algorithm, at https://slackbuilds.org/repository/14.2/system/isextract/, and was able to compile it on MacOS 11.6 (ARM64), although it lacks support for associating files with directories, and is awkward to use. I also tried "unshield", from HomeBrew, but this is incompatible with this archive format generation.

I am using Keka 1.2.13, on MacOS 11.6, on an ARM64-based system.

[aonez]

Still having some random issues but coming for sure.

[aonez]

Here a test build:

https://github.com/aonez/Keka/releases/download/dev-test-builds/Keka-1.2.19-dev.r4698.7z

I've tested it from 10.10 to 12.0 Monterey.

[vmlemon]

Here a test build:

https://github.com/aonez/Keka/releases/download/dev-test-builds/Keka-1.2.19-dev.r4698.7z

I've tested it from 10.10 to 12.0 Monterey.

Thanks for working on this, and the test build! Looks like it at least works, for some of the archives, on the WebObjects CD image, although I'm still searching for other installation archives, to test it with (harder, than you'd expect, even thinking about software issued in that era). :)

[vmlemon]

I also saw the issue with the directory creation dates, but I suspect that's down to either a quirk of the MacOS VFS layer, or the file format not storing a creation date/time, for directories, as far as I'm aware - so, it's not a big deal, personally. (The main thing, is being able to extract the files, themselves)...

[aonez]

for some of the archives, on the WebObjects

I've tested all in the Windows folder without issues. It failed for you on any?

directory creation dates

In all the decoders I've found there was no directory date read from the header. I can investigate more but without a known date for verification it may be impossible to be sure of the extracted data.

[vmlemon]

for some of the archives, on the WebObjects

I've tested all in the Windows folder without issues. It failed for you on any?

directory creation dates

In all the decoders I've found there was no directory date read from the header. I can investigate more but without a known date for verification it may be impossible to be sure of the extracted data.

Aah, yes - all of the archives worked, with the original implementation of the codec, but I only got around to trying a few of them, with your Keka build, and had no problems with extracting files from them - all of the app bundles have the correct structures, and the other files seem to be unpacked to the right places.

Sorry for not being clearer, but I'm happy with the code, as it stands, right now. :)

[aonez]

Thanks!

I've investigated a few more and can say 99% sure that there's no directory date in the header. I'm pretty sure thanks to the sample file services.Z that only contains a path in the header, even if it results in the creation of two directories:

• Path: Library/System
• Creates two directories, Library -> System

So case closed 😛

[vmlemon]

Thanks!

I've investigated a few more and can say 99% sure that there's no directory date in the header. I'm pretty sure thanks to the sample file services.Z that only contains a path in the header, even if it results in the creation of two directories:

• Path: Library/System
• Creates two directories, Library -> System

So case closed 😛

Aah, fair enough. Some kind of NTFS symbolic link, or junction/reparse point, maybe? But, I don't know if the file format even supports those advanced features, since it's undocumented, to my knowledge.

I spent some time, looking at some other installation media, from that era (some Novell NetWare ISOs, and Petz II games), and it looks like there's a bunch of different InstallShield archive formats (Cabinet, and V4/5, IIRC), supported by the UnShield utility, but they're probably best dealt with, as their own formats...