SMB2/3 protocol

The ROD stack is open source and based on the OpenBSD both Mbuf and resolver are open source, it can do IPv4 and IPv6.

The ROD stack is open source and based on the OpenBSD both Mbuf and resolver are open source, it can do IPv4 and IPv6.

But none of that work as been merged in the ROOL repository, hence my warning to Jake that as he will modify MBuf, there is a risk of creating incompatibilities. Frankly, that ROD vs ROOL split is starting to look like it will turn into a mess.

The code I believe was offered to ROOL, but they seem to want to waste time/money on doing another stack based on NetBSD rather then use a new one already developed and working. It just seems very wasteful of resources by ROOL when we have so few developers, the money could have been diverted into Bluetooth work for instance or even helping the person(s) working on the ROD stack, to get Wi-Fi work finished quicker, etc.. i.e. working together

The code I believe was offered to ROOL, but they seem to want to waste time/money on doing another stack based on NetBSD rather then use a new one already developed and working.

That, however, is totally irrelevant to the point that André is making.

It’s also possible to question the narrative, given the information published in the May/June issue of Archive.

the money could have been diverted into Bluetooth work for instance

Not if people donated it to the network stack bounty, it couldn’t. It could have been distributed across all bounties, if it hadn’t been claimed, but again, given what was said in Archive, that might not apply if the bounty was already being worked on by someone with ROOL’s knowledge when ROD’s work became known.

even helping the person(s) working on the ROD stack, to get Wi-Fi work finished quicker, etc.. i.e. working together

That might also be tricky, if someone else has already done any work that would give them a claim to the ROOL pot.

There has to be some form of “contract” between ROOL and their bounty claimants, otherwise the system couldn’t function. If someone does some work on a bounty with ROOL’s knowledge, then ROOL turn around and say “sorry, but you’re not getting any money for that, because we’ve just learned that someone else has done the same work without telling us and so we’re giving it to them”, things could get messy. Again, see the comments in Archive – and remember that “work” could easily be the non-coding planning work required for such a big project, so long as it met an agreed milestone.

Edit – that should be “contract”, not “contact”.

doing another stack based on NetBSD rather then use a new one already developed and working.

I am enjoying a cup of tea, so… won’t add my very obvious tuppence. ;)

given the information published in the May/June issue of Archive.

Which is meaningless to those of us who don’t subscribe to Archive.

already being worked on by someone with ROOL’s knowledge when ROD’s work became known

Hmm, left hand meet right hand.

The problem this leaves us with is that RISC OS can only run the one stack, only one is going to be put into ROMs. So the one that exists, has been softloaded, and is working might be overlooked for… a completely different implementation of the same thing.

I get that traditionally certain people have been extremely wary of announcing things before they were ready, however when it’s major work to an important part of the OS itself that is the subject of an outstanding bounty or two, it seems bizarre (and unfortunate) that there has been a failure of communication here.

A more pertinent question, by the way, is “is the new ROOL stack going to be IPv6 compatible?”. Reading the bounties, it looks like #2 is updating the IPv4 stack to newer code, #3 is adding WiFi support, and #4 (which hasn’t even been created yet) will be adding IPv6.
We already have an IPv6 capable stack.

That might also be tricky, if someone else has already done any work that would give them a claim to the ROOL pot.

Plus, the two stacks are from different code bases.

Dragging this back to Jake’s MBuf comment… Maybe I misunderstood, but I don’t think Jake meant that he was working on MbufManager. Indeed, it’s closed-source. I took his phrasing to mean that he was changing the Apple code to glue to MbufManager, rather than whatever it expects to glue to on macOS. So perhaps all of this ROD vs ROOL TCIP/IP distraction is, erm, just a distraction.

Thanks for the update Jake – all interesting stuff.

Sadly, the Mbuf manager is one of the few remaining binary blobs in the RISC OS codebase, so I can’t just see what it expects.

ROOL’s source has MbufManager 0.30 as a ready built blob.

ROD does have source for their version of MbufManager 7.03, and there is documentation. The source code is available as a zip, one just has to ask.

Documentation is also in the TCP/IP 7.03 download, in the Doc folder.

HTH.

The source code is available as a zip, one just has to ask.

For a new project written (one assumes) with Open Source in mind, one does have to wonder what “preparing the source for a github/gitlab release” might entail, such that it’s “still ‘in progress’” a year after the first release?

And if it isn’t even ready for publishing in this way as a stand-alone project, maybe that’s why ROOL are having some difficulties with merging the code into the RISC OS source tree?

I agree that it is a bit odd if someone took up a bounty and then all of a sudden someone else does too… but sind ROD did mention the new stack cost ROOL nil, why not simply offer those who did start some money and then use the ROD stack … assuming the ROD stack being viable instead of doing such things twice and thus perhaps even forking.

