dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/20/86)
It took me about an hour with two wack's running side by side (one wacking the 1.1 RUN, the other the 1.2 RUN) to figure out how they set the process priority to -5 in the 1.2 version. As it turns out, they seem to have put it in a variable (it was a constant load before) and do quite a lot of junk on it (probably to accomodate some aspect of the system invisible to us)... It all boils down to a SUBQ.L #$5, ... The following SR command will replace the SUBQ with a NOP. The initial testing I've done indicates no problems, but yell if you suspect anything: ---------------------------------------------- ** Always keep your original RUN, and only use SR on your working copy ** (1.2 B II) 1> sr run 5B 81 60 00 -r 4e 71 60 00 (1.1 ) 1> sr run 72 fb 60 00 -r 72 00 60 00 NOTE: SR'ing it back (by reversing the search/replace args) works on the 1.2 version. However, it doesn't work on the 1.1 version since your effective replace values occur in other places in the executable. You can get around that by going into wack and finding a larger search/replace set, but the best way to change it back is to simply use the original RUN. --- More notes along the same lines --- Be careful of writing programs that expect a given process priority. For instance, if you write a program which creates another process, and use a busy wait (for some reason) to communicate between the two, they had better be at the same priority or one will get locked out. Thus, it is a good idea to create your sub-process with the same priority as it's parent. This is done easily enough by either looking at your task structure (FindTask(0L)), or, if you don't want to deal with structures: (Cluge, but it works) priority = SetTaskPri(FindTask(0L), 20); SetTaskPri(FindTask(0L), priority); (Aztec users beware of int's bearing gifts) -Matt