Re: BDS2006 exe sizes

On Fri, 24 Feb 2006 17:12:35 +0000, Dodgy
<Dodgy@xxxxxxxxxxxxxxxxxxxxx> wrote:

On Fri, 24 Feb 2006 12:48:08 +0000 (UTC), erewhon@xxxxxxxxxx (J
French) waffled on about something:

On Thu, 23 Feb 2006 17:00:28 +0000, Dodgy
<Dodgy@xxxxxxxxxxxxxxxxxxxxx> wrote:

<snip>

If memory serves me right, in DOS 8086 assembly this would be less
that 20 bytes, most of them being the string itself.

Actually I get 26 bytes

CODE SEGMENT PARA PUBLIC 'CODE'
ASSUME CS:CODE,DS:CODE,ES:CODE
ORG 100h

BEGIN:
lea DX, Msg
mov AH, 9
int 21h

mov AH, 4Ch ; ===== EXIT to DOS ===>
int 21h

Msg db 'Hullo World',13,10,'$'

CODE ENDS
END BEGIN

Using Int 20h to exit actually comes out at 27 bytes

I suppose one could lose the 13, 10
- yes that is fine, down to 24 bytes

You don't need the function 4c on to exit on the end either, just
exit. 1 left to loose.

Heh, I tried that, there are two problems, the first is that one needs
to move: Msg db 'Hullo World',13,10,'$'

If it goes to the top, then you need a Jmp instruction before it,
otherwise you can't convert the EXE to BIN (COM)
- I had a bit of fun proving that
(its a few years since I did any heavy DOS ASM coding)

The second problem is nastier, without Int 20h or Int 21h, 4C
my MSDOS Box freezes
- figures as CS:IP just charges into undefined memory.

Using RET works fine, but that bounces the code size back up to 26
bytes. Very annoying.

Of course using RET makes the COM file more versatile, things like
Foxpro for MSDOS (and probably DBASE, Clipper etc) used to allow you
to load COM files as pseudo DLL's, in which case the RET returns
control back to the caller.

However, since I've never used those monstrosities, and don't intend
to start now, I think that the 'versatility' feature, is not really
required.

Perhaps it is inconsiderate of me, depriving posterity of such a
useful routine ... <g>




.

Relevant Pages