Failed to create primary interface

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

Yeah. But that would be a crazy idea. What was I thinking.

Yeah. But that would be a crazy idea. What was I thinking.

Probably the same thing as me, which is probably a great worry to many people.

But what neither of you is thinking is that RPCEmu is a cross platform emulator, so “communicating with the Windows network API” is not a solution.

But what neither of you is thinking is that RPCEmu is a cross platform emulator, so “communicating with the Windows network API” is not a solution.

Well, I was thinking that the application needed to communicate with the API offered by the OS.¹
A Windows only solution is a solution, it just isn’t as wide ranging as might be wished.

While Windows, Linux and Mac may offer differing network API’s that is true for video and audio too.
I suspect a large degree of commonality across the variants, simply because the coders tend not to re-invent the wheel (just change the spokes and hub-caps a bit, and sometimes just a different paint job)

¹ I suspect Nemo was thinking the same, but if not he was thinking of the largest portion of the existing/potential user base.

But what neither of you is thinking is that RPCEmu is a cross platform emulator, so “communicating with the Windows network API” is not a solution.

Then how, pray tell, does the emulator communicate with the host operating system?

I would imagine that there is a central core that handles most of the aspects of the emulation, but then – by necessity – there will be a set of functions that are platform specific, because Mac isn’t Windows isn’t Linux isn’t RISC OS.

Now there are two ways that such a thing could be handled. The current method is an entire system emulator. That is to say, the virtual ARM core, the virtual VIDC, etc etc are used to make an environment that looks and feels as exactly like a RiscPC as possible, and then the host, via the emulator, translates all of this into something that the host platform can cope with. RISC OS writes to a VIDC style bitmap, the emulator translates this to an appropriate host style bitmap, you see it. Repeat for everything.

Perhaps a potential future avenue that might work is to teach RISC OS about the host platforms via modules that can interact with the emulator itself (perhaps trap SWIs or somesuch?). In that way the emulator can be simpler and RISC OS can take more responsibility for working with the host. Yes, this may mean that the Mac version may be running different code than the Windows version, but it may be potentially useful in removing the situation where our emulation is of a quarter century old machine and all its quirks. I’m not sure we should be emulating a Pi or a Beagle or a To, but rather “a generic ARM platform” that the operating system itself can be aware of. Then, just as a 4K mode is possible on contemporary hardware, so it can be on the emulator (if the host supports it).

Think of emulation, but from the inside out. You aren’t trying to be a specific platform, you’re only trying to run a specific OS.

Now there are two ways that such a thing could be handled. The current method is an entire system emulator. That is to say, the virtual ARM core, the virtual VIDC, etc etc are used to make an environment that looks and feels as exactly like a RiscPC as possible,

Which is exactly what Nemo and I (and I think Rick?) are NOT talking about.
Nemo expressed the point that RPCEmu wastes time pretending to be something from 30 years ago.
I’d say emulating an old machine is useful if you want to run old software or test newer stuff for backward compatibility. The more accurate the emulation of the old system the better that aspect works.

Emulating an ARM platform that passes through hardware on the host system is useful if you want to run new software on a newer OS that also works on current ARM hardware and also covers the possibility that the OS hasn’t developed enough to match some future ARM hardware.

Where’s the coder to put it together in a couple of months for 2p a day and a bonus bag of wine gums every week?

(and I think Rick?) are NOT talking about.

Tout à fait.
Leave the past where it belongs, ’80s radio stations and nostalgia for when times were better ¹.

Where’s the coder to put it together in a couple of months for 2p a day and a bonus bag of wine gums every week?

Wine gums? Jeez, you could be classier and at least offer a weekly slice of Battenberg! ²

¹ Of course the 80s were better as a child as the biggest crisis was Maggie doing away with the milk; all the other things Thatcherism broke were things grown ups worried about…

² The distinctive “pink and white” cake, as English as a cake can be ³ – https://en.wikipedia.org/wiki/Battenberg_cake

³ Only… It appears to have been an import from the Arab lands, but in the current climate of misplaced nationalistic fervour, probably best not to mention that part!

The more accurate the emulation of the old system the better that aspect works.

Yes and no. I use it as a super VM, with one important benefit: my RISC OS code works on Windows.
From this point of view, RPCEmu could also emulate a simpler machine, supported only by RISC OS 5. Just to get more speed.

Windows API: on Red Squirrel there was a Windows API support provided by a virtual podule (CallWin32). IMHO, a very good way to open the emulator to the host OS, while not changing too much code. I really would like to get this under RPCEmu (for example to send PDF to Windows for printing, or to speed up some operations).

CallWin32 is GPL. And RPCEmu supports podules helpers.
https://www.nedprod.com/programs/RISC-OS/CallWin32/

Problem: documentation, examples, etc.

RPCEmu is a cross platform emulator, so “communicating with the Windows network API” is not a solution

This is nonsense.

on Red Squirrel there was a Windows API support provided by a virtual podule (CallWin32). IMHO, a very good way to open the emulator to the host OS,

VRPC too of course. Hence I was able to integrate Windows Media Player into RISC OS:

Exactly what I want to provide.

API support would also allow to track the size of the window, in order to adapt the RISC OS resolution in realtime. Today I use an awful trick for this (files written by a Windows helper).

