Cloverleaf Kickstarter includes a pledge for RPCEmu

Start RPCEmu and !Edit and save two files called “File” and “File,fff”. See the problem?

Naïve probably dumb question – but why doesn’t a text file called “file” map to “file.txt” on the host system?

Then, if “file” <-> “file.txt” and also “file,fff” (not to mention coping with text files called “File” and “FiLe” which are the same on RISC OS), it’s quite clear, as Steffen says, that there’s no ideal easy solution to mapping from the host to RISC OS.
It could perform a “best guess” but with conflicting information (such as a system presenting file.txt and File.txt as different things) or mixing extensions and comma types, things can get really complicated really quickly.

Even without RPCEmu in the mix, things can get into a weird state when you add ‘foreign’ filing systems. Yesterday I had “select1” and “select1,a70” in the same directory on a Linux machine. When I opened that directory with LanManFS, I saw two files called “select1”, one with a text icon and one with a SQLite icon. Double-clicking the text one resulted in the binary one opening.

I love how Coverleaf has brought the community together. I never thought commercialising RISCOS would be so entertaining.

I’m also really glad Andrew R has put his name to all this!

massively entitled c**t

Say what you think Peter.

Although I personally disagree with way the Cloverleaf project is going about things and have concerns around how its played the Kickstarter system, they haven’t done anything illegal yet and are simply proposing changes to open source projects, all be it in commercially funded way. As such, they do not need to discuss any of their proposals with the original authors or maintainers.

Some people have backed this approach either financially or by association, without possibly understanding the full implications of their actions. We’ll have to just see how that plays out.

Cloverleaf now have a large amount of work on their hands, that has to be completed with next to no funding – that brings them into scope of breaching Kickstarter rules when they can’t meet their commitments, but no legal recourse.

Hopefully Cloverleaf fulfil all their Kickstart commitments and the code is all submitted into the head trunks.

Already have that, load Anymode and set my RO screen size to match the X/Y dimensions of my display unit.
Actually I leave the Windows task bar uncovered for convenience.

Is not what Stefan mean with “Full-Screen”. Is a “fullsize” Window in front of WIN desktop.
What Stefan mean is what you get if you chose “Full-Screen Mode” in “Settings” and feels like a “singletask” (you can leave with Ctrl+End).

This won’t get committed to head, it is too much of a support burden for us (basically you can not program it to work well enough).

What the reason for this? Is there a real technical limitation?

@steffen I’ve been looking into this with a view to writing a new SMBFS module for newer SMB standards. Connecting with SMB3 protocols works ok but procrastination over how to handle filename edge cases has ground me to a halt – so I’ve shelved the project for the moment.

but why doesn’t a text file called “file” map to “file.txt”

Presumably if you are writing code you’d want reversible name mapping and to be able to compile via hostfs and lanmanfs.

I love how Coverleaf has brought the community together. I never thought commercialising RISCOS would be so entertaining.

I guess that’s what happens when you pop up out of the blue and essentially tell everyone who’s been working on things for the past however many years that they don’t know what they’re doing (or imply that they haven’t actually been doing anything), that you can do it better, and people should pay you to do it. Warm fuzzy feelings all around!

you’d want reversible name mapping

Nothing won’t with that. Just know that “.txt” on the host is &FFF on RISC OS. Then you can access the file from the host as well as the emulator.

As such, they do not need to discuss any of their proposals with the original authors or maintainers.

Yeah, they actually kind of do. Because unless they plan to fork it and start making their own versions, any work done will need to be merged into the main source collection. At which point it might have been a really good idea to talk to the current maintainers because there may be technical reasons for why something has not been done.

Say what you think Peter.

Really don’t think we should be encouraging the use that kind of language around here.

when they can’t meet their commitments, but no legal recourse.

Very wrong.

Read the TS&Cs.

Quote: When a creator posts a project on Kickstarter, they’re inviting other people to form a contract with them. Anyone who backs a project is accepting the creator’s offer, and forming that contract.

A little further down: The creator is solely responsible for fulfilling the promises made in their project. If they’re unable to satisfy the terms of this agreement, they may be subject to legal action by backers.

Source: https://www.kickstarter.com/terms-of-use#section4

The backers have entered into a legal contract with Cloverleaf. Normal rules apply. There may be some leeway given they’re trying to promise the earth for a small amount of money, but that’s up to a judge to decide, not Cloverleaf or a backer.

Hopefully Cloverleaf fulfil all their Kickstart commitments

I hope too, because god knows we need a lot done to make the OS anything resembling modern…

you’d want reversible name mapping

One of the difficulties is that SMB2/3 mandates UTF16 for file names.

