Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!dg!sisyphus!rec From: rec@sisyphuscpd4 (Robert Cousins) Newsgroups: comp.arch Subject: Re: Self-modifying code Message-ID: <218@dg.dg.com> Date: 17 Oct 89 17:01:37 GMT References: <480@gp.govt.nz> <6481@pt.cs.cmu.edu> <9175@etana.tut.fi> <1619@atanasoff.cs.iastate.edu> <672@sce.carleton.ca> Sender: root@dg.dg.com Reply-To: rec@sisyphuscpd4 (Robert Cousins) Organization: Data General Lines: 56 In article <480@gp.govt.nz>, don@gp.govt.nz (Don Stokes, GPO) writes: > In article <672@sce.carleton.ca>, cassel@sce.carleton.ca (Ron Casselman) writes: > > I seem to remember a piece of self-modifying code that used to run > > on CP/M. I remember it because I had to disassemble it as an assignment for > > a course in systems software. The program would copy itself to a different > > part of memory and change all address references as it did so. It would > > then load a second program into the original location. (all programs > > under CP/M started at a fixed location). The second program would then > > begin to run. Sorry I cannot remember any more details as to the purpose > > of this self-modifying code. > > Sounds a little like DDT (Dynamic Debugging Tool). If you type DDT > DDT starts itself up at the bottom of the TPA (at this stage, > DDT is just a normal COM file), slides itself into high memory and loads > from disk into the bottom of the TPA so that the program > doesn't know that DDT is there. Since DDT has to run in many different > memory sizes, it would have to relocate itself dynamically (this is based > on observation of my trusty Kaypro II, not an actual study of the code). > > Don Stokes ZL2TNM / / vuwcomp!windy!gpwd!don > Systems Programmer /GP/ Government Printing Office PSI%0530147000028::DON > __________________/ /__Wellington, New Zealand__________don@gp.govt.nz________ > Those who believe their systems are idiot-proof just do not realise how > ingenious idiots can be. Actually, there were a whole family of relocating programs under the CP/M family of operating systems. A common trick was to use PRL (Page ReLocatable) images. This was created by assembling (!) the programs at two different origins (typically 0 and 100h) and taking the difference between the two images. This was used to create a bitmap which could be used by the loading program to assign the final location to the changed bytes. Code of this form could be executed at any page (page = 256 bytes) boundry. MP/M codified this for running two programs in one 48k bank. One partition began at 0000h (and programs loaded at 100h) while the other began at a higher location. COM and PRL files could run at 100h, but PRL files only could be run at the higher addresses. The process of configuring the kernel involved relocating it by this same technique. Some companies used it for working with their BIOS also. The technique was never highly popular, however, since people rarely needed to change the base address of their code but were unable to relink it. I personally preferred the TurboDOS operating system. It was compatible with CP/M but approximately 6 times faster on file operations, multiuser and multiprocessor. I still have a TurboDOS machine at home. Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone.