Re: [Rpcemu] RPCEmu 0.9.2

> On 26 Oct 2019, at 20:42, Theo Markettos <theo@markettos.org.uk> wrote:
>
> Apple is tightening up the use of code generated at runtime, since code
> injection is a common attack pathway. It's not possible to do it at all on
> iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap()
> and also have the feature enabled at code signing time:
> https://github.com/dotnet/coreclr/issues/18617
>
> I think you also need pages RW or RX - macOS has almost no pages that are
> RWX and I suspect they want to keep it that way.
>
> Theo

Interesting, thanks for that.

I *think* I have fixed this, at least on OS X 10.14.6. I found an example of a call to mmap() that I could actually understand and popped it into the method I mentioned previously. It appears to work now, though I'm not using MAP_JIT (if I do, I get an invalid argument error), and I haven't changed code-signing. Perhaps it needs to be different on Catalina - hopefully someone will be able to test this.

A revised patch will follow in the next few days.

Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] V0.9.2 patch for Mac keyboard and networking support

Timothy Coltman, on 27 Oct, wrote:

> Following the release of 0.9.2, I have updated my Mac patches to work with
> this new release

[snip]

> Please note that due to a recent update to OS X (at least in 10.14.6),
> dynamic recompilation does not work in that particular version of OS X. I
> haven't upgraded to Catalina yet, but I suspect it's the same. Older
> versions of the operating system should (?) be unaffected.

RPCEmu 0.9.2 interpreter has built here on Catalina 10.15 with Xcode 11.1
and Qt 5.12.5.

The only oddity was that the 'netroms' folder and the EtherRPCEm module
within were not recognised, Verma showed no sign of the podule in RISC OS.
Moving the EtherRPCEmu module into 'poduleroms' sorted that and networking
then worked.

I will try a recompiler build later.

Thanks for the good work.

--
David Pitt

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

In article <58092b907fdave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> In article
> <CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> > A new version of RPCEmu is available, 0.9.2

> [Snippy]

> Excellent... good work folks...

> However, after spending some hours trying to get networking working, both
> Static (Preferred) and then DHCP not much luck.

> Problem is here I'm using RISC OS 6.20 the config options are different
> to 5.nn.

> The problem is undoubtedly mine not RPCEmus so I'll have another go at it
> tomorrow.

> Dave

Well... Interesting day...

I have two RPCEmu installs that need networking, a RISC OS 6.20 and a ROOL
RISC OS 5.27

Neither of them had active networking set up in the old bridge way...
Technical reasons I'll not expand upon...

After yesterday evenings fun and failures I set out with some purpose
today to sort it.

Yesterday I started to do a manual configure but that didn't work out, but
I did eventually managed to get them working via DHCP the easy peasy way.

New day, refreshed bonce and managed the ROOL RISC OS 5.27 manual
networking configuration without a hitch.

The RISC OS 6.20 was slightly more difficult as the Network config options
are a bit different, however with perseverance I got there in the end.

So I now have both RPCEmu 0.9.2 installs networking... Well within what
they can ATM manage. ;-)

*So thanks for for all the work you must have done to achieve that...*

Dave

Afternotes:

Lanman98 on RISC OS 6.20 networks okay.
Lanman98 on RISC OS 5.27 doesn't at all.

From what I read...
ShareFS doesn't work at all... Can that please be on the list of things to
fix at some point as I normally use ShareFS a lot.

Printing over the network to the printers I have on my LAN works okay with
both 6.20 and 5.27.

Now a question...

On RISC OS 5.27

Upon starting the shutdown process we end up with a small pane that notes:
"The computer is now ready to be switched off"

Accompanied by a "Restart" button, if this button is clicked (I did want a
restart) a new pane is displayed with the following:

RPCEmu Fatal Error.
Bad PC fc001000 fc001000

RPCEmu vanishes... Dead and gone.

This happens every time the Restart button is clicked.

Any particular reason this is happening?

Obvious answer, don't use it... :-)

FWIW. A restart action during the close down of RISC OS 6.20 does not fail
and reboots the RPCEmu.

Thanks
Dave

--

Dave Triffid

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] V0.9.2 patch for Mac keyboard and networking support

Hello all

Following the release of 0.9.2, I have updated my Mac patches to work with this new release, and would like to submit this for inclusion in the proper source for the emulator. This implements keyboard support, and also adds support for networking.

Attached is a ZIP file containing a "macosx" folder and a patch in unified "diff" format. You should unpack this in the "rpcemu-0.9.2/src" folder and apply the patch from there, i.e.:

patch -p0 -i ./rpcemu-0.9.2-mac-keyboard-patch.diff

The patch should successfully apply without error. Next, change into the "qt5" folder, and type the following:

qmake
make -j3

