Tools for developing basic Wimp applications

Loving RISCOS on Pi, and I’d like to develop some applications, starting with very simple stuff. Ive got a beginners level of BASIC from my teens, but what I have no knowledge of at all is how to get started with Wimp applications, and also accessing network functions in RISCOS Pi from BBC Basic. I don’t want to do anything too dramatic, but I do like a nice clean interface, and the Riscos GUI is too pretty to ignore!

Any suggestions on which packages are out there are suited to Basic-With-Wimp newbies?

Also, are programs written in BBC Basic for Windows fully portable to Riscos?

Any suggestions on which packages are out there are suited to Basic-With-Wimp newbies?

DrWimp – URL: – “here” http://www.chris-johnson.org.uk/software/3party.html to start with.

John

Loving RISCOS on Pi, and I’d like to develop some applications, starting with very simple stuff. Ive got a beginners level of BASIC from my teens, but what I have no knowledge of at all is how to get started with Wimp applications, and also accessing network functions in RISCOS Pi from BBC Basic. I don’t want to do anything too dramatic, but I do like a nice clean interface, and the Riscos GUI is too pretty to ignore!

Any suggestions on which packages are out there are suited to Basic-With-Wimp newbies?

You might be in for a shock, because writing Wimp stuff for RISC OS isn’t as simple as writing a “visual” something on Windows. RISC OS co-operatively multitasks, and in BASIC you need to get your hands dirty making that work. You don’t get the nice “multitasking for free” thing that BB4W gives you.

These days, you probably want to use the Toolbox, as it makes things much easier. In BASIC, that pretty much dictates that you’ll be using AppBasic

DrWimp is useful, but rather idiosyncratic from what I’ve seen of it when helping maintain software written in it.

Also, are programs written in BBC Basic for Windows fully portable to Riscos?

No. The underlying language is the same, but BB4W adds things like structures, different variable types and so on to what is provided by ARM BASIC. Anything provided by the OS will obviously be different.

Simple stuff can move across easily enough, but as soon as you use any of the “extra” bits of either dialect then things will become problematic. If you use SYS, OSCLI or * commands, you’ve got a problem.

The two dialects also tokenise differently (so you need to move programs back and forth in ASCII format)…

And, as noted above, BB4W multitasks in a window. ARM BASIC single-tasks while taking over the screen unless you write all of the necessary Wimp code yourself (or use something like AppBasic to do that for you).

Thanks for the heads up. My BBC4W stuff does use a lot of SYS commands so probably easier to rewrite. If someone can point the way to some good manuals or resources for general use in BBC Basic that would be great.

I got my head start with the book “A Beginner’s Guide to Wimp Programming”, which can be downloaded for free from here. It gives you a friendly introduction to the bare-metal interface between BASIC and the Wimp, with no third-party extensions. DrWimp or AppBasic are probably friendlier to newbies, but I’m of the opinion that everyone should learn how their programs work at the fundamental level anyway.

The downside is that it’s rather out of date, but the depressing thing about RISC OS is that not a whole heck of a lot about it has changed since 1992.

If you’re made of free time, one of the things (as you’ve doubtless worked out by now) that we’re most badly in need of is documentation, particularly for new developers. The perspective of newcomers is often invaluable when writing this stuff, and all the experienced people are severely overcommitted to attempting to keep the OS afloat anyway. As a result, we end up with vicious circles like this one, where no documentation gets written because nobody has the knowledge, and nobody can acquire the knowledge because there’s precious little documentation.

These days, you probably want to use the Toolbox, as it makes things much easier. In BASIC, that pretty much dictates that you’ll be using AppBasic

Much as I admire AppBasic, particularly for its documentation, I have to protest. There are people who write their Toolbox programs using Basalt, and they run a great deal faster. They can be a great deal smaller, too.

I got my head start with the book “A Beginner’s Guide to Wimp Programming”

I learned from the early Archive articles, and reading a lot of other people’s programs. As many others have done, I have been through all the stages of writing my own support libraries, each with a different slant, but I am not sure that is a recommendable route.

DrWimp or AppBasic are probably friendlier to newbies

DrWimp and AppBasic are the survivors of many dozens of competing library systems. IMHO some of these were superior, but their developers left the scene.

It has been my regret that Acorn never exercised control over BASIC libraries in the way that Richard Russell has over BB4W. It would have been a huge advantage to have a unified system that all could refer to, and that all could make contributions to.

It has been my regret that Acorn never exercised control over BASIC libraries in the way that Richard Russell has over BB4W. It would have been a huge advantage to have a unified system that all could refer to, and that all could make contributions to.

