Fearless extensibility: Extending THINK Pascal

I was thinking about the theme yesterday, and one of the idea I’d like to showcase is the fearless software extendability of the Macintosh, or how you can modify a closed-source program, from the outside, without recompilation, in a standard way across an entire OS.

I’m using here everyone’s favourite most badass IDE THINK Pascal(swoons), and I can add/remove items in the menu bar, rename their labels, change the shortcuts, all without opening the program itself or recompiling it via ResEdit.

If you are using THINK Pascal 4.0.2, as opposed to the exotic 4.5d4, the select all shortcut will be missing, and the default build shortcut will be ⌘G, instead of ⌘R. To change the menu shortcuts, open THINK Pascal with ResEdit, and add the missing shortcuts to the MENU resource:

The idea came to me when I found myself annoyed how in VLC, the subtitle settings are under the graphics panel instead of the subtitles pane, and how easy it would be to do had I have at my service something like ResEdit.

4 Likes

Classic Mac OS was the main computing environment I used as a kid, so I definitely feel some nostalgia seeing this again! :smile:

What do you think are the key parts for a technique like this to work?

A few important parts that occur to me are:

  • structured data formats (the resource types in classic Mac OS) that are used across a computing platform
  • specialised UIs to edit that structured data (the editors in ResEdit)
1 Like

I don’t think there needs to be that much scaffolding to make this work(at least in a really crappy way), let’s see how to reproduce this with a binary(without its symbols), with basically no infrastructure other than a header, a metadata field, a manifest and the necessary documentation pages:

I. Header(0x0000)

First off, if your system’s applications have a recognizable header(so like the first few bytes tell you something about how to reach the data that we need to change):

image

Looking at the first few bytes of some binary file, we can see 0x0186 as the address in memory where the metadata is located:

a001 8680 0637 a0f0 5a80 0837 a0f0 ba80
0a37 a0f0 aa80 0c37 6018 c2a0 02a8 8022
37a0 0172 8024 3780 0010 2000 4880 2436
a000 2839 2680 043f a00a 9435 ...

II. Metadata(0x0186)

At that location, we find the following bit of text and data:

Left
A Text Editor
By Hundred Rabbits
22 Jul 2024
	83 3c5b ( the application icon )
	0a 01c0 ( the manifest )
    ...

The manifest at 0x01c0 is the equivalent of the Machintosh’s MENU asset, it’s the location in the application memory that stores all the strings needed for localization in the dropdown menu, the shortcuts and so on.

III. Manifest(0x01c0)

So far, we’ve trampolined from 0x0186 -> 0x01c0 where we find the dropdown data that looks like a modifier-key byte, a keyboard character byte, followed by the address to that function, and a null terminated string:

05 Left 00
01 n 0000 New 00
01 r 0000 Rename 00
01 o 0000 Open 00
01 s 0000 Save 00
01 q 0000 Exit 00
02 Edit 00
01 c 0000 Copy 00
01 v 0000 Paste 00
...

The modifier byte is stored as follows:

image

So if we wanted to change Exit for alt+q instead of its current ctrl+q, we could change that line for:

02 q 0000 Bye! 00

Voila!

Now if had a hex editor that could better navigate these locations in the binary file, we’d approach something like ResEdit, but… there’s only few hours in a day. Regardless, if a program exposes just enough information to the outside world, it’s possible to go and make accessibility changes to it without having the sources readily available.

2 Likes

There are probably lots of technical designs that get the desired result. Assuming it is desired, so that’s what really matters.

I suspect that the motivation behind making UI resources external to the code of the application was internationalization, but maybe there was something else. Is this documented?

I know extremely little about early Mac, but perhaps this was a benefit of a monoculture? Did all/most apps “just happen” to be built on a single toolkit provided by Apple, so were interoperable with same dev tool?
(I think NeXT then copied the approach & culture of apps having some externally editable “resources”.)

Pretty cool demo. Are you familiar with Windows’ RC files? I haven’t programmed a Windows GUI in 25 years, but I remember windows and dialogs were created in this declarative language, and I reckon you could in theory extract them from a binary and change the shortcut of a menu or text of a label.

I doubt that’s still possible with modern Windows tech.

Also, GTK GUIs are often described with their own XML format, which ships alongside the app and placed in /usr/share/somewhere. No idea about QT and VLC, but I wouldn’t be surprised to learn their GUI declarative languages are eventually turned into C++ so cannot be updated after the fact.

By monoculture, if you mean that there was an application API and most developer kits mapped onto it, then yes. But it’s possible to break the mold a bit, I haven’t done much 68k asm myself but I’m certain that you could do something like writing programs that run without mapping to the resources needed by ResEdit.

Pretty cool demo. Are you familiar with Windows’ RC files?

I wasn’t! I’m looking into it now, it reminds me of messing around with Paladin(HaikuOS), there is probably a rich history of these sorts of systems, I’ve picked System 7 because I was somewhat familiar with it and fearless to me meant something like extending a program that didn’t want to be extended, but I can imagine a thousand ways in which one could design programs that welcome this sort of change even further.

One projects I was unsure about but considered pitching for the extensibility event was video game remixes. I played around changing games a bit in the past, for example, Purgateus is a game mod. Love2d projects sort of welcome this by letting resources be modified externally.

That is (was) the basis of Resource Hacker, the equivalent of ResEdit for Win32. This was the basis for a lot of theming/customization in the 98/Win2k/XP era. See VirtualPlastic.net and the Wayback Machine’s copy of wint.virtualplastic.net. (The latter used a Flash menu. Even with the Wayback Machine’s rewrite rules to use a Ruffle-based emulator, getting it to actually work can prove spotty. The meat of the site was under the “Modifications” button, which eventually put you at https://wint.virtualplastic.net/hackindex.php. The posts themselves were all standard HTML, so articles are still readable, if you know they’re there.)