Learning C on RISC-OS

I’m sure that there are many others, too — many developers just seem to write their own…

I guess it’s the problem when we are all used to the grotty parts of task management because that’s “just how BASIC rolls”, and we all think we can all write a better library… ;-)

Wasn’t there one called “EventLib” as well?

A recent program I wrote used custom SWI functions in assembler. It was an exercise in writing a program with an extremely minimal library, able to build with no dependencies (other than CLib). For sure, any program of any real size, you’d be crazy not to use a library – be it DeskLib or OSLib or something else. Certainly, the big oft used libraries will be solid and reliable – not something you can always guarantee if you write your own (look at Heartbleed for a good example of the potential of one small oversight that nobody picked up before code deployment). Don’t ever get stuck in the NIH Syndrome. There are some nice libraries around.

But better than all that, programmers on the whole tend to like doing “fun stuff” and not the boring repetitive crap. So a library could offer a call that does all of the mundane task setup stuff. One call and it’s on to the good bits, right? ;-)

I was very happy to find this thread yesterday:

https://www.riscosopen.org/forum/forums/11/topics/1835

… and most importantly, a working example of a “WIMP Hello World program” using OSLib mentioned in there, to be found here:

http://www.sfryatt.eclipse.co.uk/temp/wimp.html

Thank you, thank you, especially Steve in this case. I was pulling my hair to figure out how to use the the OSLib library for things like WIMP programming. To be honest the examples supplied with OSLib are pretty useless.

Slowly, very slowly I’m starting to see how things (can) work in C !!!

So, to resume, I think I’ll made a reasonably good choice with my gcc + OSLib setup and I’m going to stick with that until I have enough experience to write my own library (wink : Rick!)

I’m sure that there are many others, too — many developers just seem to write their own…

I guess it’s the problem when we are all used to the grotty parts of task management because that’s “just how BASIC rolls”, and we all think we can all write a better library… ;-)

I definately recognise what you said, I’ve been doing that in BASIC as well…

Funny enough I see you experienced guys indeed all making your own: Rick adapted DeskLib, Steve wrote his own…

I think I’ll use just OSLib without OSLib support for the moment, I like the idea of still having a bit of a feel what’s going on. Too many layers, like maybe another event lib might confuse me even more.

Around this time of year some people are looking for egss, I’m trying to find bugs…

After finding Steve Fryatt’s Wimp Example program, using OSLib, I tried making an adaption. Loading templates from a template file.

I adapted the “register_task” function as below:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "oslib/wimp.h"

#define task_name "Electron"

wimp_w RescalcWhandle; /* Our window handle */
wimp_t task_handle;   /* Our task handle */

// RescalcWind is struct w. window def.
wimp_window   RescalcWind;

int used,next;

void hexdump(unsigned int addr);

typedef unsigned char BYTE;


void register_task(void)
{
  unsigned int addr; // hexdump
  
  int messages[] = {message_QUIT, 0}; /* Avoid complexity of message block initialisation. */

  task_handle = wimp_initialise(wimp_VERSION_RO37, task_name, (wimp_message_list *) &messages, NULL);
  
  char *iconblk, *icend;
 
  iconblk=malloc(4000);
  if (iconblk==NULL) exit(1); // no mem available...
 
  icend=(iconblk+4000);
  wimp_open_template("<Electron$Dir>.Templates3");
  
// Input: window - pointer to buffer for template, or Wimp_GetSize to return required buffer size
//        data - value of R2 on entry = workspace ptr for ind.icons 
//        end - value of R3 on entry = ptr to byte after icon WS
//        font_ref - value of R4 on entry
//        name - pointer to a (wildcarded) name to match (must be 12 bytes word-aligned)
//        context - value of R6  search pos.start (0 for 1st call)
//
// Output: used - value of R1 on exit
//         icon data_used - value of R2 on exit (ptr to remaining WS)
//         context_out - value of R6 on exit (X version only)
//
// extern os_error *xwimp_load_template (wimp_window *window,
//      char *data,
//      char const *end,
//      byte *font_ref,
//      char *name,
//      int context,
//      int *used,
//      int *data_used,
//      int *context_out);
// extern int wimp_load_template (wimp_window *window,
//      char *data,
//      char const *end,
//      byte *font_ref,
//      char *name,
//      int context,
//      int *used,
//      int *data_used);

  wimp_load_template(&RescalcWind, iconblk, icend, (byte *) -1, "rescalc", 0,&used,&next);


  hexdump((unsigned int) &RescalcWind);
   
  RescalcWind.sprite_area = 0;
  RescalcWhandle = wimp_create_window(&RescalcWind);
  
  wimp_close_template();

}

I started with a template made with TemplEd (from Dick Alstein).
The template had 4 icons:
- 1 plain text icon (label/tag)
- 1 indirected text icon (longer label)
- 1 indirected writable icon with a validation string
- 1 default ‘OK’ style button.

In this situation the program worked except that icon number 1 was missing in the window the program opened! Even when renumbering the icons, still, very consequently nr.1 was missing. Not either the writeable icon, or the button, but no, always nr.1. This phenomena disappeared when I made the template with WinEd instead of TemplEd.

But when putting more icons (like 7 or 8) in the template the whole program crashed, freezing the mouse and the whole system. No, error msg, post-mortem dump, or whatever.
The hexdump function was not called, since there was no screen output of the data in the RescalcWind block, like there was when the program did function.

