Yeah when I did manage to get parallels to run plan 9 (v3) it looked like
garbage and I couldn't install it due to graphics mess ups.
I'm now hearing really great things about VMWare Fusion for the Mac... and
I'm considering taking my business there.



On 8/29/07, Axel Belinfante <Axel.Belinfante@cs.utwente.nl> wrote:
>
> late follow up. I'm running v 3 build 4560, with converted v 2 image.
> seems to work fine, as far as I can judge --
> apart from things I notice while typing this, see below (*)
>
> did not (yet) try direct install of plan 9 in v 3.
>
> resolution 1680x1050 is standard supported,
> aux/vga -m vesa -p lists no depth 32 at all, only 8, 16 and 24.
> this is on a quite recent 20" imac.
>
> audio works per ac97 instructions in wiki
> page 'Installing in parallels desktop on Mac OS X'
>
>
> (*) minor problems:
> I'm typing this from a vncv session to unix within the parallels
> plan 9 on the mac. it works ok, but the mouse cursor does funny things.
>
> screen shot http://www.cs.utwente.nl/~belinfan/parpic01.png
>
> in the vnc-ed unix session I run rio as wm.
> when I move the fat arrow in the vnc window,
> while moving it a transparent square box
> (or rather: hole, since it is tranparent)
> of, dunno, 10x10 pixels appears in the mouse cursor,
> moreover, pieces of the mouse cursor get left behind.
> combined with the transparancy thing this means I can draw by
> moving mouse moving south-east and can erase by moving mouse north-west.
>
> also, probably unrelated to vncv, when I use lens outside the vncv window
> I also see the image of the mouse cursor in the lens window. don't
> recall seeing that in native plan 9.
>
>
> turns out I have an 'international english' keyboard
> where `/~ key is next to left shift key,
> and a plus-minus/paragraph(?) key is at the usual `/~ position.
> parallels seems not to know about this keyboard:
> when I press the plus-minus/paragraph(?) key I get the `/~.
>
>
> about the 'Installing in parallels desktop on Mac OS X' page:
> I was surprised to see that
> applying the suggested 'hget -o file URL' idiom to existing
> /sys/src/9/port/devaudio.c overwrites the first part of it
> by retreived file, but leaves the last part in place.
> turns out 1) ac97 port/devaudio.c is shorter than the original
> 2) hget -o opens existing file without truncate, on purpose.
> I guess in case of an existing (different) file, first get
> original out of the way before using: hget -o file URL
>
>
> Axel.
>