one does have to wonder

Three books akin to “Git for Dummies” and no time in which to read them to figure out how the thing actually works.

ready for publishing

Question is, is the source somehow not ready to be published, or is it the impediment of getting to grips with the version control?

It exists as a zip file. I’m guessing it builds (haven’t tried), so if that’s the case, it may well be “getting it into Git” that is the issue.

As a person who is completely ignoring that (I’m very much a “here’s a self contained zip file” person), I fully understand. I don’t want to deal with the hassles of getting my system working with something alien (doubly so if it means dumping the code someplace so Microsoft can steal it, strip it of all attribution/licence, and offer it up as something their mechanical Turk dreamt up).

@Rick,

I’m on thin ice here, but…

Git != GitHub. Also, Git != GitLab. Git != Microsoft. So Microsoft won’t be stealing anything.

Managing source code in a directory which you zip up is terrible. I know this because I do it for USBJoystick (which only has myself working on it). I’ve got no way to differentiate my code easily, and see what’s changed and when. Nor any way to try out some different ideas ‘to the side’ away from the usual release. At least, no sane ways of doing these things.

In my professional life, all of this stuff is precisely what source control systems are for. I’ve used a few. Git is pretty powerful, and has the advantage that the majority of developers will be familiar with it.

I really really really want to put USBJoystick into Git. And this is why I’m on thin ice: because I have not yet done so. I would like to be able to do it easily from my RISC OS machine, so keep telling myself that the upcoming Git client will be the answer. I thought it would be a hassle to learn a ‘temporary’ solution. But maybe I should do so? Paolo’s videos probably make it easy!

The joys of remote Git solutions like GitLab and GitHub is that they make it REALLY easy to distribute your source, and for other people to contribute. Even from a web browser, I can look round bits of RISC OS, and see what has changed and when. I can’t do that with USBJoystick, or Ovation, or Zap!

I would recommend having a look sometime. Maybe I’ll take my own advice sometime too. ;)

I’m on thin ice here, but…

The question is, who would be hosting? If the ROOL GitLab, then fine. If somewhere else…

a directory which you zip up is terrible.

Not ideal, but loads of people did it. Less, now that version control systems are commonly available, but still there are some who feel the added complexity isn’t worth the hassle.

I’ve got no way to differentiate my code easily, and see what’s changed and when. Nor any way to try out some different ideas ‘to the side’ away from the usual release.

Really?

It’s easy enough to make periodic zip files (blah_0-01.zip, etc) that contain a snapshot of the project at that version.

You’ll also notice for my software, everything has a “Versions” file that records what has changed in each numbered build (by convention, a build number represents a day of working on the project, that’s why you might see v0.22 suddenly become v0.27, the unreleased ones were work in progress).
Of course, nobody else bothers to update the Versions file… 😡

To do comparisons, just diff the files in the snapshots.

And as for ideas on the side, make a subdirectory and dump the code in there, build separate from the main version.

There’s nothing not sane about it, it’s what we were doing when spreading files involved floppy discs rather than network cables…

I would like to be able to do it easily from my RISC OS machine

How close are we to having an easy to use Git client?

By easy to use, I mean like sync project "this is what has changed in text form" and it just gets on with it.

Even from a web browser, I can look round bits of RISC OS, and see what has changed and when. I can’t do that with USBJoystick, or Ovation, or Zap!

Actually, I prefer not doing that. It’s great if you just want to look at something and you know where it is. But otherwise, it can be a real pain in the arse.
I gave a pointer a short while back to something in the Wimp. You know what I did? Load Wimp01, search for text, matches? Okay, go back then load up Wimp02, search for text, matches? Okay, go back and load Wimp03…
…either nobody on earth thought of putting a “search in the code” function into GitLab, or I’ve simply not found it.

On the other hand, with a copy of the sources held locally, I just drag and drop the lot into Zap. F4, search all files, show results in window, and it’s a job done.
(StrongEd can do this too ;) )

Browsing code in a browser is fine. But looking for something specific that way is unnecessarily clumsy.

Of course, nobody else bothers to update the Versions file… 😡

Hopefully they are at least changing the version number, even if they’re not documenting what’s changed. *Looks sidelong at one particular product that has had at least seven different releases with the same version number*

It would be handy if ‘C’ users could add the name and version /time at the beginning of the runimage file.

Automatically adding the time to runimage when file saved.

It would be handy if ‘C’ users could add the name and version /time at the beginning of the runimage file

Where, exactly? Most applications created using C are squeezed. There’s nowt wrong with having info in a text file in the application directory; if you are daft enough to try mix-and-match bits of versions in that dir then you are just asking for trouble.