(Increase the 3 to however many cores you've got.)

This should produce an "rpcemu-interpreter.app" application in the top-level "rpcemu-0.9.2" folder. Double-click to run in the normal way. It should work in the same way as the previous Mac releases I've contributed to.

Please note that due to a recent update to OS X (at least in 10.14.6), dynamic recompilation does not work in that particular version of OS X. I haven't upgraded to Catalina yet, but I suspect it's the same. Older versions of the operating system should (?) be unaffected.

As ever, comments and bug reports are welcome.

Tim

Re: [Rpcemu] RPCEmu 0.9.2

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
[snip]
> 10.10.10.10 is correct. NAT provides a 10.10.10.x network inside the RPCEmu
> binary.
> The DHCP server inside the RPCEmu binary will return 10.10.10.10 as the IP
> address
> to RISC OS.

Thanks to this advice, Timothy's heads-up and finally reading
the (very clear!) instructions, it just looks like it was
all my fault, together with some strange coincidence in my
networking (both laptops I operate from while watching TV are
WLANed to an access ponit that is then connected via PowerLan to
the main router, which is not the most stable arrangement one
could think of). Just trying to get to the bottom of that, but I
now have plain RISC OS 5.24 running NetSurf OK.

So there is hope for me! Just a shame Access won't work, but
I am certainly happy with all the rest!

Thanks again
Steffen

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

At some point Steffen Huber <steffen@huber-net.de> wrote:

> I probably got confused by my RISC OS 4.02 installation not detecting
> a networking interface at all, then I read the docs and somehow jumped
> to the wrong conclusion (and after extracting AutoSense content from
> Mercurial, it DID detect the interface, which was probably even more
> confusing looking back now).

This is wrong, or rather you do not need to copy any autosense files in,
since version 0.9.1 (the previous release) the EtherRPCEm module will
automatically create the autosense files in the !Boot directory for you.

Can you tell me the contents of the 'netroms' directory in the RPCEmu
directory (alongside 'hostfs', 'roms', 'poduleroms' etc) there should
be one file 'EtherRPCEm,ffa'.

Can you tell me the output of '*help etherrpcem', it should be version
1.04 (06 Oct 2019) for version 0.9.2.

Can you double check that 'Network Address Translation' is selected in
Settings->Networking... windows. Only because you mentioned that you'd
hit the Bad PC bug on RISC OS 5 restart, this actually caused RPCEmu
to 'crash' out and not save its config (both these things are going
to get looked at).
 

I can't get networking to work. Neither on Windows 10, nor on Windows 7.
Neither via WLAN nor via LAN. Neither running as Admin or not. Neither
via DHCP nor via static IP. Neither with or without active Windows
firewall. Neither with my usual RISC OS 5 and RISC OS 4 installations
nor with a fresh reinstall of RISC OS 5.

DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
that my only DHCP server in the network would ever supply. Something
is very wrong here and I am running out of ideas what to try.

10.10.10.10 is correct. NAT provides a 10.10.10.x network inside the RPCEmu binary.

The DHCP server inside the RPCEmu binary will return 10.10.10.10 as the IP address

to RISC OS.

Check the above advice about the netroms directory, it appears the module hasn't

been loaded from the there and that your autosense hackery has loaded an older

version (from your !System).

Peter

Re: [Rpcemu] RPCEmu 0.9.2

Hi altogether,

> Steffen Huber <steffen@huber-net.de> wrote:
>
[snip]
> > I have also the IP 10.10.10.10
>
> But presumably your router is somewhere at 10.x.x.x and is configured
> to hand out addresses like 10.x.x.x. This is not the case for me.
> My router is 192.168.1.1 and is configured to hand out IPs via DHCP
> between 192.168.1.100 and 192.168.1.200 (because the rest is reserved
> for static IPs in my home network).
>
> So if a device gets 10.10.10.10 as an IP address here, there is
> something very wrong.

Having just re-read
http://www.marutan.net/rpcemu/manual/net-ro-nat.html
that address seems to be expected in DHCP situation because
of the way NAT works. I need to read the docs more closely before
complaining...

But NetSurf does not work, and DNS does not work, so there is
still something wrong. I'll investigate further.

Thanks
Steffen

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

On 27 Oct 2019, at 15:17, Steffen Huber <steffen@huber-net.de> wrote:

By "not working" I mean that ifconfig -a shows that (in the static
IP case) the IP address is correctly assigned, and route shows that
the route to the router is correctly set, and DNS is correctly
configured. But pinging the router/DNS server does not work. Pinging
any other machine on the network does not work. Name resolving
obviously does not work, either.

(Sending again, to the list this time.)

Pinging doesn't work for me either, but it seems that's a quirk of the NAT implementation.  From the website (http://www.marutan.net/rpcemu/manual/net-ro-nat.html):

"ICMP packets are not forwarded through the Network Address Translation, only IP packets, as such 'ping' will not be able to ping any host other than 10.10.10.10 and 10.10.10.2".

Tim

Re: [Rpcemu] RPCEmu 0.9.2

Hi David,

> dfeugey@ascinfo.fr wrote
>
>
> Le 2019-10-27 16:17, Steffen Huber a écrit :
> > Hi David,
> >
> > DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
> > that my only DHCP server in the network would ever supply. Something
> > is very wrong here and I am running out of ideas what to try.
> >
> I have also the IP 10.10.10.10

But presumably your router is somewhere at 10.x.x.x and is configured
to hand out addresses like 10.x.x.x. This is not the case for me.
My router is 192.168.1.1 and is configured to hand out IPs via DHCP
between 192.168.1.100 and 192.168.1.200 (because the rest is reserved
for static IPs in my home network).

So if a device gets 10.10.10.10 as an IP address here, there is
something very wrong.

> > By "not working" I mean that ifconfig -a shows that (in the static
> > IP case) the IP address is correctly assigned, and route shows that
> > the route to the router is correctly set, and DNS is correctly
> > configured.
>
> I remove all information in the DNS and Gateway configuration applet,
> and it works.
> Here, I have 10.10.10.2 as the gateway (auto configured) and no DNS.

Whatever I configure - either DHCP in the same way that works just fine
for any RISC OS 4 Select or RISC OS 5 machine, or static IP like I
do for the RISC OS 4 and previous machines - it does not work.

> > But pinging the router/DNS server does not work. Pinging
> > any other machine on the network does not work. Name resolving
> > obviously does not work, either.
>
> I suspect you defined the gateway and DNS, and that's the reason why it
> does not work.

You suspect wrongly. And even if I did, there is no way that could
result in an IP address assignment like 10.10.10.10. And it does not
make failure in static IP situation plausible at all.

Steffen

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

Le 2019-10-27 16:17, Steffen Huber a écrit :
> Hi David,
>
> DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
> that my only DHCP server in the network would ever supply. Something
> is very wrong here and I am running out of ideas what to try.
>
I have also the IP 10.10.10.10

> By "not working" I mean that ifconfig -a shows that (in the static
> IP case) the IP address is correctly assigned, and route shows that
> the route to the router is correctly set, and DNS is correctly
> configured.

I remove all information in the DNS and Gateway configuration applet,
and it works.
Here, I have 10.10.10.2 as the gateway (auto configured) and no DNS.

> But pinging the router/DNS server does not work. Pinging
> any other machine on the network does not work. Name resolving
> obviously does not work, either.

I suspect you defined the gateway and DNS, and that's the reason why it
does not work.

David

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

Hi David,

> dfeugey@ascinfo.fr wrote:
>
>
> Le 2019-10-26 16:11, Steffen Huber a écrit :
>
> >
> > Anyway, it does not work for me, neither with DHCP
>
> Be sure to remove all options for gateway and DNS server as all is done
> with DHCP.

I configured RISC OS networking perhaps a thousand times,
so I have that feeling that that part is not the problem.

> Here, it works well, apart from 'reduce CPU usage' completely broken on
> RISC OS 5 and the lack of CallWin32 (it would be useful for so many
> things).
>
> RPCEmu is almost perfect now :)

I can't get networking to work. Neither on Windows 10, nor on Windows 7.
Neither via WLAN nor via LAN. Neither running as Admin or not. Neither
via DHCP nor via static IP. Neither with or without active Windows
firewall. Neither with my usual RISC OS 5 and RISC OS 4 installations
nor with a fresh reinstall of RISC OS 5.

DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
that my only DHCP server in the network would ever supply. Something
is very wrong here and I am running out of ideas what to try.

By "not working" I mean that ifconfig -a shows that (in the static
IP case) the IP address is correctly assigned, and route shows that
the route to the router is correctly set, and DNS is correctly
configured. But pinging the router/DNS server does not work. Pinging
any other machine on the network does not work. Name resolving
obviously does not work, either.

Any ideas?

Thanks
Steffen

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

In article
<CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> A new version of RPCEmu is available, 0.9.2

[Snippy]

Excellent... good work folks...

However, after spending some hours trying to get networking working, both
Static (Preferred) and then DHCP not much luck.

Problem is here I'm using RISC OS 6.20 the config options are different to
5.nn.

The problem is undoubtedly mine not RPCEmus so I'll have another go at it
tomorrow.

Dave

--

Dave Triffid

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

There was (I believe) an issue with the pointer/length calculations for that mprotect() code at one point, for which I submitted an (untested) patch. The current code doesn't really resemble mine but I'm pretty sure it gets the correct values anyway, and so I suspect Tim is correct about it being some new sandboxing protection.

On Sat, Oct 26, 2019 at 6:30 PM Timothy Coltman <lists@maemagel.com> wrote:

On 26 Oct 2019, at 10:02, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

A new version of RPCEmu is available, 0.9.2

http://www.marutan.net/rpcemu/

Hi Peter

I'm pleased to report that from a Mac point of view, 0.9.2 does compile and run once it's been patched with my previous work from 0.9.1.  I'll issue a revised patch in due course.

Even better, networking works - I can connect to my NAS via !FTPc and use Netsurf to connect to a few web sites.  I did have to write some dummy functions for the various functions in a Mac equivalent "network-linux.c" to get the code to compile.

However, compiling with the "dynarec" option turned on gives an access denied error when you run the emulator (the "mprotect" line in "set_memory_executable" of "ArmDynarec.c").  This is OS X 10.14.6, with the latest software updates.  This looks like an Apple change or something, as previous versions of the emulator did work with dynamic compilation turned on.  It seems to object to PROT_EXEC - no idea why, though reading around suggests it may be something to do with sandboxing.

Tim

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

On Sat, Oct 26, 2019 at 06:28:58PM +0100, Timothy Coltman wrote:
> However, compiling with the "dynarec" option turned on gives an access
> denied error when you run the emulator (the "mprotect" line in
> "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with
> the latest software updates. This looks like an Apple change or
> something, as previous versions of the emulator did work with dynamic
> compilation turned on. It seems to object to PROT_EXEC - no idea why,
> though reading around suggests it may be something to do with sandboxing.

Apple is tightening up the use of code generated at runtime, since code
injection is a common attack pathway. It's not possible to do it at all on
iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap()
and also have the feature enabled at code signing time:
https://github.com/dotnet/coreclr/issues/18617

I think you also need pages RW or RX - macOS has almost no pages that are
RWX and I suspect they want to keep it that way.

Theo

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

On 26 Oct 2019, at 10:02, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

A new version of RPCEmu is available, 0.9.2

http://www.marutan.net/rpcemu/

Hi Peter

I'm pleased to report that from a Mac point of view, 0.9.2 does compile and run once it's been patched with my previous work from 0.9.1.  I'll issue a revised patch in due course.

Even better, networking works - I can connect to my NAS via !FTPc and use Netsurf to connect to a few web sites.  I did have to write some dummy functions for the various functions in a Mac equivalent "network-linux.c" to get the code to compile.

However, compiling with the "dynarec" option turned on gives an access denied error when you run the emulator (the "mprotect" line in "set_memory_executable" of "ArmDynarec.c").  This is OS X 10.14.6, with the latest software updates.  This looks like an Apple change or something, as previous versions of the emulator did work with dynamic compilation turned on.  It seems to object to PROT_EXEC - no idea why, though reading around suggests it may be something to do with sandboxing.

Tim

Re: [Rpcemu] RPCEmu 0.9.2

In article
<CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> A new version of RPCEmu is available, 0.9.2

> http://www.marutan.net/rpcemu/

> Changes in this build

> - Networking
> We have added a new networking mode, Network Address
> Translation, that significantly reduces the effort required to
> setup.

OK, so the RO bit sits behind NAT so does that mean similar rules
apply to the NAT we're all used to ie. you cannot make a connection
from the outside to a machine on the inside? I presume you cannot
even ping the RO machine from the main network.

Connections can be started from the RO protected side but not the
main network so doesn't that mean shareFS can't ever work from the
network?

I hope my understanding is wrong.


Bob.

--
Bob Latham
Stourbridge, West Midlands

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

Le 2019-10-26 16:11, Steffen Huber a écrit :

>
> Anyway, it does not work for me, neither with DHCP

Be sure to remove all options for gateway and DNS server as all is done
with DHCP.

Here, it works well, apart from 'reduce CPU usage' completely broken on
RISC OS 5 and the lack of CallWin32 (it would be useful for so many
things).

RPCEmu is almost perfect now :)

So I could use it as a VM for my apps. No need to make a Windows version
any more. Thanks!

David

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> On Sat, 26 Oct 2019 at 12:48, Steffen Huber <steffen@huber-net.de> wrote:
>
> > Hi Peter,
> >
> > > Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > >
> > >
> > > A new version of RPCEmu is available, 0.9.2
> >
> > The new networking guide refers to files inside HostFS in the Network
> > directory,
>
>
> Only in a section labelled "From version 0.9.1 of RPCEmu the following
> steps are no longer required",
> as such the files arn't included or needed in any version from 0.9.1
> onwards.

Ah sorry, suboptimal reading comprehension on my part :-(

I probably got confused by my RISC OS 4.02 installation not detecting
a networking interface at all, then I read the docs and somehow jumped
to the wrong conclusion (and after extracting AutoSense content from
Mercurial, it DID detect the interface, which was probably even more
confusing looking back now).

Also confusing is that, when coming from the "NAT" instructions, which
is only available since 0.9.2...I just did not expect to read text that
is only relevant for 0.9.1 and previous versions. Now I see that it is
the same page for NAT as well as for bridging networking, which makes
that clear.

Anyway, it does not work for me, neither with DHCP nor fixed IP on a
Windows 10 and RISC OS 4.02 and 5.24 environment. I'll try on Windows 7
later where I have admin rights to configure the Windows networking
stuff.

Thanks
Steffen aka hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

On Sat, 26 Oct 2019 at 12:48, Steffen Huber <steffen@huber-net.de> wrote:

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
>
> A new version of RPCEmu is available, 0.9.2

The new networking guide refers to files inside HostFS in the Network
directory,

Only in a section labelled "From version 0.9.1 of RPCEmu the following steps are no longer required",

as such the files arn't included or needed in any version from 0.9.1 onwards.

 

however the Windows ZIP and the Source tgz only has a ReadMe
file inside. No !System, no Autosense.

If you read the ReadMe it explains it as well.

Peter

Re: [Rpcemu] RPCEmu 0.9.2

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
>
> A new version of RPCEmu is available, 0.9.2

Three smaller niggles (not sure if those were already in 0.9.x or even
0.8.x):
- when changing the Network settings in RPCEmu menu, there is an
immediate reset without user prompt (in contrast to e.g. closing
the emu window)
- when resetting from RISC OS 5.24 (e.g. when doing "Restart" after
Shutdown or when doing "Reset now" after changing Network settings),
there is a fatal error: "Bad PC fc001000 fc001000"
- when changing the Configure settings in RPCEmu menu, user prompt is
centered to the screen, not to the RPCEmu window

Thanks
Steffen aka hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
>
> A new version of RPCEmu is available, 0.9.2

The new networking guide refers to files inside HostFS in the Network
directory, however the Windows ZIP and the Source tgz only has a ReadMe
file inside. No !System, no Autosense.

Steffen aka hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.2

A new version of RPCEmu is available, 0.9.2

http://www.marutan.net/rpcemu/

Changes in this build

- Networking
  We have added a new networking mode, Network Address Translation, that significantly reduces the effort required to setup.

  - Far fewer configuration steps
  - No need to run as root under Linux
  - No need to install and configure TAP drivers under Windows
  - Works with any host network, wired or wireless
  - Allows you to use DHCP in RISC OS for IP address configuration (if the version of RISC OS supports it)
  - RPCEmu and RISC OS configuration does not need to be changed when the host network changes

  Please see the updated network guide for more details; http://www.marutan.net/rpcemu/manual/network.html
  The EtherRPCEm ethernet driver now implements some statistics for frames and errors.

- Floppy Discs

 We now support loading of DOS (.img) and ADFS L format (.adl) disc images into the floppy drives.

- Other fixes

 Fix for crash in RISC OS 6, with 8MB VRAM, in hardware scrolling.

- Windows

 Due to changes in libraries we compile RPCEmu with, RPCEmu is no longer compatible with or tested with

Windows XP or Windows Vista. The minimum version supported is now Windows 7.

  
Matthew Howkins

Peter Howkins

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

On Mon, 21 Oct 2019 at 19:03, Timothy Coltman <lists@maemagel.com> wrote:

On 13 Oct 2019, at 08:56, Richard Torrens (lists) <Lists@Torrens.org> wrote:
>
> In article
> <CANc9Z=wsZhKt9Xm4nzJ5Z3i5aMH971ozanw2FmHAc5-AVRmWGA@mail.gmail.com>,
>   Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>> We have added a third networking mode to RPCEmu that reduces the
>> configuration to just standard RISC OS configuration.
>
> Does this apply to the Mac OS version yet? Is it likely to?
>
> It would be useful, but I have decided I can make do without direct
> network access.

I think it would depend on what the underlying technology is.  If it's still TUN/TAP, as with the current release version, then no.  If it's something like what was discussed a few months ago (SLIRP?), then maybe.  Peter, could you provide some enlightenment on this? 

Yep, it's SLIRP based, in theory it should work on Mac OS. Assuming it's not too different here, I have managed to also get it to work on FreeBSD (as well as Linux/Windows) so it's pretty portable.

Peter

 

Re: "Warning from Netsurf: Unknown"

Tim Hill wrote on 22 Oct:

>> [Jim:] Could the error message be made more informative than just the one
>> word "Unknown" ?

> NS 3.9 correctly says "timeout was reached".

I'm using 3.10 Dev CI #4874, which says only "Unknown".


--
Jim Nagel www.archivemag.co.uk

Re: "Warning from Netsurf: Unknown"

In article <aa90f10658.jim@6.abbeypress.net>, Jim Nagel
<netsurf@abbeypress.co.uk> wrote:
> Daniel Silverstone wrote on 22 Oct:

> > On Tue, Oct 22, 2019 at 11:49:01 +0100, David Pitt wrote:
> >> [INFO netsurf] content/fetchers/curl.c:1189 fetch_curl_done: done
> >> http://www.dalsemi.com/datasheets/appindex.html [INFO netsurf]
> >> content/fetchers/curl.c:1232 fetch_curl_done: Unknown cURL response
> >> code 28

> > This code is CURLE_OPERATION_TIMEDOUT

> Could the error message be made more informative than just the one word
> "Unknown" ?

NS 3.9 correctly says "timeout was reached".

Re: "Warning from Netsurf: Unknown"

Daniel Silverstone wrote on 22 Oct:

> On Tue, Oct 22, 2019 at 11:49:01 +0100, David Pitt wrote:
>> [INFO netsurf] content/fetchers/curl.c:1189 fetch_curl_done: done
>> http://www.dalsemi.com/datasheets/appindex.html
>> [INFO netsurf] content/fetchers/curl.c:1232 fetch_curl_done: Unknown
>> cURL response code 28

> This code is CURLE_OPERATION_TIMEDOUT

Could the error message be made more informative than just the one word
"Unknown" ?

--
Jim Nagel www.archivemag.co.uk

Re: "Warning from Netsurf: Unknown"

On 22 Oct 2019 David Pitt wrote:

> It is on the bug tracker now. The example above is a very broken site,
> neither Safari or Firefox get anywhere with it.

I get the same response after a long wait.

--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.

Re: "Warning from Netsurf: Unknown"

On Tue, Oct 22, 2019 at 11:49:01 +0100, David Pitt wrote:
> [INFO netsurf] content/fetchers/curl.c:1189 fetch_curl_done: done
> http://www.dalsemi.com/datasheets/appindex.html
> [INFO netsurf] content/fetchers/curl.c:1232 fetch_curl_done: Unknown
> cURL response code 28

This code is CURLE_OPERATION_TIMEDOUT

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Re: "Warning from Netsurf: Unknown"

In message <20191022093045.ora74udp2bli5gsc@kyllikki.org>
Vincent Sanders <vince@netsurf-browser.org> wrote:

> On Mon, Oct 21, 2019 at 10:40:17PM +0100, Richard Porter wrote:
>> On 21 Oct 2019 Jim Nagel wrote:
>>
>>> I downloaded Netsurf #4874 today, replacing #4850.
>>
>>> Upon trying to load various websites I get a mysterious error message that
>>> says only "Warning from Netsurf: Unknown". The status line at the bottom
>>> of the Netsurf page also say[INFO netsurf]
>>> content/fetchers/curl.c:1232 fetch_curl_done: Unknown cURL response
>>> code 28
>>
>>> Example: http://www.dalsemi.com/datasheets/appindex.html
>>
>>> I would like to know what this means! I don't recall getting this message
>>> in previous versions of Netsurf. But maybe it's just a bad day today.
>>
>>> Using ArmX6 with Ro 5.25 (Rcomp 2018-apr-25).
>>
>> I have been getting this with 4834 if not earlier. I don't think it's
>> easily repeatable.

> next time either of you see this issue please can you open an issue in
> our tracker (preferably with a log attached) so we can attempt to
> diagnose it.

It is on the bug tracker now. The example above is a very broken site,
neither Safari or Firefox get anywhere with it.

[INFO netsurf] content/fetchers/curl.c:1189 fetch_curl_done: done
http://www.dalsemi.com/datasheets/appindex.html
[INFO netsurf] content/fetchers/curl.c:1232 fetch_curl_done: Unknown
cURL response code 28
[INFO netsurf] content/fetchers/curl.c:1033 fetch_curl_stop: fetch
0x50ef4418, url 'http://www.dalsemi.com/datasheets/appindex.html'
[INFO netsurf] frontends/riscos/gui.c:2112 ro_warn_user: Unknown
(null)
--
David Pitt
Titanium

Re: "Warning from Netsurf: Unknown"

On Mon, Oct 21, 2019 at 10:40:17PM +0100, Richard Porter wrote:
> On 21 Oct 2019 Jim Nagel wrote:
>
> > I downloaded Netsurf #4874 today, replacing #4850.
>
> > Upon trying to load various websites I get a mysterious error message that
> > says only "Warning from Netsurf: Unknown". The status line at the bottom
> > of the Netsurf page also says "Unknown".
>
> > Example: http://www.dalsemi.com/datasheets/appindex.html
>
> > I would like to know what this means! I don't recall getting this message
> > in previous versions of Netsurf. But maybe it's just a bad day today.
>
> > Using ArmX6 with Ro 5.25 (Rcomp 2018-apr-25).
>
> I have been getting this with 4834 if not earlier. I don't think it's
> easily repeatable.

next time either of you see this issue please can you open an issue in
our tracker (preferably with a log attached) so we can attempt to
diagnose it.

--
Regards Vincent

Re: "Warning from Netsurf: Unknown"

On 21 Oct 2019 Jim Nagel wrote:

> I downloaded Netsurf #4874 today, replacing #4850.

> Upon trying to load various websites I get a mysterious error message that
> says only "Warning from Netsurf: Unknown". The status line at the bottom
> of the Netsurf page also says "Unknown".

> Example: http://www.dalsemi.com/datasheets/appindex.html

> I would like to know what this means! I don't recall getting this message
> in previous versions of Netsurf. But maybe it's just a bad day today.

> Using ArmX6 with Ro 5.25 (Rcomp 2018-apr-25).

I have been getting this with 4834 if not earlier. I don't think it's
easily repeatable.


--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

On 13 Oct 2019, at 08:56, Richard Torrens (lists) <Lists@Torrens.org> wrote:
>
> In article
> <CANc9Z=wsZhKt9Xm4nzJ5Z3i5aMH971ozanw2FmHAc5-AVRmWGA@mail.gmail.com>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>> We have added a third networking mode to RPCEmu that reduces the
>> configuration to just standard RISC OS configuration.
>
> Does this apply to the Mac OS version yet? Is it likely to?
>
> It would be useful, but I have decided I can make do without direct
> network access.

I think it would depend on what the underlying technology is. If it's still TUN/TAP, as with the current release version, then no. If it's something like what was discussed a few months ago (SLIRP?), then maybe. Peter, could you provide some enlightenment on this?

I'll probably need to revisit my Mac patches to make sure they work with the next release (unless they're included, of course!), so I'll no doubt have a look at networking as well (though my knowledge of networking on RISC OS is minimal).

Tim



_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

"Warning from Netsurf: Unknown"

I downloaded Netsurf #4874 today, replacing #4850.

Upon trying to load various websites I get a mysterious error message that
says only "Warning from Netsurf: Unknown". The status line at the bottom
of the Netsurf page also says "Unknown".

Example: http://www.dalsemi.com/datasheets/appindex.html

I would like to know what this means! I don't recall getting this message
in previous versions of Netsurf. But maybe it's just a bad day today.

Using ArmX6 with Ro 5.25 (Rcomp 2018-apr-25).


--
Jim Nagel www.archivemag.co.uk

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

In article <DAEBB1E4-C8C8-48A4-AF75-4701181BEB13@headingleyhills.co.uk>,
Chris Johns <chris@headingleyhills.co.uk> wrote:
> I thought about turning an old A3000 board into one years ago. I was going to put it in a box and paint black and yellow stripes on it.

> Bridge Econet - Ethernet .. a BEE :)

