Beginning Wimp Programming in C

Dear all

I recently bought the official DDE v26 from ROOL.
I am learning WImp programming in C.
Considering the lack of tutorials, I decided to follow the book “A Beginner’s Guide to Wimp Programmming” and to adapt the code for C.
I encounter a first issue, not related to C programming, but with the set-up of the applicatin directory.
In the book, we are invited to create a !Test folder with the folloxing elements:

• !Run
• !RunImage
• !Sprites

I precisly followed the book to create the !Run, !Sprites and !Sprites22 files. I configured my C projet using !Make with !RunImage as target, so as to have in my !Test folder the above files.
When I double-click directly the resulting !RunImage, the application runs as expected, proving there is no bug so far.
But if I tried to run it by double-clicking the !Test folder (as usual for a riscos application), I get the following error: (Number).
Note that if i replaced the !RunImage by its BASIC equivalent, the application launches as expected.
For the sake of completeness, here is the code for the !Run file:
Set Test$Dir <Obey$Dir>
IconSprites <Test$Dir>.!Sprites
WimpSlot -min 32k )max 32k
Run <Test$Dir>.!RunImage

If anyone can help…

Thank you in advanced

François

Try a larger WimpSlot and/or verify the syntax of the relevant line :-

WimpSlot -min 32k )max 32k

That bracket is not entirely correct.

I’d go as far as saying that it’s not correct at all :)

Also, although Make will still work, it’s deprecated and you’re now encouraged to use shared makefiles. I might write a (short!) tutorial if there’s some interest.

WimpSlot -min 32k )max 32k

I’d go as far as saying that it’s not correct at all :)

I’ve just tried it here and the error is “(Number)”!

David

Thank you for pointing this. Stupid error!

Regards

David

Thank you for pointing this. Stupid error!

Regards

Stupid error!

Well not really, the error message was not that helpful, and all of us do typos!

Thank you for pointing this. Stupid error!

It’s known as a “typo” – short for typographical error.

I tend to refer to them as “digital errors” since a digit¹ poked the wrong key :)

¹ A finger in this case.

you’re now encouraged to use shared makefiles. I might write a (short!) tutorial if there’s some interest.

I am sure that would help, those Makefiles are a bit eye-watering at first sight.

I might write a (short!) tutorial if there’s some interest.

Make it longer :-) and do a tutorial based on the DDE-Examples.skeletons.exampleapp as it comes with DDE.

While !make is deprecated it was an easier way into C for newcomers the new method assumes a lot of C knowledge I think.

those Makefiles are a bit eye-watering at first sight.

You can say that again. I can just imagine the person that wrote it thinking this will make it easier for everyone.

I think if I was just starting I’d just use !cc that comes with DDE and just compile a single file – just to get a feel for the language and not get bogged down in makefiles That would be the nearest thing to how people use basic. Then you can tackle makefiles when you understand a bit more.

I might write a (short!) tutorial if there’s some interest.

I too would find that useful and interesting, and I’m sure it would be a great addition to the RISC OS Open Wiki.

those Makefiles are a bit eye-watering at first sight.

You can say that again. I can just imagine the person that wrote it thinking this will make it easier for everyone.

those Makefiles are a bit eye-watering at first sight.

I think, once one has got one’s head around it all, that it probably is easier than it looks. All the user has to do is to interface with the Shared Makefile with a user Makefile of additions or amendments. The learning curve is the syntax of that user Makefile.

I think if I was just starting I’d just use !cc that comes with DDE and just compile a single file – just to get a feel for the language and not get bogged down in makefiles

The DDE-Examples reflect that, there is no user Makefile for ‘HelloW’.

I think I’ve been trailing some vapour-documentation for a while now, covering the writing of Wimp stuff in C. They’re still far from complete (and stop before anything representing a useful application gets produced), but since the first couple of chapters deal with using the DDE, Shared Makefiles and OSLib, I probably ought to make them available.

The documentation is here: http://www.stevefryatt.org.uk/docs/wimp/

If you’re specifically after compiling, then there’s a chapter on compiling code using the desktop front-end and that leads on in to converting the process to use Shared Makefiles

Constructive criticism is welcome, but please remember that it’s not finished!

ETA: I should probably add that the documentation does not use the Toolbox. That’s because I don’t use it either (inertia, mainly), and because the original aim of the project was to get some documentation out for my Wimp library to make it more useful than just a blob of code on my website. It hasn’t progressed that far yet.

Thanks. Cool, and easy to understand.

Neat. Now I don’t need to write anything :)

Time for a TCC port? :)

While I do not like OSLib, preferring to just call the SWI’s directly, it is definitely better than using UnixLib.

