Some improvements for SheepShaver

[Myrd]

SheepShaver is supposed to be able to run with the memory offset, i.e. the allocated memory block isn't at address zero. SheepShaver calls this "direct" memory mode, as opposed to "real".

This isn't working right now for several reasons, including:

• Unlike Basilisk II, the offset is determined or set a compile time. (Basilisk's method is better.)
• SheepShaver's CONFIGURE has no logic to use the pagezero test result to determine if real mode can be used vs. direct. So unless you explicitly set the memory mode to direct, you get real.
• As you noted, real mode won't work without a working method of allowing addresses at 0.
• There are several ways that we could get address 0 to work, but that's a lost cause, because this is expressly verboten in 64-bit programs starting with Yosemite. This means that the future is direct mode.
• Compiling with direct mode falls on 64-bit because ld defaults to creating a 4gb pagezero area when linking 64-bit executables. This means that the program configure tries to use to find a natmem offset fails, because it is only testing 32-bit addresses.
• Trying to pass an explicit natmem offset fails because there is a bug in the SED expression it uses to validate the parms. It is using grep syntax that is only valid on Sun grep, not GNU grep. The fix for that is to use \{0,1\} instead of \? in the expression.
• Even with that fix, it still gets a kernel data error at run time. I suspect that it is trying to allocate the kernel data area at a 32-bit address.

That's as far as I got. I need to get Xcode working for debugging it to find the runtime bug.

This can all be fixed. It isn't as hard as the problems with the JIT emulator.

Thanks for looking into this. It sounds like some of the issues you mention should already be fixable - e.g. the grep param. I encourage you to submit those fixes as soon as they're ready as pull requests to the upstream repository. If a fix makes sense on its own, no need to wait for other things to send it up!