can't add,create volumes Mac OS Catalina

[adespoton]

I'll try to create something when I've got some time... unfortunately, that's rather thin right now. I probably need to install Catalina somewhere too so I can ensure it all works.

Would people prefer a command line thing where you can type a command and 2g and it creates a formatted HFS+ 2GB disk, a "run this applescript and it will create a 2G formatted disk and add it to SheepShaver Prefs", a GUI thing where you can edit the prefs file and add/remove/create disks, or something else? That'll let me know how much time I (or someone else) needs to block off to get it working

[Ronald P. Regensburg]

A script that will create the disk image and add it to the prefs file would be fine for now, I think.

Do we have any reports that indeed everything else works in a SheepShaver that is newly installed in Catalina?

[emendelson]

Here is a script that creates a disk image; I had already done most of the work on this for my MacOS9 application:

https://www.dropbox.com/s/3ollkajhpa0ze ... k.zip?dl=1

Could you modify it as needed and send it back to me for code signing?

EDIT: Someone more expert than I am should be able to write code that adds it either as the first disk in the prefs file or as a later disk. It should be as easy as adding the line either to the top of the prefs file or the foot of it. I have code that works with my own systems, but it's very complicated, and builds the whole prefs file each time the system is run. I'm not sure it's worth the effort to adapt it for the normal prefs file. Someone may fix the SheepShaver code and all this won't be necessary at all.

[Ronald P. Regensburg]

The order of volumes in the list is not really important as long as there is only one startup volume. SheepShaver starts at the top of the list looking for a bootable volume and will use the first one it encounters.

[emendelson]

That sounds right. Anyone who wants to can modify my code something like this:

If no disk is listed in the prefs file, add this one.
If an existing disk is listed, offer the option to make the new one the boot disk or an additional disk.

But it would clearly be better to use the Preferences pane for this if someone expert can update the SheepShaver code.

[Ronald P. Regensburg]

If an existing disk is listed, offer the option to make the new one the boot disk or an additional disk.

As I explained above, it is not really relevant whether the added disk is the intended boot disk or an additional disk. If there will be more than one bootable disks in the list, you can remove the ones that are above the intended boot disk later. If the disk is added at the top, it is always right, boot disk or additional disk. The intended boot disk does not need to be at the top of the volumes list, it must be the first bootable disk in the list.

[emendelson]

Ah - I understand. But the script would still need to give the option to make the disk the first bootable disk, wouldn't it? If a bootable disk is already in the list, the script would need to give the option to place the new disk above or below the existing one. Or am I misunderstanding something?

[Ronald P. Regensburg]

If the added image is added at the top, it will always be the first bootable disk if it is a bootable disk. Would you also want to be able to add a bootable disk that is not to be the boot disk? In that case you need indeed need a choice to put the image below an existing bootable disk. I am not sure, though, when one would want to do that.

[emendelson]

If the added image is added at the top, it will always be the first bootable disk if it is a bootable disk. Would you also want to be able to add a bootable disk that is not to be the boot disk? In that case you need indeed need a choice to put the image below an existing bootable disk. I am not sure, though, when one would want to do that.

You would want to do that if you're copying files from one disk to another, surely?

[Ronald P. Regensburg]

OK. I suppose the script cannot discern between bootable and non-bootable images. You could then make the script to give the choice to put a new image file at the top of the prefs file or at the end of the "disk" entries.

[guiltydoggy]

Somehow I got this working on my Mac running Catalina. I am in no way a developer, so I don't know if this is just a fluke, or bug that was fixed in Catalina, or what. But I downloaded the source and built it on Catalina using the Xcode Beta and simply added the Bundle Identifier for the application. (Screenshot) (Code)

Here's a video of it working:
https://youtu.be/sv1KzVysaeM

Again, I have no idea why that works, but it seems to work as intended. Or does adding a Bundle Identifier screw something else up that I don't know about? Can somebody independently validate this?

[Elyus]

