[Rpcemu] (no subject)
theo at markettos.org.uk
Thu May 14 05:10:31 PDT 2020
On Thu, May 14, 2020 at 08:01:17AM +0200, dfeugey at ascinfo.fr wrote:
> Le 2020-05-13 22:59, Peter Howkins a écrit :
> It seems as if a large number of these suggestions are "It would be
> better if I could pretend the Host OS wasn't there". RPCEmu is about
> running RISC OS and its applications on the Host, not running Host
> applications under RISC OS, there's such a ludicrous amount of work
> there for so little benefit that I'm not not interested in pursuing
> This subject is going really to far.
> That was just - at first - a suggestion.
> CallWin32 did exist and was quite funny. With better security (selected API,
> selected calls, user confirmation, or just a big warning) it could help.
ISTM that these are the kind of things that are traditionally performed by
'integrations' in hypervisors. You install the 'guest additions' in the
guest OS which provides some drivers that hook into the hypervisor and allow
things like seamless mixing of windows between the host and guest desktops.
Such a process has host and a guest components. I don't see a problem if
the interface between host and guest is an API that is clear and
well-defined. For example, HostFS and networking are examples of such an
API. Being bounded, the API would not be able to make arbitrary OS calls
(as CallWin32), and the host side of the API would vet the requests it gets
from the guests to check if they're sensible.
Obviously, opening up any interface offers another attack surface. But a
user could decide whether to open up, say, the 'host printing' interface if
they decide they want to take that risk.
The host side of things would be naturally implemented inside RPCEmu - the
guest side would likely be more of a stub. I assume by Peter not wanting to
define an API he means an API that allow host-side RPCEmu to interface to
other closed-source host-side code. This problem wouldn't arise if the
host-side code was simply integrated into RPCEmu (being open source), and
the patch was rejected if the guest-side code wasn't also open source.
> Now, it's your project. Your choices.
> I did not suggest that to bother you.
> Working around RISC OSs lack of applications in a system emulator of a
> 26 year old piece of hardware is pretty ridiculous.
> This time, since RISC OS is used for my business: my choices ;)
> But perhaps I'm ridiculous to use it after all.
I think it depends on your use cases. If your use case is you have some
piece of RISC OS software that you want to run but want to integrate better
with host facilities (eg printing), that's different to if you want to run
(for instance) a game as if the world stopped in 1994. The existence of
such integrations in VRPC suggest that there are people who are interested
in the former.
As ever, this is moot until someone builds such a thing :)
More information about the RPCEmu