Mac OS 9 Lives
Mac OS 9 Discussion => Mac OS 9, Hacks & Upgrades => Topic started by: Dennis Nedry on May 03, 2025, 09:32:55 PM
-
I have recently discovered a new disassembler and its ability to disassemble PowerPC code, even including Mac OS toolbox calls, and also going as far as generating C code! It’s a hacker’s dream come true.
I used to do a lot with Appearance Themes a long time ago. They are like Apple’s built-in version of Kaleidoscope. I would love to decompile the code that parses appearance themes and see if there are any cool surprises in there. Also, there are a couple bugs here and there, for example, the pop-up menu text color does not use the correct entry in the clr# resource. It would be neat to try to fix that.
I do not know where this code is located though. Trying to narrow that down, I did a minimum install of Mac OS 8.6 and deleted as many system files as possible where it could still boot and let me apply a theme. I further narrowed down that it isn’t the appearance control panel itself because you can select a theme, delete the control panel, reboot, and the theme will still be working. Deleting the theme file or the correct preferences file and rebooting again removes the theme. So these behaviors aren’t depending on the control panel. The theme parsing code must lie someplace else.
I used Resorcerer to search the resource and data forks of the System file and Mac OS Resources file for the ASCII names of these resources, like ‘layo’, ‘frme’, ‘pxm#’ and not found it. I would have thought those references would be lurking as plain ASCII text somewhere and easily spotted this way. I am not sure what could be going on; maybe I didn’t look at the right place? Maybe the code is compressed or something? If anyone could help me find that, I would appreciate it.
-
The System file has multiple cfrg resources. One of them has an entry that points to the AppearanceLib.
The MPW command DumpPEF can dump all the pefs but I think it only works for cfrg 0. So you might need to make a System resource file, one for each cfrg with the resource ID changed to 0.
The below is a modern macOS shell script to do the job. It uses
https://github.com/ksherlock/mpw
to use MPW's DumpPEF command.
You can probably rewrite it as an MPW script.
The AppearanceLib is container 11 of cfrg 49 of Mac OS 9.2.2 System file.
#=========================================================================================
# Dump all pefs of Mac OS 9.2.2 System file
mkdir -p ~/SystemFragments
cd ~/SystemFragments
cp "/Volumes/Classic/System Folder/System" .
IFS=$'\n'
for thecfrg in $(derez -p -only xxxx "System" 2>&1 | perl -nE 'if (/Skipping .cfrg. \((-?\d+)/) { print $1 ."\n" }'); do
printf "include \"System\" 'cfrg' (%d) as 'cfrg' (0) ;" "$thecfrg" > "/tmp/System_cfrg_$thecfrg.r"
cat "System" > "/tmp/System_cfrg_$thecfrg"
rez -o "/tmp/System_cfrg_$thecfrg" "/tmp/System_cfrg_$thecfrg.r"
mpw dumppef -do All -pi u "/tmp/System_cfrg_$thecfrg" 2> "System_cfrg_$thecfrg.errs.txt" > "System_cfrg_$thecfrg.dumppef.txt"
if ! [[ -s "System_cfrg_$thecfrg.errs.txt" ]]; then
rm "System_cfrg_$thecfrg.errs.txt"
fi
done
#=========================================================================================
# Find library named AppearanceLib.
grep -l -R -E 'AppearanceLib.*member' .
./System_cfrg_49.dumppef.txt
# Find libraries that import from AppearanceLib.
grep -l -R -E 'from.*AppearanceLib' .
./System_cfrg_49.dumppef.txt
./System_cfrg_64.dumppef.txt
./System_cfrg_257.dumppef.txt
./System_cfrg_76.dumppef.txt
./System_cfrg_52.dumppef.txt
./System_cfrg_79.dumppef.txt
-
Thank you for this info. I was able to open the 9.2.2 system file with Resorcerer, open ‘cfrg’ ID 49, locate entry 11, and get the offset and length into the data fork for AppearanceLib.
Offset 2601440 -> 0x27B1E0
Length 317304 -> 0x4D778
I copied this region into a new file’s data fork and saved it for importing in a disassembler. Browsing this file with HxD, I found that resource names are loaded 2 characters at a time. Searching for ‘layo’ produces no results, but searching for ‘la’ and ‘yo’ in close proximity, DOES have results:
0xFD4A / FD86
0x11D6A / 11D72
0x128EA / 128F2
0x12BEE / 12BF6
0x12D82 / 12D8A
0x1DA26 / 1DA32
I think I have achieved “Hello World” status. I have a lot to learn in order to get anything useful to happen but this will at least be something fun to experiment with. Thank you for your help.
-
PowerPC instructions don't have a way to load 32 bit immediates ('layo' is a 32-bit constant), so the compiler emits an instruction sequence that pastes two 16-bit immediates together.
-
Data sections of PEFs are compressed so a utility like DumpPEF that can decompress it is useful. A good disassembler should understand the PEF format and decompress the data section for examination.
I use Jasik's Nosy II for classic Mac OS binaries but it's just a disassembler - it can't decompile. DumpPEF can disassemble but it's not as good as Nosy II.
After the AppearanceLib data is decompressed, you might be able to see some hex that is pixels for some AppearanceLib graphical objects.
-
Thanks for all the info. I have been playing with the disassembly and it has become very apparent that this indeed has the code that parses out theme files, as well as soundset files.
I spent some time where it loads 'crsr's via the 'tdat' resource, which has never actually worked as far as I know. The Gizmo theme contains 'crsr's and has 'tdat' entries for some them, but it does not have an entry for 'crsr' 128, which is the normal mouse cursor.
Looking at the code that parses the 'tdat' resource in AppearanceLib, it looked like it was checking the first 2 bytes of the resource data to see if they were 00 00 and if not, aborting. Well, 'crsr's start with 80 xx. So I changed the opcode of that branch instruction from BNE to BEQ or something like that. I made sure to modify a copy of the system file and swap it, rebooted, etc. None of that made Gizmo's custom cursors come to life but it's a start and definitely a fun thing to poke around at.
There are some symbols preserved in AppearanceLib which is pretty helpful. I think I might dig up various versions of Mac OS 8 and 9 and see if there are any different versions of AppearanceLib and if any of that has different symbols preserved, etc. I know that themes were quite a bit different between 8.2b (where they first appeared if I remember right?) and 8.5. I don't expect a whole lot of differences from 8.5 through 9.2.2 since the theme project got canceled, but who knows! Worth a look. Definitely Mac OS X had a continuation of this using Extras.rsrc in a very modified but still similar format. I am guessing that they might have continued using some of the old AppearanceLib source code so that might also be interesting to look into.
I looked into DumpPEF at this location:
https://git.sr.ht/~joshrig/dumppef
I downloaded the source code from that page and I am seeing two .c files, util.c and dumppef.c. I am not seeing any place where it does a literal decompression. Also, looking at the end of AppearanceLib, I see bytes arranged like they look like raw/uncompressed graphics, but I haven't looked deeply at that. But I am wondering if it is in fact compressed or not, and if I found the correct DumpPEF.
-
The DumpPEF at https://git.sr.ht/~joshrig/dumppef is not the same. You need the one from MPW which doesn't have source code.
The compression is byte codes in the pidata section of the PEF. The byte codes allow doing things like reducing a string of 00 bytes into a single opcode. So there is some uncompressed parts between byte codes/opcodes.
Compressed:
Pidata section 1 (<unnamed>)
Address Op Operand Encoding/data
43EA0 0000 ZERO cnt=1246 00 895E
43EA3 04DE BLK cnt=2 22
43EA4 C3FC ..
43EA6 04E0 RPTZERO cnt=2 82
43EA7 dcnt=2 02
43EA8 rpt=338 8252
43EAA 1 C400 C404 C405 237C 2768 2A54 ......#|'h*T
43EB6 7 C450 C44E C454 C456 1074 107C .P.N.T.V.t.|
43EC2 13 1084 108C 109C 1094 C5C0 C5C4 ............
43ECE 19 C5BC 2C48 C5C8 2C90 2E24 C5CC ..,H..,..$..
43EDA 25 2E04 2E44 2DE4 2F80 31D0 320C ...D-./.1.2.
43EE6 31 322C 3AD0 3268 3CC8 32F0 47EC 2,:.2h<.2.G.
...
Uncompressed:
---------------------------- Unpacked PiData ---------------------------
00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00040 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
000A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
000C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
000E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
001A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
001C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
001E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00200 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00220 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00240 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00260 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00280 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
002A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
002C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
002E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00300 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00320 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00340 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00360 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00380 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
003A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
003C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
003E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00420 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00440 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00460 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
00480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
004A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................
004C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000C3FC ................................
004E0 0000C400 0000C404 0000C405 0000237C 00002768 00002A54 0000C450 0000C44E ..............#|..'h..*T...P...N
00500 0000C454 0000C456 00001074 0000107C 00001084 0000108C 0000109C 00001094 ...T...V...t...|................
00520 0000C5C0 0000C5C4 0000C5BC 00002C48 0000C5C8 00002C90 00002E24 0000C5CC ..............,H......,....$....
00540 00002E04 00002E44 00002DE4 00002F80 000031D0 0000320C 0000322C 00003AD0 .......D..-.../...1...2...2,..:.
-
The data doesn't have to be compressed. There are different section types for compressed and uncompressed data.
Also it depends on the software you are using. IDA Pro for example automatically uncompresses the data sections while loading.
-
Thanks for the pointers with DumpPEF. I have found some of the references to ‘layo’ ID numbers but not all. At best, I have found some that would be in this compressed data region. Now, whether that is truly data or if it is executable code that the decompiler didn’t catch, I still have to look into that.
The comments I had about the ‘crsr’ starting with 00 00, now that I have been looking at more things and seeing the patterns how the code was written, that now looks like a return code. A non-zero (typically negative) value would identify the type of error that occurred. I am learning as I go.
I noticed something very interesting though. There is reference to a ‘layo’ ID 502.
500 = normal push button
501 = default push button (I.e. has a ring around it)
502 = ??
503 = small push button in Jaguar Extras.rsrc.
So when it came to Jaguar, they apparently remained aware of this 502, skipped it, and used 503 when they added the small push button. What the heck! Some other kind of push button? That is so strange, I wonder what it was. This is exactly the kind of cool stuff I want to find in there.
-
A long time ago I was really curious about how Appearance worked, but never got past looking at just the resources, and randomly changing them to see if anything happened. You're actually plumbing the very guts, which is extremely cool!
One thing you might find interesting (or not) to look into at some point is the MacOS X Developer Preview 3 release, which was when Aqua was first introduced. It had the weird "feature" that if you renamed Extras.rsrc inside /System/Library/Frameworks/HiToolbox.framework it would revert to the Platinum appearance, complaining constantly about not finding that file in the System log.
Even weirder, it has a bizarre "Classic X" MacOS 9 theme file, which seems identical to the standard Platinum, but rearranges the windowshade and maximize buttons in title bars to the match the "stoplight" order that Aqua uses, and kinda sorta tries to make the menu bar look aqua-ish even in Classic apps. (The Apple menu is changed to the running app icon, and a aqua-ish font is used).
It will only run on a few early G3 and G4 machines, but I do still have it installed on an old blueberry ibook, just because it was such an interesting snapshot of the evolution from NextStep to the MacOS X we eventually got and wanted to preserve it. For what its worth, it'd probably run in QEMU.
Going further down the ancient history rabbit hole, Developer Release 2 was the first to do Carbon in any usable form. It had a Platinum appearance for everything, and Apple tried to make Cocoa and Carbon apps look identical, but you could tell by subtle variations in buttons, menus, etc, that it was really using a theme that just looked like Cocoa, at the time. It runs on even fewer machines and I'm not sure if I preserved a running copy, but might have on an old G3 powerbook.
-
I have always been very interested in classic Mac themes and I am having loads of fun playing with AppearanceLib. I have a few new interesting things I have found in case anyone is interested.
First of all, I am finding that running Mac OS 9.2.2 in classic mode of Tiger, no modifications of AppearanceLib in the system file are having any effect. I think this means that Mac OS X is providing its own appearance manager for classic mode. Considering this and reflecting on early betas of OS X having a platinum appearance under the hood, it seems that maybe we are actually seeing OS X applying separate themes for classic and non-classic apps. And based on that possibility, maybe it is somehow possible to enable OS X's aqua appearance to classic apps. That might be cool!
I went on an expedition to gather the AppearanceLibs from all different classic Mac OS versions, starting with the 8.2 betas and even including some stuff from Copland. The build date embedded in the PEF header did change almost every version. Starting with Mac OS 8.5, the file size of AppearanceLib remained pretty stable but there were at least 5 times that it changed by the time we got to 9.2.2. The size went up and down slightly. Interesting to see that things were still happening.
I mentioned before about a layo ID 502. ID 500 is the normal push button, ID 501 is the default push button (i.e. with a ring around it or blue in OS X), and I discovered that 502 is a "Cancel" push button. Here is the pseudocode that fetches layo ID 502:
[layo id decision.PNG]
Note that I don't fully understand how the variables are structured and passed around yet, so the names and handling of the variables probably don't all make sense. You can see here, "result" is a bitfield where bit 0 (&1) means the button is default, and bit 1 (&2) means that the button is cancel. If neither of those bits are set, it is a normal button.
So that brings us to this "byte_40F48". This is a flag that is normally 0, preventing this cancel behavior ever happening. After some other hacking, I found that this flag is stored directly after Checkbox Style (X vs check), Scrollbar Arrow Style (single vs double vs both ends), and Scrollbar thumb style (fixed size or proportional size). The next spot is this flag that makes the cancel buttons separate.
[global variables.PNG]
It is possible to make a 1-byte change that skips checking that flag, permanently enabling the cancel behavior. You can do this to try it out if you want, but you won't want to leave it that way. No themes have layo 502, so you are going to have a platinum button any place there is a cancel button. In 9.2.2, you can modify this green byte; change it from 10 to 1C:
[9.2.2 data fork.png]
In 8.6:
[8.6-data-fork.png]
After making that change, you can try the attached Doohickey theme that I modified. I added a layo 502 resource in that theme copied from the default push button. For the unpressed, active state, I made a copy of the 'frme' resource and I changed the blue ring to red and gave it a light red background. (It still uses the pressed and disabled states from the original default push button.) You will see various cancel buttons turn red this way!
[cancel-button.png]
That's kind of interesting don't ya think??
I also said earlier that I could not find references to all of the layo resources, especially I could not find any of the window layo resources. I figured that out, and it is having to do with the 'tdat' resource. Themes have a 'tdat' resource where you have to basicallly register all of the elements of the theme. It is a list of resource types and IDs and the AppearanceLib runs through that list and loads all of those items into memory for quick access. There is a 'tdat' ID 1 in each theme, and there is also a 'tdat' ID 0 in the system file. There is a function in AppearanceLib that allows you to load specific items from the tdat using the index. Positive indexes come from the theme's 'tdat' and negative indexes come from the system file's 'tdat'. This is similar to the positive/negative behavior of plut resources. Having learned this, I found all of those missing layos were being referenced by their position in the system 'tdat'!
Going deeper down the system 'tdat' rabbit hole, I just looked at what was in the 'tdat' in the first place and I found some more 'layo's that I didn't know about:
502 - Cancel Button -> it is in there.
435 - Small Progress Bar in OS X
445 - Small Indeterminate (barber pole) Progress Bar in OS X
144 - Plain D Box Active in Copland
145 - Plain D Box Inactive in Copland
146 - Shadow D Box Active in Copland
147 - Shadow D Box Inactive in Copland
148 - ?
149 - ?
Small progress bars made their appearance in Mac OS X. I haven't seen a progress bar revert to platinum when it got too small. There seems to be no handling for it in AppearanceLib, but definitely interesting to find that in there. Maybe they were working on it.
These "D box" things are additional window types. They are present in the Copland previews and there is code in appearanceLib where they potentially could be used. I got the names from the layo resource names in the Copland "Z theme", which is an early version of Gizmo.
In the 9.2.2 AppearanceLib, the function at 0x1BBCC takes in an enumerated value and provides the negative tdat index to the layo resource for each window type, including active and inactive. I am not sure where that enumerated value comes from, if it is some sort of "Proc ID" or WDEF number, etc, but here is the list (let me know if this looks familiar to you):
0 = Document Window
1 = Dialog Window
2 = Movable Modal Window
3 = Alert Window
4 = Movable Alert
5 = Copland Plain D Box
6 = Copland Shadow D Box
7 = Drawer Window (i.e. docked to the bottom of the screen)
8 = Utility Window
9 = Side Utility Window
layos 148 and 149 are not present in Copland and I am not sure why they are in the system 'tdat' resource. There are also 2 copies of them in there. Based on the layo ID, it was probably a window and matching inactive window. It could have been there for debug purposes or something.
Things I am still interested to look into:
- Why are theme cursors not working? Gizmo has custom cursors that aren't used.
- 'trns' resources were an old way to provide animations for checkboxes, radio buttons, menu items, etc. It was still there in 8.2d8's Gizmo and it was removed in 8.2a2's Gizmo. It became hard-coded only for disclosure triangles (specifically pxm# 1026). I would like to see how that worked. It definitely has something to do with 'frg#' 125 in the system file, though the AppearanceLib attempts to load 'frg#' 129. Not sure if I could hook it back up by loading 125 but there is more that was removed so it won't be simple bringing that back to life. I am not seeing where it ever worked. It is possible it worked in Copland. Menu items may have had a "flip" effect? I vaguely remember a video demo showing this.
- How to use right-to-left behavior of checkboxes, radio buttons, etc. I have seen left-side growboxes in windows that are never allowed visible as well; there is some sort of left-facing behavior sprinkled around that I would like to see.
- Text color of popup menus is using index 0 in the clr# resource instead of the correct index; I would like to find that and see if it can be fixed.
- Mac OS X AppearanceLib that is being used in classic mode. I would like to learn more how that works and see if that is separate or integrated with the aqua appearanceLib.
-
Appearance.h:
/*——————————————————————————————————————————————————————————————————————————————————————————*/
/* Window Types Supported by the Appearance Manager */
/*——————————————————————————————————————————————————————————————————————————————————————————*/
enum {
kThemeDocumentWindow = 0,
kThemeDialogWindow = 1,
kThemeMovableDialogWindow = 2,
kThemeAlertWindow = 3,
kThemeMovableAlertWindow = 4,
kThemePlainDialogWindow = 5,
kThemeShadowDialogWindow = 6,
kThemePopupWindow = 7,
kThemeUtilityWindow = 8,
kThemeUtilitySideWindow = 9,
kThemeSheetWindow = 10
};
typedef UInt16 ThemeWindowType;
-
I have been reading along with this thread. I do enjoy themes, however at the end of the day the amount I know about anything is very very little. In Tiger I use ShapeShifter to try out different themes. I personally like Mes (DrawingBoard) for OS X, but when running Classic applications I use the Gizmo theme. This gives the Classic application the Gizmo look, while leaving the Tiger desktop and applications with the Drawing Board theme.
In any event the themeing in OS X and OS 9 must work differently and must not be mutually incompatible. The mix produces something of a jarring look, but it does make it very easy to see what is a Classic App and what is an OS X app.
-
Appearance.h:
/*——————————————————————————————————————————————————————————————————————————————————————————*/
/* Window Types Supported by the Appearance Manager */
/*——————————————————————————————————————————————————————————————————————————————————————————*/
enum {
kThemeDocumentWindow = 0,
kThemeDialogWindow = 1,
kThemeMovableDialogWindow = 2,
kThemeAlertWindow = 3,
kThemeMovableAlertWindow = 4,
kThemePlainDialogWindow = 5,
kThemeShadowDialogWindow = 6,
kThemePopupWindow = 7,
kThemeUtilityWindow = 8,
kThemeUtilitySideWindow = 9,
kThemeSheetWindow = 10
};
typedef UInt16 ThemeWindowType;
Ohhhhh it never occurred to me there could be header files out there! This will be very helpful!
Do you have ideas what a plain and shadow dialog was? Seeing how none of the themes had the ‘layo’s for these, they would theoretically show up in Platinum form if you are running a theme.
-
When you run an app under Classic on MacOS X, you are running an entire copy of MacOS 9. All the managers, such as Appearance, are the MacOS 9 stock ones. Sadly, MacOS X in no way themes or is involved in the drawing MacOS 9 apps.
It does hook the OS in countless ways, but at very low levels. Graphically it does this by using rectangular "cut outs" on the screen for the windows, but otherwise lets the MacOS 9 Window Manager manage its own windows. It hooks and replaces many of the device drivers, and nanokernel layer, but does as little as needed. The more MacOS 9 it replaced, the less compatible it would be for running its apps.
So, yes, the themes are completely separate, and there's a separate Carbon Appearance manager for Carbon apps.
One note, the Carbon Appearance manager has things that the MacOS 9 one doesn't, so even if they used the same headers, not everything is supported on MacOS 9. Apple kept working on the Carbon one, adding things that Cocoa could do, for a while, but the MacOS 9 one was frozen. So you'll see a lot of resources etc in Carbon that there are no MacOS 9 equivalents.
-
Ohhhhh it never occurred to me there could be header files out there! This will be very helpful!
Do you have ideas what a plain and shadow dialog was? Seeing how none of the themes had the ‘layo’s for these, they would theoretically show up in Platinum form if you are running a theme.
"INSIDE MACINTOSH" "Allegro" "Appearance Manager Reference" "Unreleased Preliminary"
(August 13, 1998) (© 1998 Apple Computer, Inc.)
"INSIDE CARBON" "Programming With the Appearance Manager" "For Appearance Manager 1.1" (April 21, 1999) (© 1999 Apple Computer, Inc.) (4/21/99 © Apple Computer, Inc.)
"Inside Mac OS X" "Appearance Manager Reference" (February 1, 2003) (© Apple Computer, Inc. February 2003)
"Carbon" "Human Interface Toolbox" "Appearance Manager Reference" (February 1, 2003) (© Apple Computer, Inc. 2004)
say the following:
kThemePlainDialogWindow
A plain modal dialog box. This window visually corresponds to that produced by the plainDBox pre–Appearance Manager window definition ID and does not change appearance by theme.
kThemeShadowDialogWindow
A dialog box with shadowing.
You can look at CodeWarrior Pro 8 sample code (PowerPlant?) that shows Appearance Manager stuff. They might show window types. I forget.
Does Resorcerer or ResEdit Window or Dialog editors show the dialog types?
-
["INSIDE MACINTOSH" "Allegro" "Appearance Manager Reference" "Unreleased Preliminary"
(August 13, 1998) (© 1998 Apple Computer, Inc.)
"INSIDE CARBON" "Programming With the Appearance Manager" "For Appearance Manager 1.1" (April 21, 1999) (© 1999 Apple Computer, Inc.) (4/21/99 © Apple Computer, Inc.)
"Inside Mac OS X" "Appearance Manager Reference" (February 1, 2003) (© Apple Computer, Inc. February 2003)
"Carbon" "Human Interface Toolbox" "Appearance Manager Reference" (February 1, 2003) (© Apple Computer, Inc. 2004)
Thank you, I will look into this. The more information that I can give the decompiler, the more it unravels the code. For example, functions often receive a pointer to a structure. They may use only a couple things from the structure. So the decompiler doesn't necessarily even know that's a structure. Providing those, as well as enums, etc, causes lots of additional deductions to be made. So I expect that this is going to make a big difference.
I am doing all of this not for any particular useful purpose. Themes have a very special nostalgic value to me; I hacked them very extensively on my 6100 when I was in high school. It was just after the point where Apple stopped caring about people making themes so it was never a problem. I never had any tools like this to see how the actual code worked at that time. And now I am seeing how themes started in Copland, evolved into Mac OS 8.5, and continued evolving into OS X aqua. This theme thing made quite a huge span across 3 completely different operating systems. I think that's fascinating.
say the following:
kThemePlainDialogWindow
A plain modal dialog box. This window visually corresponds to that produced by the plainDBox pre–Appearance Manager window definition ID and does not change appearance by theme.
kThemeShadowDialogWindow
A dialog box with shadowing.
Hmm, AppearanceLib does seem to have hooks where you could add the appropriate layo resource for these in a theme file. I will have to see if I can get a window to show up as pre-appearance-manager. This means it would look like System 7? I noticed Resorcerer 2.2's windows are like this. Maybe those are plain D Boxes. Also, the Calculator desk accessory; that's a super old-school window frame. Maybe that is the other one.
You can look at CodeWarrior Pro 8 sample code (PowerPlant?) that shows Appearance Manager stuff. They might show window types. I forget.
Does Resorcerer or ResEdit Window or Dialog editors show the dialog types?
Yes, Resorcerer shows a few different values for dialog and WIND types and variations but I didn't find anything that corresponded to these values.
When you run an app under Classic on MacOS X, you are running an entire copy of MacOS 9. All the managers, such as Appearance, are the MacOS 9 stock ones. Sadly, MacOS X in no way themes or is involved in the drawing MacOS 9 apps.
I found that when I edited AppearanceLib in the 9.2.2 system file, it had no effect in Classic mode. I made the corresponding edits in the 8.6 system file in sheepshaver, and it did have the effects. So based on this, I came to the conclusion that the System file's AppearanceLib is not being used in classic mode. Leading to my assumption being that Mac OS X's HIToolbox is drawing ALL of the interface, including OS X and Classic. Please tell me if I'm crazy.
This makes sense though, right? Classic isn't all inside its own window like Sheepshaver (for example). The classic windows intermingle with the OS X windows. They stack on top of each other in any arbitrary order. They are aware of each other; they are all painting on the screen around each other and my theory is that OS X does it all. I will poke at that some more and let you know what I find.
-
Hmm, AppearanceLib does seem to have hooks where you could add the appropriate layo resource for these in a theme file. I will have to see if I can get a window to show up as pre-appearance-manager. This means it would look like System 7? I noticed Resorcerer 2.2's windows are like this. Maybe those are plain D Boxes. Also, the Calculator desk accessory; that's a super old-school window frame. Maybe that is the other one.
Calculator desk accessory uses kRoundWindowDefinition WDEF which corresponds to the rDocProc ProcID. They are from MacWindows.h. The old pre-appearance WDEF variants are listed in that header file and are followed by theme-savvy window defproc and Proc ID definitions.
Using the Resorcerer "DLOG" editor, you can select "Set Window Type" -> "Other...", then paste the ProcID into the "ProcID" field. Then select "Try out..." to see what it looks like.
The ProcID contains a 12-bit WDEF resource ID and a 4-bit variant code. So, multiply the WDEF by 16 to get the range of ProcIDs that correspond to that WDEF.
/* • Mac OS 7.5 Window Definition Resource IDs */
kStandardWindowDefinition = 0, /* for document windows and dialogs*/
kRoundWindowDefinition = 1, /* old da-style window*/
kFloatingWindowDefinition = 124 /* for floating windows*/
/* Resource IDs for theme-savvy window defprocs */
kWindowDocumentDefProcResID = 64,
kWindowDialogDefProcResID = 65,
kWindowUtilityDefProcResID = 66,
kWindowUtilitySideTitleDefProcResID = 67,
kWindowSheetDefProcResID = 68,
kWindowSimpleDefProcResID = 69,
kWindowSheetAlertDefProcResID = 70
Mac OS 9 works with classic ProcIDs up to 1999 and Theme Savvy ProcIDs up to 1087 that exclude the Mac OS X sheet type WDEFs.
I suppose the theme-savvy window defprocs call the Appearance Manager to do their drawing and handling.
-
I found that when I edited AppearanceLib in the 9.2.2 system file, it had no effect in Classic mode. I made the corresponding edits in the 8.6 system file in sheepshaver, and it did have the effects. So based on this, I came to the conclusion that the System file's AppearanceLib is not being used in classic mode. Leading to my assumption being that Mac OS X's HIToolbox is drawing ALL of the interface, including OS X and Classic. Please tell me if I'm crazy.
I'd never dispute empirical evidence, so will definitely NOT tell you you're crazy. It goes against how I've always thought things worked, but you may have uncovered something VERY interesting! I'm going to have to do some experimenting. I wouldn't be surprised to find that MacOS X keeps a private copy of the MacOS 9 Appearance extension and uses that instead of the one in the System Folder, for reasons of its own. I'd be shocked if I found it was actually drawing EVERYTHING through Carbon...but I've been shocked about systems I've known for decades before...
-
that Mac OS X's HIToolbox is drawing ALL of the interface
most likely.
I'd be shocked if I found it was actually drawing EVERYTHING through Carbon
i´ve actually always wanted to know if the classic enviroment´s finder windows are also openGL just like the OSX finder.
which is based on the GL API, but also uses some of the drawing methods of quartz, which is otherwise the manager in the middle, and of course the OSX finder was based on the carbon framework.
and while we are on it, what technologies were involved in drawing the finder windows of rhapsody? :)
-
I found a Copland demo video where the menu items flip in Gizmo:
https://youtu.be/MSDiqMH5vGs?feature=shared&t=180
Notice how each menu has a different color text. I also see the correct cursors being displayed and kind of a sparking animation when they click the closebox. Is this actually real? It doesn't seem these functions made it beyond Copland. It sure is cool though.
Edit:
Here's the flippy thing that looks real, but no multi-colored menus:
https://www.youtube.com/watch?v=adx0h1C2MIc
Edit 2:
I have kind of a neat thing to share. I made a copy of AppleScriptLib and replaced the data fork with AppearanceLib. I then modified the ‘cfrg’ resource. I deleted the first entry, which was for the 68k version of AppleScriptLib. Then I modified the PowerPC entry with the start point of 0 and the length equal to the size of AppearanceLib. I modified the name to AppearanceLib. I put this in the extensions folder, and to my amazement, it runs the copy of AppearanceLib from the new extension!
So now I can make modifications to the extension instead of the system file. And in theory, if I break it, I can start with extensions off, if I can ever figure out how to do that in Sheepshaver. That’s my first extension! ;D
-
I think the general consensus is that quite a bit, but maybe not ALL, of the Apple Copland demo videos were either faked, or extremely carefully edited and modified to look correct. What's definitely the case is that the versions released to developers did not look and absolutely did not function like what was shown.
I have d11 on a 6100, and it only has the platinum theme, and there are no animations at all. The theme itself and even the font are subtly different, but extremely close to what we got in MacOS 8. See https://macintoshgarden.org/forum/writing-software-copland for screenshots of my machine running it, including software I wrote (just standard Mac stuff, that took no advantage of anything new in Copland).
It looks like d7 had the Gizmo theme https://www.youtube.com/watch?v=FoVEZb2ropk but he doesn't go to a menu in the video so we can't see if there were animations. BTW, d11 is much more stable, and not QUITE as terrible as what the guy goes through in the video, but still very very fragile and goes to the debugger constantly, needing reboots after running just about anything.
I really should install d7 or d9 on my 6100, always wanted to, just to see, but at the same time, have spared myself the grief and pain of doing so.
One strange thing is d11 is actually missing a bunch of things d7 or d9 had. They probably left them out because they didn't want people trying them, and having them fail, wanted them to focus on what actually worked.
There were sets of include files distributed with the Copland Developer releases. I think I remember seeing one mentioning "Desktop Animations". I might be able to dig them up. Regardless, the concept was definitely abandoned and never made it past Copland.
-
Speaking of Rhapsody...
Rhapsody, and the MacOS X Server 1.x we got, are really just NextStep with a new look. Comparing the two side by side you will see they are almost identical except for the "theme" and the dock.
As far as theme goes, there is no Carbon, and no Appearance manager at all. There is something like Classic, but it only runs full screen. So no doubt how things are being drawn that way.
On the earliest release of Rhapsody the intsaller and a couple of the low level administrator apps are NOT platinum at all, but actually have the NextStep look. So definitely no Appearance there. https://www.youtube.com/watch?v=4TpB_lgoT-0
Things only got interesting and Mac things started creeping in with MacOS X DR1, which looked the same as MacOS X Server 1.x, but had a new kernel and the first version of Carbon. DR2 had the first actual MacOS X Finder.
-
Notice how each menu has a different color text.
you can do that to most menus via the resourcefork´s menu classes, for the finder they should be in the system suitcase when i am not wrong.
So now I can make modifications to the extension instead of the system file.
this is really good, gotta try it in the next days. one of my most important apps is incompatible with kaleidoscope and this should kind of bring it back to me after 20 years.
-
I tried putting the AppearanceLib form 9.2.2 into 8.6 with the extension trick. It crashes when loading the desktop! Having drawn what appeared to be a blank System 7-style white menu bar with rounded corners. Neat to see System 7 potentially lurking beneath there. I rebooted from a different disk image and removed the extension and everything returned to normal.
I made an incomplete scheme-to-theme converter close to 15 years ago. If you had a favorite K Scheme, we can use that to mostly make a theme; it would need to be finished up by hand after running the converter.
It would be a neat project to try to add Scheme support to AppearanceLib and control panel. That would be a monumental project though. When I made that scheme converter, it attracted the attention of Greg Landweber. I had made some comments how Kaleidoscope had issues, I took sides with Apple, etc, not ever imagining he would see that. I don't even remember what I all said. But he did see it! And soon thereafter, the scheme archive died which I thought was kind of tragic. I would definitely want his blessing and potentially sharing of his source code before considering a project like that but I am not anywhere near the point where I could say that I could even do that or what it would take. Kaleidoscope does have some features that are not available in themes. Probably the best approach would work like this:
- Improve/finish the scheme-to-theme converter
- Add the missing features from Kaleidoscope into appearanceLib
- Convert all schemes of interest into themes.