greatings to everyone :-) i'm kinda new here (been readn around for a
while though) and this is my first question, so please be patients :-)
this is the msdos exe file structure and under each section there is a
couple of questions but before here are some notes referred to by some
question later in the message:
[1] what i mean by mis-aligned references is given by this example
where the the 16-bit offset from the beginning of the exe file of the
reallocation table field has value away beyond the size of the msdos
exe file header which creates an unnecessary gap of unactually used
bytes and so may go for the 16-byte-aligned 16-bit offset of the
initialized stack area field and also the one of the
code-initialized-data area field
[2] what i mean by the exe program image is remainder data in the exe
file after excluding the msdos file header, the reallocation table, any
unnecessary gaps due to mis-aligned references, and any extra added
later (after linking the exe file) at the end of the exe file (off
course giving the assupmtion that this exe file is actually a pure
msdos exe file not for example a PE-kinda exe file)
[3] what i mean by the logical analisis is that when msdos exe program
loader loads the exe file, it sets the DS and ES (i don't know about
the FS and GS, somebody would mention something about them :-p, i guess
they were unsup****ted by that time) to point to the PSP area and since
there is not distinguisable and separate initialized data area defined
in the msdos exe file header, there is not way, i believe, to refer to
the initialized data area other then have it contiguous to the code
area in memory, am i right :-) ?
signature
* is there any difference between MZ and ZM ? then why do we have two
of them ?
* is there, for any reason, more of those ? what for ?
# of bytes of last 512-byte block of the exe file
* now does the number 512 have to do with the sector size of the hard
disk drive or even with the paging-loading-on-demand mechanism (for the
sake of faster and more convenient loading of the exe file from hard
disk drives into memory, maybe) ? then why 512 specifically (to
overcome the 16-bit limitation issue) ?
* what if i had a value larger than 512 (that is larger than 200h) ?
* i've read in some do***ents that a value of 0 (0h) would be
interpreted by the exe program loader to mean the whole last 512-byte
block is actually used by the exe file, okey then does that mean having
0 (0h) has the same effect as having 512 (200h) in this field ?
# of 512-byte blocks in the exe file
* this should include the size of the header, the size of the
reallocation table, and the size of the actual exe program (that is
data, code, and stack program data) besides any wasted bytes here and
there due to mis-aligned references [1], is that right ?
* now if i added some extra data at the end of the executable file and
then adjusted this field to include it (i mean added the size of this
extra data to the actual value of this field), where would the loader
load this data, i guess it would be part of the initialized stack data
segment then, right ?
# of reallocation entries in the reallocation table
* i've noticed some variations regarding the size of each entry and the
actual structure of them, some say it is a 16-bit value being the
offset of the must-reallocated reference from the beginning of exe
program memory image's memory address [2] and some say it is a 32-bit
value being the actual segment:offset value of the must-reallocated
reference also related to the beginning of the exe program memory
image's memory address [2], now what is the size and structure of these
entries exactly and how is it interpreted by the exe program loader,
for example, is it from the beginning of the exe program memory image's
memory address ?
* as the exe file can be as big as the available memory can hold, it is
possible to run out of these entries (i mean the field is only 16 bit
in size allowing only 65536 references to be reallocated at load time),
so is there something can be done about this ?
# of 16-byte blocks in the exe file msdos header
* why exactly 16 bytes (to overcome the 16-bit limitation issue) ?
* does the size of this header include the size of the reallocation
table ? actually, i've noticed some say ya !
# of the minimum extra 16-byte memory blocks needed by the exe program
* this must be used for the uninitialized data variables including any
uninitialized extra stacks if needed, am i right ?
* where these extra blocks would be allocated at in memory, is it after
the PSP area and before the exe program memory image [2] ? then where
exactly ?
* is it true that msdos exe program loader ignores this field and only
look at the maximum field (that is the next field) ?
# of the maximum extra 16-byte memory blocks needed by the exe program
* is it true that msdos exe program loader would reserve the whole
available memory to the exe program if the value of this field is 65536
(ffffh) and otherwise it would reserve the exact value indicated in it
?
a 16-byte-aligned 16-bit offset which has to do with the SS
* is this offset related to the beginning of the exe program memory
image [2] or somewhere else ? and why 16-byte aligned exactly (to
overcome the 16-bit limitation issue) ?
* what indicates the maximum size of the initialized stack area, is it
the value in the initial SP value field in the exe file header
(mentioned later in the message) or the value calculated by subtracting
the actual position offset of this initialized stack area in the exe
file from the exe file actual size (not the 512-byte segmented size) ?
maybe it has to do also with the extra uninitialized data needed by the
exe program, don't know, does it ? then what ?
* this must be the initilized stack data area, but i'm wondering where
the exe program loader would load this area (in case it is smaller than
the maximum stack size), at the end of the stack , the initial top of
the stack (the initial SP value), or at bottom of the stack ?
* is it possible to have the initialized stack area loaded by the msdos
exe program loader at a memory address not contiguous with the program
code-initialized-data area (mentioned later in the message) ?
the initial value of SP
* no questions :-)
checksum
* is it used by the exe program loader ?
* is it one's or two's complement sum ?
the initial value of IP
* also no questions :-)
a 16-byte-aligned 16-bit offset which has to do with the CS
* same question really, is this offset related to the beginning of the
exe program memory image [2] or somewhere else ? and why 16-byte
aligned exactly (to overcome the 16-bit limitation issue) ?
* i'm not really sure but obviously with some logical analisis of the
msdos exe file structure [3], the code and initialized data areas of
the exe program must be contiguous in the memory when loaded by the exe
program loader which means this field actually points to both the code
and the initialized data areas of the exe program, am i right ?
* now what indicates the size of the code-initialized-data area, is it
the value calculated by subtracting the actual position offset of this
area in the exe file from the actual position offset of the initialized
stack area in the exe file (mentioned above in the message) ?
a 16-bit offset from the beginning of the exe file of the reallocation
table
* some do***ents indicate that the msdos exe program loader ignores
this field by assuming the reallocation table to be allocated directly
after the msdos exe file header in the exe file, is that right ?
overlay number
* i don't knot exactly what that is because most do***ents descrip it
to be obsolete and therefore should be all zero, but i'd appreciate a
little histroy if available :-)
and that's all about it :-p ... i hope i have not been annoying ...
thanks a lot
|
