I’m trying to install Word 5.1 on the existing Apple Mac OS 7.5 environment. When I get to the part where the installer asks for the second disk, I try the button on top “Change Resource Media” to the next disk, but the emulated environment does not see that I have changed disks.
Any tips?
Cynde
Hi Cynde,
Ethan is off the grid this week so I’ll do my best to find a solution in his absence. Will get back to you ASAP.
Seth
Unfortunately, the Basilisk emulator does not support the change media functionality. Our apologies for not indicating this in the UI.
We’re thinking through possible alternatives, but we may be unable to support this workflow due to the limitations of Mac emulators like Basilisk and Sheepshaver.
Seth
I was able to get around this limitation and import .sit files into a freestanding Basilisk emulator that has Stuffit Expander installed. First adding DiskCopy 6.0 as a .sit, then using DiskCopy to install a multi-floppy thing like Word 5.5 which was also imported into Basilisk as a .sit file.
In EaaSI, using the preset environment “MacOS7.5 + Stuffit Expander 5.5,” I expand DiskCopy 6.0, then see its icon there on the desktop, I shut down the emulator and then save the environment. Both as a new environment, and another time as a revision.
Both ways, when I restart the saved environment, DiskCopy 6.0 is no longer on the desktop. Just the CD with the .sit image is still in the drive.
Same with Word 5.1, when I unstuff it into a folder, shut down, save the environment, going back to this saved environment the files are no longer unstuffed.
So, Basilisk behaves differently in EaaSI compared to freestanding.
Cynde
Hi @Cynde_Moya , everyone -
First, as @seth.r.anderson confirmed, the “Change Resource Media” feature will not work with Basilisk or Sheepshaver-based Mac environments. It is a relatively recent addition, but I have made a page in the User Handbook that describes limitations and work-arounds for situations like this, where the underlying emulator’s functionality limits what EaaS/EaaSI can do. I will do my best to keep that page updated while we work on how best to communicate these complications more directly in the UI itself.
Second, when working with any classic Mac OS (pre-OSX) system in EaaSI, if you are trying to create a derivative or new environment by unstuffing or copying an application, I strongly recommend explicitly copying the application to the system drive (the one with the operating system on it, usually named “MacintoshHD” or similar - I believe that is what it is called in the Mac OS 7.5 environments in the hosted service) rather than the desktop. Detailed explanation below, but please try copying or unstuffing DiskCopy 6.0 and Word 5.1 into a folder on MacintoshHD rather than the desktop, then saving the environment in EaaSI (either as a revision or new), and please let me know if the files persist as expected.
Since OSX, every user has their own “Desktop”, so files and folders persist when you’re logged in as that user. Since classic Mac OS was “single-user” (no option to log in to the OS as different users), every mounted storage volume/drive had its own hidden “Desktop” database, storing info about icons, application shortcuts, etc. The icons and applications that displayed on the desktop were actually an invisible amalgamation of any and all of the hidden Desktop DBs available.
Now combine this behavior with the particular way that Mac OS mounts disk images when emulated via Basilisk or Sheepshaver: on the guest Mac OS side, everything gets treated as a hard disk drive (even if we the users, and EaaS, know that we are trying specifically to mount a floppy or CDROM image). Even though the mounted image should be “locked” (i.e. you won’t be able to copy or create new files on the mounted disk in Mac OS), Mac OS will still create a hidden, invisible Desktop DB for that mounted Software or Content resource. And following on that, if you copy or unstuff any files or programs directly from the mounted CDROM image on to the “desktop”, it will only edit the Desktop DB for the mounted CDROM image’s “disk”. The Desktop DB on the system drive - which is what persists from one EaaSI environment and session to another when you save derivatives - remains untouched. So you’re “saving”, but EaaSI discards the edits you made to the desktop because they’re associated with the mounted resource, not the persistent system drive.
I found all of this through a rabbit hole on the Emaculation forums: it’s referring specifically to “shared” guest/host folders here, but the problem is the same:
https://www.emaculation.com/forum/viewtopic.php?p=55465#p55465
Users there recommend explicitly moving/unstuffing /installing files and programs to the system drive rather than using the desktop to organize things if possible, and again why I recommend doing the same with any changes or additions you absolutely want to persist in an EaaSI environment using Sheepshaver or Basilisk.
(Particularly with unstuffing a .SIT from a mounted disk image that is then itself a floppy disk image when uncompressed, it’s near impossible to figure out what Desktop DB you’re editing…FWIW though, there is a shareware program called “Greg’s Browser” for classic Mac OS that is basically a more powerful Finder that can reveal hidden files and folders, or “ResEdit”, which similarly can reveal and edit hidden properties like the “invisible” file tag and resource forks)