I've committed a new feature to SheepShaver CVS. Currently, it is for Mac OS X and Unix only.

The idea is to allow for self-contained SheepShaver VMs, in a similar fashion to, for example, VMWare Fusion VMs.

The system is quite simple. If you create a folder with a .sheepvm extension, and put into it a file called "prefs" (what was previously in ~/.sheepshaver_prefs) and a file called "nvram" (what was previously in ~/.sheepshaver_nvram), you can then pass this folder path as an argument when launching SheepShaver - which will then use those files. Additionally, any relative path in the prefs file will be relative to the root of the .sheepvm directory (so you can put your ROM and disk images files in there).

On Mac OS X, as an added benefit, I've modified the Info.plist file so that .sheepvm bundles can be double clicked to automatically launch SheepShaver with that bundle.

This should make it much easier to have multiple OS installs (such as 8.6 and 9.0.4) at the same time.

Note: There isn't a feature to "manage" VMs, or open/close them from within a running SheepShaver yet - the one that is to be used is set on launch of SheepShaver only.

Also, if SheepShaver is launched normally - without a .sheepvm parameter on the command-line and without double-clicking a .sheepvm file on the Mac, it should behave the same way as before - ie read ~/.sheepshaver_prefs and such.

I'm somewhat confused. Are Myrd's changes in addition to the ones fixing the 512Mb limit of Sheepshaver, or have they been effected on a version of the source code prior to that fix? Once both things are consolidated, can someone create a new universal build that will fix the memory limit and provide the new bundle feature?

In addition, perhaps someone can give a step-by-step explanation as to how to adapt our current SheepShaver files and folders structure to the new bundle feature. For instance, which specific files should the bundle contain, apart from the OS 7/8/9 disk image itself? Does each bundle contain its own SheepShaver configuration file, or is a single configuration file still used? Does it make any sense to have a ROM file within each bundle, or can the ROM be in the same folder where SheepShaver resides? I take it for granted that the "Unix" folder should be outside the bundle.

For that purpose these changes were not really needed. I have no problem having multiple OS installs at the same time and even running them at the same time:

From left to right: 9.0.4, 8.5.1, and 8.6 with new world rom, and 8.1 and 7.5.5 with old world rom. Simply put for each installation all files in the same folder with a copy of the SheepShaver application, make sure files have identical names and use those file names in preferences instead of full paths.

But I suppose that with your changes it is now possible to have a portable SheepShaver installation on a USB stick.

The changes that solved the "Cannot map RAM" issue and that removed the 512MB limitation are not (yet) added to CVS. Myrd added his changes to CVS. So if you now build from CVS, you can have Myrd's changes, but not mschmitt's changes.


It is about the possibility to have the prefs file and the nvram file (now at root level in your home folder) together with SheepShaver and the other files in one folder with a .sheepvm extension. That folder could be a clickable bundle. Not sure how useful that is for the average user, but I suppose one could carry a configured SheepShaver installation on a USB flash drive.

Having everything together in a bundle was asked for by some users with the idea that SheepShaver could be distributed that way, with all files (rom file, disk image) pre-installed in the bundle. Well, for the rom file that can still not be done legally.

It's possible to make this both absolutely legal and useful by omitting the ROM file but including instructions on exactly which ROM needs to be added to the bundle. In Mac OS X, the user could presumably use the Show Package Contents item on the contextual menu, and add the ROM file easily.

Yes, of course. But that does not make a bundle any easier to use or distribute than a normal folder. The #1 problem for first-time users is to find a compatible ROM file and to succeed in at least entering name or path to that ROM file in GUI or Prefs so SheepShaver can at least be launched at all.

The only possible real advantage of a bundle that I can see is when it would be possible to distribute it with all necessary files inside. It will be possible to distribute the bundle with a pre-configured prefs file. That might help a little.

It appears to me that the .sheepvm bundle logic requires a pref file to be in the bundle. It is not possible to create a brand new self-contained SheepShaver VM from scratch.

