Static self-relocation typically happens at load-time (after the operating system has loaded the software and passed control to it, but still before its initialization has finished), sometimes also when changing the program's configuration at a later stage during runtime.
[5][6] In 1988, the alternative command line processor ZCPR 3.4 for the Z-System introduced so called type-4 programs which were self-relocatable through an embedded stub as well.
In addition, advanced self-relocating TSRs (even if already loaded into upper memory by the operating system) can relocate over most of their own PSP segment and command line buffer and free their environment segment in order to further reduce the resulting memory footprint and avoid fragmentation.
[13] If the shared code is not designed to be position-independent, it requires some form of internal address fix-up similar to what would otherwise have been carried out by a relocating loader already; this is similar to the fix-up stage of self-relocation but with the code already being loaded at the target location by the operating system's loader (instead of done by the driver itself).
Sometimes multiple versions of a program were maintained, each built for a different load address (partition).