App development environments

I’m a few weeks into my RISC OS 5 journey and have been playing around with the different development tools and languages. I’ve a few small examples up and running using BASIC, Assembler and C (using the DDE), and have written a small Toolbox app. All good so far!

From here I’d like to tackle a proper WIMP app (eg a new Diversions style game, maybe a utility or playing around with GPIO), and then once I understand more about RISC OS (my background is primarily Linux/Java) I’d be interested in diving a little deeper into the OS itself.

I’m looking for advice as to which development environment/toolset I’d be best focussing on. I’ll have stuff to learn whichever way I go, indeed that journey is half the fun :)

I did try doing some homework but ran in to a few questions – I hope there’s nothing too controversial in this, but here goes!

• C vs BASIC? C would be my natural choice but there looks to be more activity/documentation on the BASIC side. Assembler looks to work with both, if needed. So is there a preference when it comes to longevity/portability/capability? (I’m writing on a Raspberry Pi but would like to think my code would run elsewhere too).

• If I do go for C, than what about Toolbox vs OSLib? I gather Toolbox is the ‘native’ toolset and have been really impressed with it’s capabilities for prototyping and avoiding boilerplate, but get the impression most folks are using OSLib instead and I’m not sure why? OSLib looks to be lower level, does Toolbox hide anything that I might find myself needing access to?

• DDE vs GCC? This might relate to the previous question! What toolset(s) are used for development of RISC OS itself?

• Native vs Linux for development? I’ve done everything natively so far (RISC OS/DDE) but have seen a lot of posts talking about developing in a Linux/RISC OS mash up. What are the pros/cons for this and are there any documented/suggested setups? I’m a Debian/Ubuntu hack by trade so could see this being handy for accessing tools like Git (until that Bounty is sorted!).

C vs BASIC? C would be my natural choice but there looks to be more activity/documentation on the BASIC side. Assembler looks to work with both, if needed. So is there a preference when it comes to longevity/portability/capability? (I’m writing on a Raspberry Pi but would like to think my code would run elsewhere too).

If you’re familiar with both, then use the one that you prefer. C will certainly scale better, so if you’re familiar with it, use it. BASIC is good for small stuff, though, so don’t rule it out if you’re fluent in it and it suits the project.

The problem with BASIC is that it can very quickly get very low level, with lots of poking around in memory blocks using the indirection operators. C with a decent library is a lot more self-explanatory, as structs can be used to access the structures in memory.

Oh, and one less obvious thing that could be an issue if you’re used to source control, is that unless you jump through hoops, BASIC’s tokenised file format does not play well with any VCS which expects plain text files. The RISC OS BASIC sources are all held in plain text and tokenised at build time to get around this; I developed Tokenize to do a similar thing for my BASIC projects over on Linux. If you have no investment in BASIC and want to manage your source, this could be enough to tip the balance to C.

Incidentally, Tokenize can be used on RISC OS, too — and can give some useful insights into typos in your code.

If I do go for C, than what about Toolbox vs OSLib? I gather Toolbox is the ‘native’ toolset and have been really impressed with it’s capabilities for prototyping and avoiding boilerplate, but get the impression most folks are using OSLib instead and I’m not sure why? OSLib looks to be lower level, does Toolbox hide anything that I might find myself needing access to?

You’re asking the wrong question, as Toolbox and OSLib are not comparable. The Toolbox is a way of writing user interfaces; OSLib is a low-level wrapper around OS SWI calls, to avoid the other hacks needed when writing RISC OS code in C.

First, for new stuff, if you’re not invested in existing libraries, use the Toolbox. If Acorn had released it earlier on in the lifetime of RISC OS, and hadn’t tied it up behind a three-figure purchase cost, we’d probably all be using it these days. By the time it became affordable for hobbyists, I’d written my own libraries.

As for the library to access it, that’s a more contentious one. I’d suggest at least looking at OSLib, since it provides all of the Toolbox SWIs in very similar form to those provided by TBoxLib. OSLib has the benefit that you then get all of the other OS and third-party SWIs in a type-safe form with pre-defined structures for their memory blocks and so on.

I think most folk around here will agree that you do not want to use RISCOSLib, though. :-)

DDE vs GCC? This might relate to the previous question! What toolset(s) are used for development of RISC OS itself?