Another is that files can be created by other filing systems, so it is perfectly possible to have file, file.txt, File.txt and lots of others in a folder that RISC OS has to cope with.

Naïve probably dumb question – but why doesn’t a text file called “file” map to “file.txt” on the host system?

You could, if all you ever wanted was to use the host’s system for access from RISC OS. But as soon as you want to start exchanging files, the system breaks down because you can only have one “file”, but the host might have stored “file.txt” and “file.ini” and “file.text” and “file.cfg” which you all want to map to &FFF.

I think that, in principle, the MimeMap idea (and before that the DOSmap idea) is sound and allows for a good way of working from both sides of the world on the same FS. You “just” need to decide how to handle the edge cases in a way that is consistent and not-too-surprising for the non-technical user. If someone stores a file from RISC OS with a certain name, he expects to find it later under the exact same name. If someone stores a file with a certain name from say Linux, he expects to find it under RISC OS under the same name, but I think it would also be OK to find it under “some” name that is just very similar to the name as seen from Linux (that’s a lot of words to describe the “filename encoding problem” in conjunction with the “not all characters are allowed inside a filename”).

RPCEmu’s HostFS strategy makes sure that you can take its content, copy it somewhere else, use it from any other RPCEmu RISC OS installation no matter if you have a proper boot sequence installed with a valid MimeMap or whatever. The tradeoff is that it ruins the data exchange use case. But you cannot have a solution without tradeoffs. As Druck correctly said, it would be good to have the same tradeoff for all filing system solutions – many usability problems stem from the fact that e.g. the LanManFS handling is different from Sunfish and from ImageNFS and from LanMan98 and from HostFS (RPCEmu) and from HostFS (V-RPC).

I’ve been looking into this with a view to writing a new SMBFS module for newer SMB standards. Connecting with SMB3 protocols works ok but procrastination over how to handle filename edge cases has ground me to a halt – so I’ve shelved the project for the moment.

OK, so your proposed deal is that I provide you with a watertight spec, and you provide us all with an SMB3 capable LanManFS? This is really tempting…

OK, so your proposed deal is that I provide you with a watertight spec, and you provide us all with an SMB3 capable LanManFS? This is really tempting…

If the sources of LanMan98 are already available, better update that one, LanManFS tends to get struck in “LanManFS in use” mode all to easelly when doing more than just copying files around.

Naive question: does the displayed filename have to be identical to the filename given to and/or returned from the drive?

Just wondering whether it’s possible to put a translation layer between, to do a job that’s in principle like escaping URLs. I’m particularly thinking here of how to handle UTF16.

I’m sure it won’t be possible to deal with all the filename edge cases from all operating systems. We mustn’t let the perfect be the enemy of the good.

Say what you think Peter.

Really don’t think we should be encouraging the use that kind of language around here.

I don’t think Jon was encouraging
Not that it matters.

I’m particularly thinking here of how to handle UTF16.

I have utf16 conversion sorted by using backtickxxxx to display unknown characters – though filename length becomes another problem but it is anyway.

Rick Wrote:

ArtCube says “It should also be the base for a module that will enable all RISC OS app access to bitmap images”. This has already been done. CJE is selling ImageFS2, which I think was made 32 bit by Colin? This is a transparent process for software that can load sprite files. I believe it can also do the reverse for saving, but I’ve not used ImageFS since RISC OS 3.10 so I’m not really the one to say… however, I will point out that this problem has already been looked at. It might be worth getting in touch with whoever owns this to see about what sort of features it actually has (does it support PNG? does it cope with GIF/PNG transparency? both ways? can JPEG quality be adjusted on the fly?) with a view towards extending support within the existing framework.

As this is not RPCEmu specific I’ve replied in a new topic in General.
https://www.riscosopen.org/forum/forums/5/topics/16514

Hmm, just got spammed by Cloverleaf begging for funding (go visit the Kickstarter…).

Methinks somebody ought to read the GDPR, because “If you don’t want to receive emails from ChatCube anymore, click on this link.” at the bottom doesn’t really cut it.

just got spammed by Cloverleaf begging for funding (go visit the Kickstarter

That’s weird. I only received one email; hardly a begging letter ;)

GDPR rules aside, I didn’t mind receiving a message from Cloverleaf :)

That’s weird. I only received one email; hardly a begging letter ;)

You probably have a looser definition of spam than me. I look at an unsolicited five-screenful message (with three photos) asking for pledges, sent on behalf of ChatCube that doesn’t appear to even mention ChatCube and, well, that just says “spam”.

I didn’t mind receiving a message from Cloverleaf

It seemed weird to me. I’m guessing they sent this out to everybody who has signed up with ChatCube. There’s no ChatCube app listed in Google Play, so it may be just us RISC OS users present. So… uh… are we the ones that the “reasons why RISC OS is best” email is supposed to be aimed at?