Groan.

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

I thought about turning an old A3000 board into one years ago. I was going to put it in a box and paint black and yellow stripes on it.

Bridge Econet - Ethernet .. a BEE :)

Sent from my iPhone

> On 20 Oct 2019, at 19:58, David Glover-Aoki <me@davidglover.org> wrote:
>
> On Oct 14, 2019, at 12:17 AM, Sprow <webpages@sprow.co.uk> wrote:
>>
>> You can send Econet over IP, so no need to emulate the 5 wire balanced line
>> stuff. NetI is the module that does the stuff, it's still there in RISC OS 5,
>> Sprow.
>
> I had a (literal) dream a while ago that someone had made a box with an econet socket on one side and an ethernet socket on the other and that connecting your beeb to it and plugging it into the internet would connect to a kind of central Econet server somewhere on the internet so that everyone in the world who had one was connected to a single global econet network.
>
> Was a nice idea, I thought.
>
> David.
>
>
> _______________________________________________
> RPCEmu mailing list
> RPCEmu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

On Oct 14, 2019, at 12:17 AM, Sprow <webpages@sprow.co.uk> wrote:
>
> You can send Econet over IP, so no need to emulate the 5 wire balanced line
> stuff. NetI is the module that does the stuff, it's still there in RISC OS 5,
> Sprow.

