Wednesday, 29 May 2019

SSL3 and TLS in NetSurf3.8

New to Netsurf using version 3.8

At Qualys dot com I checked the Client Side. It states that there is SSL3, TLS1.0, and TLS1.1 encryption available/enabled.

Is netsurf packaging these in the browser, or is it tapping my version of OpenSSL (v. 1.0.2p)

MHO is that these 3 encryption suites be removed as a security request.
What should be included is TLS1.2 (forward secrecy) and option for TLS1.3
perhaps NS3.9 can accomplish this.

Thanks for a very fast and basic browser, I even found a YouTube download site that works with NS3.8.

Regards
Paul S.

Tuesday, 28 May 2019

Re: [gccsdk] Updated SDL recipes

On Tue, 28 May 2019, alan buckley wrote:

> On 27/05/2019 22:12, Jeffrey Lee wrote:
>
>> FYI I'm currently working on a couple of SDL patches of my own (adding
>> support for red/blue swapped screen modes, and a mouse handling fix)
>> which I'll hopefully get submitted to the SDL team sometime in the
>> next few days.
> Will the red/blue swapping fix 16 bit modes as well?

The lack of support for them (64K colour modes), or is there an actual bug
on some machines/OS versions which causes corrupt rendering or similar?

So far I've got red/blue swapped and 64K colour full screen modes working,
but there's more to do in terms of detecting support & windowed output.

Cheers,

- Jeffrey

_______________________________________________
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: [gccsdk] Updated SDL recipes

On 27/05/2019 22:12, Jeffrey Lee wrote:

> FYI I'm currently working on a couple of SDL patches of my own (adding
> support for red/blue swapped screen modes, and a mouse handling fix)
> which I'll hopefully get submitted to the SDL team sometime in the
> next few days.
Will the red/blue swapping fix 16 bit modes as well?
>
> Since the SDL team appear to be a bit slow in accepting our patches,
> I'm thinking that we should add all the of the outstanding ones to the
> autobuilder recipe. I can easily do that once I've tidied/finished my
> current patches.
I agree with this. We can take them out again once upstream catches up.
> (I'm also half in the mind that we should set up our own fork of the
> SDL repository on bitbucket or similar, but that would be a bit of a
> waste if we only make a couple more changes before suddenly stopping
> and leaving the code untouched for another few years)
>
I don't think we need this as we only ever seem to get a few flurries of
activity now and again.

> Cheers,
>
> - Jeffrey
Regards,
Alan
_______________________________________________
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

Monday, 27 May 2019

Re: [gccsdk] Updated SDL recipes

FYI I'm currently working on a couple of SDL patches of my own (adding
support for red/blue swapped screen modes, and a mouse handling fix) which
I'll hopefully get submitted to the SDL team sometime in the next few
days.

Since the SDL team appear to be a bit slow in accepting our patches, I'm
thinking that we should add all the of the outstanding ones to the
autobuilder recipe. I can easily do that once I've tidied/finished my
current patches.

(I'm also half in the mind that we should set up our own fork of the SDL
repository on bitbucket or similar, but that would be a bit of a waste if
we only make a couple more changes before suddenly stopping and leaving
the code untouched for another few years)

Cheers,

- Jeffrey


_______________________________________________
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

Saturday, 25 May 2019

Re: [gccsdk] SimpleGit

For anyone keeping track of this thread, I've just submitted an updated
recipe that improves file handling (",xxx" suffixes are now used where
appropriate, and image files are treated as directories to allow them to
be stored in git), and fixes a few bugs/limitations in simplegit itself.

Using this new version it's now possible to correctly checkout entire
products from ROOL's gitlab server (https://gitlab.riscosopen.org/) -
e.g.:

set UnixEnv$sgit$sfix ""
sgit clone https://gitlab.riscosopen.org/Products/Disc.git Disc
dir Disc
sgit submodule init
sgit submodule update

(However note that "sgit status" will report a few differences due to some
files having asymmetric filename translation, because of redundant ",xxx"
suffixes)

I've uploaded a build of the package to my site if people want to try it
out:

http://www.phlamethrower.co.uk/misc2/simplegit-libgit2_639-4.zip

If there aren't any major issues discovered over the next few days, it
would be good to have the package in riscos.info updated, as the ability
to store filetypes using ,xxx suffixes is a big step forward for using git
for RISC OS projects (I would have enabled it earlier if I'd realised that
UnixLib had support for it built-in!)