Seconded.

DrWimp and AppBasic are the survivors of many dozens of competing library systems.

Mmm… I used to use !WimpEd (well, a very hacked about version of WimpEd). Give it templates, associate some basic events and/or design menus, it would build a boilerplate app.

It has been my regret that Acorn never exercised control over BASIC libraries

Thirded.

It is also my regret that Acorn never made a utility to process BASIC programs and strip out unnecessary code. One of my first tasks, when using WimpEd, was to open the source and delete all the numerous functions that were in the library but were not necessary. It doesn’t matter with >200MB free. It sure as hell mattered back then, with ~600KB free!

Hmmm, plenty to chew on there… I have just begin to flick through A Beginners Guide to WIMP Programming and actually it is useful, having never done anything of that ilk before, so looks like my spare time is spoken for, at least for a while(!)

.. regret that Acorn never made a utility to process BASIC programs and strip out unnecessary code.

But I did. I was helping Joe Taylor with tools for AppBasic in 2005. The application was !Blynken (written in RiscLua :). From its !Help file:

What is it for?
-——————
Blynken is a Basic Library Linker. That is to say,
it scans a Basic program for LIBRARY commands, and
builds a new Basic program with no LIBRARY commands
but which contains just the FN/PROC definitions from
the old program, and from the libraries, that are
needed. Definitions not contained in the program’s
dependency graph will not be included.

How do I use it?
-——————-
Doubleclick to put the !Blynken icon on the iconbar.
Drag a Basic file to this icon and the new Basic
file will appear, with the same name as the old but with an “X” appended to its name.

What kind of Basic program will Blynken work on?
-——————————————————————-
Blynken has limited intelligence. It can only deal with Basic programs for which:

1. No line numbers are used (and so, of course, no GOTO or GOSUB statements). Line numbers are garbled in Blynken’s output, but this will not affect how it runs.

2. LIBRARY statements must not use computed arguments. That is, their arguments must be literal strings. LIBRARY statements must not be followed by other statements, apart from REM statements, on the same line. If your Basic program expects to fetch its libraries from the current directory, remember to set the current directory appropriately before dragging it to Blynken’s iconbar icon.

3. DEF must always be the first token on its line.

4. DATA statements, either in the main program or in the libraries, must be preceded by a FN/PROC definition that is not redundant (i.e is actually called when the program runs), and be followed by some FN/PROC definition (but which may be redundant).

5. If a FN/PROC name is computed in an EVAL statement, it must also appear literally in the text, otherwise Blynken will not be aware of it.

PS. A less ambitious application, that does not know about libraries, is !Unused, which can be had from http://www.wra1th.plus.com/stick.html . It will check for unused PROC/FN definitions and undefined PROC/FN uses in a BASIC program.

There have been a number of linking applications, most notably Dick Alstein’s !Blink, but I also have a copy of !Blinker somewhere. !Blink is in BASIC, so it could probably be updated.

Personally, I am averse to linking, and much prefer shared resources. Linking produces a stand-alone runtime, but if there are several applications using the same libraries there will be duplication of code, so the memory-saving argument fails. Linking also interposes another stage between writing a program and releasing it. This could be seen as making programs less transparent ¹, but it also brings a need for strict control of the source.

If only one copy of a BASIC library is loaded and shared among as many programs as need it, there is a predictable memory use and no duplication. That is what my Basil module provided and a couple of those now-defunct library systems used it.

¹ To some this may be desirable. ;-)

I am averse to linking

I think linking is only needed to provide something for those who do not already have the necessary libraries and resources needed by the unlinked version.

Joe used !Blynken as part of AppBasic for a while, until he found a purely Basic linker. I am not sure whether he used something already existing (!StrongBS ?) or cooked his own, using the information about the internals of the BASIC interpreter (see the section on CALL in the BBC BASIC GUIDE). Unfortunately, at that time StrongBS was not 32-bitted and the author could not be contacted.

The RiscLua library linker (!lua.RiscLua.Utilities.link) is only 23 lines of code because it uses what is already built into the interpreter for parsing and compiling.

A less ambitious application …. is !Unused

This does no dependency analysis; it would not recognize that a pair of mutually recursive but redundant procedures were in fact redundant, and so is of not much use. Its only point of interest is the iterator BASICline which produces consecutive lines of BASIC in a for-loop.

Personally, I am averse to linking, and much prefer shared resources. Linking produces a stand-alone runtime, but if there are several applications using the same libraries there will be duplication of code, so the memory-saving argument fails.