Plus, this: You are sick and tired of Windows, macOS, IOS, Android or Linux? Then help us to give you another choice for your computer or in the future for your mobile phone.

Yes, Windows annoys the hell out of me at times. But, then, so does RISC OS. ;-) I use RISC OS, Android, and Windows because each has a purpose and certain apps that I use. There’s no “one size fits all” (and if there was, Android is closest). It’s fine to promote RISC OS as an alternative, but that shouldn’t come at the cost of denigrating other systems. It’s too much like the “my Oric is better than your Spectrum” from childhood, or “my Amiga is better than your Atari” from teenage years. Everybody insults Windows, everybody insults Apple, everybody insults Android. But, newsflash, they’re the most used platforms on the planet. Compared to them, we aren’t even a rounding error.

Oh, and RISC OS on a mobile phone? Seriously?

RISC OS on a mobile phone? Seriously?

I hurt myself laughing

I suppose if the Phone was running Linux – how about Tim’s Linux version of RO :-)

Naive question: does the displayed filename have to be identical to the filename given to and/or returned from the drive?

I don’t think there’s a problem with UTF-8 filenames – RISC OS has always been happy with top-bit-set characters and if you encode the Euro symbol as 0xE2 0×82 0xAC then that’s recognisable as UTF-8 without breaking apps that don’t understand it (they just won’t present it correctly). Since UTF-16 doesn’t have that property (it can legitimately store 0×00 in a filename) I’d suggest it’s safer to convert to UTF-8.

It would be unhelpful to have an entirely disjoint file naming system, in the mode of Micros~1 Windows’ implementation of long filenames on top of FAT 8.3 filenames. That had the unfortunate feature of each file having multiple names.

What would be good though is to have a spec for conversion and a single translation library. Unixlib has unixify.c and riscosify.c but these are by no means canonical, nor particularly robust. In particular, with a spec it would be possible to be sure that particular translations are reversible and to shake out the ambiguities.

That’s not to say there would ever be a full solution, but at least agreement on what should happen in the corner cases would be a start, and code that prevents everyone reinventing the wheel in different ways. Having a common translation mechanism might also mean the behaviour could be switchable system-wide (ie we could have both HostFS and UnixLib agree on what translation they’re using rather than having to configure them individually).

(For the record, my git client foundered in this area. The problem is a lot messier than it looks)

everybody insults Apple

How to increase your spam count¹. Sign the bits to get an Apple ID (which you need in order to download free apps from the App store)
However, since it’s a work phone and a work mailbox I can filter the unwanted stuff – might be entertaining to do that in the corporate spam filter :)

¹ I get more than enough from upper management

It’s actually up to Windows. Applications can request to be associated with a file type (extension) by various means (load, print, etc).
So the place to look to see how files are mapped is Windows.

But, yes, it’s a bit Wild West, leading to annoying situations like older programs (of the DOS era) often coming with “help.doc” or “readme.doc” files that Word (or some other part of Windows if Word isn’t installed) will claim, attempt to open, and then choke because it’s a plain text file and not one of the many incarnations of a “.doc” file.

First results for the RPCEmu changes: Scroll wheel and Text clipboard working.
A possible memory leak has been reported but cannot be reproduced yet.

Dispite we had to remove the RPCEmu reward from the Cloverleaf Kickstarter due to activities of the Troll King we have done anyhow the main part of the task as we planned. So currently we have received 19 Euro for this job. I am going to add some donate button on our site next week
in case someone feels that we have done a good job.

This is the modified version of RPCEmu 0.9.3.
Added mouse wheel support and host<→guest clipboard integration.
Clipboard currently supports text only. The text is converted from/to RISC OS alphabets upon copy/paste. (CTRL+C/V)

To make it work the helper module “rpcemuhelper” has to be loaded and the clipboard monitoring task needs to be started.
The module loader script is hostfs/!Boot/Choices/Boot/Tasks/Rpcemuhelper,feb to ensure it is run at boot time.
The module binary itself is hostfs/System/350/Modules/rpcemuhelper,ffa

The size of .exe increased from original size because it linked statically with iconv that is used for UTF convertions from and to RISC OS.

RPCEmu binaries and module (you need to install full version from
www.marutan.net/rpcemu
first if you don’t have it already.

Binarias for Windows/Lunix/RISCOS riscoscloverleaf.com/rpcemu/rpcemu-0.9.3_cl_0.1.zip

The archive with patched RPCEmu sources:
http://files.riscoscloverleaf.com/rpcemu/rpcemu-0.9.3_cl_0.1_src.zip