The "RET x" is to pop the parameter bytes off the stack, not to return a value. If the function takes one parameter, then usually you need a "RET 4".
There are only really two functions in the exe to infect things:
Unit.DoInfect()
Map.SetVirusUL(LOCATION location, int spreadSpeed)
All the DLLs need to call one of those two functions to create the blight. The Unit.DoInfect is used to infect a building without blight being visible on the map, such as in Eden mission 1. The other creates visible blight on the map that will grow from it's starting point. This is the function used by pretty much every level other than Eden mission 1. If you check the DLL code closely you'll see that blight can always be traced back to one of these two calls. There are a few other blight related calls, such as to speed up the spread, but unless you've called one of these functions first, the others won't do anything.
Also, since the exe is the first module loaded in it's address space, it will always get the same load address. Thus you don't really need to search each time since those functions will always be at the same location. Plus, with all the patching we've done, the exe isn't likely to even work if it's loaded to any other address. When we patch code bytes in the exe, we've never bothered to update the relocation table. Should the exe ever get relocated, some patch code won't be relocated that needs to be, and other patch code will get relocated when it shouldn't. We've thinking of stripping the relocation table entirely for the next release. Also, it's become common practice to strip the relocation table from the exe, and only include it in DLLs. There is essentially no chance of exe code being relocated.