Incomputer programming, aself-relocating program is a program thatrelocates its own address-dependent instructions and data when run, and is therefore capable of being loaded into memory at any address.^[1][2] In many cases, self-relocating code is also a form ofself-modifying code.

Self-relocation is similar to therelocation process employed by thelinker-loader when a program is copied from external storage into main memory; the difference is that it is the loaded program itself rather than the loader in theoperating system orshell that performs the relocation.

One form of self-relocation occurs when a program copies the code of its instructions from one sequence of locations to another sequence of locations within the main memory of a single computer, and then transfers processor control from the instructions found at the source locations of memory to the instructions found at the destination locations of memory. As such, the data operated upon by the algorithm of the program is the sequence of bytes which define the program.

Static self-relocation typically happens atload-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 duringruntime.^[3][4]

As an example, self-relocation is often employed in the early stages of bootstrapping operating systems on architectures likeIBM PC compatibles, where lower-level chainboot loaders (like themaster boot record (MBR),volume boot record (VBR) and initial boot stages of operating systems such asDOS) move themselves out of place in order to load the next stage into memory.

UnderCP/M, the debuggerDynamic Debugging Tool (DDT)dynamically relocateditself to the top of available memory throughpage boundary relocation in order to maximize theTransient Program Area (TPA) for programs to run in.^[5][6]

In 1988, the alternative command line processorZCPR 3.4 for theZ-System introduced so calledtype-4 programs which were self-relocatable through an embedded stub as well.^{[7][8][9][10][11]}

UnderDOS, self-relocation is sometimes also used by more advanceddrivers andresident system extensions (RSXs) orterminate-and-stay-resident programs (TSRs) loading themselves "high" intoupper memory more effectively than possible for externally provided "high"-loaders (likeLOADHIGH/HILOAD,INSTALLHIGH/HIINSTALL orDEVICEHIGH/HIDEVICE etc.^[12] since DOS 5) in order to maximize the memory available for applications. This is down to the fact that the operating system has no knowledge of the inner workings of a driver to be loaded and thus has to load it into a free memory area large enough to hold the whole driver as a block including its initialization code, even if that would be freed after the initialization. For TSRs, the operating system also has to allocate aProgram Segment Prefix (PSP) and anenvironment segment.^[13] This might cause the driver not to be loaded into the most suitable free memory area or even prevent it from being loaded high at all. In contrast to this, a self-relocating driver can be loaded anywhere (including intoconventional memory) and then relocate only its (typically much smaller) resident portion into a suitable free memory area in upper memory. 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 resultingmemory footprint and avoidfragmentation.^[14] Some self-relocating TSRs can also dynamically change their "nature" and morph into device drivers even if originally loaded as TSRs, thereby typically also freeing some memory.^[4] Finally, it is technically impossible for an external loader to relocate drivers intoexpanded memory (EMS), thehigh memory area (HMA) orextended memory (viaDPMS orCLOAKING), because these methods require small driver-specificstubs to remain in conventional or upper memory in order to coordinate the access to the relocation target area,^{[15][nb 1][nb 2]} and in the case of device drivers also because the driver's header must always remain in the first megabyte.^[15][13] In order to achieve this, the drivers must be specially designed to support self-relocation into these areas.^[15]

Some advanced DOS drivers also contain both a device driver (which would be loaded at offset +0000h by the operating system) and TSR (loaded at offset +0100h) sharing a common code portion internally asfat binary.^[13] If the shared code is not designed to beposition-independent, it requires some form of internal address fix-up similar to what would otherwise have been carried out by arelocating 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).

IBMDOS/360 did not have the ability to relocate programs during loading. Sometimes multiple versions of a program were maintained, each built for a different load address (partition). A special class of programs, called self-relocating programs, were coded to relocate themselves after loading.^[16] IBMOS/360 relocated executable programs when they were loaded into memory. Only one copy of the program was required, but once loaded the program could not be moved (so calledone-time position-independent code).

As an extreme example of (many-time) self-relocation, also called dynamic self-relocation, it is possible to construct a computer program so that it does not stay at a fixed address in memory, even as it executes, as for example used inworm memory tests.^{[17][18][19][20]} TheApple Worm is a dynamic self-relocator as well.^[21]

• Dynamic dead code elimination
• RPLOADER - a DR-DOS API to assist remote/network boot code in relocating itself while DOS boots
• Garbage collection
• Self-replication
• Self-reference
• Quine (computing)

• Harrell III, John B. (October 1983)."DOSPLUS 3.5".80 Micro. Review (45).1001001, Inc.: 160, 162,164–168, 170.ISSN 0744-7868. ark:/13960/t8z906r42. Retrieved2020-02-06.[20][21]
• Smith, Lee; Haines, Lionel (1989-02-02) [1987-08-14].RISC OS Application Image Format (previously Arthur Image Format) (Technical Memorandum) (1.00 ed.). Cambridge, UK:Acorn Computers Limited, Programming Languages Group. PLG-AIF.Archived from the original on 2017-08-30. Retrieved2017-08-30.
• Properties of ARM Image Format. 1993.Archived from the original on 2017-08-31. Retrieved2017-08-31.
• Huck, Alex (2016-08-14)."Nachladbare Treiber unter CP/M - PRL2COM".Homecomputer DDR (in German).Archived from the original on 2020-02-21. Retrieved2020-02-21;Pohlers, Volker (2017-04-24) [2012-02-20, 2009, 2002, 1988-07-26, 1987-10-11]."PRL2COM".Homecomputer DDR (in German).Archived from the original on 2020-02-21. Retrieved2020-02-21.

• Computer programming

• CS1 location test
• CS1 German-language sources (de)
• Articles with short description
• Short description matches Wikidata
• Use dmy dates from April 2019
• Use list-defined references from December 2021