Cheers,

- Jeffrey


_______________________________________________
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

Monday, 20 May 2019

[Rpcemu] Patch to implement power-off via Portable_CommandBMU

diff -r 65e3e8e126e5 src/arm_common.c
--- a/src/arm_common.c Wed Oct 24 17:24:45 2018 +0100
+++ b/src/arm_common.c Mon May 20 20:34:55 2019 +0100
@@ -40,6 +40,7 @@
#define SWI_OS_CallASWI 0x6f
#define SWI_OS_CallASWIR12 0x71

+#define SWI_Portable_CommandBMU 0x42fc4
#define SWI_Portable_ReadFeatures 0x42fc5
#define SWI_Portable_Idle 0x42fc6

@@ -362,6 +363,12 @@
swinum = arm.reg[12] & 0xdffff;
}

+ /* Intercept Portable_CommandBMU to turn off */
+ if (swinum == SWI_Portable_CommandBMU) {
+ if (arm.reg[0] == 1) /* Remove power */
+ exit(0); // FIXME
+ }
+
/* Intercept RISC OS Portable SWIs to enable RPCEmu to sleep when
RISC OS is idle */
if (config.cpu_idle) {
Following Peter Howkins's suggestion, here attached is part one of support for powering off from inside the emulator: an implementation of Portable_CommandBMU with R0=1 (= remove power).

I couldn't work out how to exit the emulator cleanly. As far as I can see that is only currently done from the front end. I tried setting quited = 1, but the emulator freezes and then crashes a little while later.

For testing purposes therefore I simply call exit(0); if someone could let me know what I should be doing, I'd be most grateful!

--

Saturday, 18 May 2019

Re: Something went wrong with the layout engine between 4630 and 4631

On Tue, 14 May 2019 at 21:18, David Higton <dave@davehigton.me.uk> wrote:
Hi guys,

Try http://www.bbc.co.uk/news/ with versions 4630 and 4631.  Notice a
big difference?  There certainly is with the RISC OS version, and I
somehow expect it to be platform-independent.

We now handle media queries, so, because your window is wide enough,
you're getting a desktop rendering of the site now, rather than the mobile
version.

Unfortunately the page does complicated stuff with JavaScript for no
apparent reason.  Line 502 of the page source has a

<script type="text/css" id="nw-c-navigation-enhanced-css">
...
</script>

section which actually contains CSS, rather than a script.

This CSS is needed to make the page get laid out correctly.

At line 504, there's an actual JavaScript script that extracts
the aforementioned script tag's CSS content and reinserts it
into the DOM as a style element.

NetSurf doesn't handle enough JavaScript to do all these
shenanigans yet.

Cheers,

Michael

Tuesday, 14 May 2019

Something went wrong with the layout engine between 4630 and 4631

Hi guys,

Try http://www.bbc.co.uk/news/ with versions 4630 and 4631. Notice a
big difference? There certainly is with the RISC OS version, and I
somehow expect it to be platform-independent.

4631 and onwards to current (4640 as I type this) all show the same
problem.

Dave

Re: [Rpcemu] MacOS builds

On 14/05/2019, 12:51, "tim@powys.org" <rpcemu-bounces@riscos.info on behalf of tim@powys.org> wrote:

> Has anyone got RISC OS 5.24 going? Sounds like a third step for me.

Nope - I've got RISC OS 5.27 running on it instead.

Cheers,

Gerald.




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

Re: [Rpcemu] MacOS builds

> On 6 May 2019, at 11:29 pm, Phillip Pearson <pp@myelin.nz> wrote:
>
> Great! That makes four of us who are running this binary now.
>
> If you spot any bugs, please report them at
> https://github.com/myelin/rpcemu-macos/issues (if they're not already
> there -- Matt/gingerbeardman has reported a bunch already.)
>
> Once we've been trying it out for a bit, maybe this (or a link to it)
> could go up on the "contributed builds" section of the homepage.
>
> Thanks!
> Phil
>
> On Mon, May 6, 2019 at 8:22 AM Peter Moore <petemoore@gmx.net> wrote:
>>
>> This is great! I was able to successfully install on my Mac.
>>
>> Many thanks!
>