For example, you can't create a new sheepvm folder, put a ROM in it, and use it to launch SheepShaver. It gives an error: "No file at <sheepvm path>/prefs found" and then quits.

Instead, you have to create the SheepShaver prefs file through the conventional means, and then transfer it to the sheepvm folder.

This would seem to me to be a problem for new users, especially since the pref file created conventionally is a hidden file, so it is difficult for novice users to find it and move it.

Also, does the stand-alone prefs editor know how to find a prefs file in a sheepvm folder?

A prefs file will be created if you follow this procedure:

1. Name the used rom file to "Mac OS ROM". SheepShaver will recognize a rom file by that name when launched for the first time (when launched with no prefs file present).
2. Double-click the self-contained VM. SheepShaver will launch and will show the floppy icon with blinking question mark. A prefs file will be created, but yet incomplete with no reference to the rom file.
3. Open SheepShaver preferences, enter the name of the rom file, and do the further configuration as usual. For files inside the VM bundle no full paths are needed, only the file names.

The same procedure will work with the 'normal' setup and with the previous builds. See this manual: http://www.emaculation.com/doku.php/she ... os_x_setup

Edit: If you want to use the stand-alone prefs editor, it needs to be inside the bundle.
Edit 2: Correction: No, you're right. The stand-alone prefs editor will not write to the prefs file in the bundle, it will write to the ~/.sheepshaver_prefs file.

That's what I did -- but it never started the Mac. SheepShaver quit when it tried to load the prefs.

Oops, you are right. I was so convinced that it would work that way in the bundle also, that I did not actually try it. There must be a configured prefs file present. Not sure what minimum content it needs. Just a line "rom Mac OS ROM" apparently is not enough.

It will work with a rom file named Mac OS ROM and only the line with a ramsize in the prefs file. I wonder if this is now also true for the 'normal' setup. I will try that.

Edit: In the 'normal' setup no existing ~/.sheepshaver_prefs file is needed. With the latest build it still works as described in my manual.

I have done some more work to expand this feature, and the result is a SheepShaver Launcher application for Mac OS X.

It's basically a manager application for SheepShaver virtual machines (.sheepvm bundles). It displays them in a list, and lets you edit the settings of a specific one (i.e. vm prefs) and launch it - as well as add existing .sheepvms to the list, or create new ones.

Inside the bundle (inside Contents/MacOS) is a copy of the SheepShaver executable, which SheepShaver Launcher uses to launch the virtual machine.

I have uploaded SheepShaver Launcher beta1 at: http://projectmagma.net/~myrd/SheepShav ... her_b1.zip