That's excellent, guiltydoggy! Here I was looking through source code that loaded prefs and other files, dreading all the changes for sandboxing...

It does look like a bundle ID is sufficient for Open & Save to attach. I'm not sure if this is the intended requirement for non-sandboxed processes, or if it's a gray area in the current implementation that may change. Apple doesn't provide a lot of details about this sort of thing unfortunately. Either way, it's a really good solution to the problem, and it will allow SheepShaver to continue to run like normal under Mac OS for now.

You could put up a pull request to kanjitalk. This change shouldn't break anything, but it will help future builds maintain compatibility with Catalina.

Edit: emendelson, it also makes me wonder if bundle ID was part of the problem with notarizing your builds as well? Everything seems to work under hardened runtime, so it should be possible to notarize it. I was thinking it tied back to permissions and sandboxing under Catalina, but maybe not.

[adespoton]

This makes perfect sense in retrospect, because GateKeeper and XProtect maintain their security model based on the bundle ID. So the modern APIs are likely checking for the bundle ID of the application making the request, and not finding one, are bailing.

I believe you also need a bundle ID in order to interact with system events, which could be messing up some of my older scripts, and possibly some of emendelson's too.

I'm still in the middle of an inability to test things out with my dev box, and likely won't have time to do anything until mid-August at the earliest. But it sounds like nothing's needed from me on this front anymore anyway

[emendelson]

Edit: emendelson, it also makes me wonder if bundle ID was part of the problem with notarizing your builds as well? Everything seems to work under hardened runtime, so it should be possible to notarize it. I was thinking it tied back to permissions and sandboxing under Catalina, but maybe not.

I'm fairly sure I used a bundle ID in my code - but I'll check it again later on. I've been using bundle IDs for all my builds, ever since I first got a developer account.

[mabam]

[…] But I downloaded the source and built it on Catalina using the Xcode Beta and simply added the Bundle Identifier for the application. […]

I wonder whether the fact that you have built SheepShaver locally also plays a role in it working fine. I don't have Catalina, but maybe someone else who does could test your build?

[emendelson]

Elyus, Could you post your build? I'll test it on Catalina here, but I'm afraid that if I build it myself, it will run on my own system simply because I built it.

[Elyus]

Here's a build with a bundle ID. I actually did have a little trouble getting it to work without signing, but it seems like it is now. We may be encountering some buggy behavior simply because Catalina is still early beta. Hopefully others can confirm if it works for them.

[emendelson]

That worked! I've taken the liberty of codesigning your code (a version number was required, so I added that), and posted it here:

https://github.com/emendelson/macemu/re ... talina.zip

[kanjitalk755]

I merged guiltydoggy's PR.
And I also set Bundle Identifier for BasiliskII just in case.

https://github.com/kanjitalk755/macemu

[Ronald P. Regensburg]

Wonderful!

I suppose it will also work in Catalina when built in Xcode 10.2.1 in Mojave with the bundle identifier and code signed.

Does this build still work in Mac OS X 10.7 (and all later OSX/macOS), can someone check that?

[emendelson]

I see part of the problem in notarizing SheepShaver, but I have no idea of the solution.

When I build SheepShaver and use the resulting file in the "derived data" folder it works perfectly, and the unix executable is 1.9MB.

But if I archive the same code from the Xcode menu, I end up with a 1.2MB executable, and a separate 1.1MB libkpx_cpu.a file in another folder. It seems that these aren't combined when you archive the app. I do not understand any of this. Is there a way to fix this? That might make it possible to notarize SheepShaver.

[kanjitalk755]

The difference of binary size is whether it is stripped or not.
When I stripped the binary of DerivedData as a trial, it crashed as well.
As a result of investigation, it turned out that catch_exception_raise() used in SheepShaver needs symbols.

http://vikashdubey.blogspot.com/2010/06 ... -mach.html

In other words, the archived binary doesn't work.

[emendelson]

Thank you for explaining that! It sounds as if it would take a lot of work to rewrite the code so that it could be stripped, and we can live with what we have already.