OK. I've got my Workbench running in front of me now. Go to workbench and select Project->Open Workbench Development Shell. This may present you with a couple of options ("Wind River Workbench 3.0" and "Wind River VxWorks 6.3"). Select the Workbench 3.0 option and you'll get a DOS command box.
Next execute: "wrenv -p vxworks-6.3". This sets up your search path so you can run the GNU tools from the command line. In fact, via makefiles, you could compiler your code from here as well, but I digress.
CD to the location where your code was compiled. E.g., for a program called SimpleTemplate, the directory would be something like:
c:\windriver\workspace\SimpleTemplate\PPC603gnu\Si mpleTemplate\Debug\
And the program of interest would be SimpleTemplate.out.
Next, run "nmppc SimpleTemplate.out | less". Hopefully, your WRS environment has "less" in the search path. The output of this program is a list of all of the symbols in the program. You're looking for the "IsEnabled" and "IsDisabled" symbols. You can search for the symbol using the "/ IsDisabled" command. Look here:
http://sourceware.org/binutils/docs/binutils/nm.html for more info on nm.
My quick look shows these symbols as "weak" symbols. This means that if they're linked with a defined version (as would be the case of linking with the main code), then the main code's symbol would take precedence. On the other hand, if the object is loaded during the boot sequence, then there will be two versions of the symbol. One from the ZomB code and one from the main WPILib.
So, what needs to be done is to ensure that the ZomB code uses the WPILib versions of those symbols. This is typically done by making the ZomB reference an "external" reference via the "extern" keyword and making sure that the WPILib version of the symbol is loaded into memory before the ZomB code is loaded. This can be dome by simply changing the order in which the code is loaded.
HTH,
Mike