NutPi : Writer+

I’m no longer able to run Writer+. I get the following error:

“Could not process menu definitions because: menu format error”

It worked fine when we first got it, but subsequent re-installs make no difference. Is this likely to be anything related to firmware / using the daily ROMs or is it more likely to be something I have done?

A fresh RISCOSPi is not out of the question, but I do quite like the way I have things set up.

Cheers.

I have similar problem with my settings. Using a new card Writer+ works fine, with my settings (ComCentre, ProCAD+, RiscCAD, a handful tools…) not. Normally I use Techwriter, so I have no search the reasons.

Yes, it’s something to do with the daily builds. If you revert back to RC8 all should be ok.

Thanks very much guys. It’s now working fine after following Peter’s advice. It also seems to need the CPU configured to ARM 5 compatible mode. It wont load on ARM 7 Strict and doesn’t work properly on ARM 7 Fast. I guess its an old bus with good tyres :)

Writer+, and its relatives TechWriter and EasiWriter seem to have got tripped up by a bug fix in the C library. I’ve sent details to MW Software so hopefully it’ll be reasonably simple to resolve.

tripped up by a bug fix in the C library.

I am not sure that a bug fix at this late stage is that good an idea. Please do not include this bug fix in 5.20. It might break software that is no longer being maintained. Can someone confirm that Impression, ImgMaster, (trying to think of other older stuff that might use the C library) are not affected? Should both an earlier and a later version of the C library be available so that an application that needs the unfixed C library can kill the later one and RMLoad the earlier one? Or unplug the one in the ROM (leaving it statically linked to bits of the ROM that require it) and RMload an earlier unfixed library.

Tough call – I would have been inclined to think that the logical option would have been to keep old behaviour, publicise it well, and introduce parallel functions that work as expected. Is this “C” compliant? Would the standards bodies care about two decades worth of older software? One can argue that the programs that used workarounds for incorrect behaviour are in themselves buggy… ;-)

Should both an earlier and a later version of the C library be available so that an application that needs the unfixed C library can kill the later one and RMLoad the earlier one?

Yuk! As Rick quite rightly says, it is a perfectly reasonable argument, anything that relies on a bug is in itself a buggy item.

I work with a setup where national systems (NHS) are reliant on buggy behaviour of a certain well known browser. Fixes to those bugs in later versions break the system. The (slow) response on this has been to fix the system bugs or move away from the buggy application. No-one ever suggested that the browser supplier should maintain the bug/security hole so that the system would work ad-infinitum.

If the bug fixes in the C Library were corrected, shouldn’t everything sold on the NutPi have been tested and the relevant authors notified so that they could provide a solution ? After all NutPi is sold by ROOL.

I think that what is sold by ROOL, i.e. RC8 and NutPi are fine – these are both beta. The problem only emerges if you use the latest alpha build of the ROM. That’s what happens if you try out alpha software.

Actually, this bug has been fixed in Easi/TechWriter in 2006, but Writer+ has not been touched since 2002. It is not very likely that a lot of other software uses this particular CLib feature. Any bug fix in the OS has the risk of stopping broken software from working, but that cannot be an excuse for not fixing bugs.

Aaaaaaaargh!!!!

Just blew the cobwebs off my version of Techwriter (8.31 Nov 04) and tried to fire it up and…

Anyone know what bug was fixed in the C library so I can change my version back?

I think it’s this one:

Fix to scanf of a scanlist where no match occurs
In this situation, the conversion should fail.
Fixes ticket #252.

Tagged as RISC_OSLib-5_76

Darn. I’ll just have to work around it for the ‘once in a blue moon’ times that I use it these days.

Just tried loading C_Lib 5.75 (15 Jan 2013) – on RO 5.21 (25 Jul 13)
Loads ok but C Progs don’t work afterwards.
ClibOpen 5.53 (19 Dec 2006) loads but displays the same error as 5.77 (23 Mar 13) – when trying to load EasyWriter.
(Could not process menu file definitions, because: Menu format error).
Are there any softloadable C_Libs available – for RO5 – for testing older programs?

You have to load it very early in the boot sequence I just renamed a copy !!!Clib and dropped it in predesk. I’m using 5.53 Mar 2005 at the moment. I found it in the Enduser folder of an old copy of Acorn c/c++. Licence says I can only distribute with my programs. Have you bought any programs in the dim and distant past – they may have the EndUser folder included with them.

“Could not process menu definitions because: menu format error”

I now get this error on my Iyonix under RISC OS 5.20 (softload) with TechWriter 8.90 whereas under RISC OS 5.16 it is OK. So I’m sticking to 5.16 on my Iyonix until this is fixed or a documented work-around is published. I need (occasionally) to open MSWord files that appear as attachments on my e-mail.

I also get the ‘JPEG not supported by SpriteExtend’ error (MSWordDocX file) under 5.20 but not under 5.16.

@Chris
Have you try the file from this Post ?
If you not need this, I will delete.

Sorry, I remember at this moment that Martin send me a first Testbuild from 8.90 to try it on my Armini Prototype and it works not with DocX-files. I not remember the error message but the reasen was a old unzip.
As I wrote. Docx you can set as filetype zip and open with SparkFS…

I can’t load it – it’s not there anymore?

Sorry, the file is online (in the morning it works) but everything has killed the Pandora-Server. I have also not access to my website . Please try later.

11:44am: It shouldt work now.

Problem with !Writer+ and RISC OS 5.20 solved, see here

I got the writer+ error also since ever. is there a solution
for this? it’s still present at RPi RC12!

(BTW, its the writer+ from nutpi, and therefore
i fear is also no update to fix this prob?)

maybe i should stick with fireworks, which is
working fine…

Hi Erich,
If you get in touch with Martin Wuerthner (contact details at the bottom of the web page) www.mw-software.com and tell him you have Nut Pi, he’ll send you a fixed version.

Pete