EXE Header File Relocation Tables
Matt
I am trying to gain a deeper understanding of how exe files (and x86 asm
in general) work and recently have tried to interpret some exe file
headers (nothing commercial, only some example programs, some of my own
and a friend's program with his permission [in Qbasic, which might
explain the sheer number of relocations]). I understand all the basic
entries like blocks used and bytes in last page, but the relocation
table confuses me. From what I understand, when the OS loads a program
into memory with a relocation table, it doesn't just load it in one
chunk into memory, but I'm not sure exactly how the relocations work, I
googled for some info, but the best I could find was on how to load an exe:
8. For each relocation item (ReloCnt):
a. read the item as two 16-bit words (I_OFF,I_SEG)
b. add RELO_SEG=(START_SEG+I_SEG) (find the address of
relocation ref)
c. fetch the word at RELO_SEG:I_OFF (read current value)
d. add START_SEG to that word (perform the segment fixup)
e. store the sum back at its original address (RELO_SEG:I_OFF)
http://www.bsdg.org/SWAG/EXEC/0032.PAS.html
I understand the basics of assembly language. I understand what a mov
and jmp and know about indexing and segmented addressing, but there are
still quite a few fuzzy spots. The part that I don't get is what is at
the RELO_SEG:I_OFF, because from what I understand, START_SEG is a value
determined at runtime (when the os allocates memory for your program).
I vaguely remember some stuff about the program segment prefix from an
assembly book that i lent to someone and never got back ($80 book grr!),
so it seems to me that the relocation table is loaded into memory and
then the addresses are adjusted so they correctly address absolute (or
explicit or whatever the correct term is... the ones that aren't
relative ;-)) addresses in memory wherever the os loaded it, but the
part I don't get is how. How does adding the word pointed to by the
relocation table fix it to reflect the runtime address in memory? are
these file offsets or memory offsets? I would assume they have to be
memory, since they have a segment and index, but what is pointed to by
the segment and index when the relocation table is fixed? I think there
are parts of the exe-loading process that I am missing (which I might
know if I still had my book...) I'd appreciate any information or links
to some good info... perhaps my googling skills are a bit rusty ;-)
Thanx,
Matt
Alex McDonald
news:QIidnUW15Ys...@adelphia.com...
> Hello,
> I am trying to gain a deeper understanding of how exe files (and x86 asm
> in general) work and recently have tried to interpret some exe file
> headers (nothing commercial, only some example programs, some of my own
> and a friend's program with his permission [in Qbasic, which might
> explain the sheer number of relocations]). I understand all the basic
> entries like blocks used and bytes in last page, but the relocation
> table confuses me. From what I understand, when the OS loads a program
> into memory with a relocation table, it doesn't just load it in one
> chunk into memory,
The loader uses memory-mapped files. This effectively allows the pages that
make up the file to be paged in only as they are referred to. The structure
on disk is the same as the structure in memory. This efficency is lost when
there are relocations required, as each relocation fixup causes a page to be
brought into memory. EXE files normally do not have relocation sections, and
are built to run at a specific address (normally 0x40000). DLLs are built to
run at specific addresses too; the loader tries to honour the requested load
address, but if there's something else there, it will load elsewhere and get
its relocations applied. DLLs almost always have relocation sections for
this reason. Qbasic is an oddity if it's generating relocs for an EXE.
> but I'm not sure exactly how the relocations work, I
> googled for some info, but the best I could find was on how to load an
exe:
>
> 8. For each relocation item (ReloCnt):
> a. read the item as two 16-bit words (I_OFF,I_SEG)
> b. add RELO_SEG=(START_SEG+I_SEG) (find the address of
> relocation ref)
> c. fetch the word at RELO_SEG:I_OFF (read current value)
> d. add START_SEG to that word (perform the segment fixup)
> e. store the sum back at its original address (RELO_SEG:I_OFF)
>
> http://www.bsdg.org/SWAG/EXEC/0032.PAS.html
>
> I understand the basics of assembly language. I understand what a mov
> and jmp and know about indexing and segmented addressing, but there are
> still quite a few fuzzy spots. The part that I don't get is what is at
> the RELO_SEG:I_OFF, because from what I understand, START_SEG is a value
> determined at runtime (when the os allocates memory for your program).
> I vaguely remember some stuff about the program segment prefix from an
> assembly book that i lent to someone and never got back ($80 book grr!),
The PSP isn't quite the same; best forgotten in a Windows environment. Also
forget segments; the segments referred to here are segments in the file, not
segment registers. Windows has a flat memory model, and the segment
registers CS DS ES and SS all have the same value.
> so it seems to me that the relocation table is loaded into memory and
> then the addresses are adjusted so they correctly address absolute (or
> explicit or whatever the correct term is... the ones that aren't
> relative ;-)) addresses in memory wherever the os loaded it, but the
> part I don't get is how. How does adding the word pointed to by the
> relocation table fix it to reflect the runtime address in memory? are
> these file offsets or memory offsets?
They're offsets from the load point, called RVAs (relative virtual
addresses). See the articles below for an explanation.
> I would assume they have to be
> memory, since they have a segment and index, but what is pointed to by
> the segment and index when the relocation table is fixed? I think there
> are parts of the exe-loading process that I am missing (which I might
> know if I still had my book...) I'd appreciate any information or links
> to some good info... perhaps my googling skills are a bit rusty ;-)
Try the following (a bit heavyweight, but good).
http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx
http://msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx
http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx
>
> Thanx,
> Matt
>
Alex McDonald
"Alex McDonald" <alex...@btopenworld.com> wrote in message
news:ca2kj9$nod$1...@sparta.btinternet.com...
===snipped
I may have answered the wrong question; was it related to _DOS_ EXE headers?
If so, ignore the answer; my apologies.
--
Regards
Alex McDonald
Robert Wessel
You're referring to DOS (MZ) executables, right?
The only thing that gets relocated are the segment values. For
example, if you had a "mov ds,SOME_SEGMENT" instruction in your
program, the 16 bit constant in the mov instruction would be in the
relocation list.
What happens is that the program is linked as if it were loaded at
location zero. So if you looked in your link map, and you saw that
SOME_SEGMENT was located at 0200(:0000), the instruction above would
be compiled and linked as "mov ds,0200h". When the loader then loads
the program at segment 1234h (since it can't very well load it at
zero), it then adds 1234h to all of the segment values needing
relocation (those are what's pointed to by the relocation table),
which then modifies the above instruction to "mov ds,1434h".
Matt
> "Alex McDonald" <alex...@btopenworld.com> wrote in message
> news:ca2kj9$nod$1...@sparta.btinternet.com...
>
> ===snipped
>
> I may have answered the wrong question; was it related to _DOS_ EXE headers?
> If so, ignore the answer; my apologies.
>
response, I was planning on getting to PE soon anyway. Thanx, the links
look quite informative, I read them more in-depth when I get some time.
Matt
> Matt <moza...@adelphia.net> wrote in message news:<QIidnUW15Ys...@adelphia.com>...
> location zero. So if you looked in your link map, and you saw that
> SOME_SEGMENT was located at 0200(:0000), the instruction above would
> be compiled and linked as "mov ds,0200h". When the loader then loads
> the program at segment 1234h (since it can't very well load it at
> zero), it then adds 1234h to all of the segment values needing
> relocation (those are what's pointed to by the relocation table),
> which then modifies the above instruction to "mov ds,1434h".
Thanx for the info, I think i get the segment part, but the offset part
in the relocation, are those replaced in the same way?
so for example if someone did a...
mov ds, 200h
mov si, 3
;ds: // this should be implicit, right?
mov [si],7
would both the 200h and 3 be fixed, or is the offset something included
in the ds, i.e. mov ds,203h? Neither makes much sense to me right now
since how would the loader know to fix si, since si could be used for
more than indexing (though that is its primary purpose and it wouldn't
surprise me too much if it were the case), and having the index simply
added to the segment address would defeat the purpose of having the
index in almost every case. Anyway, I'll quit rambling now, but thanks
for the help, I appreciate it.
-Matt
Tim Roberts
>
>Thanx for the info, I think i get the segment part, but the offset part
>in the relocation, are those replaced in the same way?
>so for example if someone did a...
>mov ds, 200h
>mov si, 3
>;ds: // this should be implicit, right?
>mov [si],7
>would both the 200h and 3 be fixed, or is the offset something included
>in the ds, i.e. mov ds,203h?
If someone writes "mov ds, 200h", it is fixed and will never be relocated,
because the assembler won't tell the linker to do any relocation.
However, if you do this:
mov ds, seg SomeSymbol
mov si, offset SomeSymbol
where "SomeSymbol" lives in a data segment somwhere, then the assembler
will put in the segment and offset IT knows for SomeSymbol, and it will put
in a linker table that tells the linker that these two words might need to
be adjusted. Both the segment and the offset might need adjusting,
depending on the way the segments are constructed.
The key is not that it is a "mov ds" statement. The key is that you use a
relocatable symbol.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Robert Wessel
> mov ds, 200h
> mov si, 3
> ;ds: // this should be implicit, right?
> mov [si],7
And yes, ds: is implicit in "mov [si],7" (although you typically need
a size qualifier before this will assemble). Most memory references
assume DS, unless bp or sp is used, or in a few instructions (eg. ES
in some string instructions) where such usage is implicit, or in code
references. Note that if you *do* use bp to address memory, you have
to use an explicit ds: prefix to access DS instead of SS.
Robert Wessel
> Thanx for the info, I think i get the segment part, but the offset part
> in the relocation, are those replaced in the same way?
> so for example if someone did a...
> mov ds, 200h
> mov si, 3
> ;ds: // this should be implicit, right?
> mov [si],7
> would both the 200h and 3 be fixed, or is the offset something included
> in the ds, i.e. mov ds,203h? Neither makes much sense to me right now
> since how would the loader know to fix si, since si could be used for
> more than indexing (though that is its primary purpose and it wouldn't
> surprise me too much if it were the case), and having the index simply
> added to the segment address would defeat the purpose of having the
> index in almost every case. Anyway, I'll quit rambling now, but thanks
> for the help, I appreciate it.
No, the offsets are not relocated since the segments (or objects
within segments) are not moved around relative to each other by the
loader.
In your example, the 200h is not going to get relocated either, since
it refers to an absolute address. "mov ds,some_segment" will (unless
the segment is defined as absolute) generate a relocation. "mov
ds,some_segment" might compile and link as "mov ds,200h", assuming
that "some_segment" starts at 2000h bytes into the executable image,
but it'll include the relocation so that it's adjusted for where the
program actually loads.
Robert Wessel
> If someone writes "mov ds, 200h", it is fixed and will never be relocated,
> because the assembler won't tell the linker to do any relocation.
>
> However, if you do this:
>
> mov ds, seg SomeSymbol
> mov si, offset SomeSymbol
>
> where "SomeSymbol" lives in a data segment somwhere, then the assembler
> will put in the segment and offset IT knows for SomeSymbol, and it will put
> in a linker table that tells the linker that these two words might need to
> be adjusted. Both the segment and the offset might need adjusting,
> depending on the way the segments are constructed.
Just so we don't confuse the OP: while the linker may well adjust both
the segment and offset in the process of combining multiple segments,
the relocations performed by the loader will only effect the segments.
Matt
> And yes, ds: is implicit in "mov [si],7" (although you typically need
> a size qualifier before this will assemble). Most memory references
> assume DS, unless bp or sp is used, or in a few instructions (eg. ES
> in some string instructions) where such usage is implicit, or in code
> references. Note that if you *do* use bp to address memory, you have
> to use an explicit ds: prefix to access DS instead of SS.
Thanks for the correction Robert, you guys are great. I am kind of
embarassed that I forgot the word ptr part before the [si], because I
really do know better, I just wasn't thinking, but thanks for being
patient. It is definitely true that the more you learn the more you
want to know, becuase the more I understand the more that I realize
there are other things which I do not understand. The funny thing is
that last night I stayed up late reading Art of Assembly Language to
review and I came across some things in opcode generation (his
dissection of the mov instruction in chapter 4) and a discussion on
addressing (I think this was in the previous chapter, but it's all kind
of mashed together as it was 1:00AM) where that phenomenon was explained
(WOW!, this is like being in Hollywood, without the indecency! Hi
Randall! Hi Hutch! Hi
all-you-other-people-that-are-experienced-but-just-didn't-have-your-names-out-there
-so-I-would-know-you! [didn't want to make anyone feel left out]), it's
kinda funny how quickly this stuff becomes useful, even when you can't
imagine how they'd be related. Anyway, if I may, I still have a few
relevant questions:
1. What is "the process of combining multiple segments" that you refer
to? I know that you can declare various segments and the compiler would
have to do this as well, but do you mean in the process of putting the
executable code and data into the binary image? I am just trying to
reconcile this with what I do understand, so forgive me if I sound
uninformed, because I most likely am.
2. Tim Roberts said that both the segment and the offset are included,
and you have agreed, but say that only the segments are affected, is
this because the offsets should be the same? perhaps I am
oversimplifying, but when the various parts of the program are loaded,
they are loaded into different segments (i.e. a data segment to 1234h
and a code to 4321h or some other arbitrary value), right? so how does
the loader know where in the binary image one segment begins and the
other one ends? And where does the value in the binary image come from?
In my extensive experience (that was a joke, JFYI) you might do
something like this:
mov ds,@data
but what is in the binary image until the address is fixed?
Thank you guys for your help, when I finally get this stuff, I'll write
a tutorial, that way when somebody as confused as me comes back you can
point him to my tutorial and you won't have to belabor yourselves with
so many lengthy, hair-splitting questions, but I can't promise that it
won't turn into a book, since, as you can tell, I tend to be wordy ;-) I
really would like to contribute back in some way like this. But know
that I have tried to keep the questions to a minimal (i.e. I had some
other questions about offset and addr and various things, but I decided
to just RTFM and not bother you with them, but I can't find enough
information on this stuff [if you know where the info is, and don't feel
like answering my questions, you can just point me to it], hence my
justification for asking), but my knowledge of some of this stuff is a
bit rusty because this last year I have been busy with school studying
all sorts of great stuff, so anyway thanks for taking the time to
correct me in some of my stupid errors and answer some of my tedious
questions. I have already fixed some errors in this post and I'm sure
there are more that I didn't find.
Thanks,
Matt
Ivan Korotkov
> to? I know that you can declare various segments and the compiler would
> have to do this as well, but do you mean in the process of putting the
> executable code and data into the binary image? I am just trying to
> reconcile this with what I do understand, so forgive me if I sound
> uninformed, because I most likely am.
If two object files contain segments with the same name and it's combining
type is 'public', they're merged in EXE file. For example, multiple code
segments will be merged, multiple data segments, etc.
> 2. Tim Roberts said that both the segment and the offset are included,
> and you have agreed, but say that only the segments are affected, is this
> because the offsets should be the same? perhaps I am oversimplifying,
> but when the various parts of the program are loaded, they are loaded
> into different segments (i.e. a data segment to 1234h and a code to 4321h
Usually not so far from each other. If free memory is not fragmented,
linker loads them immediately after each other. And, IIRC, code is loaded
first, just after PSP (Program Segment Prefix).
> or some other arbitrary value), right? so how does the loader know where
> in the binary image one segment begins and the other one ends? And where
There is a section table in EXE that defines base offsets and lengths for
all sections.
> does the value in the binary image come from? In my extensive experience
>From linker.
> (that was a joke, JFYI) you might do something like this:
> mov ds,@data
> but what is in the binary image until the address is fixed?
mov ds, 0
Ivan
Robert Wessel
> Thanks for the correction Robert, you guys are great. I am kind of
> embarassed that I forgot the word ptr part before the [si], because I
> really do know better, I just wasn't thinking, but thanks for being
> patient. It is definitely true that the more you learn the more you
> want to know, becuase the more I understand the more that I realize
> there are other things which I do not understand. The funny thing is
> that last night I stayed up late reading Art of Assembly Language to
> review and I came across some things in opcode generation (his
> dissection of the mov instruction in chapter 4) and a discussion on
> addressing (I think this was in the previous chapter, but it's all kind
> of mashed together as it was 1:00AM) where that phenomenon was explained
> (WOW!, this is like being in Hollywood, without the indecency! Hi
> Randall! Hi Hutch! Hi
> all-you-other-people-that-are-experienced-but-just-didn't-have-your-names-out-there
> -so-I-would-know-you! [didn't want to make anyone feel left out]), it's
> kinda funny how quickly this stuff becomes useful, even when you can't
> imagine how they'd be related. Anyway, if I may, I still have a few
> relevant questions:
>
> 1. What is "the process of combining multiple segments" that you refer
> to? I know that you can declare various segments and the compiler would
> have to do this as well, but do you mean in the process of putting the
> executable code and data into the binary image? I am just trying to
> reconcile this with what I do understand, so forgive me if I sound
> uninformed, because I most likely am.
The linker will combine segments based on various rules. As a simple
example, let's say you have two assembler source programs that both
define a (non-private) segment called FRED. The linker will mash the
two FRED segments together, creating a single larger FRED segment.
The offsets in the various programs referencing the FRED segment will
be adjusted. For example, if you had:
In Program_A:
FRED segment...
a dw 0
b dw 0
FRED ends
<code in program_a>
mov ax,b
In Program_B:
FRED segment...
c dw 0
d dw 0
FRED ends
<code in program_b>
mov ax,d
The assembler would, for both programs, generate the mov instruction
with an offset of two, plus relocation information for the linker, all
in the .obj file. The linker will combine the two segments (let's
assume he puts FRED from program_a first), so that you ultimately have
in storage something like:
FRED segment...
a dw 0
b dw 0
c dw 0
d dw 0
FRED ends
Note that this is what the storage looks like, all the of the variable
names are *not* globally visible.
After the linker does this he'll also relocate the offsets in the two
mov instructions. The one in program_a will remain at two, but the
one from program_b will now be six.
> 2. Tim Roberts said that both the segment and the offset are included,
> and you have agreed, but say that only the segments are affected, is
> this because the offsets should be the same? perhaps I am
> oversimplifying, but when the various parts of the program are loaded,
> they are loaded into different segments (i.e. a data segment to 1234h
> and a code to 4321h or some other arbitrary value), right? so how does
> the loader know where in the binary image one segment begins and the
> other one ends? And where does the value in the binary image come from?
> In my extensive experience (that was a joke, JFYI) you might do
> something like this:
> mov ds,@data
> but what is in the binary image until the address is fixed?
As described above, segments and offsets have relocation information
attached in the object (.obj) file passed to the linker. Once the
linker is done creating an .exe, only segment values have relocations.
Using the above example, the offsets in the two mov instructions are
fully relocated by the linker and are fixed in the .exe, and *not*
further relocated.
Assume that there was another segment named BILLY (containing 30
bytes), and the instruction "mov ds,FRED" in the code segment.
Further lets assume that the segments are ordered and linked as
follows (you'd see this in the link map):
BILLY offset:00000h length:30
FRED offset:00020h length:8
CODE offset:00030h length:50 (for sake of argument)
First note that each segment is padded out to a paragraph (16 byte)
boundary, and then stacked end-to-end. This forms a single memory
image 96 bytes long (remember the padding). In an MZ executable there
is *no* distinction between segments, it's just one long string of
bytes. (Note that .obj files most certainly *do* include explicit
segment information).
If you look inside the .exe you'll find the "mov ds,FRED" instruction
assembled as "mov ds,0002h" (note the divide by sixteen of the
offset), plus there would be a relocation entry. The "mov ax,d" from
program_b would be coded as "mov ax,ds:[0006h]".
The loader then loads the program. It just reads the whole 96 bytes
into a contiguous chunk of memory. If it were to load that at
location zero (not actually possible), you'd be all set to go, all the
segment values would be correct. In reality, the program might load
at location 12340h (note that it has to load on a paragraph boundary).
This means all the segment values in the 96 byte image are now too
low by 1234h, so the loader adds that amount to each segment value
listed in the relocation table. So the "mov ds,FRED" would ultimately
end up as "mov ds,1236h". A "mov ds,BILLY" would end up as "mov
ds,1234h", and a "mov ds,CODE" would end up as "mov ds,1237h".
Matt
bit later (probably when I get back from work), but I have to leave for
work in a little bit, so I need to get ready. I really appreciate the
patience you and the others have shown and I'm almost surprised that
nobody's been short with me. (that happened when I posted once on one
of the c/c++ newsgroups, I asked a question about a error I had in some
code and the first response I had back was screaming at me about how I
posted wrong, about how it was too long and blah blah blah, anyway the
ending to the story was I had forgotten to include string.h, but for
some reason the compiler didn't complain about that, it complained about
some other unrelated thing) But anyway, I was wondering if I had
everybody's permission to use these responses when/if I make my tutorial
(I will give credit where it's due if I am allowed). I think it would be
a valuable asset to have a tutorial on program loading because in order
to undersand program loading you must understand a number of concepts,
and so if people try to learn how programs are loaded, they will find
where their knowledge is lacking in a number of areas (unless, of
course, they are a master of assembly language).
But if anyone else feels strongly about creating a tutorial of this
type or extending one of their own, they have my permission to use
anything I've said for instruction (or to otherwise humiliate me ;-) ),
but I doubt that anyone else has that kind of time on their hands,
especially since I'm going to write one. I'm probably going to have to
post it on geocities because I don't have a static IP (otherwise I could
host it on my own computer) so if anybody had any webspace that they
felt like using for this sort of purpose, I could email my completed
page to you when I'm done, (or you could give me ftp access :-) ),
otherwise, I'll just use Yahoo, and their service can be a bit
tempramental as websites and pieces of websites seem to vanish
regularly. Is there some kind of x86 documentation site that would
accept tutorials of this type?
But anyway, before I post any more questions on this subject, I'm going
to do an extensive review on all the related topics that I have info for
(partially to make sure I fully understand it, and partially to organize
my info for the tutorial), and if I still have questions after that (I
will try my best to eliminate them with all the books and tutorials I
can find), then I will ask. Again, I want to thank everyone that
responded especially Robert Wessel becuase he posted most.
Matt
Robert Wessel
> Usually not so far from each other. If free memory is not fragmented,
> linker loads them immediately after each other. And, IIRC, code is loaded
> first, just after PSP (Program Segment Prefix).
>
> > or some other arbitrary value), right? so how does the loader know where
> > in the binary image one segment begins and the other one ends? And where
>
> There is a section table in EXE that defines base offsets and lengths for
> all sections.
Neither of these is true for an MZ (DOS real mode) executable.
There's just a big blob of bytes loaded in a contiguous chuck,
usually, but not always, just after where the PSP is built.
Relocations are applied relative to the load point of said blob.
If were were talking about an NE or PE executable (and a DOS
extender), then yes, there would be a section table.
Tim Roberts
I was just about to object mightily to this statement when I read it more
closely. Are you trying to contrast the linker (meaning the command line
LINK.EXE) with the loader (meaning the MS-DOS component that places a file
in memory)? If so, I withdraw my objection, but I suspect it might be more
confusing to the OP to think about the difference...
Tim Roberts
>
> Thanks a lot for all your help, I'm going to work through this stuff a
>bit later (probably when I get back from work), but I have to leave for
>work in a little bit, so I need to get ready. I really appreciate the
>patience you and the others have shown and I'm almost surprised that
>nobody's been short with me. (that happened when I posted once on one
>of the c/c++ newsgroups, I asked a question about a error I had in some
>code and the first response I had back was screaming at me about how I
Ah, yes. comp.lang.c++. To quote Obi-Wan Kenobi, "you will never find a
more wretched hive of scum and villainy."
Nowhere on Usenet (with the possible exception of talk.politics.guns) will
you find a more angry collection of flaming piranhas, just itching for the
chance to pounce on and devour the hapless newcomer who has the unmitigated
gall to post a question without first becoming an internationally known
author. There is a complete and utter lack of good manners.
There are a large number of very bright and well-respected people on that
newsgroup, but I absolutely refuse to set foot in there ever again.
Although Charles will have my hide for saying so, you would get a much
better (and just as accurate) response by posting your C++ questions on
THIS newsgroup.
Robert Wessel
> >Just so we don't confuse the OP: while the linker may well adjust both
> >the segment and offset in the process of combining multiple segments,
> >the relocations performed by the loader will only effect the segments.
>
> I was just about to object mightily to this statement when I read it more
> closely. Are you trying to contrast the linker (meaning the command line
> LINK.EXE) with the loader (meaning the MS-DOS component that places a file
> in memory)? If so, I withdraw my objection, but I suspect it might be more
> confusing to the OP to think about the difference...
Since the OP asked specifically about the OS loading a program into
memory (and MZ format executables specifically), I think only the
loader is really topical. What's done in preparing the .exe is only
going to confuse things. And as far as that's concerned, MS link.exe
processing OMF style .obj files is only one way to generate an MZ
executable (although admittedly a popular one).
Bob Smith
mov ds,0200h
is not in the instruction set. Have we all been looking at the forest
and missing the trees?
--
_________________________________________
Bob Smith -- bsm...@sudleydeplacespam.com
a.k.a. bsm...@dequalitasspam.com
To reply to me directly, delete "despam".
arargh4...@now.at.arargh.com
<bsm...@sudleydeplacespam.com> wrote:
>Before we go much farther with this topic, let's all recognize that
>
>mov ds,0200h
>
>is not in the instruction set. Have we all been looking at the forest
>and missing the trees?
No but:
mov ds,x200
. . .
x200 dw 0200h
is. Not all that much difference. Just 2 bytes. :-)
4 in PM if you what to crash your program :-)
--
Arargh405 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.