While debugging I quit the program before opening the window or entering the poll loop. The error is definately in the wimp_open_template function, or more likely in my implementation of it ;-)

For example: The template name need to be word-aligned (max. 12 bytes). How do I know/make sure this is right?

Thanks for your help.

Tomas

The system:
===
Virtual RISC PC with RO 4.02 65MB RAM

GCC 4.1.2 Release 2 (released 1 October 2012)
OSLib 7.00

WinEd and / or TemplEd

You’re not allocating the window block memory correctly.

wimp_window   RescalcWind;

is fine if your window has no icons (as my original example didn’t), because the structure in OSLib contains no allocated space for the icon definitions that follow the main window structure. You need to allocate that space yourself before trying to use it (because OSLib has no idea how many icons the window might have).

However, when you do have variable size definitions and indirected data, you’re far better off reading the sizes via the Wimp’s API and then allocating the necessary space dynamically via malloc() or whatever memory management you’re using.

For example, SFLib’s Windows module contains the following function:

wimp_window *windows_load_template(char *name)
{
	wimp_window	*window_def = NULL;
	int		def_size, ind_size;
	byte		*ind_data;

	if (wimp_load_template(wimp_GET_SIZE, 0, 0, wimp_NO_FONTS, name, 0, &def_size, &ind_size) == 0)
		return NULL;

	window_def = malloc(def_size);
	ind_data = malloc(ind_size);

	if (window_def == NULL || (ind_size > 0 && ind_data == NULL)) {
		if (window_def != NULL)
			free(window_def);
		if (ind_data != NULL)
			free(ind_data);

		return NULL;
	}

	wimp_load_template(window_def, (char *) ind_data, (char const *) ind_data+ind_size, wimp_NO_FONTS, name, 0, NULL, NULL);

	return window_def;
}

You could use this (or similar) by changing your code to

// RescalcWind is a pointer to struct w. window def.
wimp_window   *RescalcWind = NULL;

and then

RescalcWind = windows_load_template("rescalc");

if (RescalcWind==NULL) exit(1); // no mem available...

hexdump((unsigned int) RescalcWind);
   
RescalcWind->sprite_area = 0;
RescalcWhandle = wimp_create_window(RescalcWind);

Note that this is untested — the library works, but the changes to your code are off the top of my head.

ETA: You should initialise RescalcWind to NULL and then test that the window was loaded correctly before actually doing anything with the pointer…

ETA2: Once you’ve called wimp_create_window(), you could free up the window definition unless you’re going to need it again (for example, if you need to create more copies of the window, or delete and re-create it).

free(RescalcWind);
RescalcWind = NULL;

Thanks Steve, that helps!

I got it working using the function ‘windows_load_template’ you supplied. Since that is part of your SFLib, I though, as a next step, why not give it a go and install your SFLib next to OSLib on my VirtRPC. I saw it had nice functionality, like sfprint-ing into icons… just what I need ;-)

Of course I needed to adapt to the RO name convention, having a ‘h’ directory and headers without .h extension…
But alas that was not the only problem, because the linker complained that your lib uses hardware FP while I have SW FP support….

You don’t have a version for SW FP? Or am I mistaken that I can only use SW FP on VRPC / RaspberryPi?

Thanks again.

Apologies for the slow reply: the lead-up to a Wakefield Show probably isn’t the best time to ask questions of RISC OS developers (or, indeed, show organisers who also try to develop stuff as a sideline). :-)

You don’t have a version for SW FP?

I don’t at present, but it should be trivial to produce. I’ll see what I can do this week.

Or am I mistaken that I can only use SW FP on VRPC / RaspberryPi?

I think so: the hard-float version of SFLib is the one that I use for all my software, and as far as I know that runs fine on a Pi.

Yes, the Pi definitely has hardware floating point (VFP) support; the standard Raspbian Linux distro makes use of this (apparently it makes a big difference to performance over software FP).

If you are using !GCC there are command line options that can select either soft or hard FP. In particular, using the Shared C Library via

-mlibscl

That sounds about right for SCL vs Unixlib: I use the SCL for my software.

Note that “hard float” doesn’t mean you actually need floating point hardware present. The Floating Point Emulator will step in if there’s no real floating point hardware in the machine (which is true of most RISC OS systems over the years).

(Better late than never)

Note that ‘hard float’ typically means compiling for the old FPA instruction set – there were only two relevant ARM processors that supported this and the last one of those was released in 1996. Even on a Cortex A9 with VFP3, NEON, etc etc FPA will still get emulated. To get true hardware FP you’d need to compile with VFP2 (ARMv6 onwards) or VFP3 (ARMv7 onwards, with a few exceptions). I don’t think anyone has written an emulator so VFP instructions will work on old machines.

This will not be directly relevant to compiling C, but back at the start of the year I was exploring VFP for my own software, which is reflected in this topic:

There are limitations to what VFP can do to replace FPA directly, so I am not sure what a compiler can do or what is done on the Linux side.

The result of my efforts is a module, provisionally called Float, which replicates as far as possible the FPA using VFP. Although it has SWIs, these have overheads that cancel most of the advantages of hardware FP, so the routines are also available directly. In that case it is quite satisfyingly fast. To enable software to run even when VFP is not available it reverts to FPA, with only a tiny overhead over using that directly.

I have not released this, but if anyone is interested I could send a copy.