Hence I was able to integrate Windows Media Player into RISC OS:

<sigh> More animated GIF trolling right there… ;-)

CallWin32 is GPL. And RPCEmu supports podules helpers.
https://www.nedprod.com/programs/RISC-OS/CallWin32/

“Just” requires a rewrite with the 26bit dependent code modified. A ‘minor’ item of course.

Problem: documentation, examples, etc.

Some for the RO side so that’s a positive aspect.

Maybe Rick is right and we should stretch to something more enticing (a years supply of Fray Bentos pies in his case) :)

I thought RPCEmu was supposed to be a pure machine emulator. It is a Risc PC. If you want networking, then you would expect an emulation of an Ethernet card, and to use the original Ethernet driver (same one as for real hardware).

I think when Graeme Barnes first did the networking in RedSquirrel, he explained to me that his plan was to replace a key RISC OS module with a wrapper which talked, through the emulator, to the Windows equivalent. I think it might have been the Internet module. Quite a cute solution, as all existing apps expected the API provided by Internet, and they still had it. Of course, this isn’t a pure emulation solution, as it will only work for RISC OS on the emulator.

In principle, I would have thought you could do similar for RPCEmu, but you might need to explore what Qt can provide, or do some platforms specific bits. I am sure anyone is welcome to submit a diff!

This is why I keep banging on about the API – it will outlast the actual code.

nemo – well remembered. It wasn’t Aleph1 though – it was a new one-man company that pretty much only had the one product. IIRC it ran horrifically slowly, and only sort-of worked. But it did sort-of work, which was key. It was called WinRisc or Win, Risc. Seems to be by a chap called Chris Claydon. CJE sold some copies at some point.

Wow, just stumbled across this topic. I’m amazed that people are still talking about something I wrote at the age of about 16. Some of you seem to remember the details better than I do!

WinRisc wasn’t a one man show though, the Windows drivers were written by a guy called (IIRC, which i probably don’t) John Harrison. Parts of the RISC OS side were by Gavan Fantom. I devised the concept and those guys helped with some of the tricky stuff, communicating across the processor bus and coding for Windows (which I didn’t want to touch with a bargepole!). Also the company wasn’t new – before that I developed RSDFS which was a full RISC OS filing system which enabled drag and drop file browsing and transfer from one machine to another, all across a cable connected between the serial ports. Also mostly hand-coded in assembler. I sold a lot of those before getting ambitious and launching WinRisc which wasn’t a commercial success but it was the first time anyone had ever done anything like it. even now, VNC and such tools generally only work on whole screens, not individual windows.

It’s fair to say it was a bit flaky but we certainly proved the concept and it was way ahead of its time. My favourite bit was converting the Windows pull down menu bars into RiscOS contextual menu trees, which worked really nicely. We also even got drag and drop for files working very well between the two operating systems! The next iteration would have been a lot faster but support for the PC card itself was already fading and, as someone said, there never was a Pentium PC card, the 586 was the last. There was a slight lag on transferring the window snapshots across so realtime image editing and such was jerky. I can’t remember the details but this wasn’t a hardware constraint, it was something about the Aleph1 drivers not supporting the optimum way of passing the image data across.

Depending what app you were using it could work pretty well but it was always more of a novelty proof of concept than something people used every day. At that time the writing was on the wall for Acorn and I shut the business down when I headed off to uni.

The UI was in BASIC, the core of it (rendering and data transfer between the CPUs) was hand coded in ARM Assembler to make it as fast as possible and the Windows drivers were in C I think. I have no idea what happened to the source code, probably still sitting on a RiscPC in my mum’s loft, if the hard disc still turns. In the unlikely case that it’s of use to anyone then I’m happy to release WinRisc free of copyright and open source. It’ll be a long time before I get a chance to visit my mum’s loft but if anyone still has a copy of WinRisc then feel free to share/upload it.

WinRisc wasn’t a one man show though, the Windows drivers were written by a guy called (IIRC, which i probably don’t) John Harrison.

As in “Anymode” perhaps?

Depending what app you were using it could work pretty well but it was always more of a novelty proof of concept than something people used every day.

It wasn’t something I had a specific use for at the time but like a number of items I bought back then and in the intervening time the money was intended to encourage further work. Acorn getting asset stripped wasn’t factored in to my thinking.

bq, In the unlikely case that it’s of use to anyone then I’m happy to release WinRisc free of copyright and open source.

You never know what would be useful so putting up the source somewhere would be useful.

The PC card software wouldn’t work on an RPC running RO5.2x though since large parts of the !PC card software are hand coded assembler in 26 bit incarnation. Parts do exist in a 32 bit form following some dubious hack work¹, but there’s a lot to twiddle with before that could even be an alpha

It’ll be a long time before I get a chance to visit my mum’s loft but if anyone still has a copy of WinRisc then feel free to share/upload it.

I know I have, where it currently is located is a different question.

¹ It was a self teaching exercise at a point where I had more spare time.

I remember the Acorn World show at which WinRisc was launched, or at least, was being heavily promoted as a new piece of software. It must have been 1996 or 1997 as those were the only two years I attended I think. I actually won a copy somehow, which I gave to one of my brother’s chemistry lecturers as he was the only person I knew with a PC card.