Failed to create primary interface

And this has triggered an ancient memory of someone doing the reverse a very long time ago – PC Emulator windows running in the RO desktop. Was that an Aleph One experiment? A Wookie special? Long time ago.

That was the PC card – plugged into the second processor slot on a RiscPC, source code made open and currently sitting on riscos.info. Quite an interesting learning exercise making portions not crash on RO5.

The WinRisc product aimed to merge the x86 and ARM elements of the installation and put Windows applications in individual windows on the RO desktop.

If I dig around I have all the above, and (I think) both a 486 and a 586 card. Mind you with the state of the front bedroom anything smaller than an adult human is easily missed.

Didn’t Microsoft get involved and add Pi emulation to QEMU?

Well as I recall there is an allegedly viable Pi emulation available for QEMU which is supposed to be capable of running an ARM version of a linux kernel.

How much it differs from a genuine Pi is the real question, but then once you have working install and can add other features by passing the underlying hardware features through to the “PiBorg”© would you really care that it didn’t match a real Pi that was missing those features?

And this has triggered an ancient memory of someone doing the reverse a very long time ago – PC Emulator windows running in the RO desktop. Was that an Aleph One experiment? A Wookie special? Long time ago.

As Andrew said, it was called “Win,Risc” distributed by “ARMed Forces Software”. Everyone wanted to use Windows 95 on the PC card, and Win,Risc sadly only supported Windows 3.1(1) applications. And amongst those, only a tiny amount worked sensibly, possibly those the author himself tried and tested. A version that should have supported Win95 was developed, but I never got that to work in any way and don’t know anyone who could. Not sure if that was ever officially released. I was an enthusiastic beta tester back then.

It was slow, it was only halfway-usable (speed wise) in 16 colour mode, and the conversion of Windows Pull-Down menus to RISC OS popup menus often failed. It also managed to crash the !PC software regularly. Bugfixes dried up quickly, and the author always blamed Aleph1 for not doing essential changes in !PC so that Win,Risc could reach much higher performance. Aleph1 always said that those changes would not be easy. There are surely lengthy discussions on Usenet in comp.sys.acorn.extra-cpu from that time. Or was it still on FidoNet?

Possibly the worst 30 UKP I ever spent on RISC OS software.

Just agreeing with Nemo and Steffen. I always felt that the future of VRPC was in creating a virtual ARM machine with as many of the underlying “host OS” APIs abstracted through to RISC OS via modules – 3D, audio in/out, MIDI, etc.

VRPC needs serious updates. And RPCEmu an easy to use networking solution. We’re stuck.

So this is what I meant , a fully compatible (as far as possible) host system and a JIT emulation in the mix. Fuly transparent system.

I’m glad we agree.

VRPC needs serious updates.

Its faults do not prevent it from being used (it’s just much better full-screen than windowed).

And RPCEmu an easy to use networking solution.

Indeed. And multiple mounts.

We’re stuck.

Only with the former. The latter is simply a matter of typing. ;-)

The latter is simply a matter of typing. ;-)

Best talk to some other monkeys cos this one hasn’t figured out the right keys yet. :(

I’m glad we agree.

Yes, I think that for the purposes of emulation we shouldn’t be looking at making it a RiscPC or a Pi or whatever. I don’t believe that there is anything to gain these days from emulating a specific hardware. We should be looking to making it the simplest system that will run RISC OS, with simple drivers on the RISC OS side that kick stuff over to be handled by the host. By doing this we might be able to cut out a lot of conversions into formats on the RISC OS side, which are immediately unconverted by the host side.

be honest, I rather convert the kernel to C

Volunteering? :-)

There are probably a number of people that wish the kernel wasn’t a gigantic heap of assembler, but it is and that’s what we’re stuck with.
Not to mention that, thanks to its MOS heritage, the “kernel” is a giant mishmash of things. All the OS Bytes, the VDU driver, conversions, blah blah…

run Linux apps on riscos would be cool.

We’d first need to teach RISC OS that more than one application can exist and run at the same time. Which… Might be “interesting” given the complete and total lack of application-specific context for anything whatsoever. There’s only one set of cursor positions, there’s only one active font, there’s only one foreground colour, there’s only…

Isn’t the Linux port the answer here? Wouldn’t that be described as a relatively skinny HAL which can run RISC OS 5? But the underlying system is Linux on ARM. OK, so it’s assuming 32-bit ARM, but like is often said for WINE, perhaps there is potential to revise that?

P.S. Forum login issues are very strange! I’ve tried about 20 times on my usual Android tablet with Chrome, and couldn’t stay logged in at all. Had to use another machine entirely (macOS laptop with Safari) where the same process worked perfectly. It’s most odd!

I’m quite tired right now so I may be writing nonsense here. Apologies, if so. :)

Isn’t the Linux port the answer here?

I was wondering about this too. If you set it up without a Linux window manager, maybe it could boot straight into RISC OS.

But the underlying system is Linux on ARM. OK, so it’s assuming 32-bit ARM, but like is often said for WINE, perhaps there is potential to revise that?