The problem is, you need third-party tools to make shared libraries work. There’s a notable reluctance amongst parts of the userbase to install software that needs that kind of thing.

If I link the libraries before release, only I need third-party tools.

Linking also interposes another stage between writing a program and releasing it.

You mean like compiling C? Personally, I like the fact that I can now just type “make release” for any of my software — C or BASIC — and have it spit out Zip files ready for my website. It seems to be a help, not a hindrance.

;-)

This could be seen as making programs less transparent

I don’t see why, if the “source” is also made available.

but it also brings a need for strict control of the source.

This is the key one: having got used to it, I can’t say that I find the idea or working without strict source control very appealing nowadays. One of the main motivators behind my writing Tokenize was to get all of my BASIC code into Subversion in a useful way; the fact that it also does LIBRARY linking for me (using libraries that are also stored in plain text format) is also crucial. I’d like it to strip out unused code from the libraries, but as Gavin notes above, that’s extremely difficult to do properly.

(Note that you can just take the ASCII source for any of my BASIC software plus libraries, TEXTLOAD and SAVE them, set the BASIC$Path variable to point to the libraries, and run them. The source isn’t obfuscated in any way and there’s no mysticism added by the tokenise and link stage beyond CRUNCH 31 and SWI name substitution.)

@Steve F

I think I agree with all you have said, but I have some comments.

The problem is, you need third-party tools to make shared libraries work. There’s a notable reluctance amongst parts of the userbase to install software that needs that kind of thing.

I wonder why there is a reluctance to employ third-party tools only now. In the past there were hundreds of applications released that used them and no-one batted an eye-lid. Some could include a copy of what was necessary in the application directory, others required an update to !System or the installation of a Resource application. Commercial applications might do this, too.

If I link the libraries before release, only I need third-party tools.

True, but is there much difference if you include the tools in the application, hidden from the user? Some big and popular applications have lots of tools, some of which are third party.

I like the fact that I can now just type “make release” for any of my software

I admire how you have got so organised, but you must admit it took you some time and it is not something that you can just give to the rest of us to use out of the box. ;-)

[less transparent] I don’t see why, if the “source” is also made available.

You mean the third-party tools and the libraries as well as the unlinked program, plus your unique Make system? Just teasing!

This could go round and round. Unfortunately, the way BASIC is used has so many niches but so few programmers that each niche probably only has one. À chacun son goût.

Personally, I like the fact that I can now just type “make release” for any of my software — C or BASIC — and have it spit out Zip files ready for my website.

Whoa – wait – you go from source to website without a final program test before release?!

I wonder why there is a reluctance to employ third-party tools only now. In the past there were hundreds of applications released that used them and no-one batted an eye-lid.

That being in response to Steve F’s comment that parts of the user base are reluctant to use/load certain things.

Perhaps the reluctance is a consequence of the ROL/Castle spat:
Perhaps it’s GStubs vs 32 bit CLib (what did Druck call GStubs? something like " a botch to avoid using the proper 32 bit CLib").
Perhaps it’s a consequence of dependencies flagging themselves as 32 bit safe when they were not.
Perhaps it’s a consequence of dependencies being readily available from a web site that disappeared overnight and the author had a nice robots.txt that stopped archive sites like wayback from collecting them.
Perhaps it’s a consequence of perfectly good applications that relied on the 32 bit CLib not working on Select because some total arse tweaked Select to not work with the 32 bit CLib (until enough people pointed out they being total arses)
Perhaps it’s all of the above.

Whatever it may be, the trust is in using the built in components since those are tested with the rest and can be fixed by the people working on the rest of the OS.

Observation/speculation…

Whoa – wait – you go from source to website without a final program test before release?!

You got that from what Steve said? Having a release phase in your build system is somewhat different to not having a testing phase in your release process…

@Steve P

Most of those have occurred to me. I would add one more:

Perhaps, the few, but experienced, hobbyist developers have a ‘not invented here’ bent. I know that I do.

Steve said:

Perhaps the reluctance is a consequence of the ROL/Castle spat:

Still? Christ, people! Move on!
That was how long ago?

Perhaps it’s GStubs vs 32 bit CLib

This I could understand to a point – why use a different shared library instead of using the regular shared library?

There was a time when I avoided the Toolbox like the plague – getting that running on my machine took a huge chunk of memory, something like 260K? But now? Now it is built in, but if it wasn’t (as UnixLib isn’t), there is enough memory for stuff like this.

Perhaps it’s a consequence of dependencies flagging themselves as 32 bit safe when they were not.

A biggie. There’s nothing more aggravating than tracking down a bug in your code to discover that it is a fault in the library.

