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

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

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"

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.