Discussion:
What is the use of Cs, Ds, Es, Fs, Gs in Windows ?
(too old to reply)
Eric Minso
2003-08-19 09:39:14 UTC
Permalink
Hello,

I have written many small programs in assembly for Ms-Dos (16-bits of
course) and now I just started with Windows.

I have written an "Hello World" in C and I decompiled it to see the
generated assembly code.

But I don't understand how are used the segments (Cs, Ds, Es...)
They seem to have "strange" values (0x23).

I thought we didn't need these segments anymore because a 32-bit
pointer can reference the whole 4 GB virtual address space, but I
found an 'mov' instruction that explicitly use Cs.

I would like to have any useful information about this subject (Which
values are stored in ? When should we use the segments and when
shouldn't we ?)

Thank you very much !

Eric.
Bryan Bullard
2003-08-19 20:56:22 UTC
Permalink
"Eric Minso" <***@altern.org> wrote in message news:***@posting.google.com...

windows runs with the intel chip in protected mode. the values in cs, ds,
es, fs, gs, and ss contain indices into what's called a global descriptor
table. protected mode is VERY difference than 16-bit real mode. see the
intel docs.

-bryan
Post by Eric Minso
Hello,
I have written many small programs in assembly for Ms-Dos (16-bits of
course) and now I just started with Windows.
I have written an "Hello World" in C and I decompiled it to see the
generated assembly code.
But I don't understand how are used the segments (Cs, Ds, Es...)
They seem to have "strange" values (0x23).
I thought we didn't need these segments anymore because a 32-bit
pointer can reference the whole 4 GB virtual address space, but I
found an 'mov' instruction that explicitly use Cs.
I would like to have any useful information about this subject (Which
values are stored in ? When should we use the segments and when
shouldn't we ?)
Thank you very much !
Eric.
Eugene Styer
2003-08-20 13:57:03 UTC
Permalink
Dennis Bliefernicht <***@triphoenix.de> wrote in message news:<bhu8ap$2kb$01$***@news.t-online.com>...

[snip]
FS = process specific data, somewhere just before 0x80000000
GS = unused
FS is a segment that contains some addresses right before 0x80000000,
where the kernel range starts. Process-specific data is stored there,
the FS is probably just for convenience.
Definitely convenience - with the limited number of registers in the
x86, you want to consider any trick that will free up a register. So
you create a special segment for the process data, and effectively
turn FS into a pointer, thus freeing up another register for more
general use. Changing the "pointer" is awkward, so it is usually
limited to something like a process pointer that doesn't change very
often (in CPU terms).

Eugene Styer
Alex McDonald
2003-08-20 20:14:53 UTC
Permalink
Post by Eugene Styer
[snip]
FS = process specific data, somewhere just before 0x80000000
GS = unused
FS is a segment that contains some addresses right before 0x80000000,
where the kernel range starts. Process-specific data is stored there,
the FS is probably just for convenience.
Definitely convenience - with the limited number of registers in the
x86, you want to consider any trick that will free up a register. So
you create a special segment for the process data, and effectively
turn FS into a pointer, thus freeing up another register for more
general use. Changing the "pointer" is awkward, so it is usually
limited to something like a process pointer that doesn't change very
often (in CPU terms).
Eugene Styer
Windows use of FS is actually even better than that. The TEB (thread
environment block, and sometimes known as the TIB, thread information block)
is pointed by FS:0 and is unique on a per-task (rather than per-process)
basis. It's "documented" (well, declared anyhow) in NTDDK.H. The value of FS
therefore changes with each task switch. (Windows 95 is a little different
from this description -- there's an extensive article on the TIB at
http://www.microsoft.com/msj/archive/S2CE.aspx by Matt Pietrek.)

GS is used for the Processor Control Region (PCR), and is _very_ badly
documented. The only doc I could find on it says "PCR: Processor control
region. An internal data structure in which the kernel stores per-processor
information, and which can be viewed by using debuggers." However,
WINTERNL.H contains a lot of processor information structures; I'm not sure
whether they are part of the PCR or not.
--
Regards
Alex McDonald
Eric Minso
2003-08-21 14:43:20 UTC
Permalink
Thank you for all your answers !!

Eric.

Continue reading on narkive:
Loading...