Most libraries will work with both tools, so use the one you prefer. If you have the DDE and wish to work natively, I’d suggest using the DDE unless you need something that only GCC can supply. That’s mainly UnixLib (if you’re porting stuff), or Shared Libraries (if you’re porting big stuff).

Certainly OSLib will work with both, as will things like DeskLib (which isn’t that relevant if you’re using the Toolbox).

RISC OS is built using the DDE, and a fair few bolt-on build tools.

One thing to note is that people will pop up and tell you that GCC only builds ELF format executables, and therefore is no use for “real” development. Whilst this is true for some cases (eg. the Shared Libraries stuff), if you’re just looking to develop “simple” stuff that’s linked to the Shared C Library (and please do this if there’s no reason not to), then both DDE and GCC can generate standard RISC OS executables.

As far as quality of code goes, it’s almost certainly swings and roundabouts.

Native vs Linux for development? I’ve done everything natively so far (RISC OS/DDE) but have seen a lot of posts talking about developing in a Linux/RISC OS mash up. What are the pros/cons for this and are there any documented/suggested setups? I’m a Debian/Ubuntu hack by trade so could see this being handy for accessing tools like Git (until that Bounty is sorted!).

There are two main reasons for Linux development.

First, if you’re porting things, the Autobuilder can simplify the process a lot as it can often use the ported items’ build systems with few changes, because it’s running on Linux with all of the tools that Linux things expect to have around them.

Second, the development tools are better. You get Git (or Subversion, or whatever), plus decent editors. I’m currently working in Visual Studio Code, and if I configure the project correctly, it will intellisense functions and structures from OSLib, and even look up the documentation for me on the fly. Zap and StrongED will do that to some extent (both use F1 to fire off a lookup to StrongHelp, IIRC), but it’s not as unobtrusive.

Personally, I’m familiar with Linux, use Visual Studio Code and source control on Windows for my day job, and find cross-compiling under Linux more polished than working on RISC OS in the DDE. That said, I have the DDE, and it works well — I’ve written a tutorial for using it, so I’m not against it.

You can find a list of the tools that I use here, and there are also some notes on how to configure things if they’re of any use. (PS. I’ve just noticed those pages are riddled with typos… They were finished to a deadline for releasing the site for last weekend’s show, and I’ve not had time to go back and proofread them yet).

Ultimately, do whatever works best for you — and enjoy RISC OS!

Please don’t consider assembler as suitable for writing anything useful here from now on (maintenance of existing things excepted). Use C. History of RISC OS has proved several times that assembler often does not port well to a newer processor, whereas C does.

(Yes, there are exceptions – this is a general rule.)

you do not want to use RISCOSLib

Somebody wrote this: http://www.chiark.greenend.org.uk/~theom/riscos/docs/apps/ROLibRequests.txt
I wonder how much is still true. Probably a depressing quantity.

As far as quality of code goes, it’s almost certainly swings and roundabouts.

These days, with the right flags and options, both compilers ought to be able to effectively schedule their instruction sequences and use current instructions (though, note, this will limit the platforms upon which the software will run) and both compilers are mature enough to do a better job than everybody who isn’t called Sophie Wilson.

There are two main reasons for Linux development.

And the reasons for RISC OS development? You’re directly building and running code on the same system. It also helps to be familiar with debugging because nobody writes perfect code. This will usually be Reporter, SysLog, or my personal favourite DADebug. At a pinch, spewing stuff to the screen works (but is tricky in the desktop). Use DDT as a last resort.
And, of course, you’ll be kicking it old school for the true retro experience. Zap (and StrongEd) are quite nice, but the rest is a bunch of command line things with UI front ends. That said, once a makefile has been created, Zap can (re)build a project just by pressing Ctrl-Shift-C (StrongEd can do similar), which can come in useful when tweaking stuff and testing those changes. Just build straight from the editor, no messing around building it manually.

Honestly, while I prefer Zap/DDE, I would suggest that you try both the DDE and GCC and, if you can, building under Linux. See what I’ve works with your way of thinking.

Thank you for such a detailed answer Steve! VCS is absolutely on my list so some useful insights there. I use git mostly and tbh would feel lost without it on any sizeable project. I’ll have another go at getting my Linux box set up to build – your Build Environment page looks really useful (and sounds very timely!).