You’re aware that OSLib is just calling the SWIs directly? Despite the ‘lib’ in its name, OSLib is just a suite of type safe veneers around the system’s SWIs. There’s no extra code in there.

UnixLib’s a red herring, too. UnixLib is an alternative to the Shared C Library (with additional functionality), and is at a level higher up than OSLib. If it helps, consider that OSLib contains veneers around the SWIs that initialise the Shared C Library.

With OSLib available, it’s hard to see why anyone would use _kernel_swi() or _swi() in new code. They all do the same, but OSLib is the only one that doesn’t require the user to cast everything to and from int each time.

With OSLib available, it’s hard to see why anyone would use _kernel_swi() or _swi() in new code. They all do the same, but OSLib is the only one that doesn’t require the user to cast everything to and from int each time.

While I would agree that it is better to use oslib for type safety, you can’t compare it to _swix for ease of use so it’s rather obvious why no one uses it. Invariably you are reading the programmers manuals to work out what you are doing where it tells you the register values to call. At that point you can either use _swix – which requires no typecasting – or search through the oslib libraries looking for the header file which has the function you want and then you have to work out how oslib has mapped the swi to the function. Added to that anyone who wants to modify your code who is not familiar with OSLib but wants to keep the programs ‘style’ has the added hastle of working out oslib. This together with the fact that _swix is always up to date – changes to the os does not need any changes – makes _swix the way to go for me.

it’s rather obvious why no one uses it

I was under the impression it was still used. I certainly use it – I started using it once I decided to convert all my stuff to C, rather than the original Basic (using !ABC to compile the bigger apps). I have always found oslib very useful. There is a good StrongHelp manual for it, which is much quicker to use than the PRMs.

Oslib also has some higher level support libraries. I found the event library and the message library helpful.

Just my 2d.

I was under the impression it was still used

I would hope it is but I wouldn’t let it any where near any of my projects unless I was releasing it as GPL. I know no-one agrees with me so I hope this doesn’t spread like the ususal GPL thread but in my view OSLib is released with a GPL licence and although the web site history says this has been relaxed so you can use it in commercial software that ‘relaxation’ doesn’t appear in the license the only licence you have is GPL.

There is a good StrongHelp manual for it

I prefer searching the pdf manuals as they are definitive.

If you don’t like OSLib, there’s always DeskLib. ;-)

I have no problem with OSLib what it does it does well, my problem is the effort involved with using it and my perception of the licence that it won’t let me use my own licence for my code. If I liked using OSLib and was writing GPL great. In a similar way I have a problem with the DDE. As far as I can see I can only use it’s libraries with Castles ROM licence so as I see it I would have to release my code with a compatible licence. So I now only tinker with the ROM and won’t be writing any Apps for distribution. People will say my interpretation is wrong but as I see it without clarity in the licence these products are of limited use.

With OSLib available, it’s hard to see why anyone would use _kernel_swi() or _swi() in new code.

“Because I can” :p

There is a little more to my reason than that, but that’s all it really needs to be, with no further justification.

As far as I can see I can only use it’s libraries with Castles ROM licence so as I see it I would have to release my code with a compatible licence.

Most of the relevant files seem to say “[This file] may be used freely in the creation of programs for Archimedes”. While the wording is out-of-date, I don’t see any issue with creating commercial apps under any licence you choose.

It’s really difficult to search for the word “licence” in the DDE though, because virtually every file has the Castle boilerplate on it too!

my perception of the licence that it won’t let me use my own licence for my code

The OSLib ReadMe says…

OSLib is copyright (c) 1994-2012 Jonathan Coxhead and OSLib maintainers.  It
is distributed in the hope that it will be useful, but  without any warranty;
without  even the  implied  warranty  of  merchantability or  fitness  for  a
particular purpose.

  OSLib is released under the GNU  public licence - for details see the  file
"COPYING" included with  this release. The  copyright holders have granted  a
relaxation of the conditions of this licence to allow its use in constructing
proprietary  software.  This means  that  it  is  free software  itself,  but
applications linked to it need not be.  It follows that any changes to  OSLib
itself (the contents of the directories Tools, Source, and OSLibSupport) fall
under the terms of the GNU Public Licence; but programmes written using OSLib
do not.

That seems fairly clear: the OSLib code is GPL, but applications that you write using it don’t need to be.

in my view OSLib is released with a GPL licence and although the web site history says this has been relaxed so you can use it in commercial software that ‘relaxation’ doesn’t appear in the license the only licence you have is GPL.

The licence appears to be in the ReadMe file (as above), which in turn refers to the GPL for the OSLib code itself. You don’t have to rely on the website: it’s in the download archive.