Apple YOINKS everything good... Let's fix it

ChadVDR

Active member
I was looking at MacFUSE with HFS support and was disappointed at reports that it doesn't read old HFS floppies so it isn't really a full solution to the HFS limitations imposed since after Leopard.

This next part is related, trust me.

I was recently trying to archive some of my Time Machine backups to my NAS. I have been banging my head on this issue for months only to have long file transfers end with "Operation not allowed" or "Quit due to an error". I figured this had to be due to my NAS because when I encountered difficulty last time I had to move my Time Machine db's all I had to do was update to High Sierra. High Sierra made the process drag-and-drop so I figured it must be the same in Monterey. Well, as it turns out, my months of wasted time and frustration are simply due to Apple doing what they always do: thinking they know better than YOU.

Apple YOINKED the ability to drag and drop a .backupdb in Mojave. Well, first they broke it such that it would never finish the transfer and then just completely reverted back to pre-Sierra functionality (that being "Operation Not Allowed" or when you drag a 40GB .backupdb it results in something like 200GB and no longer functions within Time Machine).

Inspired by some recent projects by Phipli, timtiger and many others here I simply thought why does it have to be this way? Why can't we just keep the functions we want and tell Apple to beat it?

I'm dreaming here but maybe this turns into something. I'm just a stooge with a couple of old Macs and want them to work, maybe somebody a lot smarter than me already has the solution or is working on the problem. Here goes.

A large percentage of responses to my complaint is "use an emulator" or "use a VM". I read it all over the place. Use SheepShaver, use mini vMac, run Parallels etc.

How many emulators do we need? By my count I would need to emulate System 5, OS 8, Leopard and High Sierra for what? For full MFS support, full HFS support, AppleTalk, Time Machine backupdb copying and 32bit app support etc. Why bother with four full systems to bridge old and new?

What if we made our own swiss army emulator that takes only what we want and not the shortcomings that come with each individual system?

All along the way, Apple has provided bridges as we've progressed from one architecture or system to another. What if we round up all of those bridges and build a stripped down VM that includes all of this functionality and none of the shortcomings that we are used to?

Here's a perfect example. For my SD to SCSI adapter, it's best to use exFAT format. However, the OS on said SD uses HFS. Leopard supports HFS R/W but lacks exFAT support natively. Snow Leopard gains exFAT support but leaves HFS R/W behind. I'm aware of command-line tools and pluggins etc. that might beat these systems into submission and make them work but when does the insanity end?

In my concept, the VM can handle MFS, HFS and exFAT. Take Leopard's dependencies etc. for full HFS support, emulate MFS support, mix them with a later system. That system, though, only contains the bare minimum. Finder, all utilities, basically think back to your bootable System 7 floppy! How small is that system? Could we fit a functioning VM with nothing but utilities into 4GB?

Why not install 50 command-line tools and clean, update, compile from github?

This constant patching and maintenance is becoming a nightmare for somebody that can't devote every hour of free time to learning code. Add one thing here, break compatibility there, clean this macports directory, get a permission error, etc etc.

What is the advantage of gaming consoles over PC's? The system is LOCKED and documented. An Xbox developer knows exactly how much RAM, VRAM, and cache they have to work with. They know exactly what resolution it's going to output and they can manage issues taking into account just one system running at one speed with one resolution on one CPU.

When we boot from an installer image or the System 7 floppy, we always know exactly what we're getting. There can be no conflict within the system because nothing can be added or taken away from what is baked in. Whoever develops in my system always knows exactly what resources are available, which calls and halts to make, and each utility is aware of the other. That's in contrast to the github and macports notes I see that macFUSE doesn't work with the HFS plugin on certain MacOS' because of a conflict with a resource Apple didn't remove until Monterey, so if you have Yosemite through Big Sur you're SOL. How about; If you have my VM, all the features are included and tested. And in the new version of this VM we add support for a new feature that has taken into account every version of every extension, plugin, app, resource etc so you don't have to suss out conflicts on your own.

32bit apps run on Ventura...if you have it in a VM. So why not make this VM able to execute apps that are 32bit? What if we "bake in" Classic mode? We take the resources from genuine Apple Classic from Jaguar and tailor them so that any Classic app simply executes side-by-side with any OS X apps? Classic wasn't perfect but we don't need perfect just for a utility that acts as the end-all bridge for enthusiasts.


That's essentially what I want. I want a bridge. I want my M1 Mac to be able to do whatever Apple thinks it shouldn't be allowed to do any more. Apple deprecates a function? Throw it into the VM. A whole operating system devoted to picking up the pieces. I'll call it Yoinks LOL.

Long rant. I'm tired.
 

LaPorta

Well-known member
Well, short answer: I agree with you.

I was dismayed when I found out that FuseHFS doesn’t work with ANY real disks (which is all I’d need it for). I also don’t have time to learn all this command line stuff with a ton of hobbies and family. I wish FuseHFS would just read SD cards and call it a day. But…who will put in the effort? Who knows.
 

ChadVDR

Active member
I think what puts a sour taste in everybody's mouth is that we expect just about anything and everything to be free and thus the work and effort has no monetary value and people will harass you when it doesn't work...despite it being free. The open-source community is already putting in overtime just to feed their hobbies so why would they "dumb it down" for the rest of us? They had to learn how to make it work, making it work was their reward.

