Where is the entry point CS:IP?

[clive]

An example of using 4B03h to load another EXE, written from scratch

TESTAPP.ASM

Code Select Expand

; DOS Overlay example
;  testapp.asm

; Built thusly
;  \masm32\bin\ml -c -Fl testapp.asm
;  \masm32\bin\link16 testapp.obj,testapp,testapp,,,

; Using classical segment definitions for finer control of alignment and ordering

_TEXT   segment para use16 public 'CODE'
_TEXT   ends

_DATA   segment word use16 public 'DATA'
_DATA   ends

STACK   segment para use16 stack 'STACK'
STACK   ends

_OVLY   segment para use16 public 'DATA' ; Paragraph alignment is important
_OVLY   ends

DGROUP  group   _DATA,STACK


STACK   segment
        db      512 dup (?)
STACK   ends


_OVLY   segment
overlay db      32768 dup (?) ; Allocating space to load overlay EXE
_OVLY   ends


_DATA   segment

file    db      "testovl.exe",0 ; Overlay EXE name

param   dw      seg _OVLY ; Load Segment, basically the space at buffer
        dw      seg _OVLY ; Relocation Factor

msg1    db      "Running testapp.asm", 10, 13, "$"
msg2    db      "Leaving testapp.asm", 10, 13, "$"
msgfail db      "Loading overlay failed", 10, 13, "$"

_DATA   ends


_TEXT   segment

_start:

        mov     ax,DGROUP
        mov     ds,ax
        mov     es,ax

        mov     dx,offset msg1
        mov     ah,09h          ; Print String
        int     21h

        mov     dx,offset file  ; ds:dx
        mov     bx,offset param ; es:bx

        mov     ax,4B03h        ; Load Overlay
        int     21h
        jc      _fail

        call    far ptr overlay

        mov     dx,offset msg2
        mov     ah,09h          ; Print String
        int     21h

_exit:

        mov     ax,4C00h ; Quit
        int     21h

_fail:

        mov     dx,offset msgfail
        mov     ah,09h          ; Print String
        int     21h

        jmp     _exit

_TEXT   ends

        end _start


TESTOVL.ASM

Code Select Expand

; DOS Overlay example
;  testovl.asm

; Built thusly
;  \masm32\bin\ml -c -Fl testovl.asm
;  \masm32\bin\link16 testovl.obj,testovl,testovl,,,

        .MODEL  MEDIUM

        .STACK  512 ; Uses the caller's stack, but this stops the linker griping

        .DATA

msg     db      "From the overlay",10,13,'$'

        .CODE

_start: ; Entry point assumed to be _TEXT:0

        push    ds              ; Save DS,ES of caller
        push    es

        mov     ax,@DATA        ; Data segmentation for overlay
        mov     ds,ax
        mov     es,ax

        mov     dx,offset msg
        mov     ah,09h          ; Print string
        int     21h

        pop     ds              ; Restore DS,ES of caller
        pop     es
        retf                    ; Far return back to calling app

        END _start


Run

Code Select Expand

C:\MASM>testapp
Running testapp.asm
From the overlay
Leaving testapp.asm

C:\MASM>

If you needed entry points for the EXE, I think you'd need to load the header manually and examine it. To handle bigger, random sized, EXE files you would again need to examine the header and dynamically allocate enough space for the image (minimum load size). If you used EXEPACK on the overlay, you'd need to call into it to have it unpack itself.

[MichaelW]

The attachment contains another example where the main app and the overlay are both EXEs, the overlay is loaded into allocated memory with the Load Overlay function, and the main app calls procedures in the overlay through a jump table. I included code that shows what the segment structure of the main app is, and what is going on at a memory block level. My command lines were:

ml /Fl /Sa /c filename.asm
link16 /MAP filename.obj

In my example I did not attempt to access the overlay's data segment from the overlay procedures. To do this you would need to preserve the caller's DS, load the segment address of the overlay's data segment into DS, do the access, then restore the caller's DS, for example:

Code Select Expand


push ds
mov ax, SEG xxx
mov ds, ax
mov dx, xxx
pop ds


[FORTRANS]

Hi,

   Thanks to clive and MichaelW for the examples.  I got my code
to work with the load overlay function 4B03.  Paragraph aligned
the overlay load area and changed the loRelocationFactor value.

   A question to japheth or clive; is there a way to obtain the
required .LIB or .OBJ to get the Overlay Manager to work?  Or to
recognize it among the various files/programs I own?

Code Select Expand

LINK : error L2048: Microsoft Overlay Manager module not found

