ChangeFSI broken

One possible solution is to distribute the application unchanged along with another application that makes the necessary changes to the binary in the first application.

I was contemplating doing what the licence describes and ripping out some of the code to use in my own.

The front end is a different item and if you spend any time longer than 30 seconds reading the function names and comments you do wonder what substances were being abused. Anyway a simple front end to set particular options would do. However that still doesn’t deal with the structure elements and duplicate names like Transient.

The only problem seems to be that there’s no way of getting hold of a fully RPi compatible version now, if I follow the thread correctly?

After fixing a minor problem – scanning for ADFS drives – BlackHole 4.18 seems to be OK on the RPi, even in ARMv7 strict mode. Mind you, this wasn’t an exhaustive test but dragging objects to it did move them to its bin. Trapping Filer deletes didn’t throw a wobbly either.

No, I didn‘t miss the smiley but your earlier quote along with going with the spirit rather than what the licence actually said, seemed to suggest that you thought taking liberties was all right.

No, I don‘t for one minute think that taking liberties is all right. Yes, I fully admit that I phrased what I said badly (and in future I‘ll certainly avoid making comment late at night when I‘m too tired to think things through as clearly as I should). However, the irony of all this is that I‘m very much against piracy and rip-offs of any kind; in years gone by when my children were young I‘ve counselled them against accepting offers of pirate videos/software/whatever, for both practical and, even more importantly, moral reasons. You’ll note that I suggested immediately below my ‘spirit’ comment that we contact the original author about it.

Although perhaps clumsily put, at the back of my mind my ‘spirit of the thing‘ comment was based on the copyright giving permission for people to use bits of the coding for their own, non-profit use, and giving an outline of the background to this. Although the initial part was quite contradictory to this I took from the overall ’feel’ of the thing that the intention, the spirit of it, was very generous and in the absence and very probable untracability of the author this was something that could possibly be explored, rather than let such a useful app wither on the vine. I may have got that entirely wrong but it was this I was thinking of and no more. I must admit though that that I find it reassuring to see it subsequently turned out I was not alone in my interpretation, that permission is given to use parts of the coding.

Apologies if I read too much into it.

My wording wasn’t exactly great and I understand why you might have felt how you did but I in turn felt I had to put the record straight. Your apology is unreservedly accepted, as I hope you accept mine upthread.

To turn back to the matter in hand:

After fixing a minor problem — scanning for ADFS drives — BlackHole 4.18 seems to be OK on the RPi, even in ARMv7 strict mode. Mind you, this wasn‘t an exhaustive test but dragging objects to it did move them to its bin. Trapping Filer deletes didn‘t throw a wobbly either.

This looks encouraging – I look forward to further developments! BTW, my copy of BH seems to be 4.00 as far as I can tell – where did you get 4.18 from?

After fixing a minor problem – scanning for ADFS drives – BlackHole 4.18 seems to be OK on the RPi, even in ARMv7 strict mode. Mind you, this wasn’t an exhaustive test but dragging objects to it did move them to its bin. Trapping Filer deletes didn’t throw a wobbly either.

With the simple hack of commenting out the unwanted scan of ADFS drives that don’t exist my hacked copy has worked just fine on a beagle since October. We could take that as a decent test period…

BTW, my copy of BH seems to be 4.00 as far as I can tell – where did you get 4.18 from?

Well in Freds case he already stated it came of a Foundation Risc User CD, which I suppose with the patience to download the ISO of the DVD of volumes 1-16 you could do yourself – that version seems to include a Hole500 which is 32 bit.

The alternate is to go here and download the latest version on the web.

Given the views on the license conditions and the likelihood the FRU version may have slightly breached those conditions by having the module altered I suppose you could say that the Bent Bracke web site version altered by the end user is technically OK while the FRU is not.

Of course we could stop fussing about that detail and let Fred alter Transient…

Of course we could stop fussing about that detail and let Fred alter Transient…

Yeah, maybe that’s the way to go…

Your apology is unreservedly accepted, as I hope you accept mine upthread.

I do indeed.

BTW, any luck contacting the author?

