[Virtualacorn-list] Enhancing the RISC OS experience

[Vince M Hudd]

ralph_valmai at ntlworld.com wrote:
> In message <gemini.k8xmno003hb9t00ss.vince at softrock.co.uk>
>           Vince M Hudd <vince at softrock.co.uk> wrote:

[...]

> > 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 

> The point about incompatibility is an important one, but I envisaged the
> alternative modules as providing exactly the same functionality as the
> native modules but giving a speed gain.

Yes, I realise that - I was extending the idea and pointing out a problem
with that extension. In fact what you're suggesting would have to be
implemented differently to what I suggested (because the calls to the host
system would have to be done transparently to any calling software, whereas
what I was talking about would involve a specific call to register DLLs, and
one or more which then call functions within them).

> Incompatibility would not then be an issue. 

I'm not so sure.

Having more than one version of a module means incompatibilities would slip
in, and appear as bugs, 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. 

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.

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). 

[1] You'd actually have at least three - four if you implement it on both
host platforms: a native module on RISC OS, for use on native hardware; a
native module 'shell' on RISC OS (since software will still be making the
same SWI calls) which will pass any calls on to a module that passes them up
through VA to the host; and the equivalent to the module, implemented in
whatever form on the host system(s).

[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. 

[...]

-- 
Vince M Hudd
Soft Rock Software