i think there is a DOS function you can call to see how much is available (don't remember - lol)

   You try and allocate a lot of memory and check how much
you got.  Crude and rude. The PSP also holds a value that is
the size of the memory owned by the program.

if not, you can chase the heap allocation header blocks (paragraphs) to the end of 640K

   Walking the memory control block (MCB or ARENA) chain will
tell you the size and what owns each block of allocated memory,
and if there is any left unallocated.  Seems to be a popular exercise
in some of the books I have.

Regards,

Steve N.

[clive]

   A question to japheth or clive; is there a way to obtain the
required .LIB or .OBJ to get the Overlay Manager to work?  Or to
recognize it among the various files/programs I own?

Code Select Expand

LINK : error L2048: Microsoft Overlay Manager module not found

I'm looking at MSC 7.00, there is overlay code in CLIBC7.LIB which came from dos\ovlm6l.asm, also CLIBCE.LIB,LLIBC7/CE.LIB,MLIBC7/CE.LIB,SLIBC7/CE.LIB

The overlay manager is probably in MOVETR.LIB (\src\move.lib)

LINK.EXE 5.30.051

In \C700\SOURCE\MOVE is the source for the overlay manager.

From MOVEAPI.TXT

Code Select Expand

                              MOVEAPI.TXT File

                           Release Notes for the
                    Microsoft(R) Overlay Virtual Environment

                        Released with the Microsoft(R) C
                  Professional Development System, Version 7.0

                  (C) Copyright Microsoft Corporation, 1991


     This document describes advanced features of the Microsoft Overlay
     Virtual Environment (MOVE). MOVE is a dynamic overlay manager
     for use in creating DOS programs with overlays. MOVE is described
     in the chapter called "Creating Overlaid DOS Programs" in the
     "Environment and Tools" manual. This file discusses ways you can
     customize your overlaid program and analyze its performance.


Segments to look for OVERLAY_THUNKS, _MOVETEXT, MOVEINIT_TEXT, OVERLAY_DATA

Code Select Expand

0087 - Typ:0120 sstModule        Mod:0031 Off:000092AC Len:00000024
  11.00000000[00001006]
..\src\move.asm

0088 - Typ:0123 sstPublicSym     Mod:0031 Off:000092D0 Len:000001E8
Size 000001E4
00000004: 0015 0103 S_PUB16              0000   11.0F16 -> 0BEC.00000F16 __movefpause
0000001B: 0015 0103 S_PUB16              0000   11.0F59 -> 0BEC.00000F59 __moveresume
00000032: 0016 0103 S_PUB16              0000   11.0CCA -> 0BEC.00000CCA __movesetheap
0000004A: 0015 0103 S_PUB16              0000   11.0CA5 -> 0BEC.00000CA5 __movegetmem
00000061: 0016 0103 S_PUB16              0000   11.0F18 -> 0BEC.00000F18 __movefpaused
00000079: 0016 0103 S_PUB16              0000   11.0F9B -> 0BEC.00000F9B ___lpfncvhook
00000091: 0013 0103 S_PUB16              0000   11.0BE5 -> 0BEC.00000BE5 $$MOVEINIT
000000A6: 0017 0103 S_PUB16              0000   11.0DD4 -> 0BEC.00000DD4 __movesetcache
000000BF: 0016 0103 S_PUB16              0000   11.0135 -> 0BEC.00000135 ___move_stack
000000D7: 001D 0103 S_PUB16              0000   11.0013 -> 0BEC.00000013 ___move_seg_ovltable
000000F6: 0014 0103 S_PUB16              0000   11.0B8F -> 0BEC.00000B8F ___move_ret
0000010C: 0014 0103 S_PUB16              0000   11.0F1E -> 0BEC.00000F1E __movepause
00000122: 001A 0103 S_PUB16              0000   11.02B7 -> 0BEC.000002B7 ___move_terminate
0000013E: 0015 0103 S_PUB16              0000   11.0027 -> 0BEC.00000027 __moveckbxms
00000155: 001A 0103 S_PUB16              0000   11.02B5 -> 0BEC.000002B5 ___move_stack_ptr
00000171: 0015 0103 S_PUB16              0000   11.0007 -> 0BEC.00000007 __movesegenv
00000188: 0017 0103 S_PUB16              0000   11.0017 -> 0BEC.00000017 ___move_ovlcur
000001A1: 0017 0103 S_PUB16              0000   11.0DAF -> 0BEC.00000DAF __movegetcache
000001BA: 0015 0103 S_PUB16              0000   11.0025 -> 0BEC.00000025 __moveckbems
000001D1: 0015 0103 S_PUB16              0000   11.0950 -> 0BEC.00000950 ___move_load


Code Select Expand

00E1 - Typ:0120 sstModule        Mod:005E Off:0000A1AD Len:00000026
  12.00000000[000001A2]
..\src\moveinit.c

00E2 - Typ:0123 sstPublicSym     Mod:005E Off:0000A1D4 Len:00000019
Size 00000015
00000004: 0013 0103 S_PUB16              0000   12.0000 -> 0CEC.00000006 __moveinit


[FORTRANS]

Hi,

   Thank you.  Unfortunately not a product I have.  As the
other way works, I guess not a big deal.  Especially as I
have no real need for overlays.  But it did look like a much
easier/convenient way of doing things.

Thanks,

Steve N.

[clive]

   Thank you.  Unfortunately not a product I have.  As the other way works, I guess not a big deal.  Especially as I have no real need for overlays.  But it did look like a much easier/convenient way of doing things.

I have PDS (Basic) 7.0 and 7.1 but haven't dug into them much. The MSC 7.0 project is one, of several, that I inherited from the early 90's that used overlays. It seems to work in a simple/painless way, binding them into a single EXE with multiple MZ headers, but you'd have to cluster common functions together for it to be remotely efficient. The projects look to park initialization code, and then different menus and code flow into their own overlays. Personally, I preferred just to use 16 and 32-bit DOS extenders to manage monster projects, or use DOS/EMS for large data structures.

[FORTRANS]

Hi,

   That makes sense.  Overlays seem to be a last ditch
effort kind of thing.  I think that early on some of the
larger FORTRAN programs I had to use were overlayed.
Never wrote one though.  The computers seemed to cope
with things better fairly quickly.  So by the time I wrote
larger programs they could be all in one unit.  So this little
exercise turned out to be fairly interesting.

Cheers,

Steve N.