Mail Archives: djgpp/1997/09/25/21:25:52
> Okay, I feel there's a vital difference between selectors and segments
> that I'm missing here... a selector exists only in protected mode, can be
> as large as 4GB, and is registered in some global table while segments are
> some arbitrary chunk of fixed-length, real mode memory, correct?
In real mode, a segment can be fully described by one word of data
(the offset/16 of the segment), so that word is stored directly in the
cs/ds/es registers, and they are called segment registers, because
they refer directly to the segment.
Because all possible 16-bit values refer to valid segments, segment
registers in real mode may contain any value.
In protected mode, it takes four words (eight bytes) to fully describe
a segment, which is too much for one register. Instead, a table of
these descriptor structures is stored in memory, and the register
selects one of them instead of referring to the segment directly.
They are thus called selector registers, and the values they contain
are selectors.
Because not all 16-bit values refer to legal descriptor table entries,
you may not load arbitrary values into selector registers
Note that 386 and higher implement real-mode segments with the same
8-byte hardware descriptor. It's possible to switch to protected
mode, set a selector register from a descriptor structure, and return
to real mode *without* reloading the segment register, so that it
continues to refer to the protected mode segment. This is sometimes
known as a "real32" program.
> So if the (supposedly garbage) values of 'es' and 'bx' are outside the
> limits, the function fails, otherwise you get a random read(\write).
If you use arbitrary values in far pointers in protected mode, and
they turn out to be invalid, your program will *crash* because the
operating system (or cwsdpmi) will stop it cold to prevent trashing
the operating system itself.
Since all segment-offset values are valid in real mode, such accesses
will *always* succeed, but may happen to trash your operating system
at the same time.
> > I hope that for v2.02 I will be able to convince The Powers That Be to
> > set the limit back to 1MB (+64KB, to enable accesses to the HMA). But
> > even then, any combination of ES and BX that yields ES*16+BX which
> > doesn't exceed this limit will never trigger any GPF; you just get
> > garbled data when you read that address, and risk crashing the system
> > if you write it.
Yes, 2.02 will have a 1M+64K segment for _dos_ds.
- Raw text -