Archive for April 18, 2025

Friday, April 18, 2025

Returning to macOS After 20+ Years on Windows

Randy Parker (via TidBITS-Talk):

For longer replies in Messages, I would often compose my message on my computer, email it to myself, and then copy and paste it from the Mail app on my iPhone into the Messages app.

As a Windows user, I’d have to live with this frustration indefinitely unless I considered one of the following options[…]

[…]

While looking for Mac video tutorials, I discovered another invaluable resource: Gary Rosenzweig’s MacMost YouTube channel. Rosenzweig’s polished and professional tutorials cover topics from the most basic to the most obscure (not only about macOS but also about iOS and more).

[…]

Much as I feared, the [Photoshop Elements] data migration didn’t go smoothly. The program’s backup and restore method failed. Instead, I had to experiment with manually copying over my catalog and photos and then converting the catalog format from 2022 to 2025. Eventually, I stumbled on a sequence of steps where everything migrated correctly.

[…]

I have absolutely no regrets about finally making the switch back to Mac. In fact, I quickly came to prefer the macOS user experience over Windows.

One big reason: the user interface congruity between macOS, iOS, and iPadOS.

Previously:

Investigating MacPaint’s Source Code

Jeffrey Starr (via Stephen Hackett):

One of two launch applications for the Apple Macintosh in 1984, MacPaint is emblematic of the Macintosh’s early quirky revolutionary branding, focus on ease of use, and appeal to artistic customers. Using the source code, we examine the design and implementation of the application. We find that the buffer management and bucket filling algorithms demonstrate mechanical empathy with the 68k platform and leverage the limitations of the domain as a means to improve performance. We also find positive and negative aspects in the code style and architecture and its pliability for change. Finally, we dispute some claimed novel aspects of the program while also arguing for its significance and impact on the development of digital graphic systems.

[…]

Atkinson took Polaroids of the user interface as it evolved and drove into work to share them with the team. Fortunately for posterity, Atkinson saved the Polaroids and we have a detailed visual history of the evolution of the Lisa interface and QuickDraw capabilities as shown in the 2022 CHM interview below.

[…]

The Macintosh team used the ‘Monkey’ as a durability and robustness test mechanism. Developed by Steve Capps, the Monkey would randomly type keys, move objects, and interact with menus (Atkinson 2010, pg 14-15). The team used a computer running in Monkey mode to effectively stress-test an application. MacPaint was able to survive two weeks without crashing.

[…]

Performance-critical code, such as that which manipulates the buffers directly, is in assembly. User interface control logic is in Pascal, as well as code that handles initial setup or rare operations. Operating system calls, such as checking the amount of spare space in the disk drive or invoking the system beep, are in assembly.

Bill Atkinson:

I am asking friends and well-wishers to pray for me. I believe that group intention can actually make a difference.

On October first, I was diagnosed with pancreatic cancer. Because of vascular involvement, surgery is not possible. I am taking weekly chemo treatments to shrink the tumor before surgical resection.

Previously:

The Invalid 68030 Instruction That Accidentally Allowed the Mac Classic II to Successfully Boot Up

Doug Brown (via Uli Kusterer):

This is the story of how Apple made a mistake in the ROM of the Macintosh Classic II that probably should have prevented it from booting, but instead, miraculously, its Motorola MC68030 CPU accidentally prevented a crash and saved the day by executing an undefined instruction.

[…]

I didn’t get very far while testing the command+power shortcut in MAME’s emulated Classic II, because I observed something very odd. It booted up totally fine in 24-bit addressing mode, but I could not get it to boot at all if I enabled 32-bit addressing, which I needed in order for MacsBug to load. It would just pop up a Sad Mac, complete with the Chimes of Death.

[…]

This meant the bus error handler was at 0x40A026F0, which is also known as GenExcps in the ROM map. I performed a hard reset of the emulated machine, set a breakpoint on that address, and then waited until it hit the breakpoint. It looks like GenExcps is a big list of BSR instructions that all jump to 0x40A026A0, which is common error handling code identified in the ROM map as ToDeepShit. Nice name, Apple!

[…]

If you look closely at the table of branches below the JMP instruction at 0x40A43B6E, there are only 16 entries in the table, corresponding to BoxFlags 0 through 15. The Classic II is BoxFlag 17!

So it jumped into the middle of an instruction.

The MAME-emulated Classic II was crashing because A1 didn’t change, so it still contained an invalid address. On hardware, this weird instruction, which several disassemblers refused to touch, and wasn’t even intended to be jumped to because it starts in the middle of an actual valid instruction, was changing A1 to a new value that was a good address. Was this crazy instruction accidentally fixing A1 and thus hiding a bug from Apple’s ROM developers in the early 1990s?

This is just an amazing story and writeup.