The EXE-format makes no sense.. 
Author Message
 The EXE-format makes no sense..

I'm compiling a EXE-file with tasm5 (normally i make COM-files) and saw
that if i want to use a certain amount of memory, like:

WavData   db 10000 dup (?)

That than all these zero bytes are included in the final exe-file (10 kb
of only zero's that are not yet data!!). Is this normal or is my code
wrong. I just want to use this amount of bytes later in memory (writen
from a file) and not include them.

Help me out here !

Je//yfi$h



Fri, 15 Feb 2002 03:00:00 GMT  
 The EXE-format makes no sense..

Quote:

>I'm compiling a EXE-file with tasm5 (normally i make COM-files) and saw
>that if i want to use a certain amount of memory, like:

>WavData   db 10000 dup (?)

>That than all these zero bytes are included in the final exe-file (10 kb
>of only zero's that are not yet data!!). Is this normal or is my code
>wrong. I just want to use this amount of bytes later in memory (writen
>from a file) and not include them.

>Help me out here !

>Je//yfi$h

This is normal behavior. The 'db N' compiler directive reserves N
bytes in the program. This is usually used to provide space for small
amounts of data.

If you wish to use large amounts of data, you need to either:
A) request it via an operating system call  (in C, this is 'malloc')
B) make some space by adjusting the stack pointer, either directly, or
via lots and lots of 'push' instructions.

Which you use depends on your particular circumstances. (i.e.,
single-user, embedded OS, or multi-user, multi-tasking OS)

Hope this helps,
Anthony J. Albert



Fri, 15 Feb 2002 03:00:00 GMT  
 The EXE-format makes no sense..
The only way a DB (or equivalent) statement doesn't translate to an
actual byte in the resulting EXE file is if the data statement uses the
form nnn dup (?) as in your

WavData   db 10000 dup (?)

and that data statement appears at the end of the EXE file possibly
followed by other nnn dup (?) statements.

This behavior occurs because the assembler does not generate any OMF
records for statements of this type, so the linker has no data to save
in the EXE file.  As long as the linker sizes the EXE file based on
actual data generated rather than the reported segment sizes, the EXE
file can be smaller.

Quote:

> I'm compiling a EXE-file with tasm5 (normally i make COM-files) and saw
> that if i want to use a certain amount of memory, like:

> WavData   db 10000 dup (?)

> That than all these zero bytes are included in the final exe-file (10 kb
> of only zero's that are not yet data!!). Is this normal or is my code
> wrong. I just want to use this amount of bytes later in memory (writen
> from a file) and not include them.

> Help me out here !

_________________________________________


I've been getting a lot of junk e-mail lately,
so to reply to me directly, delete "despam".



Fri, 15 Feb 2002 03:00:00 GMT  
 The EXE-format makes no sense..

Quote:

> The only way a DB (or equivalent) statement doesn't translate to an
> actual byte in the resulting EXE file is if the data statement uses the
> form nnn dup (?) as in your

> WavData   db 10000 dup (?)

> and that data statement appears at the end of the EXE file possibly
> followed by other nnn dup (?) statements.

> This behavior occurs because the assembler does not generate any OMF
> records for statements of this type, so the linker has no data to save
> in the EXE file.  As long as the linker sizes the EXE file based on
> actual data generated rather than the reported segment sizes, the EXE
> file can be smaller.

When using the simplified directives, these statements need to be in the
.data? or the _BSS segment to achieve this.

Ray



Fri, 15 Feb 2002 03:00:00 GMT  
 The EXE-format makes no sense..
: I'm compiling a EXE-file with tasm5 (normally i make COM-files) and saw
: that if i want to use a certain amount of memory, like:
:
: WavData   db 10000 dup (?)
:
: That than all these zero bytes are included in the final exe-file (10 kb
: of only zero's that are not yet data!!). Is this normal or is my code
: wrong. I just want to use this amount of bytes later in memory (writen
: from a file) and not include them.
:
: Help me out here !

Jelle, I believe what you want to do is called dynamic allocating, where
*during program run* you want to use those amount of bytes. Am I right? If so,
you may want to look into XMS or EMS programming, as they handle all of your
luscious free RAM, although it's *right* to use EMS exclusively, it really is
program specific whether or not to use XMS. Later, when you don't need this
memory, you can simply deallocate it with the handle # DOS gives ya.

Or you can just allocate memory via DOS if ya wanted, but it sounds cooler if
you make use of extended/expanded memory :)

Hope this helps.

--

Yours,

** leadGUITARIST for machineDEGENERATE **

EMail: MDLeadG at HotMail dot Com
ICQ: 46559580



Sat, 16 Feb 2002 03:00:00 GMT  
 The EXE-format makes no sense..


Quote:
> The only way a DB (or equivalent) statement doesn't translate to an
> actual byte in the resulting EXE file is if the data statement uses
the
> form nnn dup (?) as in your

> WavData   db 10000 dup (?)

> and that data statement appears at the end of the EXE file possibly
> followed by other nnn dup (?) statements.

> This behavior occurs because the assembler does not generate any OMF
> records for statements of this type, so the linker has no data to save
> in the EXE file.  As long as the linker sizes the EXE file based on
> actual data generated rather than the reported segment sizes, the EXE
> file can be smaller.

   That's right, but not enough for most DOS linkers. Even if you don't
have any initialized data in a segment, they will consider it as
dynamic placeholder only if it has a 'STACK' or 'BSS' class name or 'AT
nnn' attribute.

-- The world is full of kings and queens
That blind your eyes and steal your dreams --
[Black Sabbath]

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sat, 16 Feb 2002 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Making sense of CWFAULT

2. Where OOP makes sense

3. Making Sense

4. UNIX REXX makes sense

5. Making sense of [un]signed arithmetic and bit widths

6. Making sense of Stackless

7. making the exe readonly / exe in a network

8. Making exe smaller

9. Tip: Making your EXE or DLL smaller

10. Making an *.EXE out of a Object Rexx script

11. Making exe

12. Making EXE/COM files from RM-Cobol

 

 
Powered by phpBB® Forum Software