Added code to parse the Classic Mac OS 'styl' resources, allowing formatted text to be copied and pasted out of SheepShaver, not just plain text. In order to do this, I made some changes to the emul_op mechanism, patching ZeroScrap() in addition to the scrap methods that were already being patched. The reason for this is that since we need to read data from multiple items that are on the clipboard at once, we cannot simply assume a zero at the beginning of each PutScrap() operation.
This patch uses RTF to store styled text on the host side; unfortunately, since the APIs to convert to and from RTF data are in Cocoa but not in CoreFoundation, I had to write the new portions in Objective-C rather than C, and changed the extension from .cpp to .mm accordingly. In the future, if we are confident that this file will only be used on Mac OS X 10.6 and up, we can rewrite the Pasteboard Manager code to use NSPasteboardReading/Writing instead. This would allow us to read and write NSAttributedString objects directly to and from the pasteboard, which would make sure we were always using the OS's preferred rich text format internally instead of hard-coding it specifically to RTF as in the current implementation.
I believe that this patch should also fix the problem Ronald reported with copying accented characters.
Since I am new to 68k assembly and the emul_op mechanism, I would appreciate if someone could double-check all my changes to make sure that I have done everything correctly.
Thanks,
Charles
Note: Checks for __LP64__ explicitly because build/host/target
all get reported as i686-apple-darwin10.8.0 (not x86_64).
Also fixes a compile warning in clip_macosx64.cpp.
thread is currently only used to poll for CDROM devices and is not useful
when "nocdrom" is set. This change also fixes the problem of the emulator
preventing the CD to be ejected at the host level despite "nocdrom" being
set in prefs.
Thanks to Robert Munafo <mrob27@gmail.com> for investigating this problem!
| This patch affects the Makefile.in used to compile Basilisk II in
| order to allow out-of-tree compilation. This is useful for building
| multiple flavours of the Debian package.
|Author: Giulio Paci <giuliopaci@gmail.com>
| This patch fix a compiler warning about the direct printing of strings
| using formatted printing functions without the use of a format string.
|Author: Giulio Paci <giuliopaci@gmail.com>
|Forwarded: no
|Last-Update: 2012-03-04
version of slirp (where this code comes from), with the following checkin:
commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec
Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
Date: Mon Jan 26 19:37:41 2009 +0000
Remove the advertising clause from the slirp license
According to the FSF, the 4-clause BSD license, which slirp is covered under,
is not compatible with the GPL or LGPL[1].
[1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses
There are three declared copyright holders in slirp that use the 4-clause
BSD license, the Regents of UC Berkley, Danny Gasparovski, and Kelly Price.
Below are the appropriate permissions to remove the advertise clause from slirp
from each party.
Special thanks go to Richard Fontana from Red Hat for contacting all of the
necessary authors to resolve this issue!
Regents of UC Berkley:
From ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
July 22, 1999
To All Licensees, Distributors of Any Version of BSD:
As you know, certain of the Berkeley Software Distribution ("BSD") source
code files require that further distributions of products containing all or
portions of the software, acknowledge within their advertising materials
that such products contain software developed by UC Berkeley and its
contributors.
Specifically, the provision reads:
" * 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors."
Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials. Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.
William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley
Danny Gasparovski:
Subject: RE: Slirp license
Date: Thu, 8 Jan 2009 10:51:00 +1100
From: "Gasparovski, Daniel" <Daniel.Gasparovski@ato.gov.au>
To: "Richard Fontana" <rfontana@redhat.com>
Hi Richard,
I have no objection to having Slirp code in QEMU be licensed under the
3-clause BSD license.
Thanks for taking the effort to consult me about this.
Dan ...
Kelly Price:
Date: Thu, 8 Jan 2009 19:38:56 -0500
From: "Kelly Price" <strredwolf@gmail.com>
To: "Richard Fontana" <rfontana@redhat.com>
Subject: Re: Slirp license
Thanks for contacting me, Richard. I'm glad you were able to find
Dan, as I've been "keeping the light on" for Slirp. I have no use for
it now, and I have little time for it (now holding onto Keenspot's
Comic Genesis and having a regular US state government position). If
Dan would like to return to the project, I'd love to give it back to
him.
As for copyright, I don't own all of it. Dan does, so I will defer to
him. Any of my patches I will gladly license to the 3-part BSD
license. My interest in re-licensing was because we didn't have ready
info to contact Dan. If Dan would like to port Slirp back out of
QEMU, a lot of us 64-bit users would be grateful.
Feel free to share this email address with Dan. I will be glad to
effect a transfer of the project to him and Mr. Bellard of the QEMU
project.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6451 c046a42c-6fe2-441c-8c8c-71466251a162
version of slirp (where this code comes from), with the following checkin:
commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec
Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
Date: Mon Jan 26 19:37:41 2009 +0000
Remove the advertising clause from the slirp license
According to the FSF, the 4-clause BSD license, which slirp is covered under,
is not compatible with the GPL or LGPL[1].
[1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses
There are three declared copyright holders in slirp that use the 4-clause
BSD license, the Regents of UC Berkley, Danny Gasparovski, and Kelly Price.
Below are the appropriate permissions to remove the advertise clause from slirp
from each party.
Special thanks go to Richard Fontana from Red Hat for contacting all of the
necessary authors to resolve this issue!
Regents of UC Berkley:
From ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
July 22, 1999
To All Licensees, Distributors of Any Version of BSD:
As you know, certain of the Berkeley Software Distribution ("BSD") source
code files require that further distributions of products containing all or
portions of the software, acknowledge within their advertising materials
that such products contain software developed by UC Berkeley and its
contributors.
Specifically, the provision reads:
" * 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors."
Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials. Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.
William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley
Danny Gasparovski:
Subject: RE: Slirp license
Date: Thu, 8 Jan 2009 10:51:00 +1100
From: "Gasparovski, Daniel" <Daniel.Gasparovski@ato.gov.au>
To: "Richard Fontana" <rfontana@redhat.com>
Hi Richard,
I have no objection to having Slirp code in QEMU be licensed under the
3-clause BSD license.
Thanks for taking the effort to consult me about this.
Dan ...
Kelly Price:
Date: Thu, 8 Jan 2009 19:38:56 -0500
From: "Kelly Price" <strredwolf@gmail.com>
To: "Richard Fontana" <rfontana@redhat.com>
Subject: Re: Slirp license
Thanks for contacting me, Richard. I'm glad you were able to find
Dan, as I've been "keeping the light on" for Slirp. I have no use for
it now, and I have little time for it (now holding onto Keenspot's
Comic Genesis and having a regular US state government position). If
Dan would like to return to the project, I'd love to give it back to
him.
As for copyright, I don't own all of it. Dan does, so I will defer to
him. Any of my patches I will gladly license to the 3-part BSD
license. My interest in re-licensing was because we didn't have ready
info to contact Dan. If Dan would like to port Slirp back out of
QEMU, a lot of us 64-bit users would be grateful.
Feel free to share this email address with Dan. I will be glad to
effect a transfer of the project to him and Mr. Bellard of the QEMU
project.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6451 c046a42c-6fe2-441c-8c8c-71466251a162
For my work on digital preservation it's important to have "golden"
disk images that are not corrupted by user action. In order to enable
this, I've added support for VHD virtual disks (especially snapshots !)
to the Linux and OS X versions of BasiliskII and SheepShaver.
The support uses the open source libvhd library which is part of xen,
available here:
http://www.xen.org/products/xen_source.html
The piece that's needed is libvhd which is in tools/blktap2 and it can
be separately compiled.
The vhd-util enables creation of vhd disks and snapshots.
Compiling libvhd for OS X is non-trivial and required 1) a new config
and 2) a number of small changes to the include files and c files.
Compiling for linux is a snap.
I use this as follows.
1) create my "golden image" gold.dsk in the usual way
2) create a snapshot: vhd-util snapshot -n gold.vhd -p gold.dsk -m
3) use the snapshot in my prefs file
In my work the golden images are in an AFS system which means the golden
images can reside at "universal" addresses. The snapshots are initially
tiny, so a complete virtual machine configuration -- prefs + snapshot is
quick to download for the end user.
The snapshots are copy on write which has the pleasant side effect of
letting the end user keep any changes.
This attached patch allows you to compile the Carbon Pasteboard services on
Snow Leopard if you are building for 32-bit, but not if you are building for 64.
To maintain backwards compatibility, the Carbon UI APIs aren't going to be
stripped from the 32-bit any time soon. However, there is no worry about
that in 64, so they didn't include it.
Add bin/cue support. The following should work:
1) Basilisk and SheepShaver with sdl-audio and bincue on linux and os x
2) SheepShaver with bincue and core audio on os x
GCC has become too smart - we need to slice the binary created to be sure the
address of the trap is within the test addresses. This is why each trap occurs
between two case labels and a new section of assembly code is set in between.
giving it to the host OS, and don't clear clipboard every time as some
apps will put many varieties of the same data in succession...
however, a better fix would be to patch the ROM ZeroScrap function in a
similar way as we patch GetScrap/PutScrap
Attached is a set of patches to port the precise timer that is currently used in the Linux and BeOS builds of SheepShaver to Mac OS X (and any other Mach-based operating systems).
Currently, the Linux build uses the clock_gettime() function to get nanosecond-precision time, and falls back on gettimeofday() if it is not present. Unfortunately, Mac OS X does not currently support clock_gettime(), and gettimeofday() has only microsecond granularity. The Mach kernel, however, has a clock_get_time() function that does very nearly the same thing as clock_gettime(). The patches to BasiliskII cause the timing functions such as timer_current_time() to use clock_get_time() instead of gettimeofday() on Mach-based systems that do not support clock_gettime().
The changes to SheepShaver involve the precise timer. The existing code for Linux uses pthreads and real-time signals to handle the timing. Mac OS X unfortunately does not seem to support real-time signals, so Mach calls are again used to suspend and resume the timer thread in order to attempt to duplicate the Linux and BeOS versions of the timer. The code is somewhat ugly right now, as I decided to leave alone the pre-existing style of the source file, which unfortunately involves #ifdefs scattered throughout the file and some duplication of code. A future patch may want to clean this up to separate out the OS-specific code and put it all together at the top of the file. However, for the time being, this seems to work.
This has not been extensively tested, because I have not been able to get my hands on a good test-case app for the classic Mac OS that would run inside the emulator and try out the timer. However, performance does seem to be better than with the pre-existing code, and nothing seems to have blown up as far as I can tell. I did find a game via a Google search - Cap'n Magneto - that is known to have problems with Basilisk/SheepShaver's legacy 60 Hz timer, and the opening fade-to-color for this game appears to run much more smoothly with the precise timer code in place.
SheepShaver includes the C errno string in many error messages. One case is when it calls the memory allocation routines in the Basilisk II vm_alloc.cpp program.
This works when the memory allocation routine uses functions that set errno (such as mmap or malloc). For example, running SheepShaver on a Linux hosts produces meaningful error messages.
The problem is that when run on an OS X host, the memory allocation uses Mach routines such as vm_allocate, which do not set errno.
So when SheepShaver reported the error, it used a stale value of errno, which happened to be 17. The result was an extremely misleading error message: "Cannot map RAM: File already exists".
The fix is to change vm_alloc so that it translates Mac return codes into POSIX errno values.
It also initializes errno to 0 at the start of the memory allocation routine, so that no matter what path it takes, it won't return a stale value.
Fixes copy/paste errors in the Windows version of SheepShaver, wherein pasted
text would have a trailing null character or extra garbage after the end.
Fix for bug: SheepShaver compiled with VOSF off will not display
fullscreen on OS X. The VM boots, but the display is entirely black.
This was expected, I suppose, since video_refresh_dga() didn't
actually attempt to draw anything!
The patch fixes this. Notes:
* video_refresh_window() now takes an argument of type driver_base,
since nothing specific to driver_window was used
* video_refresh_dga() can now call video_refresh_window_static()
* update_display_static_bbox() now respects the destination having a
different bytes-per-row from the source
* fullscreen modes are now created for all depths
Here is a patch to allow compiling of SS and B2 with an SDL Framework. You can
get this by downloading from:
http://www.libsdl.org/release/SDL-1.2.13.dmg
Here is how I tested on an intel 32-bit mac with Mac OS X 10.5.6:
SS ./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl-framework --enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks --enable-sdl-video --disable-sdl-audio --enable-addressing=real
--without-esd --without-gtk --without-mon --without-x
SS /autogen.sh --disable-standalone-gui --enable-vosf --disable-sdl-framework --disable-sdl-video --disable-sdl-audio --enable-addressing=real --without-esd --without-gtk --without-mon --with-x
B2 ./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl-framework --enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks --enable-sdl-video --enable-sdl-audio --enable-addressing=real --without-esd --without-gtk --without-mon --without-x --enable-jit-compiler
B2 ./autogen.sh --disable-standalone-gui --enable-vosf --disable-sdl-framework --disable-sdl-video --disable-sdl-audio --enable-addressing=real --with-esd --without-gtk --without-mon --with-x --enable-jit-compiler
(esound does not really work on mac, it needs some better coreaudio patches.)
configure.ac for SS has two little additional fixes so that the Cocoa prefs gui
does not get built if you are building for X11 and so that you can use esd, sdl,
or coreaudio for sound.
I was testing some other SS patches and I noticed that when I ran an X11
build of SS there were not all the video modes I expected in the the
control strip. Mac OS X 10.5 changed the form of the DISPLAY environment
variable. The reason for this is that the DISPLAY variable looks like
this in Leopard:
/tmp/launch-XXXXXX/:0
The Xs are like in mktemp.
Here is a patch that has a shell script cpr.sh to recursively copy directories but
discarding things that cause problems at least on 10.4 when making the .app bundles.
This patch helps to keep the audio from breaking-up on slow machines when using
SDL audio. On those slow machines you do still get the break-up every so often
but the sound tends not to break-up nearly as often. It is much better on the
ears. Notably often the system beeps do not have a pause in them.
Slow machine is <= 1 GHz G4.
This first patch gets B2 and SS to build under Leopard and Tiger.
I tested this on a 32-bit intel 10.5.6 mac like so:
B2
./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl-video --enable-sdl-audio --enable-addressing=real --without-esd --without-gtk --without-mon --without-x
SS
./autogen.sh --disable-standalone-gui --enable-vosf -enable-sdl-video --disable-sdl-audio --enable-addressing=real --without-esd --without-gtk --without-mon --without-x --enable-jit
There is also a little tweak so that you can use sdl audio in SheepShaver when building for Mac OS X.
Previously, SheepShaver would usually hang if it was unable to access the ROM
file on startup, due to a race between media_poll_func() and DarwinSysExit().
This change eliminates the race by ensuring that media_poll_func() always ends
up waiting in CFRunLoopRun(), which allows us to terminate the polling thread
in a consistent way.
This fixes the mapping of SDL mouse-button numbers to MacOS/ADB mouse-button numbers,
to correct the reversal of the middle and right buttons. Most useful in conjunction
with a multi-button mouse enabler such as TheMouse2B:
http://hyperarchive.lcs.mit.edu/HyperArchive/Archive/cfg/themouse-2b-11.hqx
... which can turn a right-click into a control-click.
The CDROM status call "WhoIsThere" (csCode 97) is now implemented. Apart from
eliminating "WARNING: Unknown CDROMStatus(97)" complaints from the console log,
this does not appear to have had any effects whatsoever.
A typo in the implementation of the CDROM status call "GetCDFeatures" has been
corrected per Technical Note DV22:
http://developer.apple.com/technotes/dv/dv_22.html
Software cursor mode is now supported, although currently the existing hardware
cursor mode is used whenever possible. (Software mode will be used if you are
running with a recent version of SDL's Quartz video driver, since a bug in SDL
1.2.11 and later prevents the hardware cursor from working properly with that
driver.)
In hardware cursor mode, the hot-spot is now determined heuristically. Formerly
it could not be determined and was always (1,1), an annoyance for many cursors
other than the arrow.
In hardware cursor mode, the cursor will now be hidden when requested by the
emulated OS (such as when you are typing in a text field).
In hardware cursor mode, some cursor image formats that the code does not handle
correctly will now be rejected, causing the emulated OS to revert temporarily to
software cursor mode. Formerly you would just end up with random garbage for a
cursor. This typically happened for grayscale or color cursors; rejecting images
with rowBytes != 2 eliminates the worst cases.
SheepShaver window a number of times (somewhere around 30 or 40 times will do
it), SheepShaver appears to lock up. This occurs because SDL posts application
activate/deactivate events to its event queue when the mouse moves in/out of the
SheepShaver window, but these events are never consumed, and as a result, the
event queue fills up. Thereafter, no new events can be posted, and user inputs
are ignored. The fix is to consume SDL_ACTIVEEVENT in handle_events().
file I/O to the external filesystem. The application-specified ioPosMode parameter must
be masked off appropriately in extfs.cpp:fs_set_fpos(), as is done elsewhere in the file.
- Rename X86_SSE_CC_NE to X86_SSE_CC_NEQ (match Intel reference manual)
- Rename MOVDLX to MOVDXD (%Xmm register as Destination)
- Rename MOVDQX to MOVQXD (%Xmm register as Destination)
- Rename MOVDXL to MOVDXS (%Xmm register as Source)
- Rename MOVDXQ to MOVQXS (%Xmm register as Source)
explicitly generated from mig. The advantage of that is to provide a "fast"
path for x86_64 on Leopard too (fault address in code[1]).
By "fast", this means +33% faster wrt. explicitly thread_get_state() but
still pretty slow (40 usec/fault). This is on par with the i386 code path though.
Leopard kernel faster? This is pure marketing hype. For 32-bit applications,
Mach exception recovery is 60% slower. For 64-bit applications, this is up
to 40% faster though. In any case, MacOS X remains pretty slow wrt. Linux...
environment variable: SIGSEGV_MACH_FAULT. It can be set to "direct" to
assume the fault address comes from code[1] argument, or "slow" to use
the slow path through thread_get_status(EXCEPTION_STATE)->faultvaddr.
in the bundle. This is faster and more accurate as this avoids emulation.
Also clean-up code so that to prepare the use of lib uaccess on hpux/ia64.
XXX: this will need explicit use of uint64_t to define registers because
HP/UX is ILP32 capable and all registers are 64-bit capable so "unsigned long"
won't fit.
complex than expected but it was fun to play with. Who designed this ISA?
I'd love to see how the decoder is implemented in HW, by all means it is
not "simplified" unless I missed some pattern...
XNU 792.21.3 (10.4.10) and XNU 1228 (10.5.0), exception handler code[1] always
contains the fault address nowadays. So make it the default fast path but keep
provisions to check that at run-time first.
This yields a nearly 4x improvement in SIGSEGV recovery but MacOS X is still
suboptimal wrt. Linux, so VOSF is still not possible with frameskip == 0.
XXX: the ppc kernel had bugs that caused DAR (put into code[1]) to be incorrectly
decoded. This would need a broader test audience or more careful audit of the
sources changes.
- set slirp client hostname
- fix slirp redirection on systems without a useful host IP address
- separate alias_addr (10.0.2.2) from our_addr (Ed Swierk)
- fix 32+ KB packets handling (Ed Swierk)
- fix UDP broadcast translation error
- solaris port (Ben Taylor)
on Tiger+ to store FInfo and FXInfo. Otherwise, plain old .finfo/ helpers are
used. "Safe" flags and fields are always synchronized to/from MacOS X.
BTW, CFString leak was fixed at the same time.
I am adding functionality to support this. For the moment, I've only
added the platform-specific conversion for MacOSX (ie: UTF8 -> MacRoman),
but others can be added later.
Rather, use an address override prefix (0x67) though Intel Core optimization
reference guide says to avoid LCP prefixes. In practise, impact on performance
is measurably marginal on e.g. Speedometer tests.
Not quite the way I wanted to do it but it will do for now.
(on a real Mac, the real audio hardware should be able to pull/grab the data
from our buffers - an extra thread with its own set of buffers is wasteful!)
Not quite the way I wanted to do it but it will do for now.
(on a real Mac, the real audio hardware should be able to pull/grab the data
from our buffers - an extra thread with its own set of buffers is wasteful!)
- Don't export transfer types definitions (formerly used by older API)
- Handle ADD instructions in ix86_skip_instruction() (generated by icc 9.1)
- Use "%p" format for EIP/RIP addresses
if you have changed the depth since boot (seems to be something strange
with the parameters that I still haven't worked out). If this happens,
we now put a suggested workaround in the warning message.
This reduces the number of Screen_fault_handler() calls by 80%. i.e. VOSF
is now viable on this turtle MacOS X. Besides, since there is no buffer
comparison, idle sleep can really be effective. SheepShaver in idle mode
on my PBG4 now goes below 8% of CPU resources instead of 70-80% with
bounding boxes based video refreshes.
Caveat: if your program doesn't use standard MacOS routines that call NQD,
then you can expect slower (visual) performance. However, I do think the
new default behavior (VOSF+NQD) is the most common.
This does not improve graphics performance but helps CPU because it reduces
the number of bytes transfered to actual screen. I saw an improvement by up
to 26% in frameskip 4 800x600x16 but also a hit by 3% with frameskip 0.
The next step is to use NQD bounding boxes to help detecting dirty areas.
So far, this is the best I can do without VOSF working (MacOS X performance
bugs -- pitifully slow Mach syscalls)
- Properly handle migration from "screenmodes" and "windowmodes" to "screen"
- Fix has_mode() logic to really test for actual mode availability. i.e.
no longer start in large screen mode if user specified a max size.
- Call user handler for KERN_INVALID_ADDRESS too (SIGBUS)
- Check for VALID_THREAD_STATE_FLAVOR in forward_exception()
- Return KERN_FAILURE if forward_exception() got an unknown behavior code
Other bugs fixed:
- CD-ROM media are polled and now can be changed without rebooting
- Buffer overflow, memory leak and extra wait in CD-ROM ejection code
