• Please review our updated Terms and Rules here

Frustratingly Hard to Source Mac Software

NeXT

Veteran Member
Joined
Oct 21, 2008
Messages
9,130
Location
Kamloops, BC, Canada
I'll be honest that I built my own LAN ecosystem and have not really needed to download files directly from an older PowerPC or 68K mac from The Internet in 15 years so I've missed a lot in the meantime.
However I have been violently reintroduced into what the modern world of classic mac software availability is and oh my god, how the hell do you people function??

Okay, so I have a friend who the other night got a Power Macintosh 6300 family machine and we proceeded to get them setup with MacOS 8.1 because they needed a driver to use their Apple Fast Ethernet 10/100 PCI card and for the sake of our sanity it comes with a basic version of Stuffit Expander and our choice of Internet Explorer or Netscape.
Initially they wanted 7.6 but I wasn't ready to curl into a ball and die in a corner because without any way to load software, that mac was never going to be able to get online.


I'm lost. The more I feel around trying to see if there's a better way to do this I don't find anything but extremely stupid hacks which seems wrong given how Apple built their ecosystem to be designed for idiots (and it shows), many of which I don't see a first time user being skilled enough to do on their own, hence why I'm helping someone else which is revealing a pretty massive marble pedestal.
The best way to explain the problem is like an iPhone. When you get a nice and shiny new phone, the first thing it asks is if you want to transfer everything over from your existing iPhone.
What if you have never owned an iPhone? Have fun. The process to get setup is there but since you were clearly not here for the last decade we aren't going to make it clear how to join the cool club.
In this case however it's actually getting software, much less installing it. We have MacintoshGarden and MacintoshRepository being the two big names on the Internet for your Greyware and both do agent detection and will drop down to HTTP if you try to connect with an older browser. The problem is however they are impossibly heavy for these early browsers bundled with MacOS. The sites both eventually fail because they are too busy loading the UI. The obvious solution is "get a newer browser", however didn't we just state that by default the two biggest download sites for the classic mac aren't loadable on the only browser options you have out of the box? It's not like you can go elsewhere. It's also not like the passage of time caused this. Both sites just suck and don't have "simple" pages for early browsers, or at least they aren't created with the fact that if you got a fresh MacOS install, you only have two options and that's it. The HTTP sites are flawed. The HTTPS fearmongering rendered most if not all of the rehosted Macintosh file repositories inaccessible, unless you already have a newer browser....which we can't download because.....well you see the loop?
We ended up having to build a workaround that involved setting up a Filezilla FTP server on the person's laptop, dropping files downloaded using a modern Windows web browser into a folder and then using the built-in FTP client on the bundled browsers to reach across the LAN and download them on the mac. As a group we could not believe this was the only solution for someone completely new to classic macs and had no other available resources to draw from.

Once we did however get the process of how to download files sorted for the individual, we were still stuck with Stuffit files.
I know this problem. I know this problem very well. Stuffit's compression changed over the years and as a result you always needed at least three different versions of Stuffit Expander to unpack almost anything you downloaded, especially if it was a file that at some point had been handled by a FAT filesystem the resource fork got nuked. I solved this problem years ago. It doesn't help in this case though when all you have is the basic Stuffit Expander Apple bundled with the browsers on the install disc.
For those who do not know, that expander is false hope, especially now. If you have a sit file you can just drop it into the icon and one of three things will happen:

-Stuffit Expander opens, then closes and nothing happens.
-Stuffit Expander opens, nags you to buy the full version for faster decompression speeds and tools, then does nothing.
-Stuffit Expander actually does the thing it calls itself and decompresses the file.

More often you get 1 and 2. Well this means whoever stuffed or restuffed the file used a newer version of Stuffit and this very old version doesn't know what to do. On a tangent you won't believe my rage when I found out my copy of Adobe Photoshop 7 was downloaded and came in a sitX file. Yet another version of the compression format which only the last versions of Stuffit Expander supported.
Anyways, the solution here is to download a newer version of Stuffit Expander, like 5 or 5.5 which you can download from a number of places that grabbed it from Aladdin before their site went down (killing the direct links on a number of other older older software sites like mac.org), notably the above mentioned two repositories.....which you can't access from the mac, so we also have to pay the same stupid song-and-dance with FTP to get it on the mac. Now you are faced with the next problem. The installer you have been given has been packed (originally) in an smi file (we could also talk about sea files, but the same still applies). These are SELF-MOUNTING IMAGE files and were specifically designed for people without an existing or functioning copy of Stuffit Expander. You downloaded it. You opened it and it automatically extracted.
Except what you got was StuffitExpanderInstaller55.smi.sit
Yep. You can put self-extracting files into stuffit files and a lot of people did this. In fact, almost every smi you expect to find online is going to be like this and once again because of the above mentioned issues with newer versions of stuffit not working with older expanders and MacOS only shipping with the most basic of shareware versions of Stuffit Expander
YOU ARE SCREWED.
I wish violence upon everyone who partakes in this, either because they believe they can make the file smaller or to preserve the resource fork. Fsck you. Fsck youuuuu.

