With AI I feel like a lot of these bygone-era OS's could see a whole new ecosystem of modern apps within a very short period of time.
With AI I feel like a lot of these bygone-era OS's could see a whole new ecosystem of modern apps within a very short period of time.
At this point, they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.
I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?
It's also available for both 68k and PPC architectures. And the PPC version can run 68k software (it internally emulates a 68020)
It does but not all that much.
I had a Classic II, so a very limited machine.
Not a "road apple" but a "compromised Mac":
https://lowendmac.com/1991/mac-classic-ii/
68030 on a 16-bit bus, max 10MB RAM, no expansion slots so nothing except SCSI.
So, I put 10MB in it, a bigger SCSI HDD, a SCSI Ethernet adaptor on the back, and built both OSes up from scratch.
MacOS 6.0.8 with all the extras: a menu bar clock, hierarchical Apple menu with modular Control Panel, MacTCP, etc.
And MacOS 7.6.1, which doesn't officially support the Classic II as it wants 12MB RAM minimum -- but I had RAMdoubler. OpenTalk, Netscape Navigator 3, Communicator 4, some early Internet Explorer, etc.
Honestly, there was little difference. It was usably quick on 7.6.1 and more stable. So many things that are extras on 6.0.8 are built in to 7.x that it doesn't need that much more disk or memory.
7.x did more, made it easier, and ran well.
But, as an example, on roughly 1MBs ADSL, it took about half an hour to render the top-left quarter of https://slashdot.org/.
Perfectly usable machine, could do email, FTP, Gopher, but forget it on the WWW on of the noughties (2000-2009).
I would love to play with a hundreds-of-megaHertz class emulated classic 68K Mac on a Raspberry Pi! :-)
The PiStorm delivered this on a lot of classic Amigas.
After I wrote about it in 2024:
https://www.theregister.com/on-prem/2024/02/12/pistorm-turbo...
... Some people told me that everyone they knew still running classic Amigas had PiStorms in them. It is a cheap upgrade and it's apparently become ubiquitous.
As such, it's odd, but I don't know of fully-working versions for classic Atari ST or 68k Mac hardware.
There are 2 all-FOSS recreated ST OSes I know of now: AFROS, by the team behind ARANYM, and the formerly-commercial MagiX. It shouldn't be that much of an effort to make some bare-metal emulation that can run that on a Raspberry Pi.
Classic MacOS remains proprietary. Some of the comments in this thread hint at why -- that quite a bit of original Finder code at least made it into OS X. Pity. I'd hope that some day Apple might release whatever source it still has.
I'd love a community Copland to play with. :-D
I highly doubt this will ever happen. It seems like Apple is trying to avoid any association at all with classic Mac OS, even to the point of declining to go after folks hosting system software or ROM images, or even leaked ROM source code... on GitHub!
Even in the case of QuickDraw, whose source was published by the Computer History Museum, it's under a non-free license — so it wasn't quite released, but merely exhibited. (If you're unclear on the difference, ask any resident of a zoo.)
In the meantime, my own work-in-progress reimplementation of Mac OS is dual-licensed AGPL/commercial. The goal is to run classic Mac applications on commodity hardware.
Gopher://typed-hole.org it's fine too.
I've a wild whim to try this with Windows 95. What's an x11 or wayland? we're going EXPLORER.EXE!
Skins and theming only gets it so far, I want it to actually be the Win95 front end with Linux underpinnings.
It had most if not all of that.
It had networking from the start with AppleTalk, later Ethernet and internet with MacTCP.
MacOS 9 had a preemptively scheduled kernel.
The problem is having that and supporting the software ecosystem, which depended on cooperative scheduling without having memory protection.
MacOS 9 ‘solved’ that by running the classic OS in a single process. It had APIs for creating preemptively scheduled threads, but those threads were limited in what they could do.
You are describing attributes of the NeXT-based OS X but calling it MacOS 9.
MacOS 9 was the final version of Classic. No preemption, weak virtual memory, weak cooperative multitasking, no virtual machines for anything.
MacOS 9 is the OS that ran inside the Blue Box on Mac OS X for backwards compatibility.
You're mistaken.
> MacOS 9 [had] no preemption
Classic Mac OS has had vertical retrace (VBL) interrupts since System 1.0 (which are a form of preemption). But suppose we disregard that.
>> MacOS 9 had a preemptively scheduled kernel.
The GP is correct. Applications run cooperatively within the Blue task, but the Blue task itself runs preemptively with other MP tasks (which an application can create).
Very very little used it. About the only classic app I ever heard of that could even use pre-emption and background execution were some demanding Photoshop filters. Enough that Daystar Digital built multiprocessor Mac clones just for that alone:
https://lowendmac.com/1995/daystar-genesis-mp/
Within the MacOS kernel it is as coop as ever, and there were no different OSes inside virtual machines. No, Tenon MachTen does not count.
I think the clincher is this line:
« MacOS 9 ‘solved’ that by running the classic OS in a single process. »
That is absolutely unambiguously referring to Mac OS X. OS X ran what was even called Classic in a single process: the Blue Box.
MacOS 9 did not do that. It does not have pre-emptive "processes" as such at all and it does not run any older OSes in anything.
It is clear to me that this is not talking about the nanokernel, but if it were talking about the nanokernel it would still be wrong, because that did not appear in MacOS 9. It first appeared in MacOS 7.1.2 which was the first PowerPC release, I think, but that version had no tasks or anything.
But the first version with tasks and asymmetric MP support was in MacOS 8.6.
I could have phrased this better, the "modern" is a prefix on each item in the list:
modern {memory protection, virtual memory, preemptive multitasking, and networking}.
rather than: {modern memory protection}, {virtual memory}, {preemptive multitasking}, and {networking}.You'd lose compatibility with the applications, though, so you'd have to decompile and rework those as well. And even if you did, you couldn't legally distribute any of it.
An alternative approach is high-level emulation. Running a separate instance per application gives you process isolation (via the host OS) for free.
> I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?
I haven't measured it as such, but yes.
The AI know this too, and that is a way to rework the OS.
An AI trained on leaked Apple ROM code?
> and that is a way to rework the OS.
What you do on your own machine is your business, so have fun with that. You can't legally share it, though.
Nah, just one which read e.g. every Hacker News discussion like this.
> What you do on your own machine is your business, so have fun with that. You can't legally share it, though.
Unclear, as with so much else going on in this space right now.
Don't get me wrong, it feels like it ought to be against the rules to me… but then again, several highly successful businesses also felt to me like they ought to be against the rules.
Haiku specifically does not accept AI-generated code.
I expect if you use AI to explain how to write it and then write it yourself that would be okay.
You need to be able to explain your work without just pasting in what Special Needs Wintermute says.
Haiku still doesn't boot on many modern systems.
Haiku can use all the help it can get.
* I like hobby projects, no shade here. But it is a hobby project, just like the people trying to keep RISC OS modern, or my suggestion about MacOS classic. There's no obvious reason to pick these things over "just use some flavour of linux" in the present world, unless you're a nerd like us.
Ironically, it being a hobby project might actually be a good reason to keep the AI away: the effort is the point.
But it won't be included upstream.
If you look at Haiku, they have a handful of regular contributors. I think from memory they have one or two people working on it.
I would love to be able to sit down and port drivers by hand and contribute them. And maybe when I am retired in 20 years time, I can do that -- at which point, Haiku will be a 40 year old project.
Perfect is the enemy of good.
You already do. What are you trying to run it on, that isn't booting?