Infinite Mac: BeOS
blog.persistent.info
blog.persistent.info
Beyond that, I'm not sure if buying Be would have fixed the managerial problems at Apple. Would they have been able to add the required features to BeOS to turn it into a production OS without the project turning into another Copland? Would the existing Apple management have slimmed down the massive Apple product line that had dozens of nearly identical models? Would it have gotten rid of dead-end projects like Newton and Pippin? Etc.
Jobs is what makes or breaks Apple in that critical period. I didn't like him but that's relevant to the success of the company. JLG did not have whatever it was Jobs gave the company.
I wish that had happened... it might have saved both companies.
We paid Cygnus(?) millions for that. The multiple virtual inheritance needed for MediaKit was a real joy to get working.
32-bit Haiku can run old Be apps, but must be built with ancient GCC.
64-bit Haiku is built with modern GCC but it is not binary compatible with old BeOS.
This is a surprising amount of effort to not break compatibility ;-)
Which is what Windows has been doing since C++ replaced C for most of the systems programming stuff, around Vista timeframe.
There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.
I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
I get that from knowing my way around OS X, naturally it isn't Windows COM, rather shares many of the same ideas,
https://developer.apple.com/library/archive/documentation/De...
https://developer.apple.com/library/archive/documentation/De...
> I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
I think that those that use such argument tend to be on anti-C++ crowd, they forget that NeXTSTEP even had Objective-C++ as well.
This is just the part how they deal with forward ABI problems, and is exactly the same that Be was doing too, as I mentioned in an above comment: private impl pointers and "preemptive" empty virtual functions (Be calls it "stuffing", OS X calls it "padding").
https://developer.apple.com/library/archive/documentation/Co...
Note that on Android they took an hammer solution, programming patters to invoke such code on main thread, have as outcome that there are either lint compile errors, or platform killing the application, for those flows not verifiable at compile time.
But it was 90s era C++, so probably that was all just a polite agreement and the reality was that circumventing the message passing to directly call methods on objects that belong to other threads was common, and just as likely to happen by accident as on purpose.
Should be:
SwingUtilities.invokeLater(closure)If not, desktop computing would be taken over by C++ as main systems programming language, and UNIX like computing relegated to servers.
In the places where there's something entirely different going on, such as networking in earlier BeOS, it's trash and you'd obviously want to throw it away and do what Unix did - Be were doing so. So a hypothetical turn of the century fruit-flavour BeOS is probably much closer to "Unix with a different UI" than you're thinking. NeXT changed nothing there.
The amount of work done by Haiku to provide a proper POSIX userspace support proves the point.
There were several companies that had the BeOS source and that source can be found in the wild. It is speculated that yellowTAB ZETA was based on unlicensed BeOS source code.
"BeOS: Porting UNIX Applications"
https://www.amazon.com/dp/1558605320
Maybe I am wrong, won't dispute being 100% certain, nor do I have the R5 CD around.
1. The Rhapsody developer previews, which are NeXTstep with a menu bar at the top and desktop icons, and a Platinum skin.
2. Mac OS X Server 1.x which has cascading finder windows, an icon view by default, and some other things much like that.
3. Mac OS X 10.0, which I used, or tried to use, as a daily driver, with a broadly Mac-like experience with an Apple menu, but with app names next to it containing global "about" and "quit" options, and so on.
It never did acquire any of the nice stuff that came in with System 7 (e.g. drag-and-drop customisable Apple menu stored in folders in the System Folder) or MacOS 8 (e.g. folder drawers that shrink to tabs).
Yeah, a lot of those “blue” features never were adopted or came back. The whole spatial Finder concept was lost.
https://www.youtube.com/@designedinca
(Specifically they talk about Be beginning: https://youtu.be/5IFxwnXASyQ)
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 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.
It's also available for both 68k and PPC architectures. And the PPC version can run 68k software (it internally emulates a 68020)
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}.
{modern memory protection}, {virtual memory}, {preemptive multitasking}, and {networking}.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?
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.
I really need to dedicate some time to understand why. I'd love to contribute with apps and drivers.
I wish that there was some edict from KDE Project management telling everyone working on the Plasma desktop to spend a week in Haiku or something.
The amount of indirect "open a dialog box, click 6 tabs down, then enter a value" stuff in KDE that is a single drag in Haiku drives me mad.
GNOME 3 was trying to built a clean modern minimalist desktop without all the clutter inherited from the design of Windows... But all they know is, very visibly, Windows and KDE.
RISC OS is that clean legacy free desktop. It's unlike anything else, built from scratch by a team not interested in what the rest of the world was doing.
And it's still alive and still updated and works well on modern hardware. Several separate efforts are building 64-bit replacements today.
https://www.riscosopen.org/content/
It runs on all Raspberry Pi models up to the 4, and runs really well. As of version 5.30 it supports the Wifi chip in the Pi so it can connect to WLANs.
The owners of the IP are RISC OS Developments Ltd (ROD) and they have an enhanced version -- free on the Pi -- called RISC OS Direct, with an IPv6 stack and a modern WebKit browser:
https://www.riscosdev.com/direct/
They also sell more capable hardware for it.
There is another fork of the OS that is still proprietary. That's owned by 3QD. They used to sell upgrades for real Acorn-compatible kit but there's none of that that isn't vintage now, so it focuses on a software emulation that runs on modern x86 machines:
https://www.theregister.com/software/2022/06/21/risc-os-is-3...
Search the Reg for "riscos" and you'll find interview with the original core team, looks at the last couple of FOSS releases, the Moonshot effort to go 64-bit and more.
I know almost nothing about it, so I will give your links a read.
Uh, legacy free? I'd argue the opposite - it's got tons of legacy baggage - cooperative multitasking, and a lot is written in old ARM assembly language. It's disk limitations, filetypes.
> And it's still alive and still updated and works well on modern hardware.
I am quite impressed that the bounties that are put out to improve it get funded. (to be clear, this is not sarcasm , there's tens of thousands of pounds £s donated). I've tried in on my Pi, and it's super snappy, if a little odd.
Me, after a third of a century fighting modern preemptive OSes models on Unix, I'm over it, but I'm in a minority.
But what I'm talking about here is the UI design. KDE and GNOME are so accreted in layers of legacy junk that the original shape is hard to discern any more.
RISC OS isn't. It's unlike anything else.
The other thing is that it says right at the start of the BeOS Book - and this is carried across to Haiku - is that you shouldn't have a spinner or hourglass. It should do *something*, it shouldn't make you wait.
Now imagine macOS progressing to the point where title bars have been replaced with toolbars, and buttons no longer have borders, so you have to guess what part of the window will drag it.
:-|
I remember using the fluxbox wm like this back on the university Sun machines
Granted it was already Windows 10, so nothing that original.
I loved the tabs on BeOS.
Good work everyone who made this for Haiku.
And yes I know it's not really a linux specific thing, but that gets the point across. It is very common on linux. I could twirl my os/desktop hipster mustache and say "my obsd/spectrwm desktop handles no window chrome really well" but then I feel really pretentious instead of only slightly.
Speaking of which. It is not a Linux solution but stock X11 twm window manager features dating back into 1988, i.e.:
NoTitle
BorderWidth 0
Button1 = m4 : window : f.move
Button3 = m4 : window : f.resize
[0] m4 stands for the Mod4 modifier, now commonly assigned to the Super/Windows key. The equivalent 1988 configuration would have used m (Meta), since the original binding syntax supported Shift, Control and Meta only.
The original Nike store in NYC purchased one to do their signage media playback. It didn’t go well.
I was installing GNOME pieces compiling from source, on top of Sun Solaris. So it was a weird configuration. But FWIW I relied on the tabs a lot.
I seem to recall that you could hold down Alt key and drag the tab horizontally. So a tab could stick up anywhere along the top of the window frame. The SPARCStations had three-button mice, and this might have been mapped to middle or right mouse button.
The tabbed interface features the ability to gather windows into tab groups. So when you are moving a window by dragging its tab, if you drag the tab next to another window's tab, the dragged window will snap to that other window's frame, the dragged window will be the selected tab and its contents displayed in the frame. Then dragging any of the tabs drags the whole set of tabs that are snapped to that frame. Click on a tab to make it the active tab displayed in the frame.
It's effectively like tabs now, but sort of inside out: tabs are managed by the windows manager and not the app. Tab groups of multiple, different apps. The app does not have to be "tab-aware" to be in a tab group, although I suppose there are events that can signal the manager to make a window the selected tab. It's just raising a window, making it frontmost. Modal dialogs can get tangled up, but it's no worse than the mess commonly accepted today.
One of the few upgrade experiences that was a discernable improvement and completely revised experience.
And while I agree that Steve Jobs and Next were the right business (and people) choice, I still mourn the loss of a much better UI (never been a fan of the Mac UI, and it's my daily at-work system).
I'm a computer science teacher at the high school and part of what I do is make my students use old operating systems (via InfiniteMac.org and others) and ask them to identify what's the same on those older OS, what's better, and what's worse, and why.
My hope is that they don't just waste time by keeping on reinventing the wheel, getting burnt by the most easily avoided mistakes, or reviving something we've made the mistake of leaving behind.