BTW, my copy of BH seems to be 4.00 as far as I can tell – where did you get 4.18 from?

It’s on FRU CD 16 (and above). Some digging round revealed that the conversion to 32-bit was done by Christian Ludlam but his site is gone and the WayBack machine doesn’t seem to have a copy of blackhole.zip.

With the simple hack of commenting out the unwanted scan of ADFS drives

Here’s how I fixed it, it has the advantage that BlackHole will still run on other platforms. Load the !RunImage into a text editor, then go to line 893 (F5 in StrongED).

The code should read:

SYS&40242 TO ,Drives%
IF Drives%>0 THEN

Change it to:

SYS&60242 TO ,Drives% ; flags%
IF (flags% AND 1) = 1 THEN Drives% = 0
IF Drives%>0 THEN

Save the altered file. It should now run on RPi.

Of course we could stop fussing about that detail and let Fred alter Transient…

Don’t think I’ll changing Transient initially but I do plan to have a play with the ideas mentioned in this thread.

that version seems to include a Hole500 which is 32 bit.

On examination the Hole500 module is all but identical to the Hole350 module. The differences appear to be the addition of the additional elements of a 32 bit header and the change of the instruction at 768

This pair:
|L00000768|
LDMFD R13!,{R0-R12,R14}
MOVS PC,R14 ; Function exit, Ends

Becomes
|L00000768|
LDMFD R13!,{R0-R12,PC} ; Function exit, Ends
MOVS PC,R14

Interesting change.

Mmm.

LDMFD R13!,{R0-R12,R14}
MOVS PC,R14 ; Function exit, Ends

I wonder why the original wasn’t just LDMFD R13!,{R0-R12,PC}^ (directly write PC, making the MOVS superfluous)?
The updated version does it this way (only without the flags restore).

I wonder why the original wasn’t just LDMFD R13!,{R0-R12,PC}^ (directly write PC, making the MOVS superfluous)?

Have a shufty at the rest of the Hole350 module – it uses the non-flags restore version. That’s the only flags restore. That’s a module written for RO 3.50 that only uses a PSR manipulation once

Still strange to load R14 and then MOVS it when the ^ would do the same thing in an instruction less. ;-)

any luck contacting the author?

Nothing back via email as yet. I’ll give it a few more days then if still no reply I’ll write via surface post. As such a long time has elapsed since BH2 was released, to be honest I’m writing more in hope than expectation but as they say, nothing ventured…

Thanks BTW for looking into the whereabouts of v4.18.

Still strange to load R14 and then MOVS it when the ^ would do the same thing in an instruction less. ;-)

To me it has all the hallmarks of code done with a set of macros (push registers to stack and pull back at end) and a hand twiddle for the exit (MOVS)
Basically without that manual twiddle it would be clean.

Back in the 26 —> 32 discussions mentality, people need pointing at 26 bit dependencies and the replacement macro. That way, should anything new come up the macro is changed and people just recompile.

Back in the 26 —> 32 discussions mentality, people need pointing at 26 bit dependencies and the replacement macro. That way, should anything new come up the macro is changed and people just recompile.

The only macros I use are EQUD / EQUS (and EQUSZA for null terminated, aligned) as I prefer that to DCD / DCS.
I prefer, otherwise, to know what the code I write is doing instead of hiding stuff behind macros.

That said, a properly implemented macro would either define it dynamically depending upon the attributes of the compilation (26 bit vs 32 bit) as RISC OS does. Alternatively, change the macro…

The only macros I use are EQUD / EQUS (and EQUSZA for null terminated, aligned) as I prefer that to DCD / DCS.

BASIC with extensions that have problems in 32 bit

I prefer, otherwise, to know what the code I write is doing instead of hiding stuff behind macros.

Bad habits die hard then? :)

That said, a properly implemented macro would either define it dynamically depending upon the attributes of the compilation (26 bit vs 32 bit) as RISC OS does. Alternatively, change the macro…

Precisely.

any luck contacting the author?