How close are we to having an easy to use Git client?

There’s a screenshot of one supposedly in action on page 51 of the current Archive, which (in as much as one can tell from a single desktop image) looks as if it has the potential to be up there with things like TortoiseGit on Windows. I don’t know what the release schedule is, but its the one from this bounty.

Where, exactly?

Something to remember is that C is a modular language.

My Mamie game is split into sections, such as “draw” (high level drawing), “game” (game logic), “menu” (does the menu stuff), “rdsp” (for the effects), “screen” (low level drawing), etc etc etc.

Draw was last updated several versions ago. Menu and game were updated with the current version. I don’t think rdsp has been touched since around v0.11 because, well, it works the end.

My build process creates a file with the version numbers and current date, and forces this to be included, but this is something they I specifically do.

Otherwise, in C one could use __TIME__ and __DATE__ but that’s up to the programmer.
It won’t suffice to simply embed them into the code. If it’s code that isn’t used, the compiler will simply discard it.

are squeezed

Yuck.
These days I can’t see any call for squeezing (we’re not loading off floppy any more) or releasing software with function names stripped (a pile of anonymous functions in the backtrace just makes things harder than it needs to be).

Hopefully they are at least changing the version number

Uhhhh…. 😡

Looks sidelong at one particular product that has had at least seven different releases with the same version number

I trust you’re referring to the fetcher stuff, as it’s had numerous non-identical releases with the same version including a functionally broken build in the midst of it all.

These days I can’t see any call for squeezing (we’re not loading off floppy any more)

ISTR it did still help with larger applications being loaded off SD

I trust you’re referring to the fetcher stuff

Isn’t there something a little more recent than that? Eight releases with the same version number by my count, which is definitely “at least seven”… :-)

Isn’t there something a little more recent than that?

Probably. I’m not specifically aware of, because I suspect if I saw how many things didn’t get a version bump when they should have, I’d 😭.

The question is, who would be hosting? If the ROOL GitLab, then fine. If somewhere else…

https://gitlab.com/
https://bitbucket.org/

Even the old sourceforge uses git these days and there are more public repositories.

If you are on a crusiade against AI learning, then keep your code private and never share it, not even on here, not even in a zip file. Because there are many companies and they are ALL scanning for code on the internet and on many websites, so the war against Microsoft, is only another “smallville” internet behaviour. Like the recent war against RedHat where a youtuber started sustaining they were breaching the GPL, until some kind lawyer (where kind means they did not ask the youtuber to be paid for their consultancy), made him understand that RedHat was not breaching the GPL. He then had to apologise for his reaction.

In any case, if you are on a cruciade against AI learning, again don’t share your code on the internet, included your own website, don’t post articles on coding on X or Y language with code examples, run off the grid! XD

These days I can’t see any call for squeezing (we’re not loading off floppy any more)

ISTR it did still help with larger applications being loaded off SD

This and thankfully we are slowly moving away from it, thanks to Sata interfaces and work being done on NVMe. Unfortunately, next stop is FileCore/FileSwitch, to reduce perfs. So, probably squeezing code, may still be useful (TBD).

Three books akin to “Git for Dummies” and no time in which to read them to figure out how the thing actually works.

Can we help on making your transition less painful even having a little time available?

Did you check some of the videos already made on multiple ways to use Git with RISC OS, both ON RISC OS or via other OSes, which include Windows and should work on Windows XP too?

[edit]
Oh and yes, they are scanning also ROOL GitLab, if that is of interest.
[/edit]

If you are on a crusiade against AI learning,

Let’s start by tossing away words like “learning”. That implies it has some sense of understanding what it’s actually doing, instead of plenty of clever pattern matching.

Secondly, ask yourself why this AI stuff is being trained on open repositories rather than, say, Microsoft’s own code? The answer is because it can regurgitate actual bits of the code it has ingested (in one case an entire function from something (Quake?) that even included the sweary comments).

That’s the truth of AI. It’s a corporate entity ripping off everybody else’s code to spew out a mashed up mess of it with zero consideration given to whatever licence people may have chosen to release their code under.
You know me, I really don’t agree with the GPL. So I don’t use it and I don’t use bits from it. I don’t take it, discard the licence, and use it anyway. And that’s what these AI systems are doing.
If you give the slightest crap about open source, you’d be concerned by this “AI” nonsense too.

they are ALL scanning for code on the internet and on many websites

That’s fine. If I should ever find an AI regurgitating any of my code, I’ll get in touch with Max Schrems (I guess he’d be the guy to know) to see what is necessary to drag their balls through the fire. Scanning all of the code hosted on a website they own is one thing (they probably slipped it into the Ts&Cs when they bought it), but downloading a file from my site and taking the code from within? Blatant copyright infringement.

