Android application to manipulate sd image from the site

aaaa

aaaa

aaaaa

aaaa

—

aaaa

aaaa

aaaa

I compiled squach on my Iyonix this morning with !GCC 4.1.2 and there were no warnings or errors.
Making the sqar from a tar no problem.
Opening the sqar reveals the top level OK but squach couldn’t interpret a path to a lower level.
I will have to go back to true Linux again to get a picture of whats going on.
I wouldn’t like to say what is right or wrong, with so many levels of conversion going on.
Perhaps tars will always use the unix naming internally, and squach seems to be reading them OK at compression.
You will have a difference in a RISCOS made tar having ,xyz extensions though.
There can be differences in the two unixlibs and switches used to how a binary will act to the names you give it.
Generally I use the same convention as the compiler binaries, Which is simply feed unix naming in, and you get RISCOS names printed on output. It’s an easy rule of thumb.
Unixlib binaries wll accept RISCOS names in most of the time and when using a drive description it is necessary to have the part up to the $ in RISCOS form. ie ADFS::HD4.$/work/source/kalc
At the end of the day things have to be juggled to work in a way to get what needs to be achieved.

aaaa

It might not turn out to be a biggy, I think riscosifying/unixifing is reasonably automatic, I have seen small problems arise when a binary alters the file suffix’s and it conflicts a little at the output.

For now i’m looking into making a filer in assembler who can read the sqar file and display the content in riscos.

aaaa

A bit for me to get my head around, If I recall, my gnu tar needed ,xyz even within RISC OS.
Now, squash is storing the individual filetypes, this wouldn’t be necessary as long as it can it get the filetypes from a RISC OS made tarfile that hasn’t applied ,xyz extensions? Is it possible for a generic tar to hold filetype information without ,xyz?
On a different platform, squash decompression will have to add ,xyz on decompression of the squash to retain them, looks like you are already doing this.

Sorry for being lazy, and just asking you the basics.

On the subject of the RISC OS frontend, you are probably looking at a standard filer interface so it blends the way sparkfs or other various fs have done. I’d just like to mention the possibility of using something like the Ftpc frontend, allowing useage of your own additions like search and select a file, Something that isn’t available in a plain filer window without a second app.
If the functionality was added to Ftpc as an extension maybe it would then work with an ftp file server?

Edit: I guess the standard Ftpc would only have to send the execute cmd, The work would be in getting the ftp server to run squach and send the result in a directory form.

aaaa

aaaa

Edit: I guess the standard Ftpc would only have to send the execute cmd, The work would be in getting the ftp server to run squach and send the result in a directory form.

If another program would be to use this, it would be better to directly handle the archive format internally.

From a RISC OS client view, you might have to have two filetype identifiers.
somefile,fca,ff5 would look like a postscript file on a riscos client.
ftpc has ‘remove ,xyz’ function, I’m not sure what would happen with 2 layers though. RISC OS clients will remove the ,fca and set the filetype to squash on downloading.
Perhaps the modded ftp server could strip the ,ff5 off when it sends it.
It seems that there would be no special client needed on the RISC OS side.

For a local RISC OS scenario, the bottom line would be command line and probably a filer window at the high end.
#if defined __riscos works in !GCC, it is likely to be the same in ROOL’s compiler.

aaaa

If it is important to have particular functions, you might need to make a header file with them so compiling on RISC OS works seamlessly.
Thats odd, one click 2 posts, Dual core processor must be kicking in :-)

aaaa

I found this table which is interesting.
Index and Pointer Code for Accessing an Array a with Elements of Type T

Array Index Code       Pointer Code
-------------------------------------
int i;                  T *p;
i = 0                   p = a  or p = &a[0]
a[i]                    *p
a[i].f                  p->f
i++                     p++
i +=  K                 p += K
i == N                  p == &a[N] or p == a + N

There is a few locations in the RISC OS file attributes unused,(reserved for future use) but only enough to use as a pointer to a block, I reckon. I dont know where you could put such a block in the file and get away with it.

aaaa

aaaaa

aaaa

aaaa