I'm old enough to remember when many of these file sites gave you the option of an smi or a sit file, specifically to avoid this problem. Presumably this knowledge went away once those sites died and as their contents was reconsolidated, their files were "curated" reorganized and of course, repacked before being uploaded to the current major players of sites.
Once again, there's this marble pedestal where unless you already have a number of applications you cannot actually get onto the mac without having prior access to the files through a mac, nothing is going to work.

I'm on my fifth cigarette now and I and others cannot comprehend how the hell this is at all possible that the Apple community as a whole just forgot about the ground-floor users who have no existing resources to work with and have completely failed to solve this. In comparison to how Bitsavers is accessible from everything with a web browser, there's nothing for the mac. Is this actually how it is or have we missed some other website where it's HTTP, it's the basic text-only formatting and a giant list of locally hosted files that actually solve all these problems?
 
Last edited:
if it's not super hard to detect versions of stuffit then it would be a great idea if these sites would show exactly which version a compressed file is packed with.
 
It’s been years since I’ve messed with classic Mac stuff, but from memory about the only thing I can say is this: if I were stuck with an old Mac and had to get software on it “directly” without help I would just give up, full stop. I feel like it’s always been that way, honestly. Just dealing with all the insane BS with resource forks getting amputated half the time you try to transfer anything to a Mac has left me with permanent bald spots from pulling my hair out.

So far as I’m concerned the only semi-rational way to deal with this is download all your software on a Linux computer with BasiliskII and/or SheepShaver installed and use it to fix up everything to the point that you can spoon-feed it to the real Mac via disk imaging and/or Netatalk. Like you said, everything is broken and awful and the people archiving this stuff put absolutely no care into making the files easy to consume or withstand being handled by intermediary OSes.

A little part of me dies all over again every time I see a CD stored as a Toast image. No. Just stop it.
 
I use a scsi Zip drive to get files to my Mac SE.

I think I followed this article to get that working. I have a USB Zip drive I can use with a modern computer, but I assume if you have a tweener with scsi you could use the same drive for both.


Before I had that I would make floppies using a kryoflux, but that is very hit or miss since the are GCR and not MFM. Sometimes it took multiple tries.
 
TBH it's painful to do this using an emulator too. Perhaps not as painful as you can feed the emulator disk images and thus you don't need a way to write disk images to physical disks, but still.

To make things worse there seems to be various conventions on how to store the resource/data forks on non-forked filesystems, and they seem to not be compatible, and/or not supported. I.E. at least Basilisk II supports reading/writing files from the host (afaik by just hijacking the ROM APIs to read/write files, or something similar), but you generally can't just download some file on the host and serve it to the emulation hoping that the resource fork survives.

I'd say that a problem here is that it unsurprisingly seems like a large percentage of those engaged in uploading/preserving old Mac software seems to be running OS X, and I have a hunch that they might be somewhat blind to these problems as they would have actually somewhat functional modern versions of these files, and I think that OS X can store forked files, so they can "juggle" these files between different compression programs and whatnot, and thus it's less of an issue for them. Perhaps.

This kind of makes me think that it might be a decent idea to have a virtual machine running OS X, partially as an intermediate step.
 
I use a scsi Zip drive to get files to my Mac SE.

Before I had that I would make floppies using a kryoflux, but that is very hit or miss since the are GCR and not MFM. Sometimes it took multiple tries.
Related tangent:
Is GCR the problem here, or is the variable bit rate that might not align well with the afaik fixed 2MHz sample rate of the Kryoflux?