I'd 100% offer backing if somebody had a promising concept of exactly this. If we got something on the level of SheepShaver (when it used to work) I could personally see it being worth investing $200 but if we got anything near what OCLP has become (with a cleaner idiot-friendly front end) I'd be in it for $500. That's about what a programmer might make in 3 hours but hey if there are 20 people like me it is a start.

I know some of these things work but then everybody that wants the function has to rack their brain and pull their hair out looking for support and digging into their system. In my concept, once one person figures it out, it works for everybody. Download the latest VM version and it just works and will always work because it is a potted system with no surprises from a user. Don't you hate when you try to help somebody and you devote all the time and resources into figuring out what's going on only for it to be because the user fiddled with some plists or config files and forgot about it? Not the case in a potted or baked-in system.

Executing the actual VM would be no different than when we download preconfigured images for Classic OS versions. Put the OS image into SheepShaver and boot. Voila.

Hm, what if we were to base it on Leopard and patch onto that everything else? That would cover HFS, PowerPC/Intel, AppleTalk and SparseBundles. SparseBundle support gets us closer to integrating the High Sierra capability to drag and drop backupdb's. Pull in Jaguar and you have Classic support. Classic support gives you MFS if you can shoehorn pre-System 7 pieces into that.

So imagine a VM inside of a VM but because it's all baked-in you can do risky configs that would normally be a bad idea if done by the user. You can theoretically run Leopard in a VM to run PowerPC apps on Monterey, right? (disregard license restrictions and whether Parallels officially allows it) That Leopard VM could also run SheepShaver which emulates 68K Macs. If you were to "flatten" this concept... By flatten I mean once you're in the VM all enclosed VM's or emulation (sheepshaver, Classic) don't have to run within an enclosed window. They can execute apps side-by-side even though their resources are actually within the virtual machine that's within the virtual machine somehow.

Hm.... I might do something silly as a "proof of concept".
 

chelseayr

Well-known member
I don't really have anything more to add to this good if not long original post. I did some time ago try look up fuse for a few days but after having problems simply trying to run it I just decided to simply delete the whole thing instead and shortly checked kijiji for if there would be any g4 something around .. somehow managed to luck out on someone selling a cosmetic-fair function-great ivory ibook for cheap or that i got it (using like 10.4.11 or so I can't recall now, just know that it was a lot more capable than what 10.11+ won't directly support)

and mm yeah the ibook paired with an imation superdisk drive got quite a lot of uses plus an external cd drive just a few times too (the internal optical drive was in a bit of bad shape contrast to rest of ibook but hrm) .. now I barely even have anything that specifically needs the ibook for so may eventually boot it one more time soon to do a final batch of misc medias before I finally sell this kit off or something
 

IPalindromeI

Well-known member
You're talking about without proposing anything concrete. Running older software in virtualization has been done for years. What are you trying to accomplish here?
 

LaPorta

Well-known member
Not sure about OP, but two things I’ve wanted are:

1. FuseHFS to work on physical disks.
2. dd to have a front end like Disk Utility.

That’s about all I have to add :p
 

ChadVDR

Active member
You're talking about without proposing anything concrete. Running older software in virtualization has been done for years. What are you trying to accomplish here?
The idea is to have one virtual OS form a bridge between Classic, PowerPC, Intel and modern Macs.

Create a modified Mac OS (call it Yoinks) and strip down the overhead so that rather than running SheepShaver plus a whole install of High Sierra or Mojave or whatever you have just the bare system. Finder, disk utilities, the essentials. Strip out anything to do with the Mail app, iTunes, calendar, location services, screen savers etc. (Palindrome, if you've used a System 7 bootable floppy, it's essentially that)

Just like you open SheepShaver to run your image of OS 8, I think you should be able to open a similar VM to run an image of Yoinks.

The ultimate goal is that the single OS combines all of the bridging techniques we need. As I illustrated, full HFS support ends where exFAT support begins. This is just one of the niggles that can make this hobby so unnecessarily difficult and this mends it.

Yes we can just download and install 50 apps and command line utilities but most of us could just walk to work too.
 

CC_333

Well-known member
This is a neat idea, but I have a question or two:

Has anyone tried to simply copy the filesystem plugins for HFS from Leopard into Snow Leopard and vice versa for exFAT? Do such things even exist discreetly, or are they baked into the Mach kernel or some such?

I'm supposing that if it were possible, someone would've tried it years ago, and yet, I've never heard of such a thing...

EDIT: OOO, interesting! I just poked around a little, and on Mojave, there appear to be filesystem plugins under /System/Library/Filesystems, so I'm guessing this means that macOS is natively filesystem agnostic, and these plugins are implemented to allow for extra flexibility. If a similar folder exists under both Leopard and Snow Leopard, I'd be curious if swapping stuff around would work without causing too much breakage.

c
 

ChadVDR

Active member
According to this you are right. I would be cautious due to changes in coding versions such as later Python, Bash and AppleScript etc.

Sometimes getting software to work from one version to another is as simple as cleaning up the methods per-OS. That’s what I’ve read on some Macports notes at least. Just for instance: in later versions of Mac OS you can test network speed by simply typing “networkQuality” into terminal. The same function is possible in just about any OS X version but you have to write out quite a long script. So if you had a program or script that used “networkQuality” then you would have to clean up the code by adding verbose scripting to accommodate the older systems that don’t know the new command.

Thanks for reminding me but I think that we once could natively read and write NTFS volumes but no longer.
 
Top