Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!comp.vuw.ac.nz!windy!gpwd!gpwrdcs From: don@gp.govt.nz (Don Stokes, GPO) Newsgroups: comp.arch Subject: Re: Self-modifying code Message-ID: <480@gp.govt.nz> Date: 16 Oct 89 12:01:40 GMT References: <6481@pt.cs.cmu.edu> <9175@etana.tut.fi> <1619@atanasoff.cs.iastate.edu> <672@sce.carleton.ca> Organization: Government Printing Office, Wellington, New Zealand Lines: 23 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.