TypeStyler

August 21, 2026 by Thor 1 Comment

I make a lot of sample files. Whenever I have access to software I haven’t sampled before, I immediately make a few files to keep for reference. If I am making a signature for those files, I try and find as many versions of the software out there and make sample files from each. This way I can ensure the signature is accurate and possibly distinguish between important version changes. This process works well, but takes some time.

I discovered a flaw in my process recently, which illustrates the need for enough variation in samples to make sense of the file format. I recently made a bunch of samples from an old Macintosh software tool called TypeStyler. It is a pretty amazing early Desktop Publishing tool, with a neat past. The problem turned out to be more revealing about the format than I realized.

TypeStyler was the product of two brothers, Dave and Ken Stillman developed in 1988. It was a very incredible program that helped the Macintosh be a leader in Desktop Publishing and design. They had already made a program called PosterMaker which they sold to Broderbund, and TypeStyler did well under the same Publisher. When the Macintosh turned its focus to MacOS X, the software stalled for a number of years, finally coming back under the Strider Software name.

Let’s take a look at one of the files from version 1.0 of the software.

% hexdump -C TS1-s02 | head
00000000  02 da 02 28 00 00 00 00  00 00 02 35 02 da 02 28  |.?.(.......5.?.(|
00000010  00 00 00 64 02 da 02 28  00 00 00 00 ff ff ff ff  |...d.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 00  |????????????....|
000000b0  00 01 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |.........x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

The first thing I noticed was a repeating pattern. 02 DA 02 28. This pattern seemed important. I could also see it in later versions, but not always exactly the same.

% hexdump -C TS3-s01 | head
00000000  02 d8 02 28 25 21 00 01  00 00 02 db 02 d8 02 28  |.?.(%!.....?.?.(|
00000010  00 00 00 64 02 d8 02 28  00 00 00 00 ff ff ff ff  |...d.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 80  |????????????....|
000000b0  00 10 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |.........x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

I could see this pattern in many of the samples but not all of them, but it seemed inconsistent, not following a pattern based on version. It was then I realized I had seen the pattern before. Specially the pattern seen on line 200 or the 516th byte.

% hexdump -C TS1-s02 | head
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

If you look back at two of the other formats I have discussed on this blog. MORE and Ready, Set, Go! you would see the same pattern in those sample files as well.

% hexdump -C RSG1-s01 | head
00000000  00 78 00 03 00 00 00 48  00 48 00 00 00 00 02 da  |.x.....H.H.....?|
00000010  02 28 ff e1 ff e2 02 f9  02 46 03 47 05 28 03 fc  |.(????.?.F.G.(.?|
00000020  00 02 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000030  00 01 00 00 00 64 00 00  00 01 00 01 01 01 00 00  |.....d..........|
00000040  00 01 27 0f 00 01 00 01  00 00 00 00 00 00 00 00  |..'.............|
00000050  00 00 00 00 00 02 00 19  01 90 00 00 00 00 00 40  |...............@|
00000060  00 00 00 00 00 00 00 00  00 01 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 01 00 48  |...............H|
00000080  00 48 00 48 00 48 00 01  00 00 00 01 00 00 00 01  |.H.H.H..........|
00000090  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C MORE3-s01 | head
00000000  00 06 4d 4f 52 33 00 80  00 00 00 80 00 00 00 78  |..MOR3.........x|
00000010  00 00 00 f8 00 00 01 b4  00 00 02 ac 00 00 00 a8  |...?...?...?...?|
00000020  00 00 11 16 00 00 00 32  00 00 11 48 00 00 00 20  |.......2...H... |
00000030  00 00 11 68 00 00 00 00  00 00 11 68 00 00 00 10  |...h.......h....|
00000040  00 00 11 83 00 00 00 0c  00 00 11 68 00 00 00 00  |...........h....|
00000050  00 00 00 00 00 00 03 54  00 00 0d c2 00 00 11 78  |.......T...?...x|
00000060  00 00 00 0b 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 03 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.....?.(|
00000090  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

How can this same pattern be found in three completely different software titles, from three different developers? Granted they are all originally Macintosh software, but still, there shouldn’t be any common encoding between them. I will admit it took me a minute to figure it out, and I did employ the use of AI to help brainstorm the pattern.

I should have seen it sooner as my background is in commercial printing and I have been using desktop publishing tools for years. You see the most common value in printing with Postscript is the value “72”. 72 is the number of points in an inch which all started with the development of Postscript, originally on a Macintosh. The hexadecimal “00 48” is 72 in decimal in big endian systems like the Macintosh. So the first part of the pattern seen in all three formats is 72×72 values indicating the unit of measurement. The next 4 bytes happen to be the page size in points. “02 DA” is decimal 730 and “02 28” is decimal 552. If you add 60 points used in margins, then you get roughly 8.5×11 letter sized page size. You can see the change here if I save a letter size page out with one portrait and one landscape.

% hexdump -C TS-Letter-Vert | head
00000000  02 da 02 28 00 00 00 00  00 00 02 3d 02 23 01 9e  |.?.(.......=.#..|
00000010  00 00 00 4b 02 da 02 28  00 00 00 00 ff ff ff ff  |...K.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 a3  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |. .......x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

% hexdump -C TS-Letter-Horz | head
00000000  02 28 02 da 00 00 00 00  00 00 02 3d 01 9e 02 23  |.(.?.......=...#|
00000010  00 00 00 4b 02 28 02 da  00 00 00 00 ff ff ff ff  |...K.(.?....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 a3  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |. .......x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 28 02 da  |.....H.H.....(.?|
00000210  ff e2 ff e1 02 46 02 f9  03 45 05 28 03 fc 00 02  |????.F.?.E.(.?..|

The bytes are swapped! Very cool to figure out, but not so helpful in identification as the values could be different in every file. You may have noticed the values in the 4th set of 4 bytes was different in these samples. A little experimentation and it looks like those 4 bytes are the value of what level of zoom is displayed in the software. If at 100%, which is often default, then the values would be the same as the page size, at 50%, they would be half. So also not helpful in identification, but helpful to document.

There are other bytes we can use for identification, the 3rd set of 4 bytes, after many samples made, appear to be representative of the version of software that created the file. The value increases with each version.

% hexdump -C TS1-s01 | head
00000000  02 d0 02 40 00 00 00 00  00 00 02 35 00 b4 00 90  |.?.@.......5.?..|

% hexdump -C TS2-s01 | head
00000000  02 d8 02 28 00 00 00 01  00 00 02 3b 02 22 01 9e  |.?.(.......;."..|

% hexdump -C TS3-s01 | head
00000000  02 d8 02 28 25 21 00 01  00 00 02 db 02 d8 02 28  |.?.(%!.....?.?.(|

% hexdump -C TS372-s01 | head
00000000  02 d8 02 28 00 00 00 00  00 00 02 f9 02 d8 02 28  |.?.(.......?.?.(|

TypeStyler 3.7.2 was the last version before the 9+ year gap before the next release, version 10. So these files will all have the value “00 00 02” then 34 through the hex values up to F9. Many of the point releases I have been able to make samples of have values spanning this gap.

Version	Value	Version	Value	Version	Value
1.0 Beta	00000234	2.0.1	0000023B	3.46.3	000002DB
1.0	00000235	3.2.1	0000023D	3.5.8	000002DC
1.5.2	00000239	3.43.2	000002DA	3.7.2	000002F9

These values are probably a little short for a solid identification. If you have been paying attention, you might have noticed each TypeStyler file also has a large sequence of “FF” values. Majority have 144 bytes worth, starting at offset 28 or 0x1C, there are a random couple files which are slightly different. I think with the two parts, a fine signature can be made and not accidentally identify one of these other desktop publishing formats.

Well, in 2009, the Strider Software company released their TypeStyler software built for MacOS X intel computers after a long hiatus. They added many more features which also meant a change to the file format. No longer did they use a single file to store the graphics, they used the commonly used Apple Package format. In essence a folder with an extension, which when registered with the Mac, appears as a single file. This way you can add all the files you like to the folder and it stays together. Seemed like a good idea at the time.

% tree TypeStyler11-s01.tsdx 
TypeStyler11-s01.tsdx
├── QuickLook
│   └── Thumbnail.png
├── Template
└── contents
    ├── PkgInfo
    ├── TSDoc.tsx
    └── TypeStyler Document.xml

4 directories, 4 files

This new package format has a structure with thumbnail and a contents folder. This folder has an extension of TSDX and within the contents folder an XML file, a PkgInfo, and a TSX file. Let’s look at each of them.

% cat TypeStyler11-s01.tsdx/contents/PkgInfo 
????????%  

% cat TypeStyler11-s01.tsdx/contents/TypeStyler\ Document.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Application Version</key>
	<string>10.0</string>
	<key>images</key>
	<dict/>
</dict>
</plist>

% hexdump -C TypeStyler11-s01.tsdx/contents/TSDoc.tsx | head
00000000  03 18 02 64 24 03 00 01  00 00 03 36 03 18 02 64  |...d$......6...d|
00000010  00 00 00 64 03 18 02 64  00 00 00 00 ff ff ff ff  |...d...d....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 bf  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000e0  00 00 00 00 00 00 00 00  00 00 32 5c 0c 5c 5f 64  |..........2\.\_d|
000000f0  64 64 64 64 64 64 19 19  5c 5c 5c 46 1e 00 42 c8  |dddddd..\\\F..B?|

The PkgInfo file is unhelpful. The XML is semi-helpful, but considering this was a version 11.6 file, the XML displays only 10.0 which I think is in all the samples I have.

The best identification comes from the TSX file, which excitingly looks like the previously format. We have pages sizes in the same place as well as the 144 bytes of “FF” and the values for the version show “00 00 03 36”. This seems to make sense with 03 being a natural increase to the 02 used in the previous versions. Looking at a sample from version 10:

% hexdump -C TyperStyler10-s01.tsdx/contents/TSDoc.tsx | head
00000000  03 18 02 64 00 00 00 01  00 00 03 30 03 18 02 64  |...d.......0...d|
00000010  00 00 00 64 03 18 02 64  00 00 00 00 ff ff ff ff  |...d...d....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 3c  |????????????...<|
000000b0  00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  b3 08 00 00 00 00 00 4d  00 22 01 59 02 33 00 4c  |?......M.".Y.3.L|
00000210  00 21 01 58 02 33 cc d3  e2 06 10 00 00 00 00 00  |.!.X.3???.......|

The version pattern starts fresh with 30! The TypeStyler software is still available, but appears to have stalled again. Version 11.6 was the last version released in 2019, so another 7 year hiatus. Ken Stillman passed away in 2023, further adding to the uncertainty of the future of TypeStyler.

This was a fun exploration of a format beyond the simple identification I usually focus on. With some of the variations I found I came up with this signature for Versions 1-3 of the TypeStyler Document format starting from offset 8

000002[30:FF]{16-20}FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

This signature takes into account the hex values 30 through FF to cover all the incremental updates. Instead of using all 144 bytes of “FF”, I limited it to just 64 bytes to allow for the couple of variations I found. I am not addressing versions 10-11 yet, ther eis no great way of identifying package formats with PRONOM yet. I may add the TSX format by itself, but for now you can find the signature and sample files on my Github page.

Ready, Set, Go!

July 31, 2026 by Thor Leave a comment

By the title you might think this was a post about racing. But this is a file format blog, so we will keep on that topic. When I was in school many years ago, I remember using desktop publishing tools like PageMaker for the first time. When I got a job working for a local commercial printer in the early 1990’s, I was introduced to QuarkXPress. This became a career and I spent the next decade and a half working in the PrePress field. I got to know tools like Quark and InDesign extremely well. But even before these layout tools became what they are today, there was an early entry into the desktop publishing market.

Ready, Set, Go! was the “Ultimate Page Processor” released in 1985 for the Macintosh by Manhattan Graphics Corp. But had started advertising as early as Summer 1984.

For a few years it was one of the best layout tools on the market and was not very expensive. It continued to add features which rivaled the more expensive tools. Aldus PageMaker also come out shortly after in 1985, but was almost $500 when released. The software was sold to Letraset in 1987 and used it to replace their MacPublisher/LetraPage product and shortly afterwards released version 4.0 of Ready, Set, Go!. Letraset made some improvements and even tried to make a pro version called DesignStudio in 1989. When sales started to stagnate and Tools like Pagemaker and Quark owning most of the market, Letraset gave the software back to Manhattan Graphics in the USA in 1992 who then released a small update combining the two products back together into version 5.0. Then they released version 6.0 later that year. In 1996 the international rights were sold to Diwan, a company who could make use of the very foreign language capabilities of the software.

Ready, Set, Go! had a great history of foreign language support, thanks in part to the Apple Quickdraw GX software which helped render other language glyphs and writing directions. There were special versions for languages like Hebrew. A GX version of the software was released in 1996 that supported many other languages.

Because of and in spite of the craziness of the software’s ownership, the file format used with the software changed frequently, but mostly kept the same basic structure. Identification of the different versions will be difficult, but that is why we are here, let’s take a look. Remember, these were all very early Macintosh programs, meaning there is no extension and their identification is based on Type/Creator codes. Luckily, there is no Resource Forks we need to account for in their identification or preservation.

Here is a look at a file from version 1.

 % hexdump -C RSG1-s01 | head
00000000  00 78 00 03 00 00 00 48  00 48 00 00 00 00 02 da  |.x.....H.H......|
00000010  02 28 ff e1 ff e2 02 f9  02 46 03 47 05 28 03 fc  |.(.......F.G.(..|
00000020  00 02 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.......(|
00000030  00 01 00 00 00 64 00 00  00 01 00 01 01 01 00 00  |.....d..........|
00000040  00 01 27 0f 00 01 00 01  00 00 00 00 00 00 00 00  |..'.............|
00000050  00 00 00 00 00 02 00 19  01 90 00 00 00 00 00 40  |...............@|
00000060  00 00 00 00 00 00 00 00  00 01 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 01 00 48  |...............H|
00000080  00 48 00 48 00 48 00 01  00 00 00 01 00 00 00 01  |.H.H.H..........|
00000090  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C RSG2-s01 | head
00000000  00 78 00 02 00 00 00 48  00 48 00 00 00 00 02 d8  |.x.....H.H......|
00000010  02 28 ff e0 ff e2 02 f8  02 46 03 07 05 28 03 fc  |.(.......F...(..|
00000020  00 02 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.......(|
00000030  00 01 00 00 00 64 00 00  00 01 00 01 01 01 00 00  |.....d..........|
00000040  00 01 27 0f 00 01 00 01  00 00 00 00 00 00 00 00  |..'.............|
00000050  00 00 00 00 00 02 00 19  01 90 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 13 00 04  |................|
00000080  00 10 00 1c 00 04 00 10  00 10 00 01 00 01 00 00  |................|
00000090  00 03 17 54 00 06 14 9e  00 05 08 ae 00 01 50 ec  |...T..........P.|

% getfileinfo RSG2-s01
file: "RSG2-s01"
type: "RSGI"
creator: "MART"
attributes: avbstclInmedz
created: 04/17/1986 17:31:32
modified: 04/28/1986 10:53:01

% hexdump -C RSG3 | head
00000000  00 1e 00 00 00 86 00 01  b8 2a 00 01 00 03 00 02  |.........*......|
00000010  00 01 b8 12 00 01 b8 1e  00 01 b8 4e 00 00 00 01  |...........N....|
00000020  b8 0a 00 00 80 00 00 00  80 00 00 00 80 00 00 00  |................|
00000030  80 00 00 00 40 00 00 00  40 00 00 04 00 02 00 01  |....@...@.......|
00000040  b8 06 ff fd 52 53 47 33  00 6c 65 64 00 ff ff f0  |....RSG3.led....|
00000050  1f ff ff f0 1f ff ff f0  00 00 00 10 00 00 34 42  |..............4B|
00000060  41 50 50 4c 00 00 00 ff  00 00 00 10 00 00 00 22  |APPL..........."|
00000070  44 52 57 47 00 01 00 ff  00 00 00 10 00 00 00 00  |DRWG............|
00000080  00 10 43 54 00 02 00 01  ff 00 ff ff 00 00 00 78  |..CT...........x|
00000090  00 03 00 00 00 48 00 48  00 00 00 00 02 f0 02 40  |.....H.H.......@|

% hexdump -C RSG4-s01 | head
00000000  01 90 00 00 01 e6 00 00  01 e2 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 00 00 00 cc  00 04 5b a0 00 01 00 03  |..........[.....|
00000070  00 02 00 04 5b 68 00 04  5b 70 00 04 5b 7c 00 00  |....[h..[p..[|..|
00000080  00 04 5b 5c 00 00 00 04  5b 64 00 00 80 00 00 00  |..[\....[d......|
00000090  80 00 00 00 80 00 00 00  80 00 00 00 40 00 00 00  |............@...|
000000a0  40 00 00 04 00 02 ff 00  00 04 5b 60 ff fe 08 52  |@.........[`...R|
000000b0  53 47 34 2d 73 30 31 00  00 00 00 00 00 00 00 00  |SG4-s01.........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% getfileinfo RSG4.5 
file: "RSG4.5"
type: "RSGR"
creator: "MEMR"
attributes: avbstclInmedz
created: 11/16/2021 13:39:34
modified: 11/16/2021 13:39:34

If you would like to play around with some samples from version 2. You can download them from here:

We can look at the hexadecimal for all the files, but this table will better explain the differences between versions.

Version	Type	Creator	First two Bytes	Developer	Year
1.0.1	RSGF	MART	0078	Manhattan Graphics Corporation	1985
2.0	RSGI	MART	0078	Manhattan Graphics Corporation	1985
3.0	RSGJ	MRSN	001E	Manhattan Graphics Corporation	1986
4.0	RSGK	MRSN	0190	Letraset	1987
4.5	RSGR	MEMR	138B	Letraset	1988
Design Studio 1.0	RSGS	MRJN	13C9	Letraset	1989
Design Studio 2.0	DSTD	MRJN	13E4	Letraset	1991
6.0.2	MG6F	MROS	1770	Manhattan Graphics	1993
7.0.5 Intl	MG7F	MRDN	1B61	Diwan	1996
7.2.8	MG6F	MROS	1BBC	Diwan	2002
7.7.8	MG6F	MROS	1BBC	Diwan	2011

This table is what I know currently, there is probably many more I can add as I locate samples, such as Version 5.0 and 5.1.

It amazes me how often the Creator code changes, usually this is fairly stable, but since it did change hands a lot, it makes a little sense. The Type code can often indicate changes in file format, so we can see version 1 & 2 are probably compatible, and later versions 6 & 7, but there own read me files helps us understand the compatibility. Version 2 added multiple page support, so it might have more differences.

Ready,Set,Go! 6.0 can open files created with Ready,Set,Go! 4.5, 4.5a, 5.0, and 5.1, and DesignStudio 1.0, 1.01 and 2.0. It cannot open files created with versions 1, 2, 3 or 4 of Ready,Set,Go! Registered users can obtain a special version of RSG 4.5 to open files created with earlier versions of Ready,Set,Go! to convert them to Version 6.0.

Ready,Set,Go! will open an old RSG document down to version 4 and a DesignStudio document down to version 1.0. Ready,Set,Go! 7.1 will automatically save it with the name ‘Copy of (filename)’ in order not to overwrite the old document. Whereas Ready,Set,Go! 7.2 or later can save documents that are compatible with Ready,Set,Go! versions 6 and 7.0.

So it seems you need version 4.5 to open earlier files and version 6 to open versions 4.5 to 5.1, then in 7.2 a change happened separating versions 6-7.1 and 7.2 and greater. Sounds like we will need at least 4 signatures to identify all the major changes.

Here is the problem, the main differences between the versions is the first two bytes. This is not enough to make a strong signature in PRONOM. Let look at some options.

% hexdump -C RSG4-s01 | tail
00000160  00 00 02 da 02 28 00 01  00 00 00 64 00 00 00 01  |.....(.....d....|
00000170  00 01 01 01 00 00 00 01  27 0f 00 01 00 01 00 00  |........'.......|
00000180  00 00 00 00 00 00 00 00  00 00 00 02 00 19 01 90  |................|
00000190  00 00 00 00 00 40 00 00  00 00 00 00 00 00 00 01  |.....@..........|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 2a 00 00 00 00  00 00 00 00 00 00 00 00  |...*............|
000001c0  00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 01 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 ff ff ff ff ff ff  |................|

Many since version 3 end with at least two bytes of the values FF FF, but that is also pretty common.

% hexdump -C RSG4.5 | head
00000000  13 8b 00 00 04 10 00 00  04 0c 00 00 04 14 00 00  |................|
00000010  04 18 00 00 04 1c 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 00 00 01 88  17 62 e1 d4 00 01 00 03  |.........b......|
00000070  00 02 17 62 e1 d0 17 62  e1 dc 17 62 e1 e8 00 00  |...b...b...b....|
00000080  17 62 e1 cc 00 00 17 62  e1 c8 00 00 80 00 00 00  |.b.....b........|
00000090  80 00 00 00 80 00 00 00  80 00 00 00 40 00 00 00  |............@...|
000000a0  40 00 00 04 00 02 ff 00  17 62 e1 50 ff fd 06 52  |@........b.P...R|
000000b0  53 47 34 2e 35 65 64 00  00 00 00 00 00 00 00 00  |SG4.5ed.........|

The header generally contains two bytes, then 00 00, then repeats for a few bytes, but adding 00 00 to a signature is also not very robust. Comparing version 3 to version 4 file doesn’t show much in common except for zeros. It may not be possible to combine signatures, they may need individual signatures for each version.

But the versions after 6, have an interesting segment of bytes. “050102030102060102030102060102030102060102030102060102030102070102090102070102030102070102090102070102090102070102090102070102090102060102030102060102030102060102030102060102030102050102030102050102030102050102030102050102030102050102030102050102030102060102030102050102030102050102030102050102030102”

% hexdump -C /Users/thorsted/Downloads/ReadySetGo\ \(1\)/RSG6       
00000000  17 70 00 00 34 70 00 00  34 6c 00 00 34 74 00 00  |.p..4p..4l..4t..|
00000010  34 78 00 00 34 90 00 00  34 a4 00 00 38 fe 00 00  |4x..4...4...8...|
00000020  39 20 00 00 39 68 00 00  3b 40 00 00 3b 44 00 00  |9 ..9h..;@..;D..|
00000030  3b 44 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |;D..............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  00 03 01 01 00 ff 00 00  00 00 05 01 02 03 01 02  |................|
000001d0  06 01 02 03 01 02 06 01  02 03 01 02 06 01 02 03  |................|
000001e0  01 02 06 01 02 03 01 02  07 01 02 09 01 02 07 01  |................|
000001f0  02 03 01 02 07 01 02 09  01 02 07 01 02 09 01 02  |................|
00000200  07 01 02 09 01 02 07 01  02 09 01 02 06 01 02 03  |................|
00000210  01 02 06 01 02 03 01 02  06 01 02 03 01 02 06 01  |................|
00000220  02 03 01 02 05 01 02 03  01 02 05 01 02 03 01 02  |................|
00000230  05 01 02 03 01 02 05 01  02 03 01 02 05 01 02 03  |................|
00000240  01 02 05 01 02 03 01 02  06 01 02 03 01 02 05 01  |................|
00000250  02 03 01 02 05 01 02 03  01 02 05 01 02 03 01 02  |................|
00000260  00 09 20 60 00 08 80 00  00 0b 00 00 00 01 00 00  |.. `............|
00000270  00 02 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000280  00 00 00 00 00 ea 04 b0  00 64 03 e8 00 00 00 00  |.........d......|
00000290  17 97 50 6c 00 00 00 00  00 3c 00 3d 00 3e 00 3f  |..Pl.....<.=.>.?|
000002a0  00 40 00 41 00 42 00 43  00 64 00 05 00 00 00 00  |.@.A.B.C.d......|
000002b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

It is in all the samples I have for version 6+, most have the same 150 bytes, all starting around the 458th byte (0x1CA). I have no idea what it means, but it makes up for the weak bytes available in the older versions. If anyone out there knows the significance in this byte sequence, I would like to understand. Visually it looks the most interesting in a 3 column view, and some files do have one byte difference.

Ok, so for now, it looks like the best option is to group the signatures into Version 3-4, Version 6-7, and DesignStudio 1-2. I will look at what is best for Version 1-2 of ReadySetGo in the future. For now, you can see my samples and suggested signature on my GitHub page.

Beef & Babe’s

July 14, 2023 by Thor 2 Comments

The 1990’s was a an exciting time for Desktop Publishing. I got my first taste of design in the early 90’s with Aldus PageMaker. QuarkXPress was king in commercial publishing world. For the most part designers and commercial printers used Macintosh computers which QuarkXpress catered to. For those who could not afford the high prices, or used a PC, there was a few options. Microsoft Publisher, TimeWorks Publish It!, and Express Publisher were a few. There was many debates during that time on which software was the best.

I have submitted signatures to PRONOM for many of these:

Express Publisher was proving elusive for finding software and sample files. Express Publisher was developed by Power Up who had been developing a DOS version since the late 1980’s. At one point Power Up decided to sue QuarkXPress for the use of the name XPress. In 1991 Power Up sold all their assets to Spinnaker around the time they released the first Windows version of Express Publisher.

When I first took a look at some samples from the Windows version 1.0 of Express Publisher, the magic header looked familiar.

Ok #retrocomputing folks, there must be a story behind the use of 0xCAFEBEEF in the header of these Express Publisher files from the early 90's. #fileformats #digipres pic.twitter.com/MMKafv5K4C
— Tyler Thorsted (@CHLThor) May 5, 2022

If it looks familiar to you it is similar to the famous, well nerd famous, JAVA Class file format.

The story goes that James Gosling needed a magic number for his new class format and was in a place they called Cafe Dead when he realized CAFE was a hex value, he soon used CAFEBABE and CAFED00D for his new formats. JAVA was released by Gosling in 1995 for SUN Microsystems.

File Format magic numbers are often used when designing a file to be used with software. Often times it is meant to be a sequence of hex values or a string indicating the file supported by certain software, this is more accurate than the simple extension at the end of most files. They are not required to be there, in fact there are a few formats which are difficult to identify as they don’t use this type of magic number in the header. To learn more read Ross Spencer’s post on magic numbers for digital preservation.

CAFED00Ds and CAFEBABEs

At first I thought it was some sort of homage to the JAVA Class format until I realized the Express Publisher file format was released 3 years earlier. Just a coincidence? I am sure whomever developed this format probably has an interesting story behind it.

These formats are not in PRONOM so lets take a look at what is needed.

The document format for Express Publisher version 1 for Windows 3 uses the EWD extension, as well as EWT for templates. Magic numbers work best for a signature when they are at least 4 bytes long, this gives enough to have little chance of conflicting with another file format. So our PRONOM signature byte sequence would look like this:

  <ByteSequence Reference="BOFoffset">
    <SubSequence MinFragLength="0" Position="1" SubSeqMaxOffset="0" SubSeqMinOffset="0">
      <Sequence>CAFEBEEF</Sequence>
      <DefaultShift>5</DefaultShift>
      <Shift Byte="CA">4</Shift>
      <Shift Byte="FE">3</Shift>
      <Shift Byte="BE">2</Shift>
      <Shift Byte="EF">1</Shift>
    </SubSequence>
  </ByteSequence>

In looking at the earlier DOS versions of Express Publisher they used the extension EPD for a document and EPT for templates. I only have a few samples of version 2 and version 3, but they have different headers.

Version 2 & 3 has consistent bytes starting at offset 4, version 2 using the string PAGES, and version 3 the string EP300. I will have to dig a little more to see if I can find some samples of version 1 to see how they compare and then should be able to submit a PRONOM signature for them.

For the time being, adding “CAFEBEEF” to PRONOM will be a good addition. I wonder if there are any other “CAFE” formats out there, if you know of any, let me know!

UPDATE – There is another format, AnFX Movie, which uses the magic header “CAFEBEEF”. More research is needed to distinguish the two formats.