Had to re-read your last statement AFTER my morning coffee...

If you are using other executables, they'll be multiple files. If you are planning on running multiple Kix scripts, you'd need individual script files - OR - some mechanism to tell Kix which "module" within the single script file to perform. I doubt that the second method will prove reliable enough, or have any benefit to make it worthwhile.

Simply - map your resources, then issue a string of Run commands, one after the other.
 Code:
Run 'avupdate.exe'                ; update antivirus def
Run 'bginfo.exe blah blah'        ; update background with PC data
Run 'kix32.exe kixscript2.kix'    ; run a concurrent kix process to tweak settings

As you see, to benefit from this with other kix scripts, you need to run a separate instance of Kix32. Of course, that will isolate one script from another, so you'll need to pass any needed arguments to it on the command line ($ARG="value"). There will be no way to return data to the main script, since Run spawns a child process via Exec rather than a Fork method. There's no communication path back in this mode. Your scripts can create logs or use INI files if they need to communicate with one another. Of course, that opens issues of concurrent file access.. so its best to only use tasks that are truly independent.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D