RISC OS

Disclaimer

Before I begin this review, I will make a couple of things clear.  First, most of the issues I name here have been passed onto VirtualAcorn with as much detail as was relevant, and graciously received, although I do contest how the program ought to behave in a number of instances.  Second, I didn't pay for the product - at least, not directly.  VirtualAcorn provided me with VirtualRiscPC as sponsorship for my work on bringing Firefox to RISC OS in return for advertising. 

Why VirtualRiscPC?

As I've mentioned a couple of times in recent articles, my real RISC OS machines are currently in transit across the North Atlantic.  Moving country meant that I needed a portable computing solution - a solution that would allow me to use both RISC OS and another operating system.  As such, I invested in a Acer laptop earlier this year, paying around 500 UKP for the cheapest widescreen (1280x800) system I could find, which has a Sempron 2800 processor and all the other usual stuff you find on laptops.  Naturally, had I waited a few weeks, I could have had integrated WiFi and a DVD writer with it for the same price and had a sensible graphics chip it in (the current one doesn't work well with Linux), but there's little you can do about price drops after the fact.

Running WinXP really wasn't my ideal choice, with all the hassles of maintaining a Windows system and the exceptionally tedious user interface that makes things that would be a simple case of drag-and-drop under RISC OS a prolonged chore. I do have Linux on the machine, but with the aforementioned video driver issues, it's not entirely practical to use.  For the moment, I'm taking the pragmatic appropach and sticking with it.

Installing VirtualRiscRPC

Although the install itself is smooth enough, I have a number of misgivings about the ID/key system used to activate the software, that others seem to share.  For one, it relies on looking at your network interfaces to generate a key.  In my case, it decided that the primary interface was my removable PCMCIA card.  In practice, this means I can't start the program unless I supply an alternate activation key, and of course that key changes back if I reinsert the card.

In time, since the machine does not have integrated WiFi, I intend to install a mini-pci 108Mbit wireless card which will be in the machine permanently, but for the moment the wifi card has to be removed for transportation. 

About my usage

Apart from running RISC OS on VirtualRiscPC to handle mail, news and various other computing activities, I'm also running Cygwin.  This allows me to run a Linux-like environment under Windows, and in turn, use GCCSDK to perform RISC OS development - in particular, building Firefox for RISC OS. I have a HostFS mount under VirtualRPC which allows me to look directly at the programs I've build under Cygwin.

As you might expect, under Windows I have all the usual free software suspects - Firefox, Thunderbird,  OpenOffice.org, PuTTY, The GIMP and the various software (some of it of dubious use) that Acer saw fit to bundle with the machine. 

VRPC in use

The most frustrating thing I've found with VRPC is that it's simply not practical to use it in multi-tasking use, because of the dual mouse pointer behaviour.  Clicks outside the VRPC window when it still has focus often result in inadvertant clicks under RISC OS.  Plus the behaviour of Windows itself, bringing windows to the front on focus makes any kind of side-by-side work difficult.  I have been assured that the mouse handling will be improved in future versions.

Ideally, I would be able to use VRPC in full-screen all the time, but the real-world requires me to use Windows at times - mostly for things like connecting to the internet (internet connection sharing via wireless link), using Firefox under Windows (which of course is rather more polished than my version and runs faster since it isn't being emulated) and accessing Cygwin so I can try and improve the issues in RISC OS Firefox.  For this last point, it might be sensible to run a local telnet server (telnetd) under Cygwin, allowing a telnet session from RISC OS, but I haven't investigated this yet.

Filename handling

The handling of RISC OS filenames under HostFS uses the standard ,xxx extension to indicate the RISC OS filetype that I talked about in a previous article.  This will work just fine as long as you only create from within VRPC.  As soon as you create filenames from elsewhere - examples include from inside Cygwin, transferred via LanMan98, or from a CD employing the same system, then things start to go wrong.  The problem is that, as I outlined in a further article on filetyping, VRPC does not implement the system very well.  The options for creating mounts do contain a couple of options for filetype handling, but no combination results in a setup that works correctly.  In practice, this means that the default filetype is data rather than text, and that I have to have two mounts to access my Firefox build - one is to edit the text files, so that they don't gain an ,fff extension when they're saved, and the second is to access the final binary, which must be viewed under an alternate mount to have the correct filename and filetype (the actual filename under Cygwin is firefox-bin,ff8).   VA have also assured me that this will be investigated.

I've also expressed my frustrations over the mount handling dialogue and the menu layout, which is sadly reminiscent of so many poorly designed UIs in Windows programs.  I understand this has been slated for an overhaul.

Other bugs

There are a handful of over issues I found caused me headaches.  For example, the networking under RISC OS may refuse to resolve an address if it previous attempt failed to resolve it (because there was no internet connection, for example).  The only work around is to quit and restart VPRC.  Programs like NewsHound are susceptible to this. As an incidental note, I found that a Windows virus checker I had installed would "helpfully" scan POP3 email fetched by POPStar. 

Other problems include mixed behaviour of the various restart options - asking for a powercycle will more likely result in the emulator crashing.  Also I found (on my particular setup) that when I tried to use it on a dual display setup, that it ungracefully found itself in a state , after a failure to create the surface, in a situation where I had to ctrl-alt-delete it.  VA have suggested this is because of lack of memory on my video chipset, but I suspect this isn't the case.

All in all, I'm now aware of most of these problems and can avoid them or work around them, but they are nevertheless annoying, and dimish the polish on an otherwise very useful product.

Finally

For completeness, I will note that the version I have is VirtualRPC-SE, which comes with RISC OS 4, but as a (former) Select subscriber, I have installed that on it.  VA tell me that the only feature I miss out on is use of screen modes which use more than 2MB or VRAM (up to 8MB).  For me personally, this isn't such a big deal, but might become so if I had a laptop with a larger resolution.

As a portable computing solution, there's obviously no contest for RISC OS against VRPC, although I feel in most instances, I would prefer to have a real RiscPC - at least, one is that is as specced up as my own with a Kinetic, ViewFinder and IDE card.  Compared to a vanilla StrongARM 233 machine with no other add-ons, I might feel differently.  As for its comparison with an Iyonix, that of course can't run Select, and I haven't forked out for 32-bit versions of some software I use like Messenger and Photodesk, although I imagine doing so next year, so a comaparison is less clear.  The Iyonix is still faster for most things, although file copying under VRPC is very quick indeed compared to traditional speeds under RISC OS.

I do hope that VRPC improves, and I'll welcome any Linux version, but I can't see using it as a primary RISC OS solution whilst real machines remain so useful.