When I first got the DDE (Norcroft C version 4), I began to write using RISC_OSLib.
After much stress:

• So… w? wind? window? Pick one and bloody well stick with it!
• ‘e’ (or was it ‘m’?) isn’t the same thing. It changes depending on what you’re talking about.
• Everything in the desktop world is prefixed “wimp_”. Like wimp_IBACKCOL (icon) and wimp_WPANE (window is a pane) and wimp_EBUT (poll event) and wimp_MCLOSEDOWN. What moron thought all that up, and never considered icon_BACKCOL and win_PANE and event_BUTTON and msg_CLOSEDOWN as more useful logical this-makes-loads-more-sense alternatives?
  I fell in a heap trying to get the event handling to work sanely. There’s no bullet point here as this is a memory I’m trying to repress.
• “template” sucks: "The templates are assumed to be held in a file “Templates” in the application’s directory.".
• “msgs” sucks: can’t do parameter substitution. You need to fiddle around with the control block and use the SWI veneers in msgtrans. Lame.
• What the hell is an “unknown” event? Is this like Donald Rumsfeld’s known unknowns?
• What’s all that crap about the program quitting if all active windows are closed? [re: win_activeinc()] This isn’t Windows, you know!

In the end I switched to DeskLib. It had its own bugs, but there was also source so if something didn’t seem right, I could see what the library was doing, rather than relying on documentation that frequently omitted to highlight things that it should have (want an app without an icon bar icon? close that window and the app will quit – re. win_activeinc() above).

Perhaps it’s a consequence of dependencies being readily available from a web site that disappeared overnight

Uh-hu. Been there.

and the author had a nice robots.txt that stopped archive sites like wayback from collecting them.

And there.

In the change to 32 bit, I used two libraries mostly. DeskLib, I converted myself (because I could!), though there is a compatible-for-the-moment “official” version. The other was a little library that I forget the name of that filled in some extra features and provided an easy interface to the sockets and such. Well, that library no longer existed as far as Google could tell me. Gone. archive.org on the old host site? A message saying that it was not permitted to archive that site.
Great.

A bunch of the functions, I rewrote myself. I’m also grappling with SocketLib/InetLib and can’t believe how klutzy the low-level socket interface is. It isn’t hard to use, it just involves more steps than seem necessary. Create? Bind? Listen? Can’t we have one call that does that?

Perhaps it’s a consequence of perfectly good applications that relied on the 32 bit CLib not working on Select

…wait? What ?

because some total arse tweaked Select to not work with the 32 bit CLib

I ought to reply “You’re kidding me, right?” but feel I would be wasting my time…

Whatever it may be, the trust is in using the built in components since those are tested with the rest

Or maybe just that they are supplied.
There’s two ways of dealing with shared components. The first is to have some sort of mechanism to add it to !System. While this is much better than it was, it is something that some people wouldn’t want to start fiddling with. The second? To have a copy inside each application. That’s RISC OS’s version of DLL hell.
I ran into this myself when something (Nettle?) came with a copy of UnixLib that I installed, but then NetSurf refused to run because UnixLib was too old and as it was running it refused to quit.

and can be fixed by the people working on the rest of the OS.

My request for the Internet module to be capable of doing a socket that doesn’t have TCP/IP headers prefixed has so far been met with a resounding silence. ;-)

A different Steve said:

Perhaps, the few, but experienced, hobbyist developers have a ‘not invented here’ bent. I know that I do.

I think, these days, I would be happy to adopt any library that:

• Does what I want
• Is sanely written (RISC_OSLib, you can leave the discussion)
• Is supplied with source code (licence type irrelevant so long as I can use it in my programs)

The last bullet-point is of equal value to the first two. Because with the source, if the developer takes it in a direction that I don’t personally agree with (the well-meaning but seemingly forgotten Desk 3.20; the plan to take DeskLib into the world of elf object files) or if the developer gets in a huff and goes off to be a billionaire writing an app that lets you say “yo”, or if the developer changes their mind and decides to take out all the good features and make them a paid-for upgrade (not on RISC OS, but is becoming depressingly common in the mobile app world), then these upheavals won’t affect me. I’ll be able to carry on using the library.

That said, if I’m writing something small and uncomplicated, it is often quicker to write some veneers in assembler than go to the hassle of hooking in a pre-existing library.

because some total arse tweaked Select to not work with the 32 bit CLib
I ought to reply “You’re kidding me, right?” but feel I would be wasting my time…

Oh, you missed that little short lived episode. I awarded them -10,000 personality points for that one and went for a long walk.