I had a (literal) dream a while ago that someone had made a box with an econet socket on one side and an ethernet socket on the other and that connecting your beeb to it and plugging it into the internet would connect to a kind of central Econet server somewhere on the internet so that everyone in the world who had one was connected to a single global econet network.

Was a nice idea, I thought.

David.


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Furteh to NetSurf bug 0002698

This bug posted by me concerned RISC OS NetSurf not responding to clicking
on a URL when UniServer was running. It was agreed that it probably wasn't
primarily a NetSurf problem.

However, for the last few test builds NetSurf does once again respond to
these clicks. "These are deep matters, Wilson"!

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

On Mon, 14 Oct 2019, at 08:17, Sprow wrote:
> In article <01fea574-c85a-43bf-82b2-d4561a993a99@www.fastmail.com>, Richard
> Walker <richardwalker@letterboxes.org> wrote:
> >
> > And even further down my crazy line of thought, add emulation of the Econet
> > interface? Mind you, not sure what you would actually join that up to, as
> > real Econet interfaces in Linux/macOS/Windows are not exactly common...
>
> You can send Econet over IP, so no need to emulate the 5 wire balanced line
> stuff. NetI is the module that does the stuff, it's still there in RISC OS 5.

True, I suppose that would connect you to another Ethernet-connected Net service such as Level 4 file server.