And it is now at least five running this binary. I got it going last night after a fair struggle to remember how to get the Utilities including Boot disc onto hostfs. I must write down what I did (50 times).

What a delightful surprise yesterday when I decided to catch up on all my mailing lists.

Many thanks to Philip for the binary and Timothy for the patch.

This is on MacOS 10.14.3. Running RISC OS 5.22 with 128M of RAM, 2M of video RAM and 60 frames/sec for a screen of 1024x768 gives a steady average MIPS of 140 odd. For comparison VRPC on the same machine, but located on SSD and running at 24 frames per sec for a screen of 1680 x 1050, peaks at 300 MIPS but dips to 10 or so and shows no average figure.

Next step will be to see what I can do for MacOS networking. And to see what happens on a portable Mac.

Has anyone got RISC OS 5.24 going? Sounds like a third step for me.

--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/


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

Saturday, 11 May 2019

[Rpcemu] Revised Mac patch for 0.9.1

Hello all

Following Philip Pearson's recent post about MacOS builds, I've revised my Mac patch from a few months ago to fix a number of the issues found when testing.  These issues can be found on Philip's github:


Attached is a ZIP file containing the revised patch.  The same provisos and instructions for building apply as last time (see my message dates 19/11/2018 in the mailing list archives).

The patch fixes the following issues:

* "No way to click menu/middle button" (#8).  When the two button mouse is turned on in the "Settings" menu, the "Command" key on the keyboard now mimics the "Menu" mouse buttons.  The left and right mouse buttons perform their normal functions - "Select" and "Adjust" respectively.
* "Hard crash on quit" (#9).  This will probably affect other platforms as well and only rears its ugly head if you move the mouse around furiously after clicking to confirm you want to quit.
* "MBP Control-FN-right" doesn't exit full screen mode" (#12).  This was a keyboard issue I missed last time around because I don't use full screen mode.  This should now be detected properly.

As before, any comments and suggestions are welcomed.

Tim

Monday, 6 May 2019

Re: [Rpcemu] MacOS builds

Great! That makes four of us who are running this binary now.

If you spot any bugs, please report them at
https://github.com/myelin/rpcemu-macos/issues (if they're not already
there -- Matt/gingerbeardman has reported a bunch already.)

Once we've been trying it out for a bit, maybe this (or a link to it)
could go up on the "contributed builds" section of the homepage.

Thanks!
Phil

On Mon, May 6, 2019 at 8:22 AM Peter Moore <petemoore@gmx.net> wrote:
>
> This is great! I was able to successfully install on my Mac.
>
> Many thanks!

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

Re: [Rpcemu] MacOS builds

This is great! I was able to successfully install on my Mac.

Many thanks!

On 6. May 2019, at 16:23, Phillip Pearson <pp@myelin.nz> wrote:

Hi,

I've been using RPCEmu on macOS for a while now, mainly to rebuild RISC OS with fewer modules so I can use it as a bootloader on another project[1].

I pushed my local source tree, consisting of RPCEmu 0.9.1 and Timothy Coltman's macOS patches, up to GitHub (https://github.com/myelin/rpcemu-macos) a while ago.

I just got around to pushing some binary builds, after gingerbeardman on GitHub asked[2]; if anyone is interested in trying out a prebuilt macOS RPCEmu 0.9.1 binary, here are mine:


Cheers,
Phil

[1] http://myelin.nz/arcflash -- flash ROM emulator for Arc/RPC machines


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

[Rpcemu] MacOS builds

Hi,

I've been using RPCEmu on macOS for a while now, mainly to rebuild RISC OS with fewer modules so I can use it as a bootloader on another project[1].

I pushed my local source tree, consisting of RPCEmu 0.9.1 and Timothy Coltman's macOS patches, up to GitHub (https://github.com/myelin/rpcemu-macos) a while ago.

I just got around to pushing some binary builds, after gingerbeardman on GitHub asked[2]; if anyone is interested in trying out a prebuilt macOS RPCEmu 0.9.1 binary, here are mine:


Cheers,
Phil

[1] http://myelin.nz/arcflash -- flash ROM emulator for Arc/RPC machines


Saturday, 4 May 2019

4587 onwards fail to render the ROOL site correctly

CI versions up to 4585 render the ROOL site correctly, 4587 onwards
don't, in the RISC OS versions at least. How about builds for
other platforms?

https://www.riscosopen.org/forum/

David Higton