Project Description This project is a SheepShaver package that I have been working on for Windows. It contains everything needed, simply unzip the file and install a few things.
For in-depth information, see the READ_ME.TXT file in the package. This is a project that I have been tweaking around with since late 2011. It started with Mac OS 9.0.4, a newworld ROM file, and the SheepShaver program + the GUI. I have since added a lot to the package, and will post any update info here.
As of current update: - Minor bug: Must install GTK Runtime to default folder in Windows 7. Not under my control, this is a problem with GTK. - Glitch fixed: Disk Tools not wanting to boot. - GTK Runtime setup added to package - HFV Explorer added to package - Added Mac OS 8.TOAST to package, rather than a seperate download - A new update of HFV Explorer allows a fullscreen resolution of higher than 640x480.
Using Mac OS 9 in an emulator. Mac Life - 2016-12-13 - CREATE - Luis Villazon. Although you can download apps directly from the web browser running in OS 9, you'll generally find it much easier to download the files in mac OS and then move them to the emulated OS 9 environment. Sheep Shaver uses a shared folder.
It's worrisome that the only remaining way to run classic Mac OS software now needs to be compiled on classic Mac OS software.:- I'm working in a branch over here: It compiles but doesn't yet run do an issue with the kernel_data_init function involving shared memory allocation at a specific address. This no longer seems to be allowed on modern OS X because the call to shmat in shm_map_address fails. I'm not familiar enough with what the code is trying to do so I'm not sure how to fix it properly yet. Issues so far: • I had to disable/remove JIT, which no longer seems to compile with clang, due to the global register issue: • Running 'lowmem' corrupts the mach-o executable, so that is removed from the build phase.
Not sure what this is for. • 'Cannot create SHM segment for Kernel Data' - kernel_data_init/shm_map_address failure: shmget/shmat alternatives. Both projects are useful right now.
Qemu has in some ways a stronger foundation, but is missing quite a lot of features: • No FPU support • No sound • No support for Mac OS 8.x or earlier • Apparently no support for the 68k emulator? • Crashes if some standard INITs are installed • Requires a custom INIT for networking to work • No clipboard sharing • No shared filesystem • Much slower I'm also not sure how the qemu developers are even planning to add integration features like clipboard sharing or a shared filesystem, without some sort of patching mechanism. Those are pretty poorly supported even in Windows or Linux guests!
Maybe they could write custom INITs that support virtio? Do the SheepShaver downloads from. Com/doku.php/sheepshaver not work for you? I believe SheepShaver compiled with the 10.6 toolchain should still work fine on latest OS X. If there's some issues than they can be investigated and fixed. In terms of compiling with a more modern toolchain - well it would certainly be nice to have. But I don't see it being a big deal since the more important thing is that it actually runs and works - rather than how it's built.
But certainly patches are welcome to bring it closer to compiling with a modern tool chain. (As long as they don't regress the existing build environment. But it should be possible to keep both.) I think the 'cannot create kernel data' error is directly related to lowmem not working for you. I suspect if you fix the problem with lowmem, then it should just work.
But you can also explore compiling with different addressing modes. I think the JIT stuff is the main blocker for compiling with Clang (although I think you can still install and use GCC on OS X - via something like MacPorts.) There's a couple ways to fix this. First thing that's important to understand is what's broken is a build step that uses the compiler to compile a bunch of common instructions and then disassembles that to get the actual x86 assembly to use at run-time. So one easy solution is to simply check in the file produced by GCC (one for x86 and one for x86_64) and just use those directly - instead of recompiling each time. You can even check in the disassembled versions of those - which I think just become C++ files with byte arrays corresponding to the instructions. I think that's simplest solution and should be pretty easy to set up. The more complicated solution would be to add support to Clang to compile the input files the same way.
But this is likely hard. A third option would be to change how we generate the assembly - for example we could just add those instruction files as ASM source files and then they can be maintained as any other source file - with only challenge is generating them for new CPU architectures - something that's not relevant very often. But as I said, probably simplest would be to have the preprocessed generated files checked in. Then, it should just build with Clang. On Tue, Nov 1, 2016 at 2:57 PM, Chris Ballinger wrote: I spent a few days trying to fix the kernel data memory stuff and eventually gave up because I don't understand how it works. It seems like there's a lot of low level hacks regarding hardcoded memory locations that don't translate well to modern systems.
I tried to replace the hardcoded locations with dynamic addresses but it doesn't quite work as expected. I don't mind running without JIT as long as I can play some of these old school games at reasonable frame rates. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread. Are there any error messages in Console.app?
I can looking at fixing it once I have some time. On Wed, Nov 2, 2016 at 12:03 AM, Chris Ballinger wrote: It appears that this version no longer runs on macOS 10.12.1, either in 32-bit or 64-bit mode. It looks like SDL does some initialization (causing Flux to ficker) and then quits without emitting a crash report. SheepShaver_UB_20140201.zip SHA256: 545bcd5348c5ce88d18f3f0f2208d1c84361d94c8ce2c238212788 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. By the way, if you want to take a stab at the JIT stuff, here are the x86 and x86_64 files generated by the GCC-based build. So to support clang, it should be a matter of changing the build to just use those files rather than trying to generate them first.
(That doesn't solve your lowmem / memory mapping issue - but should solve the JIT one.) On Wed, Nov 2, 2016 at 12:06 AM, Alexei Svitkine wrote: Interesting. Are there any error messages in Console.app? I can looking at fixing it once I have some time. On Wed, Nov 2, 2016 at 12:03 AM, Chris Ballinger. By the way, I was able to confirm that a SS works fine on 10.11. So if it doesn't work on 10.12 - it was something that broke with 10.12 - which was released less than two months ago.
I'll see if I can debug once I get 10.12 installed on one of my machines. Also happy to provide a download for SS built from TOT with the 10.6 code project. On Wed, Nov 2, 2016 at 12:17 AM, Alexei Svitkine wrote: By the way, if you want to take a stab at the JIT stuff, here are the x86 and x86_64 files generated by the GCC-based build. So to support clang, it should be a matter of changing the build to just use those files rather than trying to generate them first. (That doesn't solve your lowmem / memory mapping issue - but should solve the JIT one.) On Wed, Nov 2, 2016 at 12:06 AM, Alexei Svitkine wrote: Interesting.
Are there any error messages in Console.app? I can looking at fixing it once I have some time. On Wed, Nov 2, 2016 at 12:03 AM, Chris Ballinger wrote: It appears that this version no longer runs on macOS 10.12.1, either in 32-bit or 64-bit mode. It looks like SDL does some initialization (causing Flux to ficker) and then quits without emitting a crash report. SheepShaver_UB_20140201.zip SHA256: 545bcd5348c5ce88d18f3f0f2208d1c84361d94c8ce2c238212788 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. The February 2014 build should work in macOS Sierra.
However, there appears to be an issue when it is newly installed on that macOS version. An odd workaround that was reported to work for others also, was described by Howard Spoelstra (Cat_7) here: Op 2 nov. 2016, om 05:03, schreef Chris Ballinger: It appears that this version no longer runs on macOS 10.12.1, either in 32-bit or 64-bit mode. It looks like SDL does some initialization (causing Flux to ficker) and then quits without emitting a crash report. SheepShaver_UB_20140201.zip SHA256: 545bcd5348c5ce88d18f3f0f2208d1c84361d94c8ce2c238212788 — You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread. Usually, the quarantine attribute gets removed (or modified?) when the user moves it in the Finder. But because SheepShaver comes in a folder, and the user moves the whole folder to /Applications, the attribute on the app is not changed. • The easiest solution would probably be for me to buy an Apple signing key, and sign my SheepShaver build. I'm not even 100% sure this disables translocation.
• Alternatively, we could try to make the app self-contained, so that the attribute gets removed on move. But then where would the ROM and keyfiles go? • Maybe more solutions I haven't thought of? How about distributing SheepShaver as separate 'files', the SheepShaver application that is to be moved to the Applications folder and one or more.sheepvm virtual machines that can be placed anywhere the user finds convenient. Each VM could already contain a keycodes file and an empty 'prefs' file. (The empty prefs file is needed because of a bug in the VM feature, it does not create a 'prefs' file in the VM when none exists).
(And I would be tempted to add rom files to the VMs.) Would that work? ( I have not yet upgraded to Sierra myself.) Op 2 nov. 2016, om 15:30, schreef Dave Vasilevsky: Usually, the quarantine attribute gets removed (or modified?) when the user moves it in the Finder. Whackhead Simpson Pranks Mp3 Downloads more. But because SheepShaver comes in a folder, and the user moves the whole folder to /Applications, the attribute on the app is not changed.
The easiest solution would probably be for me to buy an Apple signing key, and sign my SheepShaver build. I'm not even 100% sure this disables translocation. Alternatively, we could try to make the app self-contained, so that the attribute gets removed on move. But then where would the ROM and keyfiles go? Maybe more solutions I haven't thought of?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread. The user downloads the zip archive that contains the SheepShaver application and a VM (or more).
The application is to be moved to the Applications folder. A rom file needs to be added to the VM (that may be an issue for unexperienced users).
Then the user then starts by opening the VM. Or maybe working with the Launcher would be simpler. That works with VMs that can be folders, not necessarily packages. (Everything would be so much simpler if we would not be so scrupulous about not distributing rom files.) Op 2 nov. 2016, om 16:16, schreef Dave Vasilevsky: How do you propose a new user would get started?
Something like this? Download SheepShaver.app Open it, it asks you to create a new VM and save it somewhere.
It pops up the prefs dialog to ask for a ROM and such. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread. AFAIK all versions. It is mentioned as a fact in several forum threads but so far no one tried to find the cause. People just continued using SheepShaver in 32-bit mode.
2016, om 17:02, schreef Dave Vasilevsky:: Oof, it doesn't run at all? That really sucks. Do you know if it's all versions of SheepShaver, or just my build?
Do you have any more information? A thread from emaculation? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. Ok, I'll create an issue to look into that.
Back to 32-bit for now. The sheepvm stuff is a cool idea, but will take some time to fully figure out. Here's a quick, short-term solution that I can probably bang out in a day or two: • Ship just SheepShaver.app in the zip file • On macOS, look for prefs/ROM/keycodes in some more visible location. Eg: ~/Documents/SheepShaver/Settings • Keep looking in the old locations too, for backwards compatibility • On startup, if ROM is missing, open the new SheepShaver settings directory so the user can put things there.
• Pre-populate it with a keycodes file, we can ship one inside SheepShaver.app Mid-term: • Add a README.rtf to that directory, which explains what should go inside. Maybe link to emaculation's setup guide!
• Add a prefs file to that directory, with some recommended settings. • Make ErrorAlert() show a dialog on OS X, so unsophisticated users have some idea what's going on. Long-term: • Make sheepvm packages the default way users interact?
• Improve the preferences editor, so it can create sheepvms. Maybe integrate SheepShaverLauncher better? • Maybe ship ROMs? Or at least allow emaculation to ship a version containing ROMs, if they so choose.
Any objections? All of those sound great to me! Thanks for working on it. On Wed, Nov 2, 2016 at 6:28 PM, Dave Vasilevsky wrote: Ok, I'll create an issue to look into that.
Back to 32-bit for now. The sheepvm stuff is a cool idea, but will take some time to fully figure out.
Here's a quick, short-term solution that I can probably bang out in a day or two: • Ship just SheepShaver.app in the zip file • On macOS, look for prefs/ROM/keycodes in some more visible location. Eg: ~/Documents/SheepShaver/Settings • Keep looking in the old locations too, for backwards compatibility • On startup, if ROM is missing, open the new SheepShaver settings directory so the user can put things there.
• Pre-populate it with a keycodes file, we can ship one inside SheepShaver.app Mid-term: • Add a README.rtf to that directory, which explains what should go inside. Maybe link to emaculation's setup guide! • Add a prefs file to that directory, with some recommended settings.
• Make ErrorAlert() show a dialog on OS X, so unsophisticated users have some idea what's going on. Long-term: • Make sheepvm packages the default way users interact? • Improve the preferences editor, so it can create sheepvms. Maybe integrate SheepShaverLauncher better?
• Maybe ship ROMs? Or at least allow emaculation to ship a version containing ROMs, if they so choose. Any objections?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. I can imagine it working like this in the future: If SheepShaver does not find a setup in the old locations, it creates the folder ~/Documents/SheepShaver/Settings and populates it with the keycodes file and (empty or partly pre-configured) prefs file (and later the nvram file). The user needs then to add a compatible rom file to the folder. The Settings folder could also be the default location in the Open dialog for adding files in preferences. Two additional advantages: • We get rid of the hidden files in the user home folder.
• When the user wants to add more setups, the default Settings folder can be used by SheepShaverLauncher as one of the virtual machines. 2016, om 23:28, schreef Dave Vasilevsky: Ok, I'll create an issue to look into that. Back to 32-bit for now. The sheepvm stuff is a cool idea, but will take some time to fully figure out.
Here's a quick, short-term solution that I can probably bang out in a day or two: Ship just SheepShaver.app in the zip file On macOS, look for prefs/ROM/keycodes in some more visible location. Eg: ~/Documents/SheepShaver/Settings Keep looking in the old locations too, for backwards compatibility On startup, if ROM is missing, open the new SheepShaver settings directory so the user can put things there.
Pre-populate it with a keycodes file, we can ship one inside SheepShaver.app. That is right. 64-bit was added in 2010. In my latest builds (2014) I set architecture priority such that they will run in 32-bit mode by default. One must uncheck the box in Finder Info to make it run in 64-bit mode. LSArchitecturePriority i386 x86_64 ppc LSMinimumSystemVersionByArchitecture i386 10.4.0 ppc 10.4.0 x86_64 10.6.0 Op 3 nov.
2016, om 10:48, schreef Dave Vasilevsky:, I think the 2009 version has no x86_64 executable—it's just ppc and i386. That means it's 32-bit only, so of course it doesn't encounter the problem we only see with 64-bit builds. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. Thanks for the explanation. But just to clarify, I've been trying to execute SS without any configuration at all, so I'm not concerned about ROMs.
In my tests I pass an invalid argument to SheepShaver and hope it fails graciously. The 2009 version outputs a help text. All others crash because of this pagezero segment issue. I am only stating something is odd about 2009 version. I don't know how SS allocates memory, but I assume there is something about addressing memory in 32-bit that is an issue in a 64-bit binary.
If the pagezero issue is fixed, SheepShaver will probably run in any systems newer than Mavericks. Does Basilisk behave similarly? Vids Iv50 Decompressor Download. No idea - I haven't studies what the macOS sandbox requires. You're certainly welcome to investigate.
On Thu, Nov 3, 2016 at 1:08 PM, Chris Ballinger wrote: While we're discussing this, is there any chance that a modified version of SheepShaver could be compatible with the macOS sandbox? From my experience it generally works as long as you don't require R/W access to odd parts of the filesystem without user input, and the modifications that are being discussed as far as path randomization would seem to solve that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Regarding the.sheepvm idea, I actually just wrote a utility yesterday for BasiliskII that implements the same concept (I was tired of never having my configs & such after long gaps between uses, and not having the peace of mind of snapshots). It could probably be easily modified to support SheepShaver in the short term, then in the long term have BasiliskII/SheepShaver (and 's Medusa?) support the structure natively. Should that be split out into its own issue (didn't see one, but could've missed it)? So on the original subject, of wanting to be able to build SheepShaver on a modern macOS version with the latest Xcode.
Since no one apparently figured out how to set it this up yet, I decided to spend some time this afternoon to do it and have now landed an Xcode 8 project of SheepShaver that builds a 32-bit version (since 64-bit doesn't work due to the pagezero issue). It builds fine with Apple's clang compiler and seems to work. Instead of building & running dyngen, which we know doesn't work with Clang, I've instead committed the pre-generated JIT source files from the GCC build into the source tree and made the Xcode project use them. Next, I'll take a pass at fixing the various warnings that are emitted by Xcode 8.