I guess it is things like an MDFS or FileStore that need the classic interface (or perhaps messing about with the GateWay app, I cannot remember!).



--
Richard Walker
richardwalker@letterboxes.org

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] gccsdk on arm

Den lör 19 okt. 2019 19:41David Pitt <pittdj@pittdj.co.uk> skrev:

In message <57e4fa80cdchrisg@care4free.net>
  Chris Gransden <chrisg@care4free.net> wrote:

> In article <f4ba7be457.mickenx@michael.grunditz.gmail.com>,
>    Michael Grunditz <michael.grunditz@gmail.com> wrote:
>> Hi

>> I wonder if it is possible to build and use gccsdk on ARM Linux?
>> I would love to do so. My PC does heat up the room :)

> It builds successfully on a Raspberry Pi4 using Debian Buster (aarch32)
> making the below change after the initial build fails,

> Change line 2227 in srcdir.orig/gcc-trunk/gcc/config/arm/arm.h from 'if
> defined(__arm__)' to 'if !defined(__arm__)'.

Thanks for the above tip, the autobuilder and !GCC, svnversion 7267,
have been built on a RPi4.

The resulting !GCC build ran on the Titanium but not on the RPI3B+
where it failed initially with "SWI &59D00 not found", until the new
ARMEABISupport in 500.Modules was found. OK now.


--
David Pitt
Titanium

The problem for me was that it didn't build owb. So I sold the pi4 same day!