(A tangent on this tangent: There were software + adapters for the Amiga to use MAC 800k 3.5" DD drives, as the Amiga controller can do GCR but not variable bit rate. I've been thinking a bit about this and it's somewhat surprising that no-one made an accessory connected to the video port, using the input for an external 28.xxx MHz clock, using a PLL circuit to run everything at a few different clock speeds to match the bit rate you'd end up when reading/writing MAC DD disk using a regular fixed speed 300RPM disk drive. On an OCS Amiga it would result in an incorrect picture, potentially dangerous to monitors that don't like the wrong sync frequency, and thus it would be a good idea to have the adapter also optionally switch off the sync outputs when running at an odd frequency. On an ECS or AGA Amiga the display is more programmable and thus it would be possible to output a signal with the correct sync frequencies even though the resolution would differ from the standard one. Good enough to at least display what's going on).
 
Is GCR the problem here, or is the variable bit rate that might not align well with the afaik fixed 2MHz sample rate of the Kryoflux?
Oh that a good point. I don’t know for sure. I think some people suggested that it was an issue with filtering in the drive that was expecting the normal mfm formats, but I don’t know enough about that to say if that’s right either.

I do know that when reading Mac disks with the kryoflux, sometimes some tracks would read with one drive, but not the whole disk, and so I’d read the disk with multiple drives to get enough “green blocks” and then recombine all of the files for the good reads into a new folder and then use that to create one good image.
 
To make things worse there seems to be various conventions on how to store the resource/data forks on non-forked filesystems, and they seem to not be compatible, and/or not supported. I.E. at least Basilisk II supports reading/writing files from the host (afaik by just hijacking the ROM APIs to read/write files, or something similar), but you generally can't just download some file on the host and serve it to the emulation hoping that the resource fork survives.

The UNIX filesystem access in BasiliskII/SheepShaver was mostly useless because of the resource fork issues. (They really phoned in the resource fork emulation for that.) What was really useful was:

A: Netatalk (you can use it to share with a running emulation instance), because it has good facilities for faking resource forks for things like archive file formats.
B: Disk image manipulation software like hfstools,
C: Running a local web server to reshare files in ways accessible to ancient browsers,
D: Various native Linux hacks for directly converting Mac formats like DiskCopy images, and
E: running native Mac browsers, decompression tools, etc, *much* faster than a 68k Mac does

All of these save massive amounts of time compared to trying to get the drooling gimp of beige plastic to do it.
 
… back in the day I actually got a Quadra 650 I bought at Weirdstuff for a few bucks running without having to fuss with physical media at all; it came without a hard disk, so after adapting a comically huge SCA server drive to 50 pin SCSI I hooked it up to the SCSI controller I had in my Athlon system to drive my scanner and used BasiliskII’s direct SCSI mapping support to partition and format the drive. Then I just dragged the contents of my emulator disk image over and called it a day.
 
Oh that a good point. I don’t know for sure. I think some people suggested that it was an issue with filtering in the drive that was expecting the normal mfm formats, but I don’t know enough about that to say if that’s right either.

I do know that when reading Mac disks with the kryoflux, sometimes some tracks would read with one drive, but not the whole disk, and so I’d read the disk with multiple drives to get enough “green blocks” and then recombine all of the files for the good reads into a new folder and then use that to create one good image.
Oh, I hadn't thought about that the analogue properties of the drive might be optimized for certain data rates. Good point.

Btw at least for the bielt drive disk drives (not sure how common that is, I would think that most are direct drive) it might not be that hard to disconnect the drive for the built in motor, trick the drive that the motor runs correctly, and then add your own motor from say a record player or cassette deck or whatnot, and run that at different speeds, to create a "DIY MAC DD drive" of sorts. Perhaps. Maybe.
The UNIX filesystem access in BasiliskII/SheepShaver was mostly useless because of the resource fork issues. (They really phoned in the resource fork emulation for that.) What was really useful was:

A: Netatalk (you can use it to share with a running emulation instance), because it has good facilities for faking resource forks for things like archive file formats.
B: Disk image manipulation software like hfstools,
C: Running a local web server to reshare files in ways accessible to ancient browsers,
D: Various native Linux hacks for directly converting Mac formats like DiskCopy images, and
E: running native Mac browsers, decompression tools, etc, *much* faster than a 68k Mac does

All of these save massive amounts of time compared to trying to get the drooling gimp of beige plastic to do it.
I haven't had a look at how much work it would be to build Basilisk II. In general I find that the biggest problem in changing things like this on existing open source projects is that they might be built using a build environment that might be hard to setup and/or take up loads of disk space (hey Microsoft Visual Studio... IIRC I had to install more than a gigabyte of files to get the small executable that shows what a DLL file exports...). Actually modifying the code to add/change features tend to not be super hard. Or rather for some projects it's not that hard, for others it might be harder, depending on how much indirection (for a lack of a better wording) the code uses to do various things.

Btw I've never tried it myself but it's said that the Appletalk implementation in Windows NT Server (maybe also a part of Windows 2000) works fine. So for someone like me who emulates various machines that might be a way to share files with intact resource forks.

I don't know if the Windows Appletalk server and Netatalk stores resource/data forks the same way or not. If not any change to Basilisk-II (and SheepShaver if that also has a host filesystem feature) ought to be able to use both formats. I.E. search for both ways to save files when opening an existing file, and configurable which way to create new files.

Btw it the "drooling gimp of beige plastic" is at least a PowerMAC 7600 or 8500, and it has say more than 64M RAM or so, and enough disk, another option is to persuade it to run OS X. IIRC you can run OS X 10.1.5 on these, even though officially OS X requires at least a G3 processor and IIRC at least 128M RAM. It's rather slow but not totally unusable to run OS X on one of these with 96M RAM and whichever PPC they have (720, 704 or whatnot). As a bonus OS X supports some PCI USB1.x cards without needing any additional drivers, which makes it easy to connect any mouse with more than one button.

(Anecdote tangent: Back when I used an iBook G3, the first white rectangular one rather than the "My First Computer" styled ones, I used an adapter to connect a Microsoft branded PS/2 mouse to it :) ).
 
