I've read all the documentation related to Windows' memory management on MSDN, but it's really not clear.
I would like to know the name of the memory model as they are named in Intel architechture software developper manual volume 3.

I wonder if Windows is using a basic flat model a protected flat model or a multisegment model. According to Microsoft, it should be one of the flat models, but the description looks much more like the multisegment model because each process seems to have it's own adress space.
Moreover the use of a debugger allowed me to se that the segment selectors DS and SS are equal but differents from CS. How comes that there are two different segment selectors if ther is only one linear 4 GB large adress space for each process ?

The use of pages is rather clear to me, but I'm totally lost with the segments under windows. How many segments are used for each process, why does Microsoft say there is ONE 4 GB larg space of virtual memory for each process if they are TWO segments ?

I'm really confused, any help would be greatly appreciated
Posted on 2001-10-29 22:34:03 by ringzero
Windows runs in a protected-flat mode. Windows uses segmenting and paging together (i.e. virtual memory). Linear address space has nothing to do directly with the logical addressing mechinism. Logical addresses consist of a 16-bit segment selector and a 32-bit offset. The segment selector is used to retrieve the location of the segment in the linear address space and then the offset is added to that point to find the exact address location in the linear address space. As for the segment selectors, they are 6 of them, of those only the CS DS and SS are the most important. The CS (Code Segment) register points to code related segments in memory, as do DS (Data Segment) and SS (Segment Selector) respectively. The segments are used in conjunction for varoius things.... also, it could be used much differently than what it is commonly used for, as I am soon about to prove with my kernel design ;). If you want to truely understand how Windows uses these registers and other things, you should refer to the Intel System Programming manual for the basis of where Windows gets its ideas for these useages.
Posted on 2001-10-29 23:19:27 by SpooK

Windows in 32 bit uses a flat memory model in protected mode. Each running process has its own seperate memory space and they normally cannot address memory in another process.

Any attempt to directly address memory outside the memory allocated to the running process generates a read or write page fault and this is the action of protected mode memory management. Segments do not have a place in 32 bit programming at the application level. If you attempt to address memory with a segment/offset addressing method, it will come down with a thud.

Segments are normally set to the same address in flat memory model protected mode. The format for EXE files in win32 is the PE format and this uses both code and data within the same memory space. This makes windows PE files similar to the old DOS COM files where you could mix data and code in the same segment, the effective difference is that a PE file in 32 bit can address a nominal 4 gig address space.

Probably what would be useful to you is to get some data on the PE format as this will help you in what you are after.


Posted on 2001-10-30 02:11:18 by hutch--
As a related question, are segment registers "OK" or "bad" to use in a Windows application, and why/why not? I'm a little confused too.
Posted on 2001-10-30 10:22:59 by Irving W.
It's not possible to run in "native" 32-bit mode unless the x86 is in protected mode. "Native" mode means there are no opcode prefixes for 32-bit adds, subtracts, moves, etc.

In protected mode, segment registers are loaded with selectors, not paragraph values.

Two selectors are needed because executable code must use a code selector, and you can't write to memory via a code selector. So you need a data selector for writable memory. Because of the way these two selectors are mapped in the flat model, they are really aliases to each other.

There is actually a third selector (loaded in FS) for identifying threads. It is not mapped as an alias to the other two selectors.


The loader sets up the segment registers for the flat memory model. It's not Windows that uses flat model, but your application. You have direct access only to the memory space set up by the segment register settings.

Part of a selector is an index into a table of descriptors. If you cannot modify this table, then you cannot create a new valid selector. There is no API to access this table. This is the main reason why you don't want to change the segment registers.

When you work with SEH (Structured Exception Handling), you will use FS to override the default segment. There is no other (easy) way to access the thread-specific information.

In general, there is no real need to use any other segment overrides. There are two special cases I can think of: 1) writing to "code" space, and 2) accessing a fixed data location.

Writing to code space is discouraged because it prevents sharing of executable code. It also means that when a code block is paged out, it must be stored on disk (in a swap file) rather than discarded. Reloading the paged out code comes from the swap file instead of the original executable file. Writing to disk takes time.

Accessing a fixed location is also discouraged because what is located at location xyz in Win98 may be located elsewhere in Win XP. It might not even be accessible (from ring3) in XP.
Posted on 2001-10-30 14:28:37 by tank