Also thanks for clarifying my confusion there about OSLib, that makes much more sense in hindsight. I’d not found DeskLib as yet either, looks interesting and I’ll definitely give that a try.

Dave – noted :D I usually only write Assembler on a rainy Sunday afternoon as part of kamikaze style projects where there’s already a perfectly good C library available! I guess that’s just to keep my hand in, eg having a look at ARM assembler recently has taught me a lot about RISC. I’ve have no desire to use it for anything sizeable, and definitely would not be inflicting my Assembler on anyone else!

Please don’t consider assembler as suitable for writing anything

Selective quoting to make a point.

Stuff written in BASIC has pretty much withstood the innumerable changes in the ARM since the Archimedes was a thing.

Stuff written in C has suffered, but the “fix” was usually rebuilding the project with an updated compiler and libraries.

A lot of stuff written in assembler has had to be updated manually. Every. Single. Time.
And stuff written in assembler that tries to be clever is a nightmare. My go-to example here is Impression which is too damn clever for its own good, which can make porting it to the 32 bit realm kind of a nightmare.

So, the only justifiable use of assembler is low level stuff where higher level languages fear to tread, and short snippets to glue the APCS world of the compiler to whatever SWIs you’re calling, in the absence of existing routines (such as DeskLib and OSLib).
Outside of those two situations, writing things in assembler is a fool’s errand.

[and yes, I’m quite aware that recently on my blog I write an MEMC page table dumper in assembler; but then it was something to dump the CAM table of a thirty three year old memory controller, basically for the lulz (and, justifiably, Arthur can’t run C)]

Somebody wrote this

That’s my bedtime reading sorted!

Use DDT as a last resort

I’ve only used DDT so far (well, after I wrote my own assembler to examine the registers)! I shall try out DADebug etc. I’ve been using Zap too and completely missed the shortcut to make – my first ~week was dragging and dropping onto the iconbar with windows popping up all over the place (the star command terminal was a revelation!)

The retro experience is indeed one of the interesting aspects, and tips like these go a long way thank you!

I shall try out DADebug etc.

The other one that can be worth a look is Reporter.

At first glance it’s geared up for BASIC use, and there’s a lot of work gone into *Report to make it do sane stuff with variables and the like, but a number of people have written C wrappers for the Report_Text0 SWI (including that example there), and these make it very useful in C as well. It’s my standard RISC OS debugging tool — although I’m not really sure how I feel about that, as it’s not quite an integrated IDE and debugger…

When I found here in the forum that new RISC OS apps like e.g. !ChatCube are made using GCC and TBX I gave it a try.

In my view GCC and TBX are both more powerful and easier to use than traditional tools.

In the beginning I had two problems:

TBX is C++ and I am no OOP expert. But I found I can make a wrapper around the required C++ toolbox class, and then the main program can be made in ordinary C

And TBX was started in a time, when there were no powerful RISC OS machines. So with Linux cross-compile in mind, and using makefile. But on a Pi 4 TBX compile in RISC OS is fast enough, so I replaced makefile with an obey file for g++ and this works well.

Also in the beginning, I made two demo APPs which I could share: oscilloscope for Pi GPIO ADC, sprite demo

The big plus of TBX: easy use of sprites and draw files – and events and callbacks (!)

And together with ResEd, creating windows, buttons, sliders is almost like Visual Studio :-)

Unfortunately, I currently have no private webpage, so no way to share.

And the forum does not support uploads, it seems.

I currently have no private webpage, so no way to share.

You can use google drive if you get/have a gmail address.

You are very welcome – it’s always good to see new people interested in development for RISC OS. I’m a long time RISC OS user but only recently started to develop in C. At work I’m also used to Java. I started with DDE, but I might switch to GCC at some point or use both because I prefer to use C++ over C and C++ support seems to be much better in GCC (btw. there is a GCC 8 or even GCC 10 port in the progress IIRC). But DDE is a bit more native and since I don’t port a bigger application it seemed to be a good starting point.

I have written two small wimp applications (in C with DDE using OSLib and some other libs) which make use of REST (web API) which you may know when you are working with Java. I’m going to publish them soon including the source code but I can send them to you now if you send me an e-mail to riscos at luafox dot com.

I would also like to mention that there is a recent lua port (risclua) available and there is Python 2 and an early version of Python 3.

