Get your own Free HomepageOverlay programming allows large programs to fit into limited memory space. Particular procedures are not continuously in RAM (CSeg) but loaded from Disk or EMS upon demand. It is a somewhat outperformed approach today, when people buy computers with 128 MB of RAM to hold their multitasking programs entirely in memory - but there are also serious programmers who hate wasting the resources for coloured images and other flourish...
Very old computers (mainframes) simply relied on the overlay approach, I remember an IBM 3 machine with 16k words of core memory (magnetic). Even on the old CP/M machines with the 8080 and Z80 it was the only way to get some commercial programs running, even the very first WordStar used overlays. Now there are other methods to extend memory, eg. DPMI and other protected mode methods. But they usually NEED physical RAM to be existant. Windows swaps out memory to the disk on demand as an operating system to simulate big RAM memory. This unburdens the application programs of handling this task - but it does not speed up the process too.
Overlays in Turbo Pascal are used in standard DOS applications with the famous 640kB memory limitation in mind.
With Turbo Pascal (written here for Ver. 6 but useful in TP 5.5 and BP 7 too) the overlay handling is automatically performed by the run time code, when certain rules are observed.
First, you must know that TP moves (swaps) the overlay procedures into the heap memory area on demand, not into the code segment (as TP 3 did). Usually the biggest overlay unit determines the amount of reserved heap space for the overlay swap area, but the programmer can extend it to hold more than one unit in the swap area simultaneously. This is described in the TP manuals in more detail.
When using overlays, ALL units and the main program must be compiled to use FAR procedures, this is accomplished with the $F+ compiler switch. The $O+ compiler switch tells the compiler to make the unit aware of being an overlay unit. It need not really be used as an overlay unit anyway.
Programs are best suited for the overlay approach if they have many distinct menu items, which run rather distinct procedures, input dialogues etc. as usual in many commercial applications, eg. customer masks, article handling, printing procedures etc. where is little logical interaction between the procedures.
It is not clever to have all units as overlay units. And you must be aware that units are swapped as a whole. So it can be wise to make rather small units with few procedures or objects. It may be clever to divide an existing unit in two parts, one static and one overlaid.
It is very wise especially to make an initialisation unit and run it as an overlay unit. This unit performs all memory setup, screen options setup, open the static files etc. and a similar approach can be used for final cleanup. These routines do not waste expensive space during the program run.
With Turbo Vision and similar object oriented windowed programs you can get a drawback with overlays, if various distinct windows are on the desktop simultaneously, which can receive some kind of evBroadcast event to .Draw parts of the window frequently as a result of changes in the foreground window. This will make heavy traffic on the overlay swap mechanism. Of course it is not clever to have the status bar procedures in overlays if they display the current time or other frequently changing displays or even worse, the Drivers unit. With objects it can be tedious to split procedures into different units to get smaller units. Sometimes it helps to divide the object in two parts, where the main object inherits methods from its parent in another unit, but this must be done with care and needs much experience.
OVRinitEMS is an optional instruction. TP then tries to copy the .OVR file into EMS memory for speed. Note that the swap area remains on the heap, but the entire .OVR file is maintained in expanded memory. This has two advantages: speed and multiuser / multitasking / networking benefits. The programmer may invoke OvrInitEMS anyway - if no EMS is installed, the user simply does not get the benefits. This is one of the clever usages of EMS memory for TP programs.
The Overlay unit must be initialized before any overlaid
unit can be called. When overlaid units have an initialization procedure
(in the final begin ... end. - clause), which is very usual, then it will
not help to initialize the overlay unit in the main program. Instead you
will need an extra tiny unit which is invoked in front of all other units:
| Program MyProg;
Uses Overlay,OVRunit,CRT,DOS.... ; {$O StdDlg}
|
The Overlay unit is supplied by Borland, OVRunit is made by you,
eg.:
| Unit OVRunit;
{$F+,O+} {it is in fact never overlaid!} Interface
Implementation Procedure OverLayInit;
Begin
|
It is suggested that you first make a good structure of units which you want to be overlaid in your application program. It is possible, but not preferred, that overlaid units call procedures in other overlaid units.
Note that DSeg variables, which are declared in a unit, are alive throughout the program. So you cannot save DSeg space with overlays.
While running procedures in an overlaid unit, the CS: of the CPU points somewhere on the heap. It is not possible to get the physical address of the procedure into a procedure pointer (procedural type) immediately to do some awkward pointing around (like self modifying code...), since the address points into the standard CS area to a special jump instruction which forces the swap mechanism. Yet you can use the procedure address to call the procedure as usual, eg. as a parameter to another procedure and for sophisticated forward declarations...
ANYWAY, you must consider the principle law that anything which gives a benefit has a drawback too. Whoever disputes this law is not serious - or too young to have enough experience!
Jul-03-99: a related posting by Mike
Copeland in the 1QA articles
Get your own Free Homepage