Hmm, what’s the betting GPLv4 will have a no-AI clause? ;)

sustaining they were breaching the GPL

You mean the part where RHEL is now closed source? Well, yes and no.

The thing is, under your agreement and licence with Red Hat you will not publish any of the sources you receive, and if you do then they’ll toss you out on your ear.
The GPL, which most of the source they are trying to lock up is released under makes it quite clear that no further restrictions can be placed upon the code.
So IBM/RH have taken the attitude that one can redistribute RHEL as is permitted by the GPL, but they will in turn take punitive action if one should do so.
It’s technically legal, unfortunately, but what a class example of how to piss off the community that your business model is built upon.

You know, this entire post, from the AI to RHEL demonstrates what happens when the corporate mentality meets open source. They can’t conceive of things not having price tags attached, they probably think it’s a great wheeze that they’re coining it while others (who did the work) aren’t on their payroll.

Oh and yes, they are scanning also ROOL GitLab, if that is of interest.

You know this for a fact, or are you just assuming everything is being lifted?

For what it’s worth, I asked ChatGPT about setting up an MEMC1a for an A5000 with 4MB of memory.
It suggested the following code:

.global _start

.equ MEMC_BASE, 0x48000000  // Base address of the MEMC1a registers

.equ PAGE_SIZE, 32768       // 32K page size
.equ MEM_SIZE, 4194304      // 4MB memory size

.section .text
_start:
    // Configure memory mapping
    // Set up memory regions for different purposes
    
    // Initialize video display
    // Set screen resolution, color depth, etc.
    
    // Configure hardware sprites
    // Set sprite size, position, image data, etc.
    
    // Enable video display and sprites
    // Activate the necessary MEMC1a features
    
    // Continue with other parts of your program or simply exit
    // ...

configure_memc:
    // Set up memory mapping

    // Set page size
    ldr r0, =MEMC_BASE
    ldr r1, [r0, #0x24]   // Read current value of MEMC_PAGESEL register
    bic r1, r1, #0xFF    // Clear the page size bits
    orr r1, r1, #0x02     // Set page size to 32K (0x02)
    str r1, [r0, #0x24]   // Write back the modified value to MEMC_PAGESEL

    // Set memory size
    ldr r1, =MEM_SIZE     // Load the memory size
    ldr r2, =PAGE_SIZE    // Load the page size
    udiv r1, r1, r2       // Divide memory size by page size to get the number of pages
    sub r1, r1, #1        // Subtract 1 to get the maximum page number
    lsl r1, r1, #16       // Shift the maximum page number to the high bits of MEMC_CONTROL register
    str r1, [r0]          // Write the modified value to MEMC_CONTROL

    // Configure memory regions
    // Set up memory regions for different purposes (e.g., video display, system memory, etc.)
    // The exact details depend on your specific memory layout requirements

    bx lr

_start:
    // Set up memory mapping
    bl configure_memc

    // Initialize video display
    // Set screen resolution, color depth, etc.
    
    // Configure hardware sprites
    // Set sprite size, position, image data, etc.
    
    // Enable video display and sprites
    // Activate the necessary MEMC1a features
    
    // Continue with other parts of your program or simply exit
    // ...

The blank sections are “fill in yourself depending on the hardware”.

Make of that what you will…

@Rick,

It’s easy enough to make periodic zip files (blah_0-01.zip, etc) that contain a snapshot of the project at that version.

That’s what I’m doing. It’s terrible. Also, updating a ‘Versions’ file isn’t the same. I don’t want to make a ‘release version’ – I want to see differences of every change I make. Periodically, those changes form a release, and that’s when the release notes would be updated.

I admit I have not looked too hard, but visual diff utility would be a big help. Seeing the code changes in a ROOL GitLab MR is really easy-to-read. Under RISC OS, I don’t know how to achieve that with my copy/paste of directories.

I really should bite the bullet and install SimpleGit (two clicks with PackMan!) and make myself a repo on GitHub or GitLab. At least I could easily do this stuff from their web interface. I find the web interfaces useful. Right now, I’m on a MacBook in the garden. I doesn’t have RISC OS installed. The Pi is indoors. So I don’t have any RISC OS code locally.

Versions is just a record of what was done, it’s a changelog – see http://heyrick.eu/software/harinezumi/Versions.txt for an example.

Release notes are something different (more human readable for a start). ;)

Under RISC OS, I don’t know how to achieve that with my copy/paste of directories.

Do you have the DDE? If so, there’s a Diff app. It’s… not great but then it’s about what can be expected from a bunch of command line tools.