Bonjour,
For Michael and curious people, I put on my site one of my experiences with C ++ and DDE. I am using CathlibCpp, hosted by Alexander Thoukydides, (he built PsiFs with it!)

The shared C library still only uses soft floats, I believe. So if your C software is to avail itself of VFP then GCC is the only way to go. This is an area where ancient history (when ARM chips only did integer arithmetic) is still an obstruction.

I have started a Toolbox library for Python3, but so far it only handles a few things so isn’t very useful.

As soon as I get a “proper” release of Python out I will probably go back to it. I’ve been working on said release for weeks now, however I keep finding things that I’d like to fix before it goes out :)

I stuck my toe into some RISC OS coding a couple of years ago, and bought the DDE for my Pi. I found Steve’s articles on C programming most helpful. I would absolutely agree with everything he has said here.

I use Visual Studio in my day job, and as much as I dislike Windows, VS is very powerful. It would be awesome if, say, StrongEd had a ‘solution files’ tree view and could quickly search my codebase. And intellisense, that is the biggie! It is interesting that Steve mentions having some of that in play on Linux, so that is promising.

it would be awesome if, say, StrongEd had a ‘solution files’ tree view and could quickly search my codebase.

I used Borland Builder and its development environment.I used the DDE and took their development structure as a model. With Rick Griffin’s Treeview module I created a small application which allows to have a tree view on my projects in a single window. I use it a lot.
Michael Gerbracht told me he was using it for his HTTPtest program.
DDE tools link
Thanks to test.

Yes, I used it and it really helps to keep the desktop clean as you don’t have to keep a lot of windows open and you can quickly compile, install and run your project. Also it forces you to stick to the DDE development structure of you directory – which is a good thing.

@Jean: the last line of the ToolBoxMod file checks for the Treeview module v0.22, but the error message says printdbox!

However, I only have Treeview 0.18 and have not yet found v0.22.

However, I only have Treeview 0.18 and have not yet found v0.22.

http://packages.riscosopen.org/thirdparty/arm/SqueakySoftware/TreeView_0.22.zip or PackMan.

@David: Thanks for that. I had not thought of looking there.

However, with Treeview v0.22 installed and loaded,starting Diderot gives:
Message: Unable to create window: The gadget flags have reserved bits set (gadget type 0×4028)

Clicking on the Icon sometimes locks up the App, and sometimes gives:
Message: Exception inattendue main: Invalid Object Id (0xff131920) (0×46ea4920) (0×1)., errnum 461425410

And there are a few ZeroPain errors as well.
This is on RO5.28. I will try again after my next reboot.

Thank you for the link to Diderot. I gave it (0.15) a spin on my Pi4 (5.29 30-11) and it falls over with an exception. Happy to post the debug info here or …

Thanks for testing !Diderot.
In the zip file there are the latest module from Rick Griffin:
Treeview and Tab. Rick kindly modified his module by adding a function to find the window identifier.
I have added his stronghelp manuel in the zip file,in case.
Thanks for the correction in toolboxmod files. The application use the treeview 0.23 version.

Happy to post the debug info here or …

OK

@Jean-Michel: Thanks, I had not realised there was a v0.23 of TreeView required, as ToolBoxMod only checks for v0.22.

Now I have v0.23 loaded, it does start up without error messages … but there are two ZeroPain errors, which I would send if there was an email in the Help file!

The tree display is nice, but I have noticed that the window seems of fixed height and is not scrollable over iall the data, so only about 17 items are displayed and I can find no means of seeing the items off the top and bottom.

It also may be better to Obey ToolBoxMod in !Run instead of Filer_Run, so that if any modules are not found the startup fails rather than continuing to try to run the program.

Thanks for these advices for the toolboxmod file.

the window seems of fixed height and is not scrollable over iall the data, so only about 17 items are displayed and I can find no means of seeing the items off the top and bottom.

Thanks to discover this problem on your machine.
This morning I went back to the toolbox v1.59 module and indeed this problem exists!, usually I use version 1.71 and I don’t have this problem.
I have an ARMX6 and the scroll wheel allows you to display the complet tree.
I’ll do some testing and see if I can make my program more compatible. Strongly unification of the ToolBox, I have the same problem with TextGadget 0.49

I know from bitter experience that there are differences between ROL & ROOL toolbox modules. Unification cannot come too soon. Good luck!