VirtualAcorn Tech Support

VirtualAcorn Tech Support

Using a Mac touchpad

If you are using VirtualRPC-AdjustSA for Mac on a laptop then you may not have a mouse connected. It is still possible to use VirtualRPC in this way provided you have a recent Mac. Later Macs have the facility to provide both left and right mouse clicks from the touchpad. A single tap is interpreted as a left click. A double tap is interpreted as a right click. So you can use both the Select and Adjust buttons. However RISC OS is very reliant on the centre mouse button to open a menu. From the VirtualRPC preferences window you can swap round the Menu and Adjust buttons so that instead of a double tap being interpreted as Adjust it is interpreted as Menu.

Another option to consider is a third party program called SideTrack. This is shareware and you can download an unregistered copy from www.ragingmenace.com/software/sidetrack/index.html. This will allow you to use all three mouse buttons using only the touchpad.

Menus on the Mac

Keeping on the subject of VirtualRPC for the Mac there is another oddity that has puzzled a few users. If VirtualRPC is running in full screen mode then pressing down on the centre of the mouse (on the scroll ball) will open a RISC OS menu as you would expect. However if you are running in a Window then the default behaviour on Mac OS X is that a press on the scroll ball will open the Dashboard. Obviously this means that you can't open a RISC OS menu whilst running in a window. There are two solutions to this problem:

Re-configure DashBoard so that it starts with a different mouse click (e.g. a side button on a mighty mouse).
Simply hold down SHIFT whilst pressing the centre of the mouse, this will bypass DashBoard and open a RISC OS menu correctly.

DSStore files

The Mac has a quite different filing system to other machines, this can cause some odd effects when using VirtualRPC. The mac uses special "hidden" files which contain information about what's in a folder, these files are called "DSStore" and they can turn up inside a VirtualRPC harddisc unexpectedly. As all VirtualAcorn users know the VirtualRPC "harddisc" is just a folder on the hard drive of the host machine. RISC OS "sees" this is a disc drive, the host machine sees it just as normal folder with files in.

This means the host machine, in this case running Mac OS X, can open the RISC OS harddisc and copy files in and out. This is where the strange "DSStore" files come from. By default the VirtualRPC harddisc folder has none of these files in its structure. If the user copies files in, or out, of the harddisc4 folder from MacOS X then the mac will copy a DSStore file into the particular sub directory. As an example. If you open the root of the VirtualRPC for the Mac harddisc4 folder and double click on a PDF file (as generated by !Printers) it will load into Adobe Reader. It can now be examined, taken apart or printed. If you now load VirtualRPC and open the harddisc4 from RISC OS you will probably find that a text file called "DSStore" has been created, the Mac won't show this files as is is "hidden", but the VirtualRPC will. Some users have worried about these files, but they are nearly always harmless. You can delete from from RISC OS, or leave it in place. It's up to you.

Although, as I have said, these files are nearly always harmless they can cause niggles if they end up inside the !Boot sequence. If a DSStore file ends up inside Boot:Choices.Tasks then it will be run. So when the VirtualRPC starts up the DSStore file will be opened inside an Edit window. There are no real nasty side effects, but a couple of users have been surprised to see this happening. So it if happens to you, just do a search from inside RISC OS for any files in the main HardDisc4 called "DSStore" and delete them.

VirtualRPC on Leopard

We have now done quite a bit of testing on Leopard and are happy that VirtualRPC runs correctly provided the user is running with an administrator account. Leopard, somewhat like Windows Vista, "protects" certain areas of the harddisc and some activities. This type of hand holding gets right up my nose, but I accept that it has a value for some users. However currently if you are running Leopard with a normal account then VirtualRPC might complain. This is because on the current builds the "HardDisc4" folder is place in applications. This gets "protected" as unless you have an administrator account you can't write data into Applications (which is like Program Files on Windows). The solution is to move the "HardDisc4" folder to one of the user libraries and then to update the VirtualRPC configuration files to point to the new location. The current intention is to sort out the installer for Beta4/RC1 so that it installs all the components where Leopard "prefers" them. This will then "future proof" the application for later versions of Mac OS X as and when they arrive.

In the mean time you can alter the access rights to the VirtualRPC, so that it has read and write status for all user accounts.

I'll copy my boot sequence...

Moving on from VirtualRPC for the Mac lets take look at an issue that (so far) has only affected the Windows versions of VirtualRPC, overwriting the VirtualRPC !Boot sequence. I am at a loss to understand why a few users think that it's fine to drag boot sequence between machines. The recent example we had was one user who complained that their VirtualRPC "wasn't working properly". This doesn't really help me very much so I asked for some more details. The response was pure garbage and read like the English translation of the original Chinese manual for a cheap toaster. I again asked for more details. This time I got a little further as the user concerned complained that "the internet doesn't work but I've set it up".

This always rings alarm bells for me. This is because there is nothing to set up. The internet access on VirtualRPC is automatic and works out of the box. After intense probing (regretfully without a cattle prod) the user said that they had copied all their files "from the Acorn". OK, so had they also copied the boot sequence off the "Acorn", and whilst we are on the subject what the hell was their "Acorn" anyway? A RiscPC? If so with which version of RISC OS? The user didn't know, but did complain about all the "stupid error messages" that the "virtual risc os" was generating on booting. By this point I was convinced that they had copied a boot sequence from another machine over the top of the one from the VirtualRPC.

Even if your VirtualRPC and "Acorn" are running the same version of RISC OS this is still a very, very bad idea. This is because the VirtualRPC boot sequence has been carefully set up by ourselves so that it has up to date components. It also contains a number of customised or special components designed purely for VirtualAcorn. If these are not run as part of the boot sequence then some features may not work.

In the case of this user most of their error messages were caused by moving a boot sequence from an ADFS machine to a HostFS VirtualAcorn. As you can image every path in the boot sequence that started with ADFS generated an error. The boot sequence copied from the "Acorn" had also been in use for many years and as a result was a complete shambles. A quick examination with the user over the phone led me to wonder if the Boot sequence had ever worked on the real machine. "Oh yes...apart from a couple of error messages...".

In this case the user had made such a mess of things that I told them to un-install the VirtualRPC, then delete the entire contents of C:\Program Files\VirtualAcorn and start again. They were not very happy but I explained that they had caused this and I could not fix the many faults they had caused. I also explained that they needed to be careful when copying stuff across from the "real" machine. I haven't heard back so I assume that they have been more careful this time, but the experience did give me an idea.

When a user makes a real mess of a VirtualRPC they always have the option of un-installing and re-installing it (which is yet another advantage over a real machine). However in some cases the user has only messed up the !Boot sequence and so a complete re-install will mean a lot of work. So in this case I have now started suggesting that the user renames the current !Boot sequence and then shuts down the VirtualAcorn. Then they should re-install over the top of their current installation. This will "repair" the system by copying a new clean Boot sequence in place. The user then just needs to re-unlock the VirtualRPC and it will boot up correctly. Having done this they can then carefully (that's carefully) copy anything they need (modules, fonts etc) from the broken Boot sequence to the good one until they have everything restored. Having done this I then always suggest taking a copy of the fully working Boot sequence, just in case the urge to bugger it all up again gets too strong.

Aaron