This patch fixes one lingering problem with the 64-bit clipboard code; the way it was designed, the Mac clipboard was being cleared every time a single item was being requested by GetScrap, causing clipboards with multiple items to be unceremoniously whittled down to one. On the other hand, a similar issue was causing some items to get duplicated on the host pasteboard. This patch fixes the issue by making conversion between the host pasteboard and the Mac clipboard a singular operation; when the pasteboard data changes on the host side, it is all converted and sent to the Mac pasteboard at once, and similarly, all Mac clipboard data is sent to the host pasteboard in one operation. Also, data from the host side is copied to the Mac clipboard only if it has changed since the last check, which should improve performance as conversions will not be done over and over every time the Mac side checks whether the scrap has changed.
In addition, I've added a rudimentary PICT converter. It's rudimentary at the moment, only going in one direction, converting to PICT and not from PICT, and currently it always rasterizes the source image and creates a PICT containing bitmap data. However, it's a start, and it should solve Ronald's issue with copying images from OS X to Mac OS. In the future, more could possibly be added. I've put the new PICT code in the main source directory instead of in the MacOSX subdirectory, so that it can be used by other platforms if needed.
I would like to leave the license on the new PICT code as "Public Domain" if that is okay.
Thanks,
Charles
./configure --enable-macosx-gui
The goal is to get rid of the build files under src/MacOSX by
allowing the ones under src/Unix to produce the same outputs.
Note: This currently has video problems, but this is consistent
with what you get when building out of src/MacOSX.
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.
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
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.
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.
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.
STANDALONE_GUI. This is the second step towards a more interesting GUI alike
to VMware. Communication from/to the GUI is held by some lightweight RPC.
Note: The step should be enough to provide a tiny GTK GUI for MacOS X.
up to 1 GB of Mac RAM in both REAL_ADDRESSING and DIRECT_ADDRESSING modes.
NetBSD 2.0 can use the Linux linker script. However, I could not verify 1G
support since my installation does not permit this.
arches. This probably already worked in the past but I have just verified
that Basilisk II works with up to 1 GB of Mac RAM in DIRECT_ADDRESSING or
REAL_ADDRESSING mode.
BTW, a quick Speedometer 4 CPU performance test showed a +15% speed increase
in real addressing mode vs. direct addressing. x86 arches don't benefit much
from that mode since they support complex address modes already (beyond plain
load/store).
TODO: check on MacOS X for Intel so that to reduce the test to darwin*:*)
problems on big endian systems. IOW, Basilisk II can hang there. I also
noticed that on Linux/ppc so that's probably not MacOS X specific, assuming
the same problem. ==> A packet arrives but Basilisk II can't seem to trigger
an interrupt (need to try sheep_net/tun in linux to make sure)
