DDE, new tool ideas

Developers here, having their ways of working, ranging from developing on Linux or attaching another computer to RISC OS for debugging. I wonder if there’s another way?

Perhaps, a new DDE tool where you can drag and drop RISC OS applications or binaries to, with an icon on the icon-bar icon to run the application sandboxed from RISC OS.

RISC OS has various RPCemu programs; could any of those programs be utilised to do this?

Perhaps because most applications DO need to interact with RISC OS? Like have files dragged to them?

to run the application sandboxed from RISC OS.

The Debugger? ;)

It might be interesting to set up a minimal version of RISC OS on another core, that pushes it’s requests to the host for integration with the primary OS (so it appears to be a normal app). Then, it can be frozen and examined, and if it crashes just reset that core and not the entire machine. Better yet, if it crashes, access the core’s memory to try to work out why.

But, same question as always, who’s going to do these things?

@ Andrew,
I don’t want to sound like I am pushing for the Hypervisor idea (also because as I stated multiple times, it’s only an experiment for now), but:

• With the Hypervisor (if and when it’ll work) we can spin up a 2nd RISC OS instance on the same RPi/board
• Using HostFS we can share the App with the 2nd RISC OS instance
• The 2nd instance is effectively an isolated environment perfect for testing and even running the App (if the app allows that) in DDT or another debugger.

If the App messes RISC OS instance, just shut it down and retry. You main instance won’t be affected.

But, same question as always, who’s going to do these things?

In this case I am actually experimenting on it and working on this. Again, if it will work, there isn’t much other changes to do on a first release. It will be (obviously) Open Source, so whoever is interested will be able to join and help making it better etc…

The Hypervisor should also:

• work fine with Jeffrey effort for multi-processor (it is able to assign multiple CPUs to RISC OS instance).
• Follow ROOL requirement they shared back in 2020 London Show where Steve Revil clearly said they prefer RISC OS only solution. The hypervisor is actually just a “program” that can also be compiled on RISC OS itself if one has plenty of time to wait for it to complete :)
• Initially the Hypervisor and RISC OS will be independent from each-other, so I am doing my best to avoid touching RISC OS 5 at all to make it work on the Hypervisor
• RISC OS will run on bare-metal CPU, so no emulation, I am focusing on using the MMU and Resource Tree to trick RISC OS to think it’s running on a board with 2 cores and 2GB RAM (for example), and using HostFS to access the storage.

Similar idea to what Michael has achieved by running BSD with RISC OS on the same board, but in my case they can share storage and can communicate with each-other via Virtual NIC drivers (which are just shared memory on the Hypervisor itself).

Also RISC OS will access a frame-buffer that is mapped to an accelerated video driver. This is achieved by re-implementing Linux drivers API in the hHypervisor, that allows me to port Linux drivers to the Hypervisor with minimal changes (Rick I have been listening to you asking if there was a way to use Linux Drivers with RISC OS, this is as close as I can get to that idea). Given that Linux API is GPL and so are its driver, this means the Hypervisor will be GPL too, BUT that won’t influence RISC OS as it will run as a separate binary.

If, in the future, we’ll start to move logic out of RISC OS into the hypervisor, the hypervisor will talk with the RISC OS stub as a “client/server” architecture, so, also in this case, GPL will not cause issues to RISC OS.

If I manage to work the architecture right, RISC OS should also be able to access other VMs frame buffers and that, in the end, should help to run other OSes in a window similarly has we did on the RiscPC with M$ Windows running on the x86 card.

There are several things a virtual or containerised approach might encompass:

• Debugging. What happened when the binary or the program you dragged onto its icon on the Iconbar? Did it crash, produce any error reports?
• WIMP environment for testing drag and drop scenarios; scripts to try different use cases.
• A Task window environment
• A debugging environment that supports or provides similar features to tools such as Valgrind and gdb.

Benefits of such an approach:

• a safety net for new programmers
• reduce the number of machines needed for debugging
• avoids situations such as unexpected behaviour or where a program locks up the machine
• a modern debugging environment.

who’s going to do these things?

There are plenty of people around here with the skills, but not necessarily the inclination or time; perhaps opening a bounty might stir some interest.