If you don’t get any luck contacting Mark Greenwood, you could try getting in touch with Bent Bracke (RISC OS software here: http://bracke.dk/apps.html), who seems to have inherited much of Mark’s work.

Bent’s email address is given in, eg, this file: https://github.com/bracke/TBKeyList/blob/master/Resources/UK/TextManual.

BASIC with extensions that have problems in 32 bit

Huh?

          MACRO
          EQUSZA  $var
          DCB     "$var", 0
          ALIGN
          MEND

Bad habits die hard then? :)

Bad habits? Macros are optional, you know. Sometimes they are useful…
Sometimes I just prefer not to use them.

MACRO
EQUSZA $var
DCB “$var”, 0
ALIGN
MEND

Oh, well, if you’re going to spell STRING $var wrong how is anyone supposed to know?

Edit. Oh, :)

Nothing back via email as yet.

Well if it hasn’t bounced then at least the domain is still there so not all is lost. You could try social media, that’s how I found Transient’s original author.

Thanks BTW for looking into the whereabouts of v4.18.

No problem. It’s just a shame that I wasn’t able to find anything helpful regarding Hole500.

have a play with the ideas mentioned in this thread.

Right, I’ve done some initial explorations and come up with a way to trap Filer deletes that doesn’t lose the structure of deleted apps/dirs. A proof of concept can be found here

It will move deleted objects to Transient’s today directory (the directory can be changed by modifying the source). To delete something out right hold down Shift.

It’s still early days but this looks promising. Any comments?

It’s still early days but this looks promising. Any comments?

Rather quick. I’ll see if it breaks anything…

I’ll see if it breaks anything…

Well, apart from the ability to empty the Transient directory. A second (identical delete
Might be an idea to put in an exclusion for deletes from the Transient directory next. (Shift and delete does work as expected)
Over-write of items in the Transient directory does occur.

Loaded while Blackhole is running it intercepts before Hole as expected, when the module is killed deletes occur and Hole does not intercept until re-initialised.

It’s still early days but this looks promising. Any comments?

I loaded TrapDelete late last night on my Iyo. Machine is on 24/7 and runs some SyncDisc jobs overnight. Just compared the SyncDisc logfile with what is in the <Transient$Today> directory and everything that SD ‘removed’ from the backup appears to be in Transient, including the original directory structure.

So it looks like it is a very good start.

I will put it on the BB and PB today and report back later (good or bad 8)).

Well, apart from the ability to empty the Transient directory.

At the moment it simply traps every delete through Filer_Action. For a release version there’d have to be a way to set up an exclusion list for things not to trap (Transient, Scrap, etc).

Over-write of items in the Transient directory does occur.

That’s because Transient doesn’t know about the objects being moved to its Today dir as it’s been done behind its back – in this case the Today dir is just another directory.

Loaded while Blackhole is running it intercepts before Hole as expected, when the module is killed deletes occur and Hole does not intercept until re-initialised.

That’s not what I’m seeing here. With both BlackHole and TrapDelete, deleted objects appear in BlackHole’s bin and in Transient’s Today dir. Which is what I would expect given how they work.

After killing TrapDelete, deleted objects appear in BlackHole’s bin only. I cannot see how TrapDelete could stop Singularity from working so could you please try again to confirm this.

So it looks like it is a very good start.

Thanks Chris. That’s a bit more rigorous testing than I had in mind but it’s good to know that TrapDelete is coping well.

BTW was the work you did on GIGO a one-off or are you planning/willing to do more work on it? GIGO is one of the options I’m considering (commute FilerAction deletes to DataLoad messages), I also found a bug in GIGO.

BTW was the work you did on GIGO a one-off

Well, at the time I assumed it was essentially a one off, in that it was primarily a recompile for ARMv7. I haven’t received any bug reports from other users. I would certainly be willing to try to fix bugs. I do not use GIGO in anger here, so would be unlikely to identify bugs myself, without some prompting.

I do not use GIGO in anger here,

Neither do I but I’ve been exploring the various trashcans recently and found an issue with GIGO.

Putting back a directory with subdirs doesn’t work correctly when it’s on another FS from GIGO itself, it only does the top level objects. Probably caused by not specifying the recurse flag when calling xosfscontrol_copy in Unbin(), so this could be an easy fix.