Btw it the "drooling gimp of beige plastic" is at least a PowerMAC 7600 or 8500, and it has say more than 64M RAM or so, and enough disk, another option is to persuade it to run OS X. IIRC you can run OS X 10.1.5 on these, even though officially OS X requires at least a G3 processor and IIRC at least 128M RAM.

I’ll admit to being baffled as to how that would help in any way, considering how little useful software there was for OS X prior to Tiger and the web browsers and other tools are just as obsolete as what runs on OS 9, but sure, why not.
 
I know it's a narrow use case, but it's kind of a way to get a glimpse on how OS X was in it's earliest (but still somewhat usable) days.
IIRC there were at least an officially supported software development package, and it's a Unix line system, so I at least find it a bit more usable and pleasant than old school Mac OS.
Very much a matter of taste though.
 
I know it's a narrow use case, but it's kind of a way to get a glimpse on how OS X was in it's earliest (but still somewhat usable) days.
IIRC there were at least an officially supported software development package, and it's a Unix line system, so I at least find it a bit more usable and pleasant than old school Mac OS.
Very much a matter of taste though.

I have used every version of OS X since “Public Beta”, I’m aware of its capabilities. (And the very first day I had PB installed I had experimental ports of the NetBSD packagesrc tree installed on it, and by the end of the week I’d learned enough about NetInfo to get it partially working on a Solaris NFS domain.) My point was simply that installing a version of OS X that old on your beige powermac, which I think would require you to track down an ancient build of XPostFacto in addition to suitable install media for the OS itself, isn’t going to grease the wheels much so far as solving the problems the OP is complaining about.
 
We have MacintoshGarden and MacintoshRepository being the two big names on the Internet for your Greyware and both do agent detection and will drop down to HTTP if you try to connect with an older browser. The problem is however they are impossibly heavy for these early browsers bundled with MacOS. The sites both eventually fail because they are too busy loading the UI. The obvious solution is "get a newer browser", however didn't we just state that by default the two biggest download sites for the classic mac aren't loadable on the only browser options you have out of the box? It's not like you can go elsewhere. It's also not like the passage of time caused this. Both sites just suck and don't have "simple" pages for early browsers, or at least they aren't created with the fact that if you got a fresh MacOS install, you only have two options and that's it. The HTTP sites are flawed. The HTTPS fearmongering rendered most if not all of the rehosted Macintosh file repositories inaccessible,
And that is why we fail
Bitsavers looks the way it does for exactly this bootstrapping reason
and has a very thin vernier over what in the bad old days would have been an anonymous ftp site

I hope some day someone else will deal with this problem on macs, because I'm not going to
and set up a bitsavers-style repository with all of the bootstrapping tools in OS-appropriate
groups, not the giant bitpile of MG and MR