Please try it out, and give me feedback. The SheepShaver executable inside it is one that I built from CVS that is Intel-only. You can replace it with a different one, if you wish (such as a Universal version or one that was build with the memory fix that's currently not in CVS yet).

All the code for the launcher is in CVS with an Xcode project.

This is a terrific idea - many thanks for it. It works perfectly and easily.

One request for a future version: can you make it possible to rename a *.sheepvm bundle directly from the list?

This is already a superb idea. Thanks again.

Sounds great! Right now I am very busy, but I will try this as soon as I have more time.

Hi,

Some remarks on the launcher. On the fundamental level: We now have a built-in prefs editor, a standalone prefs editor and your launcher app. I confuses me that it now looks like the launcher, with all the abilities the prefs editors also have, would be able to create complete SheepShaver packages.

On the usage level: If I want to create a hard disk file from the launcher, it is created at a location at my discretion, but not inside the .sheepvm folder. If I move the hard disk file inside the .sheepvm, the launcher can't find it, and I can't adjust the path to point to inside the .sheepvm folder, because I can't browse the package.

Result:
I need to manually put the required files into a .sheepvm folder to get the launcher going. And I need to manually adjust the path in the prefs file.

In my opinion, the launcher prefs windows would not need the options to handle disk/rom files inside the .sheepvm folder, simply because it can't handle them (or not yet? What are your plans with it)

Another feature I would like to see added is the ability to remove virtual machines from the list. My experiments have already created 5 vm's listed, of which some are copies and I can't remove them.

Best,

Cat_7

I thought there was no way to remove VMs from the list, but I discovered that all you have to do is highlight a machine and press the Delete key - you'll be prompted to remove the VM from the list.

Here's b2 of the Launcher:

http://projectmagma.net/~myrd/SheepShav ... her_b2.zip

Main change is you can now browse to inside .sheepvm bundles - and also default disk creation location is inside the .sheepvm bundle.

As for the confusion in terms of prefs editing - I think this launcher obsoletes the standalone prefs editor, while the built-in prefs editor from the SheepShaver prefs menu can be complimentary, but I need to update it to be consistent with the one in the Launcher.

One possibility for the future is to have the Launcher app simply be called SheepShaver - and to not distribute a "stand-alone" SheepShaver version. This would make the experience more consistent with products like VMware Fusion. Obviously, the launcher would need to reach a level of usability that it doesn't yet have, but I think its possible to iron out all the issues eventually. The other concern would be the experience diverging between different platforms - unless someone writes an equivalent launcher in GTK or something.

This is terrific.

One suggestion: could you add a field at the top of the Setup tab (above the list of disk volumes) with a name something like "Folder name"? This would display the current foldername of the bundle, and let the user change the name from there. It might need a "Change" button, then a pop-up dialog, and an OK button in order to tell OS X to change the name, but that would be better than going to the Finder.

Thanks for this!

Tried beta 2.

It is fun to have different VMs running from one single executable, but I am not sure if a first time SheepShaver user can easily understand how to use it. It is really convenient, though, that browsing in the prefs editor defaults to the selected VM folder.

- The VM is now a normal folder, not a clickable bundle anymore. Is that intentional? Maybe to allow browsing inside the folder?

- Both the Launcher and SheepShaver present themselves as SheepShaver in the menu bar and other places. Only in the Dock it is called SheepShaverLauncher. When all instances of SheepShaver are quit from the Dock, the Launcher is still running as SheepShaver. Confusing.

- The preferences cannot be used anymore in SheepShaver itself. The menu item is still there, but it disappears when selected. That is because it needs to be updated?

- Not sure how useful the "New" button in the launcher is. It wil create a new VM folder, but one still needs to go into the Finder to gather needed files.

- The prefs editor does not have the Refresh Rate setting "dynamic" (frameskip 0) anymore. Intentional?

- There is a new prefs setting "Ignore Illegal Instructions". What does it do?


Suggestion for possible improvements:

For the Launcher:
- Again showing the Virtual machines list window when the window was closed and the Launcher is activated again.

For the prefs editor:
- Possibility to browse for a keycodes file like for the rom file and the Unix Root shared folder.
- Set a higher default for the RAM, for instance 64 or 128 instead of 16.
- Set a larger default for the window size, 800x600 instead of 640x480
- Set a higher default for the Refresh rate, 15Hz or 30Hz instead of 7.5Hz
- Set slirp networking as default


An old problem with SheepShaver (not related to the VM) is that it often takes several attempts, sometimes many attempts, for SheepShaver to create a working nvram file, especially when the rom file is not named "Mac OS ROM". This problem is now repeated with every new VM, unless one copies a nvram file that is known to work. Could the Launcher or the prefs editor create a working nvram file instead? I imagine a generally working nvram file in SheepShaverLauncher/Contents/Resources/ that is copied into a new VM. The same procedure would be convenient with the keycodes file.

Here's b3 with more fixes:

http://projectmagma.net/~myrd/SheepShav ... her_b3.zip

In this version, the main changes are the re-addition of the Dynamic refresh rate, better default preferences, a browse button for the keycodes file, and having the VM list window re-open on a click on the Dock.

You might have removed your standalone SheepShaver instance that recognizes the .sheepvm files as bundles. The launcher doesn't yet do this - so just having the launcher present isn't enough to show them as bundles (yet).


I agree that this should be improved. The problem is that the SheepShaver sub-process doesn't get its own icon in the dock and stuff - since its launched as a task from inside the Launcher. I'll have to think about a good way to handle this. Perhaps the Launcher can instead be renamed to Mac Emulator Launcher - and have it support launching the standalone emulator apps (which you would set in its preferences). Then it could also support Basilisk and mini vMac VMs too - but that's just another idea right now.


This is a known issue. You'll have to wait until I get this fixed.


I understand it's not that useful right now. The idea is to improve it to a point where it would be useful. Perhaps it would be good to implement a sort of "Wizard" process for configuring the VM for the first time.


Re-added.


It sets the ignoreillegal pref value. This makes SheepShaver not crash if an illegal (unknown) machine instruction is invoked. I added this to make a certain classic app work that was needed for my users.


Done.


Done.


I thought I read somewhere that different versions of MacOS require different nvram files. In which case, a single default one is not appropriate. Aren't the keycode files dependent on keyboard layout? For instance if you have a qwerty keyboard vs. an azerty keyboard.



I was thinking of implementing this by adding a Rename button in the list. This would make it easier on the coding side - and less prone to issues - for example if the same prefs window would be openable from SheepShaver - renaming a running SheepShaver instance could definitely cause issues.

I reproduced the problem and took a look at it a week ago. When SheepShaver tries to open the NVRAM file, if it doesn't exist or isn't initialized it creates a new one. It completely wipes it out (8K of nulls), and initializes the 20 byte "system parameter area" (PRAM) to default values. It always uses the same default values. *

Presumably the rest of the NVRAM is getting values put there by the Mac ROM and operating system code, not by SheepShaver.

When I compare a NVRAM that dies vs. one that succeeds, the PRAM part of the NVRAM is the same -- the only difference is a timestamp.

So, the problem would appear to be in an area that isn't set by SheepShaver.

I was testing by booting from a physical CD, with no hard drive file. I noticed when booting from OS 8 it had trouble capturing the CD; it would hang until I explictly dismounted it (by "eject") from the host machine.

So all I can think of is either the NVRAM issue is a symptom of some deeper problem, or it has to do with how the guest machine is remembering what the start up disk should be, or tied up with the CD emulation logic.

Whatever it is, I can't think of any way it would have to do with the ROM file name.

Wait, I've got an idea: We need to look at what the NVRAM file looks like if you start with no file, then attempt to boot with no ROM (or, it can't find the ROM). Maybe SheepShaver is only partially initializing it.


