In the Classic Macintosh world back in the day it was important to use compression tools to keep files small and also allow you to send Macintosh files through the internet. Floppy disks could only hold a small amount of data so utilizing compression was a way to use the space effectively. I have already made posts on BINHEX and DiskDoubler which where also used for similar purposes. The most popular compression software for Macintosh is Stuffit, which used .SIT and .SEA extensions. One of the other often used tools was called Compact Pro.
Compact Pro, originally know as Compactor, developed by Bill Goodman in the early 1990’s and was quite popular. It was generally faster in its ability to compress and decompress files on the Macintosh. By 1995 the last version was released and by 2002 the software was officially discontinued.
Also, Macintosh files often contain a Resource Fork to go along with the data. Archiving files within a Compact Pro archive could contain both forks along with creation, modification dates and the finder Type/Creator codes. Then an archive could be transferred through the internet or on a non Macintosh file system without loosing these key bits of information.
You can see from the image below, the compression of a PICT file retained the resource fork and finder data with an impressive 60% savings in size.
Compact Pro could also segment an archive into multiple parts. This was advantageous when needing to copy a larger file on to a set of floppy disks, or for transferring smaller files through the internet and combined later. Segments would be extracted by opening the final segment.
The other nifty feature of Compact Pro is it could create a Self-Extracting Archive. Archiving as an SEA, would compress the file into an archive, but contained within an application which could extract the archive without the use of the the full Compact Pro application. This was used mainly for use on distributed Macintosh file system disks as the application could only be run on a Mac OS system.
Let’s look at the actual Compact Pro file format.
hexdump -C CompactProTest.cpt | head 00000000 01 01 6f 07 00 00 00 cb 80 35 04 56 00 60 50 50 |..o......5.V.`PP| 00000010 00 50 50 00 60 05 60 50 00 00 00 00 00 00 00 00 |.PP.`.`P........| 00000020 00 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00 |..`.............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 |...............0| 00000040 00 00 04 60 00 05 00 06 00 55 40 00 00 00 00 00 |...`.....U@.....| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 60 00 00 00 |............`...| 00000070 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 |.....@..........| 00000080 00 00 00 00 00 00 00 00 05 08 00 01 20 00 00 00 |............ ...| 00000090 00 20 01 10 88 c1 04 f6 05 41 3e 47 56 e4 09 5f |. .......A>GV.._| hexdump -C CP-s01.cpt | head 00000000 01 01 90 69 00 00 10 55 80 46 78 67 77 67 78 67 |...i...U.Fxgwgxg| 00000010 86 88 09 89 9a 70 8b 90 ba 97 0a a7 90 87 a6 bb |.....p..........| 00000020 90 8a a0 90 ab b7 aa a0 a0 80 a8 a0 98 89 00 9a |................| 00000030 99 80 98 99 69 a9 60 0a 79 ab 86 0a b7 98 a7 90 |....i.`.y.......| 00000040 98 a0 97 7a 90 00 09 00 07 77 80 00 aa 9b 00 ba |...z.....w......| 00000050 99 a0 90 00 08 08 a0 8a 08 a0 00 00 b9 b0 09 7a |...............z| 00000060 08 0a aa 90 0a aa 00 00 98 60 90 b9 9b 9a 9a 57 |.........`.....W| 00000070 a8 88 bb aa aa 00 00 77 89 7a 09 b9 89 79 9b 78 |.......w.z...y.x| 00000080 86 80 8a 96 65 55 56 66 65 17 00 02 24 35 46 47 |....eUVfe...$5FG| 00000090 57 67 67 78 88 8a 70 80 80 90 00 a0 90 a0 00 00 |Wggx..p.........|
The file format is not recognized by PRONOM, and as you can see from the headers above, identification is not easy as there are no magic bytes. Using Unarchiver they identify as Compact Pro.
lsar CP-s01.cpt CP-s01.cpt: Compact Pro CP.PICT
The only bytes which seem to be consistent is the first two, but “01 01” is not a signature which is unique to Compact Pro. The Unarchiver uses a more complicated calculation of file size and the CRC for identification, from what I can tell.
hexdump -C CP-s01.sea | head 00000000 01 01 8a 89 00 00 10 55 80 46 78 67 77 67 78 67 |.......U.Fxgwgxg| 00000010 86 88 09 89 9a 70 8b 90 ba 97 0a a7 90 87 a6 bb |.....p..........| 00000020 90 8a a0 90 ab b7 aa a0 a0 80 a8 a0 98 89 00 9a |................| 00000030 99 80 98 99 69 a9 60 0a 79 ab 86 0a b7 98 a7 90 |....i.`.y.......| 00000040 98 a0 97 7a 90 00 09 00 07 77 80 00 aa 9b 00 ba |...z.....w......| 00000050 99 a0 90 00 08 08 a0 8a 08 a0 00 00 b9 b0 09 7a |...............z| 00000060 08 0a aa 90 0a aa 00 00 98 60 90 b9 9b 9a 9a 57 |.........`.....W| 00000070 a8 88 bb aa aa 00 00 77 89 7a 09 b9 89 79 9b 78 |.......w.z...y.x| 00000080 86 80 8a 96 65 55 56 66 65 17 00 02 24 35 46 47 |....eUVfe...$5FG| 00000090 57 67 67 78 88 8a 70 80 80 90 00 a0 90 a0 00 00 |Wggx..p.........|
The self extracting archive has the same basic structure. I have also noticed on all the archive samples I have, the byte at offset 8 is always “80”. This could be significant.
Another thing to note, when looking at a segmented archive, the first two bytes are in sequence, 0101 for the first, 0102 for the second and so on.
CompactPro could use some further investigation. You can find quite a few on site such as: https://websites.umich.edu/~archive/mac
For now, it would be good to add the CPT extension to PRONOM with the name CompactPro Archive.
Just wanna say, I quite enjoy reading your blog posts about file formats. I created dexvert and this article helped me add better support for self-extracting compact pro files. So thanks again 🙂
Thanks! I appreciate all the samples you add to the file formats wiki. Very helpful.