So now I've gone down a rathole what the best way to bootstrap software onto classic macs, and it would probably
be an external scsi emulator with an archive pre-loaded onto it where the target mac has no network connectivity.
Of course, all modern operating systems have depreciated the 68k-era pre-IP Appleshare file serving years ago.
 
Last edited:
my method (only applies to superdrive macs):
1) install OS from readily available disk (raw sector) images written with winimage or the like
2) obtain raw sector images of stuffit expander 4.5 (any 68k) or 5.5 ('020 minimum) from the garden and write them with PC

If you have an '020 or better you're basically done here. You can download whatever .SIT files you want on a modern PC, copy them to a 1.44MB floppy and extract on target system. If you have a plain 68k then you'd be well served to setup a basilisk instance on your modern pc. In the emulator you can unstuff the .SIT files which are too new to open on stuffit 4.x and then binhex them for transfer to the mac, or transfer over the network if your mac has a NIC.

If you only have a 800k or worse, 400k drive, then I can't imagine a process which would work without having a tweener mac with a superdrive.

FYI - Disk Copy 4.2 images can be freely copied across other file systems without concern for the resource fork, it's not needed for anything but the checksum which can be ignored. You will need to use resedit to set the type to "dImg" and creator to "dCpy" to get them to open.

Disk Copy 6.3 "read/write" images are identical to binary sector images from other PC based floppy image software such as rawrite or winimage and can also be freely copied across other FS.
 
If you only have a 800k or worse, 400k drive, then I can't imagine a process which would work without having a tweener mac with a superdrive.
If you want a really out of left field solution, I made disks for my 512K Mac (with the original 400K internal) by using a Apple IIgs netbooted off a Netatalk server:


(There are disk imaging tools for the GS that can write diskcopy 4.2 images.)

That is one thing the IIgs has over any 68K Mac, you can NetBoot it. Of course you need an Ethernet/Localtalk bridge, but until fairly recently they weren’t too hard to find. (One of the dumb ones intended for printers works.)
 
Of course, all modern operating systems have depreciated the 68k-era pre-IP Appleshare file serving years ago.

Nice thing about Unixoid OSes is you can still go back and install Netatalk 2.x. There’s enough retro activity around it that it hasn’t code rotted to oblivion… yet.
 
We could start a whole separate thread about how to restore and bootstrap old systems without having the whole vintage
ecosystem that surrounded them. I've done this a bunch of times at the museum where we needed a functional device for
something like a one-off video shoot where all I have is the machine and I want to bring it up using current(ish) computing
resources.
When you are doing these sorts of things at scale, keeping a room full of support equipment that needs to be fixed too
isn't practical or time efficent.
 
My problem is that you have to take everything you know and throw it away. Like in my case here, the person I am dealing is with is on the other coast, has no network infrastructure, a Windows 11 laptop and nearly no computer skills or extra Quality-of-Life hardware. Everything just came with the modem and the laptop and just coexists without you having to open a command line, compile code or configure servers.

AKA: Your typical mac user. ;)

While bitsavers is absolutely the idea I'm wishing existed, it requires commitment to host the site and perform maintenance. Something I've seen come and go multiple times in the case of my complaint. The other is the arguments of "what do you need to bootstrap a networked mac?" An updated browser? OS specific updates that used to be hosted by Apple? Resedit? A telnet client that wasn't originally freeware? A patched copy of Drive Setup? Appleshare Server? A copy of Timbuktu with the key in a textfile, stating it was downloaded from Demonoid? For as much as the Apple folk love to get their warez, they are also very quick to speak against piracy and these download lists I find easily tread out of available by necessity and into blatent piracy, which as an HTTP-only site that advertises itself as the go-to place to get your mac off the ground you don't want that. Browser downloads, Apple-supplied updates and tools, Stuffit Expander. What you do after that and how you handle the hell of incompatible disk/disc images is your problem. ;)
 
"what do you need to bootstrap a networked mac?"
The short answer is "it depends on what kind of mac you are trying to bootstrap"
I suggested a scsi emulator. But that would have to have a LOT of smarts going in to be capable of handling every type of Mac that had a SCSI port
in a turnkey fashon.
It would be incredibly cool if it could just load in enough code to be able to determine the model of the machine and throw up a magic dialog box to
tell you what to do without even bringing up MacOS, but that is not something I'm holding my breath to see.
There is a lot of magic that could happen with a drive emulator that could transparently switch to any image on it that you needed to install.
 
Back
Top