The author mentions that they didn't have a debugger and couldn't get MacsBug to work inside the emulator. A useful technique here is to use the emulator itself as the debugger: most emulators have features for setting breakpoints and single stepping through emulation and directly reading memory values from the emulated system's memory (by absolute memory address). For example, here is the documentation for 'hardware'-level debugging in the PCE emulator: https://github.com/jsdf/pce/blob/pcejs/doc/monitor.txt
One 'nice' thing about working with old architectures like classic Macintosh is that there is basically no abstraction between the software and the hardware, so manipulating the behavior of the emulated hardware becomes a powerful debugging tool.
MacsBug has a number of interesting features that are a bit above what you'd normally want from a CPU-level emulator, like setting breakpoints and being able to use debugging information. (Funnily enough, I'm taking a quick Hacker News break from implementing ptrace support in a CPU-level emulator, in part because trying to debug code without it means I need to keep Ghidra open and single-step code execution from the closest system call…)
MacsBug also had a ton of MacOS-specific features, like transparent integration with the 68k emulator, the ability to display symbols for both application code and the system ROM, and a wide variety of tools for interacting with the Memory Manager and Resource Manager (including intrusive operations like compacting or purging memory).
It also had mouse support -- you could click any address on screen to view its contents and information about the memory region it was in, for instance -- and a menubar. :)
Macsbug won't run in the SheepShaver emulator, as it takes a number of shortcuts which are incompatible with MacsBug. It works fine under qemu-system-ppc, though!
It's also not difficult to add them. Even in rtl style emulators like cen64, you just tap what's going on at the last pipeline stage or the ex stage, whichever is more convenient.
I miss the constrained design of Mac OS Classic. You could use multiple windows even on those puny Mac SE -type 512x384 displays and with some 1024x768 display you could have lots of different things happening for file operations, apps etc. It's weird that X's current windowing system is really bad at this even on 4k displays.
Oh and the spatial file navigation with Finder worked perfectly. Haven't seen anything so awesome ever since Classic got obsolete.
I'd say some of the problem is precisely that they didn't really update UI for larger screens. The menu at the top made perfect sense on small screen when the movement was small, on my 4k (non-scaled) screen it's definitely a chore.
I wish it were possible to still use them for anything useful... I'm slowly working on a new ssh client for 7/8/9, but there's no way a modern browser could be ported, and the CPUs would be too weak for the modern web
I have a quadra that I haven't booted in several years, running A/UX. I also used to own some other old world ppcs. I remember a decade ago or more, ssh was very slow on them. Hope your client has figured out how to make that not suck.
I also think it'd be kinda cool to see an X window manager that takes some hints from classic Mac.
>I also think it'd be kinda cool to see an X window manager that takes some hints from classic Mac.
A full, lightweight Classic Mac OS clone DE would be amazing, though I suspect that it might have to cut out X11/Wayland in favor of something more direct to get the same feeling of snappiness and "one piece construction" that original Mac OS had.
I disagree with this. Hardware is so crazy good now relative to then, that you could put layers upon layers of abstraction (including say a 68K mac emulator compiled to javascript and running inside Firefox on x11) and the old-school gui tasks of the 90s still purr.
If apple could do it at 25mhz or whatever, a modern amd64 machine should be able to handle it no matter the overhead of the windowing system.
great thought, but (!) I have to say from personal experience, you can bring practically any system, of any horsepower, to a crawl, with overweight layering and dispatching..
That's true. So, I would say there is an unspoken emphasis in my comment that you also need to do it "right".
Personally my X setup looks a lot like the 90s, and when people say X performs so terribly, I really don't see it. The hardware runs circles around what I used to run X on 20 years ago, and the software setup isn't really very different. But most people when they use X or think of X are thinking of a really heavy desktop environment.
Dumb newbie question, but does it handle TLS 1.3 okay?
I was using my Pismo G3 on the weekend and frustrated at how much of the web was inaccessible just because Mac OS 10.4 lacks modern TLS. The machine itself worked quite well with Opera for sites that were still HTTP compatible. If you've solved that for 68k machines, maybe it will be possible to get it working for software on PPC machines too.
It seems like the continued evolution of TLS is a huge barrier to retrocomputing with current networks. Relatedly, I happened to be writing some TLS code on a bit of a side project and I was curious on what old OSs I could get it on with minimal effort. I found the builtin SChannel on Windows XP for example cannot interact with www.google.com at all, or even some of my own TLS-enabled hosts that I maintain myself.
For projects with source available or that you're hacking on, it's not very hard to build libressl. It's a shame that some of these older OSs probably can't have support bolted on for 1st party APIs. Of course, they also are probably full of security holes and you probably don't want them on the public internet anyway.
Another barrier some day will be that those old systems are ipv4-only.
> It's a shame that some of these older OSs probably can't have support bolted on for 1st party APIs.
What first-party APIs? As far as I'm aware, classic Mac OS never had native SSL/TLS support -- every application which needed it (mostly web browsers in that era) included their own implementation.
One thing that's pretty interesting is how much the OS X/macOS aesthetic drifted back pretty close to the original MacOS 8/9 aesthetics (although since Yosemite it's been a little closer in brightness to 7).
It would be great if the PowerPC-specific changes to Swift could be upstreamed so that Switft can be built on Debian's (and other BSD and Linux distributions) powerpc port.
One 'nice' thing about working with old architectures like classic Macintosh is that there is basically no abstraction between the software and the hardware, so manipulating the behavior of the emulated hardware becomes a powerful debugging tool.