Re: [gccsdk] gccsdk on arm

In message <57e4fa80cdchrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

> In article <f4ba7be457.mickenx@michael.grunditz.gmail.com>,
> Michael Grunditz <michael.grunditz@gmail.com> wrote:
>> Hi

>> I wonder if it is possible to build and use gccsdk on ARM Linux?
>> I would love to do so. My PC does heat up the room :)

> It builds successfully on a Raspberry Pi4 using Debian Buster (aarch32)
> making the below change after the initial build fails,

> Change line 2227 in srcdir.orig/gcc-trunk/gcc/config/arm/arm.h from 'if
> defined(__arm__)' to 'if !defined(__arm__)'.

Thanks for the above tip, the autobuilder and !GCC, svnversion 7267,
have been built on a RPi4.

The resulting !GCC build ran on the Titanium but not on the RPI3B+
where it failed initially with "SWI &59D00 not found", until the new
ARMEABISupport in 500.Modules was found. OK now.


--
David Pitt
Titanium

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

In article <01fea574-c85a-43bf-82b2-d4561a993a99@www.fastmail.com>, Richard
Walker <richardwalker@letterboxes.org> wrote:
> On Sat, 12 Oct 2019, at 19:28, Peter Howkins wrote:
> > For example, turn on 'Network Address Translation' in the RPCEmu
> > Networking GUI
>
> And even further down my crazy line of thought, add emulation of the Econet
> interface? Mind you, not sure what you would actually join that up to, as
> real Econet interfaces in Linux/macOS/Windows are not exactly common...

You can send Econet over IP, so no need to emulate the 5 wire balanced line
stuff. NetI is the module that does the stuff, it's still there in RISC OS 5,
Sprow.


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

On Sat, 12 Oct 2019, at 19:28, Peter Howkins wrote:

For example, turn on 'Network Address Translation' in the RPCEmu Networking

GUI, then in RISC OS select 'DHCP' (or fill in 3 IP addresses if you're

using an earlier version of RISC OS) and it is working.

That does sound cute.  Congrats.

So you've provided a virtual network which includes a DHCP response?  Cunning.

I wonder if you could ever have crazy stuff, like run two instances or RPCEmu, with both seeing each other's virtual network?

And even further down my crazy line of thought, add emulation of the Econet interface?  Mind you, not sure what you would actually join that up to, as real Econet interfaces in Linux/macOS/Windows are not exactly common...

-- 

  Richard Walker

  richardwalker@letterboxes.org

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

In article
<CANc9Z=wsZhKt9Xm4nzJ5Z3i5aMH971ozanw2FmHAc5-AVRmWGA@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> We have added a third networking mode to RPCEmu that reduces the
> configuration to just standard RISC OS configuration.

Does this apply to the Mac OS version yet? Is it likely to?

It would be useful, but I have decided I can make do without direct
network access.

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

In article
<CANc9Z=wsZhKt9Xm4nzJ5Z3i5aMH971ozanw2FmHAc5-AVRmWGA@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:

[Snip]

> We have added a third networking mode to RPCEmu that reduces the
> configuration to just standard RISC OS configuration.

> For example, turn on 'Network Address Translation' in the RPCEmu
> Networking GUI, then in RISC OS select 'DHCP' (or fill in 3 IP addresses
> if you're using an earlier version of RISC OS) and it is working.

[Snip]

Oh! Miracles do sometimes happen. :-)
Well done guys... kudos!

Dave

--

Dave Triffid

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

