Unable To Run Program In RPCEmu v 0.7.4

Hello there

I am attempting to run Derek Haslam’s new version of Gateway To Karos from his boulsworth web site. However on attempting to open the program !Gateway from the apps folder I receive a box entitled Run (Text ua) and a dump of the text in the file in a black dialog box. I suspect it is opening the !Run file as a text file but I have little expertise in this emulation. Does anyone have any ideas?

Regards

Canalboy

Was it a zip? And did you extract it on the host into the HostFS folder?

As it sounds like you did and lost the file types as a result.

Copy zip into HostFS and use Spark to extract it in RISC OS.

Yes I’d already unzipped itn from hostfs with the same result. I ncan’t see how to modify the files manually.

SparkPlug is open on the icon bar. Dragging the !Gateway icon on to the icon bar does nothing. Zap won’t work either. It still opens as textua every time.

If I open Sparkplug I get four options, Info, NewArc, Log and Quit. None of them seem to be unzipping options. I tried unzipping using 7zip direrctly to the hostfs file and then Zap and they always unpack the files but as text files. Sparkplug sits serenely but uselessly in the icon bar.

In the end I dragged it into a directory containing something called InfoZip and it unpacked it straight away; the program is now running. Sparkplug seemed to do bugger all to be honest. Thanks for your response.

Canalboy

gateway254/zip unzips perfectly here with SparkPlug 2.29 on RPCEmu 0.9.4 OS5.29. !Gateway does have to extracted from SparkPlug by dragging it to a filer window from which it can be run, it cannot be dragged directly to the icon bar.

It’s 2023, why are we even talking about SparkPlug?
Is SparkFS not available?

Hmmm…
https://www.riscosopen.org/zipfiles/platform/common/SparkFS.1.55.util

It’s a self extracting Utility. Download it, set it’s type to Utility (or FFC for short), then run it. It will disappear, but in its place will be the app !SparkFS.

It’s 2023, why are we even talking about SparkPlug?
Is SparkFS not available?

Freely available. When it wasn’t (free, that is) was when SparkPlug had a purpose.

Of course, then you have to appreciate that, unlike on other OSes, dragging a file you expect to decompress to the utility icon on the iconbar actually does something useful.
In the case of SparkFS that includes setting the file type metadata of the file you dragged in accordance with the file content.

Do we have documentation around that references using SparkPlug instead of SparkFS? Seek and destroy… :)

Do we have documentation around that references using SparkPlug instead of SparkFS?

The only two mentions are on the File types page (it uses filetype 5F4) and on the Software compatibility list where it appears immediately after SparkFS. I suppose a comment of the form “Most users would prefer to use SparkFS” could be added to the “Notes” section, but given that the link points to David Pilling’s “Retired software” page (which only mentions SparkFS, not SparkPlug) I doubt that many users are acquiring SparkPlug by following that link.

SparkPlug does of course get numerous mentions on other RISC OS websites such as StarDot¹ but those websites often have good reasons for doing so (e.g. a user might want something that is easy to install on RISC OS 3.1).

¹ Some of those mentions were even made by me…

It sounds t me like the downloaded file was named gateway254/zip but had a filetype of Text.

given that the link points to David Pilling’s “Retired software” page

Fixed :)

It sounds t me like the downloaded file was named gateway254/zip but had a filetype of Text

Drag to SparkFS would fix that.

I’ve found there are some times where SparkPlug will open an archive where SparkFS will not; there are some examples on the Archive DVD — at least the one which included up to volume 22 (I don’t think there has been a later one); ISTR it uses a different method of de-archiving which can work in some cases, e.g. if the catalogue is damaged.

I’ve found there are some times where SparkPlug will open an archive where SparkFS will not

Offhand that sounds rather like having some of the SparkFS modules not loaded/running.

Offhand that sounds rather like having some of the SparkFS modules not loaded/running.

No, there’s a real problem with SparkFS if you try to copy a recently-created archive too quickly. SparkFS won’t write the Zip central directory until 5 seconds (approx.) after the last file is added. If you take a copy of the Zip file before that happens, you will be copying a (corrupt) Zip file that SparkFS won’t read. Fortunately SparkPlug doesn’t use the Zip central directory so will be able to read the corrupt Zip file. This has been the case since SparkFS 1.36, and famously resulted in the copy of David Pilling’s website on one of the later Acorn User CDs having 100% corrupt Zip files.

As I learned years ago, the central directory is just for speed, and you can entirely reconstruct it from the files in the zip. I wonder if this is why I can’t open some RISC OS zip files with 7-zip on Windows, but !SparkPlug opens them fine…

Fortunately SparkPlug doesn’t use the Zip central directory so will be able to read the corrupt Zip file.

If you have a really old ZIP without the central directory (which confusingly is actually at the end of the file!), or that got truncated due to file corruption like Stuart says, you can tell SparkFS to ignore it and recreate the directory layout by serially chewing through the file. The command is *ZipUseCentralDirectory 0 and to turn back on use 1.

I can’t open some RISC OS zip files with 7-zip on Windows, but !SparkPlug opens them fine…

They probably aren’t zip. Drop ’em into Edit. Are the first two characters “PK”?

Back in the day, there were things called “Sparkives” (often with a .Arc extension) and also a slightly different sort of thing from ArcFS.
These are RISC OS specific and won’t be understood by archivers on other platforms.

You could well be right, whilst they’re definitely .zip files, that might just be coincidence.

Personally I was very much a user of ArcFS back in my full time RISC OS days, although I do recall Sparkives as a term.

From the SparkFS ReadMe, concerning the missing central directories from Zips, these commands are in the SparkFS !Run, maybe for the modern era the timeout could be reduced ¹. The ReadMe explains why this feature was added.

Perhaps there is a way of trapping something accessing an archive (file copy for example) and flushing the unwritten data before it gets a chance – look at the file system vectors.

Why might archives not be readable by 7-zip – as said above, maybe a RISC OS type it does not know wrongly given a zip extension. Some SparkFS produced zips have incorrect zip tag lengths – although I have no reports of that being a problem.

I imagined 7-zip might handle Spark files, they’re close to SEA .arc. Hard to tell without trying it because Google now thinks Spark is another piece of software to my program from 1988. ArcFS files would be slightly more exotic for for 7-zip.

¹

The new command

controls if changes to archives are cached. The default setting is 0 i.e. no
caching which was the previous behaviour. The timeout after which the
archive is updated is provided by the *SparkFSImageTimeout command (see
below).

In my case, yea, the file wasn’t a zip but had a .zip file extension. It is apparently a .arc file, based on a download elsewhere that had the same binary structure.