Interface With External Modules Second Draft All modules should be made as common executables. Upon execution they will seek up the main task and report for duty. There it will give a list of the functions available. These functions, together with some info about the task they belong to, are added to a shared list maintained by the main task. When the module is told to quit (CTRL-C) it will remove those lines it self from the shared list (which is semaphored ofcause) and quit. This is all the "main" function in the module will do. It will just init, wait and unload. The public functions MUST be able to quit very fast when it recieves a CTRL-C. The "Are you very very very sure" questions is asked by the main task. Other than that it's pretty up to the rest of the functions what to do. Some nifty features that really should be implemented in all modules to make the module unloadable. This can be implemented pretty much how the module author wants. There is a few rules though. By setting the function pointers in the shared list to NULL indicates that the function is not in memory. And by telling the module to flush (CTRL-D) it should evaluate if it's safe to unload. This could f.ex. be implemented as such: A module global integer which is increased everytime a function is called and is decreased before they return. This way one could simply check if this integer is 0 and thus know it's safe to unload. It may be aproperiate to send CTRL-D when you know you don't need that module anymore for a while. The module will get a CTRL-C when the user quits the main program. The main task will have a few semaphores with global data such as GUI data etc. / Fredrik Rambris