Digression: What I would like is a way to easily dual boot Linux and native RISC OS on a Pi. I know you can swap SD cards but depending on where the Pi’s mounted that’s not always convenient.

Yes, indeed. You don’t need to consider a typical Linux-based bistro which then has the ‘RISC OS Linux port’ installed as some sort of extra. If you could be bothered, I don’t see why a cut-down distribution couldn’t, from the user’s point of view, boot into RISC OS. You probably wouldn’t want exactly that in reality, as you’d miss out on the ability to do things like run Linux applications side-by-side.

Dual-booting on a Pi? Life’s too short. Just spend between £5 and £50 and buy another Pi! :)

Life’s too short. Just spend between £5 and £50 and buy another Pi!

That is what I have done. RISC OS on an Rpi3B+ and Raspbian Buster on an Rpi4.

You don’t need to consider a typical Linux-based bistro

I find this idea fascinating! I’d give it a try!

VRPC needs serious updates. And RPCEmu an easy to use networking solution. We’re stuck.

There is some teasing for the latter here https://www.riscosopen.org/forum/forums/1/topics/14722 in the London Show announcement…“The RPCEmu team will be demoing the much anticipated/desired “Easy Networking” support.”

Let’s hope for the best!

Fingers crossed.

TBH “Easy” is still worrying. “Completely automatic” is what I’d aim for.

TBH “Easy” is still worrying. “Completely automatic” is what I’d aim for.

Everything that is easier than “create that OpenVPN bridge by hand” would be a big step in the right direction!

My setup (RPCEmu on a Debian box with simple networking bridge) works like a charm. Has done so since I created it almost six years ago. No issues whatsoever and a piece of cake to set up. No issues making a server running on RPCEmu available to the network either (does the default method suggested for Linux even support that?).
Will this “Easy Networking” support break things? Then it’s not an improvement for me.

Obligatory: https://imgs.xkcd.com/comics/workflow.png

TBH “Easy” is still worrying. “Completely automatic” is what I’d aim for.

Everything that is easier than “create that OpenVPN bridge by hand” would be a big step in the right direction!

Bit of a busy day¹ otherwise I’d have commented earlier, but I totally agree that having a network setup that requires mystic hand-waving of a network techie level to produce something half stable is not good so I await the appearance of the easier version with bated breath.

My setup (RPCEmu on a Debian box with simple networking bridge) works like a charm.

That would be because it avoids the use of the network TAP provided by elements of OpenVPN. Sadly the Windows situation is different, and even more sadly is generally buggered about with by the shifting MS sands.

¹ The wife is due to have her shoulder rebuilt, so this morning I was across the site with her going through the pre-op assessment. Time in the waiting area was long enough for me to finish a couple of jobs using a laptop on the wireless in the area. Neither included surfing the net :(

Obligatory:

Not really.

http://www.marutan.net/rpcemu/manual/network.html

See ‘Ethernet Bridging’. Currently nothing unusual about it.

See ‘Ethernet Bridging’.

Sadly bridging isn’t available without the OpenVPN TAP and that is a bit unstable when used with RPCEmu.
Take it from me, it isn’t a quick and stable click and go.

Much as I’d like to see more people using Linux it isn’t likely to be a majority portion of the user base in the immediate future.

I should hardly need point out that the way it should work is:

• Install RPCEmu on one PC
• Install RPCEmu on another PC
• Run both
• Share discs via ShareFS
• Works

That’s what happens with VRPC, and not by the power of magic. Talking about “IPv4 addresses” and “bridging” is really missing the UX point. And when you get to these known issues it should be obvious you’re Doing It Wrong™.

I don’t remember having to do any of that to get this browser working, and it can literally talk to any computer in the world! Why should I have to do all that to talk to the machine at the other end of the desk?! Get a grip.

I don’t remember having to do any of that to get this browser working,

That would be an instance of a Windows application communicating with the Windows network API.

And when you get to these known issues it should be obvious you’re Doing It Wrong™.

That would be a Windows application not communicating with the Windows networking API but going through an intermediate stage. This may not be a good idea.

not by the power of magic

When I referred to “mystic hand-waving of a network techie level” I didn’t mention that I have (with some extra hand wave and prod plus a bit of cheap kit) succeeded in connecting RPCEmu through to the EOOL site using a laptop out in the garden. I’m not writing it up as I wouldn’t punish people with that level of awkwardness.

As I said earlier, I await the appearance of the easier version with bated breath.

RPCEmu 0.9.1. has been running RO5.24 fully networked on my Win7 laptop for over a month now with complete reliability. I don’t regard myself as particularly expert when it comes to grappling with IP4/6, and in fact had wrestled fruitlessly to set up networking for weeks beforehand. The breakthrough consisted of (1) degrading to OpenVPN 2.1.3, and (2) setting Windows Firewall to specifically allow RPCEmu through the firewall. I also assigned individual static addresses to the network bridge and RPCEmu respectively, although the networking instructions are not specific on this point. All that said, it can be a very demoralising business, largely because one has no idea, when it fails to work, what the cause is, so any part-automation or simplification will be welcome.