C for Yourself - part 17

Steve Mumford introduces the ideas behind writing a multitasking application.

Welcome to this month's C tutorial - before we embark on the convoluted route to a fully multi-tasking application, I thought I'd have a look at the changes we'll have to make in order to code a program capable of running in the Desktop. Although by now you should have a good grasp of the ins and outs of the language, there's a whole new range of ideas to consider before we can start knocking windows round the screen.

So far, we've been writing single-tasking programs which operate outside the co-operative multitasking environment of the Desktop - once you've started their execution, they'll carry on regardless until they crash, terminate themselves or get hijacked by a bored user pressing Escape. This is all very well for a simple application, but unless your program is so processor-intensive that multitasking is unfeasible, there's a lot to be gained for writing your code to run in the Desktop.

Benefits of multi-tasking

Implementing a point-and-click interface can increase user friendliness and ease of operation, and the fact that other applications can be executing concurrently removes some of the insularity that can dog a single-tasking application. A good example of this is the use of object linking and embedding to provide the user with a fast way of editing files within files. For instance, Computer Concepts' Impression allows the user to embed an object such as a sprite or a table within a document. A couple of mouseclicks in the right place, and Impression automatically loads the appropriate application, passing the file over. The user can then make any changes as required, and once Impression detects that the modifications are complete, the original file in the master document is updated. This form of interactivity would be particularly difficult to implement in a single-tasking environment.

Another benefit of writing applications to run in the Desktop is that the programmer can make use of the resources already provided - instead of spending time creating a comprehensive cataloguing system so that the user might look through a disc and load a file, you write routines that listen out for the WIMP's broadcast messages. As soon as an icon has been dragged from the standard filer windows to your application, a WIMP message arrives to let you know. All that's required then is a routine that performs the actual loading of the file. This standardisation is particularly helpful for the user - once they've mastered the techniques of moving files about in the Desktop, that knowledge can be applied to the majority of RISC OS applications available.

At this point, we've got our single-tasking application working, and we want to alter it so that it runs under the WIMP system. Several changes will be necessary, but the actual amount will depend on how the source code was written in the first place. A single-tasking program doesn't need a definite program structure since it's got nothing else to contend with. Functions can call each other as they see fit, and there's no way of knowing which point the execution has reached within the code.

The is unsatisfactory in a Desktop program due to the way RISC OS operates its multitasking system. On some computers, multi-tasking is automatically enforced, and there's not much the programmer has to do about it. Once the central controller had deemed that a host application has enjoyed enough run time, it will cut that one dead and move onto the next. In this way, the individual programs don't have to be aware of each other. It's perhaps easier to program for, but there's less communication between the applications.

In Acorn's co-operative multi-tasking environment, it's up to the individual programs to make sure they don't hog the computer's resources. This technique is more flexible, but it requires more housekeeping and tighter program control on the part of the applications running under it - one of the disadvantages of programming the WIMP in C. At the merest hint that you might want an application to run in the Desktop, the sourcecode starts bristling with references to header files that are scattered about your hard disc or - as I endured for some time - across stacks of floppies. This can make it difficult to jump into a program you've not seen before and understand what it's doing, since it's hard to tell whether a function is defined as part of an internal header file or is actually part of a Desktop library.

The main feature of a Desktop program is its polling loop - the section of code that is called each time the WIMP gets round to dealing with your application. When your program gets to the front of the queue, the WIMP passes control back to the polling loop with any relevant information about the state of the program contained in a data block. At this point, the routine should examine any messages the WIMP has handed it, and act accordingly. Any short operations can be executed completely within the polling loop, but drawn-out processes should be split over several polls so any other multitasking applications don't grind to a halt. A 'tame' application will keep an eye on the time it's taking up, and if a delay is unavoidable, it should inform the user by displaying the hourglass.

The big catch

There's one problem to consider before you happily grab your reference manuals and design all manner of weird and wonderful templates. As soon as you add the necessary code to allow your program to run within the Acorn Desktop, your application is no longer portable. If you want to transfer your multi-tasking marvel to another machine, major surgery is required, and although a proportion of your code could remain untouched, a large amount would have to be altered to suit the windowing protocols on the target computer. With this in mind, it is possible to write source code so that these changes are minimised, but this requires both strong knowledge of both prospective compilers and I won't attempt to cover that just yet. Having said all that, I believe the advantages of using the Desktop far outweigh the portability problems encountered, so our next step is to choose a method of programming the WIMP.

Over the next few months I'll look at the methods of building up a multitasking application, starting with the process of initialising the task before moving on to the creation of windows and icons. See you on the Desktop.

Sidebox: "Making the switch"

Depending on which version of C you've purchased, several options will be open to you. Firstly, if you own Acorn's combined C and C++ package, you'll have access to the so-called Toolbox. It's constructed from a variety of relocatable modules whose functions can be called from a number of different languages including C, BASIC and Assembler. One advantage of this system is that the methods for interacting with the Desktop remain the same no matter what language you're using - hoervrt, I'm afraid to say that Acorn's Toolbox manual isn't the most lucid of documents and I caught myself heading for a mental meltdown on a couple of occasions. Older versions of Acorn's C included RiscOS_Lib, a library to add WIMP functionality to C. It's not been widely used, and I'd advise the application of a sizeable bargepole when considering this option.

Beebug's Easy C comes complete with the Freeware package DeskLib, supplying the user with a whole range of C functions that automate some of the processes of running a Desktop application. If you're interested in learning more, a comprehensive reference to the functions it provides can be found in Gareth Boden's CHelp, supplied on last month's cover disc. Easy C++ supplies you with a provisional version of Vista, a class library that makes use of the enhanced features of C++. Again, C++ falls outside the range of this tutorial for the moment, and since I've been informed that Vista will be undergoing some sizeable alterations in the near future, I'll leave that to one side.

There's one more option that might appeal to some of you - why not write your own? Although it requires a fair amount of extra work there are several advantages, including the fact that if you're the programmer behind it, you're less likely to forget what all the function calls do. From my point of view, it will allow me to cover the techniques behind WIMP programming without getting too involved, as well as introducing the concept of creating your own library. It also gives me the opportunity to discuss the methods of making SWI calls from within C.

Tofla note on that last bit:
This article was written in 1995, and WIMP libraries have moved on since then. Today's favoured libraries include Desk and OSLib, and I've probably forgotten others. However, I would also advocate writing your own, if you've been following the series up to this point. It's vital to learn what's going off at the lower level, before you blindly leave it for someone else's library to handle. If nothing else, it'll make you appreciate the amount of work which goes into projects like Desk.

Source: Acorn User - 161 - November 1995
Publication: Acorn User
Contributor: Steve Mumford