🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2660

Re: Self-modifying code

#2660
From: Robert Cousins
Date: Tue, 17 Oct 1989 17:01
56 lines
3488 bytes
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
> <program> 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
> <program> 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.
Technical Details
Message-ID: <218@dg.dg.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!dg!sisyphus!rec
References: <480@gp.govt.nz> <6481@pt.cs.cmu.edu> <9175@etana.tut.fi> <1619@atanasoff.cs.iastate.edu> <672@sce.carleton.ca>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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