Confirmed: both Mac OS X Server 1.0's PowerPC AppKit and current ARM64e AppKit
create and add the titlebar controls in the same semantic order: close, zoom,
then miniaturize. Because later-added sibling views are in front, the
miniaturize button is above both the close and zoom buttons when they overlap.
The positioning code is also in AppKit in both releases: Server 1.0 uses
NSTitledFrame origin methods plus _tileTitlebar; current macOS uses
NSThemeFrame origin methods plus _updateButtonPositions.
- Server 1.0 PowerPC assembly
- Server 1.0 positioning
- Current ARM64e assembly
- Current ARM64e positioning
- Cross-generation comparison
The binaries establish matching behavior across the two releases; they do not by themselves prove uninterrupted source-code lineage from 1999 to 2026.
From this directory, install the read-only filesystem and disassembly tools:
./install_deps.shThen download or resume the exact preserved ISO and verify its size and SHA-1:
./download_iso.shThe dependency script installs hfsutils, sleuthkit, and capstone with
Homebrew. The download script writes the ISO into the directory containing
download_iso.sh, resumes partial downloads, and rejects a file whose size or
SHA-1 does not match.
To inspect the current, loaded AppKit methods and run the geometry probe:
clang -fobjc-arc -framework AppKit -framework Foundation \
inspect_current_methods.m -o inspect_current_methods
./inspect_current_methods --windowThe current-build offsets reported by that helper are reproducible only on the same AppKit build; the Server 1.0 addresses below belong to the extracted fixed address PowerPC image.
- Source image:
Mac OS X Server 1.0.iso - Size: 678,135,808 bytes
- SHA-1:
7f01415dc96093acc77edbfe8da0d003c0b56da7 - Container: raw optical-disc image with an Apple Partition Map, not UDIF/DMG
- Startup volume: classic HFS, 142,606,336 bytes
- System volume: big-endian UFS1 inside
Apple_Rhapsody_UFS - APM UFS partition offset: 296,388 512-byte sectors
- NeXT
dlV3front porch: 160 2,048-byte sectors - Actual UFS offset for Sleuth Kit: 297,028 512-byte sectors
The helper inspect_next_label.py parses the nested NeXT label and locates the
big-endian UFS magic values.
The files were recovered directly from allocated UFS1 inodes with icat.
| Installed path | Inode | Size | SHA-256 |
|---|---|---|---|
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit |
15899 | 5,268,704 | 6897a7fa932ba92cfe92a4a1af36db9300d63c1dcc81eb66ceba5963710a9240 |
/System/Library/PrivateFrameworks/appkit.framework/Versions/A/appkit |
31813 | 3,524,488 | 519d1bdf22fa47c738e03ae38952c5c8d28418fb7e1c056b8e9a0dea4ad3dd29 |
The relevant implementation is the public PowerPC AppKit dylib:
- Mach-O type: 32-bit PowerPC dynamically linked shared library
- compatibility version: 45.0.0
- current version: 380.3.0
__TEXTbase:0x43300000
Symbol: -[NSTitledFrame _updateButtons]
- address:
0x4336e0ec - file offset:
0x0006e0ec
The relevant PowerPC instructions, with selector references resolved from the extracted AppKit, Foundation, and System frameworks, are:
; close
4336e12c addis r4,r31,0x2f
4336e130 mr r3,r30
4336e134 lwz r4,0x5054(r4) ; newCloseButton
4336e138 bl 0x43642004 ; objc_msgSend PIC stub
4336e140 stw r5,0x5c(r30) ; close-button ivar
4336e148 mr r3,r30
4336e14c lwz r4,-0x7e2c(r4) ; addSubview:
4336e150 bl 0x43642004
; zoom
4336e1bc addis r4,r31,0x2f
4336e1c0 mr r3,r30
4336e1c4 lwz r4,0x5050(r4) ; newZoomButton
4336e1c8 bl 0x43642004
4336e1d0 stw r5,0x60(r30) ; zoom-button ivar
4336e1d8 mr r3,r30
4336e1dc lwz r4,-0x7e2c(r4) ; addSubview:
4336e1e0 bl 0x43642004
; miniaturize/collapse
4336e220 addis r4,r31,0x2f
4336e224 mr r3,r30
4336e228 lwz r4,0x504c(r4) ; newMiniaturizeButton
4336e22c bl 0x43642004
4336e234 stw r5,0x64(r30) ; miniaturize-button ivar
4336e23c mr r3,r30
4336e240 lwz r4,-0x7e2c(r4) ; addSubview:
4336e244 bl 0x43642004The factory symbols themselves are:
-[NSTitledFrame newCloseButton]at0x43373d24-[NSTitledFrame newZoomButton]at0x4338c944-[NSTitledFrame newMiniaturizeButton]at0x4338adc4
Positioning is also implemented in the public AppKit binary, not in Window
Server. -[NSTitledFrame _tileTitlebar] at 0x43346f78 asks the frame for each
origin and sends setFrameOrigin: to the corresponding button:
; closeButton ivar at self + 0x5c
43346fa8 lwz r5,... ; _closeButtonOrigin
43346fac bl 0x43642094 ; struct-return objc_msgSend stub
43346fb4 lwz r3,0x5c(r30)
43346fb8 lwz r4,... ; setFrameOrigin:
43346fc4 bl 0x43642004
; miniaturize/collapseButton ivar at self + 0x64
43346fe0 lwz r5,... ; _collapseButtonOrigin
43346fe4 bl 0x43642094
43346fec lwz r3,0x64(r30)
43346ffc bl 0x43642004 ; setFrameOrigin:
; zoomButton ivar at self + 0x60
43347018 lwz r5,... ; _zoomButtonOrigin
4334701c bl 0x43642094
43347024 lwz r3,0x60(r30)
43347034 bl 0x43642004 ; setFrameOrigin:The three origin methods are:
| Symbol | Address | Recovered position |
|---|---|---|
-[NSTitledFrame _closeButtonOrigin] |
0x43346844 |
x = titlebarRect.x; vertically centered |
-[NSTitledFrame _collapseButtonOrigin] |
0x43355c8c |
x = maxX(titlebarRect) - buttonWidth; vertically centered |
-[NSTitledFrame _zoomButtonOrigin] |
0x433568e8 |
x = maxX(titlebarRect) - _maxXTitlebarButtonsWidth; vertically centered |
For example, the collapse method resolves the titlebarRect and
sizeOfTitlebarButtons selectors, then performs the right-edge calculation:
43355cb4 bl 0x43642094 ; [self titlebarRect]
43355cc8 bl 0x43642094 ; [self sizeOfTitlebarButtons]
43355cec lfs f0,0x50(r1) ; titlebar x
43355cf0 lfs f13,0x58(r1); titlebar width
43355cf4 fadds f0,f0,f13
43355cf8 lfs f12,0x48(r1); button width
43355cfc fsubs f0,f0,f12 ; maxX(titlebar) - button widthThe Y path in all three methods computes half the difference between titlebar
height and button height, passes it through the binary's pixel-alignment helper,
and adds titlebarRect.y. Server 1.0 therefore does not place the controls
in a traffic-light row: close is on the left; collapse is at the right edge;
zoom is immediately to the left of that right-side group.
The same binary supplies the ordering proof:
-[NSView addSubview:]calls the child's_setSuperview:.-[NSView _setSuperview:]calls the parent's_addSubview:.-[NSView _addSubview:]lazily creates anNSMutableArraywithallocWithZone:andinitWithCapacity:, then callsaddObject:.-[NSView hitTest:]starts atcount - 1, fetches each child withobjectAtIndex:, and walks downward until a hit is found.
Therefore later-added siblings are in front. Server 1.0 creates and appends the buttons in close, zoom, miniaturize order, so the miniaturize/collapse button is frontmost.
On macOS 27.0 beta 6, build 26A5416b, AppKit UUID
6E2B8742-E130-3414-9402-57F0C396B9A7 has:
- binary:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit - dyld-cache
__TEXTbase:0x184ec2000 - symbol:
-[NSThemeFrame _updateButtons] - image offset:
0x5d3f4 - preferred address:
0x184f1f3f4
Its creation/add sequence is likewise:
; red / close
184f1f580 mov x0,x19
184f1f584 bl 1880944a0 ; newCloseButton
184f1f58c str x0,[x19,x28]
184f1f594 bl 1880738a0 ; addTitlebarSubview:
; green / zoom
184f1f624 mov x0,x19
184f1f628 bl 1880946f0 ; newZoomButton
184f1f630 str x0,[x19,x22]
184f1f638 bl 1880738a0 ; addTitlebarSubview:
; yellow / miniaturize
184f1f6c0 mov x0,x19
184f1f6c4 bl 188094610 ; newMiniaturizeButton
184f1f6cc str x0,[x19,x22]
184f1f6d4 bl 1880738a0 ; addTitlebarSubview:Current positioning remains in AppKit, now on NSThemeFrame. On the inspected
build the main methods are:
| Symbol | Image offset | Preferred address | Role |
|---|---|---|---|
-[NSThemeFrame _updateButtonPositions] |
0x00068e8c |
0x184f2ae8c |
Obtains and applies all button origins |
-[NSThemeFrame _closeButtonOrigin] |
0x00069098 |
0x184f2b098 |
Computes the red button's anchor, including centering/RTL/titlebar cases |
-[NSThemeFrame _setButton:frameOrigin:] |
0x000698b8 |
0x184f2b8b8 |
Converts/applies an origin to a button |
-[NSThemeFrame _collapseButtonOrigin] |
0x0006a3ac |
0x184f2c3ac |
Derives yellow from red |
-[NSThemeFrame _windowTitlebarButtonSpacingWidth] |
0x0006a47c |
0x184f2c47c |
Supplies inter-button spacing |
-[NSThemeFrame _zoomButtonOrigin] |
0x0006a4d0 |
0x184f2c4d0 |
Derives green from yellow |
Two related policy helpers are _shouldCenterTrafficLights at image offset
0x00069480 and _shouldFlipTrafficLightsForRTL at 0x00069528.
The compact part of the ARM64e positioning logic is the chain from close to miniaturize to zoom. Selector-specific dispatch stubs are annotated here:
; -[NSThemeFrame _collapseButtonOrigin]
184f2c3c8 bl 18803d810 ; _closeButtonOrigin -> d0=x, d1=y
184f2c3d8 bl 1880b1010 ; sizeOfTitlebarButtons -> d0=width
184f2c3e4 bl 1880706c0 ; _windowTitlebarButtonSpacingWidth -> d0=spacing
184f2c3e8 fadd d10,d10,d0
184f2c3f0 bl 188064700 ; _shouldFlipTrafficLightsForRTL
184f2c3f4 fneg d0,d10
184f2c3fc fcsel d0,d0,d10,ne ; choose -step for RTL, +step otherwise
184f2c400 fadd d0,d8,d0 ; collapse.x = close.x +/- step
; -[NSThemeFrame _zoomButtonOrigin]
184f2c4ec bl 18803d9d0 ; _collapseButtonOrigin -> d0=x, d1=y
184f2c4fc bl 1880b1010 ; sizeOfTitlebarButtons -> d0=width
184f2c508 bl 1880706c0 ; _windowTitlebarButtonSpacingWidth -> d0=spacing
184f2c50c fadd d10,d10,d0
184f2c514 bl 188064700 ; _shouldFlipTrafficLightsForRTL
184f2c51c fcsel d0,d0,d10,ne
184f2c524 fadd d0,d8,d0 ; zoom.x = collapse.x +/- stepThe binary shows how AppKit positions the row, but not Apple's original rationale. A likely reason for the relative chain is that close is the only button that needs the complicated global anchoring policy: titlebar geometry, centering, toolbar mode, custom offsets, and RTL can all affect that first origin. Once close is placed, the other controls only need to preserve the local invariant “one button width plus the current spacing from the previous button.” Deriving collapse from close and zoom from collapse therefore keeps the group contiguous while automatically inheriting changes to the anchor, control metrics, spacing, and layout direction. It also avoids duplicating the same global-position calculation three times. This is an inference from the structure of the implementation, not a claim recovered from source comments.
In a normal 640-by-480 titled test window on this build, the runtime probe
reports a 14-point button width, 9-point spacing, and origins {9,489},
{32,489}, and {55,489} for close, miniaturize, and zoom. The 23-point delta
is exactly 14 + 9. The displayed button frames have the same X coordinates;
their Y coordinates are converted from titlebar-view space by
_setButton:frameOrigin:.
This is positioning logic, distinct from sibling z-order. Stretching changes the button frames enough to expose their overlap; creation/add order determines which overlapping sibling is on top.
| Question | Same? | Server 1.0 PowerPC | Current ARM64e |
|---|---|---|---|
| Is the logic in AppKit? | Yes | Public AppKit framework |
Public AppKit framework, delivered through the dyld shared cache |
| Same frame class name? | No | NSTitledFrame |
NSThemeFrame |
| Same three factory selector names? | Yes | newCloseButton, newZoomButton, newMiniaturizeButton |
The same three selectors |
| Same creation/add order? | Yes | Close, zoom, miniaturize | Close, zoom, miniaturize |
| Same high-level operation per button? | Yes | Create, store in an ivar, add as a child | Create, store in an ivar, add as a child |
| Same add-to-hierarchy selector? | No | addSubview: |
addTitlebarSubview: |
| Same individual origin selector names? | Yes | _closeButtonOrigin, _collapseButtonOrigin, _zoomButtonOrigin |
The same three selectors |
| Same overall positioning entry point? | No | _tileTitlebar |
_updateButtonPositions |
| Same spatial arrangement? | No | Close at left; zoom and collapse at right | Close, miniaturize, zoom in one traffic-light row |
| Same positioning strategy? | No | Each origin is calculated from titlebar geometry | Close is the anchor; collapse derives from close; zoom derives from collapse |
| Explicit RTL-aware row direction? | No evidence | No equivalent branch in these origin methods | _shouldFlipTrafficLightsForRTL reverses each relative step |
| Same frontmost button when all three overlap? | Yes | Miniaturize/collapse, because it is added last | Miniaturize, because it is added last |
| Opcode-for-opcode translation? | No | 32-bit PowerPC ABI and common Objective-C dispatch stubs | ARM64e ABI, pointer authentication, and selector-specific stubs |
| Does this prove continuous source-code lineage? | No | Matching binary behavior is evidence, not provenance | Matching binary behavior is evidence, not provenance |
The creation groups correspond closely at the semantic level, but they are not opcode-for-opcode translations:
| PowerPC (1999) | ARM64e (2026) | Meaning |
|---|---|---|
mr r3,r30 |
mov x0,x19 |
Put self in the first argument register |
lwz r4,… |
Selector-specific call stub | Select the Objective-C method |
bl objc_msgSend |
bl msgSend$new… |
Call the button factory |
stw r5,offset(r30) |
str x0,[x19,…] |
Store the returned button in an ivar |
bl objc_msgSend |
bl …addTitlebarSubview: |
Add the button to the view hierarchy |
PowerPC loads the selector into r4, returns the object in r3, and repeatedly
calls a common objc_msgSend PIC stub. ARM64e returns the object in x0 and
uses selector-specific message-send stubs. Current AppKit also uses the
specialized addTitlebarSubview: rather than ordinary addSubview:.
Despite those ABI and implementation differences, both binaries have the same high-level sequence for each control: create, store, add—first close, then zoom, then miniaturize.
The observable claim is confirmed for both binaries: the Server 1.0 PowerPC AppKit and the current ARM64e AppKit create/add the controls in the same semantic order—close, zoom, miniaturize—even though Aqua placed miniaturize between close and zoom spatially. Because sibling order is back-to-front, miniaturize is above both other controls when stretched into overlap.
This proves matching implementation behavior across the two releases. It does not, by binary evidence alone, prove that Apple preserved the identical source code continuously between 1999 and 2026.