Le 2019-10-12 20:28, Peter Howkins a écrit :
> GUI, then in RISC OS select 'DHCP' (or fill in 3 IP addresses
> if you're using an earlier version of RISC OS) and it is
> working.

Just one word: THANKS!

David

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

At the forthcoming RISC OS Show in Feltham London, RPCEmu will be having a
stand.
We'll be demonstrating the latest updates and showing off a new easier
networking solution.

Come along and say hello.

http://riscoslondonshow.co.uk/

Peter Howkins
Matthew Howkins


What is easier networking?

We have added a third networking mode to RPCEmu that reduces the
configuration to just standard RISC OS configuration.

For example, turn on 'Network Address Translation' in the RPCEmu Networking
GUI, then in RISC OS select 'DHCP' (or fill in 3 IP addresses if you're
using an earlier version of RISC OS) and it is working.

On Windows this removes any need to install the TAP driver, and its
complicated configuration and need for typing in commands at the Windows
command-line. On Linux it removes the complicated configuration of the ip

forwarding rules and the need to run the binary as root or using sudo.

[PATCH] libnsfb: DirectFB port

Hi all,

DirectFB may belong to the past, but here is a patch for people still
interested in using it.
A screenshot with NetSurf running directly on top of DirectFB is available on
the HiGFXback (History of graphics backends) project.

Nicolas Caramelli

diff --git a/Makefile b/Makefile
index dd6bbac..9c4d73b 100644
--- a/Makefile
+++ b/Makefile
@@ -44,11 +44,19 @@ NSFB_XCB_PKG_NAMES := xcb xcb-icccm xcb-image
xcb-keysyms xcb-atom

# determine which surface handlers can be compiled based upon avalable library
$(eval $(call pkg_config_package_available,NSFB_VNC_AVAILABLE,libvncserver))
+$(eval $(call pkg_config_package_available,NSFB_DIRECTFB_AVAILABLE,directfb))
$(eval $(call pkg_config_package_available,NSFB_SDL_AVAILABLE,sdl))
$(eval $(call pkg_config_package_available,NSFB_XCB_AVAILABLE,$(NSFB_XCB_PKG_NAMES)))
$(eval $(call pkg_config_package_available,NSFB_WLD_AVAILABLE,wayland-client))

# Flags and setup for each support library
+ifeq ($(NSFB_DIRECTFB_AVAILABLE),yes)
+ $(eval $(call pkg_config_package_add_flags,directfb,CFLAGS,LDFLAGS))
+ $(eval $(call pkg_config_package_add_flags,directfb,TESTCFLAGS,TESTLDFLAGS))
+
+ REQUIRED_PKGS := $(REQUIRED_PKGS) directfb
+endif
+
ifeq ($(NSFB_SDL_AVAILABLE),yes)
$(eval $(call pkg_config_package_add_flags,sdl,CFLAGS))
$(eval $(call pkg_config_package_add_flags,sdl,TESTCFLAGS,TESTLDFLAGS))
diff --git a/README b/README
index b4a1685..d4a3820 100644
--- a/README
+++ b/README
@@ -18,6 +18,7 @@ Requirements

The following libraries may also be installed:

+ + DirectFB (for the DirectFB surface)
+ SDL 1.2 (for the SDL surface)
+ libxcb* (for the X11 surface)
* wayland-client (for wayland surface)
diff --git a/include/libnsfb.h b/include/libnsfb.h
index dfb720c..9aec3dd 100644
--- a/include/libnsfb.h
+++ b/include/libnsfb.h
@@ -36,6 +36,7 @@ typedef struct nsfb_bbox_s {
enum nsfb_type_e {
NSFB_SURFACE_NONE = 0, /**< No surface */
NSFB_SURFACE_RAM, /**< RAM surface */
+ NSFB_SURFACE_DIRECTFB, /**< DirectFB surface */
NSFB_SURFACE_SDL, /**< SDL surface */
NSFB_SURFACE_LINUX, /**< Linux framebuffer surface */
NSFB_SURFACE_VNC, /**< VNC surface */
diff --git a/src/surface/Makefile b/src/surface/Makefile
index 848c3d4..d35d1cc 100644
--- a/src/surface/Makefile
+++ b/src/surface/Makefile
@@ -4,6 +4,7 @@
SURFACE_HANDLER_yes := surface.c ram.c

# optional surface handlers
+SURFACE_HANDLER_$(NSFB_DIRECTFB_AVAILABLE) += directfb.c
SURFACE_HANDLER_$(NSFB_SDL_AVAILABLE) += sdl.c
SURFACE_HANDLER_$(NSFB_XCB_AVAILABLE) += x.c
SURFACE_HANDLER_$(NSFB_VNC_AVAILABLE) += vnc.c
diff --git a/src/surface/directfb.c b/src/surface/directfb.c
new file mode 100644
index 0000000..4a108a0
--- /dev/null
+++ b/src/surface/directfb.c
@@ -0,0 +1,259 @@
+/*
+ * Copyright 2019 Nicolas Caramelli
+ *
+ * This file is part of libnsfb, http://www.netsurf-browser.org/
+ * Licenced under the MIT License,
+ * http://www.opensource.org/licenses/mit-license.php
+ */
+
+#include <directfb.h>
+
+#include "libnsfb.h"
+#include "libnsfb_event.h"
+
+#include "surface.h"
+#include "plot.h"
+
+typedef struct directfb_priv_s {
+ IDirectFB *dfb;
+ IDirectFBDisplayLayer *layer;
+ IDirectFBWindow *window;
+ IDirectFBSurface *surface;
+ IDirectFBEventBuffer *buffer;
+} directfb_priv_t;
+
+static int directfb_set_geometry(nsfb_t *nsfb, int width, int height,
+ enum nsfb_format_e format)
+{
+ if (nsfb->surface_priv != NULL) {
+ return -1;
+ }
+
+ nsfb->width = width;
+ nsfb->height = height;
+ if (format != NSFB_FMT_XRGB8888) {
+ return -1;
+ }
+
+ select_plotters(nsfb);
+
+ return 0;
+}
+
+static int directfb_initialise(nsfb_t *nsfb)
+{
+ directfb_priv_t *directfb_priv;
+ int ret = DFB_OK;
+ DFBWindowDescription desc;
+
+ if (nsfb->surface_priv != NULL) {
+ return -1;
+ }
+
+ directfb_priv = calloc(1, sizeof(directfb_priv_t));
+ if (directfb_priv == NULL) {
+ fprintf(stderr, "DirectFB private data allocation failed\n");
+ return -1;
+ }
+
+ ret = DirectFBInit(NULL, NULL);
+ if (ret) {
+ fprintf(stderr, "DirectFBInit failed: %s\n", DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = DirectFBCreate(&directfb_priv->dfb);
+ if (ret) {
+ fprintf(stderr, "DirectFBCreate failed: %s\n",
+ DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = directfb_priv->dfb->GetDisplayLayer(directfb_priv->dfb, DLID_PRIMARY,
+ &directfb_priv->layer);
+ if (ret) {
+ fprintf(stderr, "GetDisplayLayer failed: %s\n",
+ DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ desc.flags = DWDESC_WIDTH | DWDESC_HEIGHT | DSDESC_PIXELFORMAT;
+ desc.width = nsfb->width;
+ desc.height = nsfb->height;
+ desc.pixelformat = DSPF_ARGB;
+ ret = directfb_priv->layer->CreateWindow(directfb_priv->layer, &desc,
+ &directfb_priv->window);
+ if (ret) {
+ fprintf(stderr, "CreateWindow failed: %s\n", DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = directfb_priv->window->GetSurface(directfb_priv->window,
+ &directfb_priv->surface);
+ if (ret) {
+ fprintf(stderr, "GetSurface failed: %s\n", DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = directfb_priv->surface->Lock(directfb_priv->surface, DSLF_WRITE,
+ (void **)&nsfb->ptr, &nsfb->linelen);
+ if (ret) {
+ fprintf(stderr, "Lock failed: %s\n", DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = directfb_priv->surface->Unlock(directfb_priv->surface);
+ if (ret) {
+ fprintf(stderr, "Unlock failed: %s\n", DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = directfb_priv->window->CreateEventBuffer(directfb_priv->window,
+ &directfb_priv->buffer);
+ if (ret) {
+ fprintf(stderr, "CreateEventBuffer failed: %s\n",
+ DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ ret = directfb_priv->window->SetOpacity(directfb_priv->window, 0xff);
+ if (ret) {
+ fprintf(stderr, "SetOpacity failed: %s\n", DirectFBErrorString(ret));
+ goto fail;
+ }
+
+ nsfb->surface_priv = directfb_priv;
+
+ return 0;
+
+fail:
+ if (directfb_priv->buffer)
+ directfb_priv->buffer->Release(directfb_priv->buffer);
+ if (directfb_priv->surface)
+ directfb_priv->surface->Release(directfb_priv->surface);
+ if (directfb_priv->window)
+ directfb_priv->window->Release(directfb_priv->window);
+ if (directfb_priv->layer)
+ directfb_priv->layer->Release(directfb_priv->layer);
+ if (directfb_priv->dfb)
+ directfb_priv->dfb->Release(directfb_priv->dfb);
+ free(directfb_priv);
+ return -1;
+}
+
+static int directfb_finalise(nsfb_t *nsfb)
+{
+ directfb_priv_t *directfb_priv = nsfb->surface_priv;
+
+ if (directfb_priv == NULL) {
+ return 0;
+ }
+
+ directfb_priv->buffer->Release(directfb_priv->buffer);
+ directfb_priv->surface->Release(directfb_priv->surface);
+ directfb_priv->window->Release(directfb_priv->window);
+ directfb_priv->layer->Release(directfb_priv->layer);
+ directfb_priv->dfb->Release(directfb_priv->dfb);
+ free(directfb_priv);
+
+ return 0;
+}
+
+static bool directfb_input(nsfb_t *nsfb, nsfb_event_t *event, int timeout)
+{
+ directfb_priv_t *directfb_priv = nsfb->surface_priv;
+ int ret = DFB_OK;
+ DFBWindowEvent dfb_event;
+
+ if (directfb_priv == NULL) {
+ return false;
+ }
+
+ ret = directfb_priv->buffer->WaitForEventWithTimeout(directfb_priv->buffer,
+ timeout / 1000,
+ timeout % 1000);
+ if (ret == DFB_TIMEOUT) {
+ event->type = NSFB_EVENT_CONTROL;
+ event->value.controlcode = NSFB_CONTROL_TIMEOUT;
+ return true;
+ }
+
+ directfb_priv->buffer->GetEvent(directfb_priv->buffer,
+ (DFBEvent *)&dfb_event);
+
+ if (dfb_event.type == DWET_KEYDOWN) {
+ event->type = NSFB_EVENT_KEY_DOWN;
+ event->value.keycode = dfb_event.key_symbol;
+ } else if (dfb_event.type == DWET_KEYUP) {
+ event->type = NSFB_EVENT_KEY_UP;
+ event->value.keycode = dfb_event.key_symbol;
+ } else if (dfb_event.type == DWET_BUTTONDOWN) {
+ event->type = NSFB_EVENT_KEY_DOWN;
+ switch (dfb_event.button) {
+ case DIBI_LEFT:
+ event->value.keycode = NSFB_KEY_MOUSE_1;
+ break;
+ case DIBI_MIDDLE:
+ event->value.keycode = NSFB_KEY_MOUSE_2;
+ break;
+ case DIBI_RIGHT:
+ event->value.keycode = NSFB_KEY_MOUSE_3;
+ break;
+ default:
+ break;
+ }
+ } else if (dfb_event.type == DWET_BUTTONUP) {
+ event->type = NSFB_EVENT_KEY_UP;
+ switch (dfb_event.button) {
+ case DIBI_LEFT:
+ event->value.keycode = NSFB_KEY_MOUSE_1;
+ break;
+ case DIBI_MIDDLE:
+ event->value.keycode = NSFB_KEY_MOUSE_2;
+ break;
+ case DIBI_RIGHT:
+ event->value.keycode = NSFB_KEY_MOUSE_3;
+ break;
+ default:
+ break;
+ }
+ } else if (dfb_event.type == DWET_MOTION) {
+ event->type = NSFB_EVENT_MOVE_ABSOLUTE;
+ event->value.vector.x = dfb_event.x;
+ event->value.vector.y = dfb_event.y;
+ event->value.vector.z = 0;
+ } else {
+ event->type = NSFB_EVENT_NONE;
+ }
+
+ return true;
+}
+
+static int directfb_update(nsfb_t *nsfb, nsfb_bbox_t *box)
+{
+ directfb_priv_t *directfb_priv = nsfb->surface_priv;
+
+ if (directfb_priv != NULL) {
+ directfb_priv->surface->Flip(directfb_priv->surface,
+ (DFBRegion *)box, DSFLIP_WAITFORSYNC);
+ }
+
+ return 0;
+}
+
+const nsfb_surface_rtns_t directfb_rtns = {
+ .geometry = directfb_set_geometry,
+ .initialise = directfb_initialise,
+ .finalise = directfb_finalise,
+ .input = directfb_input,
+ .update = directfb_update,
+};
+
+NSFB_SURFACE_DEF(directfb, NSFB_SURFACE_DIRECTFB, &directfb_rtns)
+
+/*
+ * Local variables:
+ * c-basic-offset: 4
+ * tab-width: 8
+ * End:
+ */

Re: [Rpcemu] RPCEmu Windows XP and Windows Vista support

On Fri, 4 Oct 2019 at 17:46, Steffen Huber <steffen@huber-net.de> wrote:

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> Due to needing to remain on a supported version of a library that we use to
> build RPCEmu, future releases of RPCEmu will no longer support Windows XP or
> Windows Vista. We will continue to support the Windows 7, 8 and 10 families.

Could you go a bit further into the details? Which library? Something big
like Qt, or something small where alternatives could be found? Last time
I looked, RPCEmu did not really have much dependencies beyond the main
toolkit (previously Allegro, now Qt).

It is QT, the previous Long Term Support version we were using, 5.6, has now reached end of life. So I've moved to using the next Long Term Support one, 5.9.

Peter

Re: [Rpcemu] RPCEmu Windows XP and Windows Vista support

Hi Peter,

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> Due to needing to remain on a supported version of a library that we use to
> build RPCEmu, future releases of RPCEmu will no longer support Windows XP or
> Windows Vista. We will continue to support the Windows 7, 8 and 10 families.

Could you go a bit further into the details? Which library? Something big
like Qt, or something small where alternatives could be found? Last time
I looked, RPCEmu did not really have much dependencies beyond the main
toolkit (previously Allegro, now Qt).

I happen to have use cases for emulators on Windows XP (old laptops
with true floppy drives where necessary drivers for newer Windows
versions are not available). This is not of ultimate importance
because those use cases are catered for with other emus and old
versions just fine. So just asking.

Have fun
hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu Windows XP and Windows Vista support

Dropping support for such out-dated and insecure operating systems can only be a good thing. If anyone has a machine that can't handle Win7 at least then it probably won't run RPCEmu very well anyway. Good to hear it's still being developed!

On Thu, Oct 3, 2019 at 10:38 PM Peter Howkins <rpcemu.howkins@marutan.net> wrote:

Due to needing to remain on a supported version of a library that we use to
build RPCEmu, future releases of RPCEmu will no longer support Windows XP or
Windows Vista. We will continue to support the Windows 7, 8 and 10 families.

What does this mean in detail?

1) All releases of RPCEmu so far released that do support Windows XP and
Vista will continue to run as they do currently. There is no magic code that
will disable old versions.

2) Previous versions of RPCEmu will continue to be available via the previous
versions page, probably indefinitely.
 http://www.marutan.net/rpcemu/oldversions.html

3) Future Windows versions of RPCEmu will not be supported on Windows XP and
Vista. While it is theoretically possible they may still work, they will no
longer be tested, may partially work or fail in 'interesting' ways.

4) Bugs that are reported against previous versions on Windows XP and Vista,
that are not also present in the current, will not be investigated.

5) Bugs that are reported against previous versions on Windows XP and Vista,
that are present in the current version, will be investigated but the fixes
will come out in releases that are not compatible with Windows XP or Vista.

6) All good things come to an end, whilst we may be dropping support for
these older OSs, it is still 5 years more support than Microsoft gave the OS

itself.

Peter Howkins

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu Windows XP and Windows Vista support

Due to needing to remain on a supported version of a library that we use to
build RPCEmu, future releases of RPCEmu will no longer support Windows XP or
Windows Vista. We will continue to support the Windows 7, 8 and 10 families.

What does this mean in detail?

1) All releases of RPCEmu so far released that do support Windows XP and
Vista will continue to run as they do currently. There is no magic code that
will disable old versions.

2) Previous versions of RPCEmu will continue to be available via the previous
versions page, probably indefinitely.
 http://www.marutan.net/rpcemu/oldversions.html

3) Future Windows versions of RPCEmu will not be supported on Windows XP and
Vista. While it is theoretically possible they may still work, they will no
longer be tested, may partially work or fail in 'interesting' ways.

4) Bugs that are reported against previous versions on Windows XP and Vista,
that are not also present in the current, will not be investigated.

5) Bugs that are reported against previous versions on Windows XP and Vista,
that are present in the current version, will be investigated but the fixes
will come out in releases that are not compatible with Windows XP or Vista.

6) All good things come to an end, whilst we may be dropping support for
these older OSs, it is still 5 years more support than Microsoft gave the OS

itself.

Peter Howkins