* actually it is only completely initialized if it doesn't exist at all. If it does exist, but isn't properly formatted, then it only wipes out the 256 byte XPRAM portion. I think this is carried over from Basilisk II, where the PRAM is only 256 bytes. I think the larger 8K NVRAM started with PCI Macs. This is a simple thing to change.

That is quick. :)


When SheepShaver is launched, it makes small changes to the nvram file depending on the used rom file and the installed system. However, in my experience, once you have a working nvram file, it will work always with any rom file and with any installed system. I keep a copy of such a working file. It works in VMs as well as copied to ~/.sheepshaver_nvram


No, on the contrary. Using the default keycodes file with SheepShaver (or BasiliskII) makes it possible to use all Western (and probably more) keyboard layouts. Only US-English and some related (like Dutch) layouts can use SheepShaver without the keycodes file. I usually advise to always use the keycodes file. (If the file is always in the VM folder, it could be the default setting. Again one possible user problem less.)


I have no explanation for it. Before I kept a copy of a working ~/.sheepshaver_nvram file and when I tried to start again with no pre-existing ~/.sheepshaver_nvram file, I used to have the best chance when I renamed the rom file to Mac OS ROM (regardless oldworld or newworld rom) and started from a MacOS 9.0 or 9.0.4 system.

With no ~/.sheepshaver_prefs file present yet (the very first time SheepShaver is started), SheepShaver will recognise a rom file in the same folder when it is named "Mac OS ROM". Maybe that provides a clue for an explanation?

I do not see changed default preferences.

Another default that could be changed is the Unix Root. It is now "/" , but using the root of your MacOSX disk as such is usually not a good idea. Maybe better leave it blank.