[Virtualacorn-list] Enhancing the RISC OS experience

[David J. Ruck]

Vince M Hudd wrote:
> ralph_valmai at ntlworld.com wrote:
>> In message <gemini.k8xmno003hb9t00ss.vince at softrock.co.uk>
>>> In theory, the emulator could provide hooks to allow any DLL (on the
>>> Windows version
> 
> [...]
> 
>>> such a feature would have either incompatibilities or limited
>>> functionality for people running on native hardware 

So? That's called progress, which there has been pitiful little of in 
recent years, hence the state we are in.

[snip]

> Having more than one version of a module means incompatibilities would slip
> in, and appear as bugs, 

Only if being implemented by complete muppets. People are running RISC 
OS apps on a variety of different OS versions, and with a huge variance 
of module versions without any problems in the vast majority of cases.

> although I imagine that using GCC (which I don't
> personally use) should mean that the same sources can be used for all
> versions[1], so that might negate the issue. 

That's completely irrelevant.

> In some cases, I'm sure there would be a benefit - but for the vast majority
> of modules I'd bet there would actually be very little to gain, and the
> overhead (program calls shell-module, which passes the call to a special
> module that passes it through VA to a DLL on the host, which then does the
> work and passes the return data back through VA to the shell-module to be
> returned to the calling program) would probably outweigh the gain from using
> the host system in this way.

Vince, you've obviously got no knowledge of the VRPC SDK. There is very 
little overhead communicating between a RISC OS module and a native code 
dll, and the native OS APIs can be called directly from RISC OS.

This feature has been available since before Red Squirrel became Virtual 
Acorn/RPC, however very little has been done with it in the 5 years 
between the release of the networking code and the video driver (which 
I've yet to get working).

> How many modules do anything intensive enough to actually make this
> worthwhile[2] - and how many of /those/ happen to be written in C? (If not
> C, then you have to write a wholly compatible version in a different
> language/environment). 

Seeing that the host system is likely to be at least 10x (probably more 
than 50x faster for multimedia operations) than emulated RISC OS code , 
there is hell of a lot of things that could benefit from running native 
code.

Indeed we should be abandoning emulating obsolete RISC OS hardware 
completely and replacing all of the hardware related RISC OS code with 
calls to the native OS. That would both greatly simplify and greatly 
increase the performance of the emulator.

> [2] In some cases, there might be benefits for the developer to move some of
> their application using this mechanism, but that's not necessarily in a way
> that's good for RISC OS; as soon as any given developer starts moving any of
> his/her output to Windows (or MacOS), then that developer is starting on the
> path of porting his/her software. 

The alternative is complete stagnation, which we are very close to 
achieving. Is that what you are advocating?

Cheers
---Dave

-- 
Email: druck at druck.org.uk
Phone: +44-(0)7974 108301