I guess it's pretty slick what Windows does. They try to make it appear as if it were a flat memory model to the user, when in effect they are using the paging mechanism for maximum security. So when they allocate memory to a program, they create and keep track of Page tables & PTEs. Believe me. In their system, they must know where the memory is physically located or their would be no file sharing. All processes are allocated through page table entries.
"Flat mode" for 32bit OSes simply means that programs have base=0, limit=4gig memory space, it doesn't imply they should have shared memory space.
Iirc 9x had a single pagetable and patched entries on context switch if the new thread belongs to a different process, whereas NT has per-process pagetables (updates CR3 on thread context switch).
Kernel mode part of the system is always mapped identical for all processes, iirc, this makes things easier.
Iirc 9x had a single pagetable and patched entries on context switch if the new thread belongs to a different process, whereas NT has per-process pagetables (updates CR3 on thread context switch).
Kernel mode part of the system is always mapped identical for all processes, iirc, this makes things easier.
Yeah but in a flat memory model you can limit the size of memory for different processes. Four gig is just the maximum addressable capability. So no, they are not shared. But Windows does not use a flat memory model. They use paging. They allocate memory to a process in 4 Meg & 4 K pages. So they can even hide part a process from it's own self.
Tomato vs. Tomato, mate :)
All the sources I've seen (including intel's PDFs) mention "flat address space" simply as having all selectors BASE=0, LIMIT=4gig, so you can use only a few selectors and share them for all processes... and they call it this regardless of whether paging is in effect or not.
Btw., your forgot about 2meg pages :P
All the sources I've seen (including intel's PDFs) mention "flat address space" simply as having all selectors BASE=0, LIMIT=4gig, so you can use only a few selectors and share them for all processes... and they call it this regardless of whether paging is in effect or not.
Btw., your forgot about 2meg pages :P
Ahhh...this is fun :P Thanks for the memory exercise. I need it. Well you got segmentation as another method of limiting memory in a flat model as well as MTRRs (Memory Types Range Registers). I probably missed a few others too. Never the less, the method that Windows uses is the most secure. Last time I poked around in the TSSs I only saw only 4 Meg & 4 K pages in their Page Dirs. I also found out that when they allocate memory to a process, they don't always allocate it sequencially but a file might have 4K pages scattered through out the memory.
As soon as you introduce segmentation, you're not dealing with flat memory/address space anymore :) - but they're both ways to insulate processes against each other.
One of the points of paging, apart from insulation, is that you can scatter physical memory as much as you want, and still have a coherent & linear virtual address space - which is nice. I don't know whether scattering physical memory has performance penalties, anyone has info on this? I would assume not, since processor cache-lines are much smaller than the smallest pagesize (32/64 bytes vs. 4k).
Btw, while paging is imho the best way to go for x86, maverick suggested an alternate CPU could use some equivalent of MTRRs to isolate processes, while still having a segment-free flat address space, but also having no paging and thus sharing the full address space... interesting idea, but not feasible on x86.
One of the points of paging, apart from insulation, is that you can scatter physical memory as much as you want, and still have a coherent & linear virtual address space - which is nice. I don't know whether scattering physical memory has performance penalties, anyone has info on this? I would assume not, since processor cache-lines are much smaller than the smallest pagesize (32/64 bytes vs. 4k).
Btw, while paging is imho the best way to go for x86, maverick suggested an alternate CPU could use some equivalent of MTRRs to isolate processes, while still having a segment-free flat address space, but also having no paging and thus sharing the full address space... interesting idea, but not feasible on x86.
Oh I'm sure there are performance penalties, but security seems to be a major concern and therefore an acceptable trade off in Windows. Pretty soon they will need all ECL in thier bus logic. Intel seems to be doing a good job creating faster & faste processors. If I remember correctly, A flat model still uses segment registers, they are just able to overlay each other but the limits can still be set in the segment descriptors if desired. Windows does not do this though. Unstead they use paging to limit and protect memory accessability.
Oh I'm sure there are performance penalties, but security seems to be a major concern and therefore an acceptable trade off in Windows.
Paging does incur performance penalty, and so does updating CR3 & flushing TLBs. I dunno how much it is and how noticable it is, but there is some overhead. What I was talkign about, however, was whether it matters, performance-wise, if you use sequential physical pages or not for a sequential linear mapping.
I suppose it doesn't matter, as mentioned previously, since CPU cache lines are much shorter than the 4kb minimum page size.
If I remember correctly, A flat model still uses segment registers, they are just able to overlay each other but the limits can still be set in the segment descriptors if desired. Windows does not do this though. Unstead they use paging to limit and protect memory accessability.
Well, on x86 you cannot disable segmentation, so it's still in effect - however, FLAT model means that all selectors use descriptors that cover the entire memory space, in effects nullifying the use of segmentation (LOGICAL=LINEAR with FLAT memory space).
Sure, you can combine segmentation and paging, but once you start using segmentation, you no longer have a FLAT memory model.
That's what I meant. I'll bet it does effect performance to use non-sequential memory because the MAR (memory Addr Reg) has to be reloaded.
I think the basic premiss behind flat memory is that all segment registers are zero based. I believe segment limits can still be applied in the segment descriptors, meaning limit checks will generate exceptions.
I think the basic premiss behind flat memory is that all segment registers are zero based. I believe segment limits can still be applied in the segment descriptors, meaning limit checks will generate exceptions.
That's what I meant. I'll bet it does effect performance to use non-sequential memory because the MAR (memory Addr Reg) has to be reloaded.
Never heard about MAR, so no clue what that is.
I think the basic premiss behind flat memory is that all segment registers are zero based. I believe segment limits can still be applied in the segment descriptors, meaning limit checks will generate exceptions.
I don't think that would be called flat memory space, though.
And it's certainly not going to be applied on Windows, since the kernel is mapped high there... and doesn't make much sense anyway, when depending on paging for security, since you'll get lovely #PF instead.
Hey Fodder, I felt guilty so you are the first one I am responding to this morning. I should have told you I had to eat. The poor wife feels neglected anyway... ;) But thanks for intellectual excercise (conversation). I think you are just what this board needs. You do push people don't you? Well, got to knock out some work today. I'm not real enthusuastic about it though. After I designed a unit they sold the assembly of it to some one else. I don't really like assembly but the money was there so I got to start over as usual. I'm still mad! :mad: I could have got 20 thousand for lots of 400 and on going income. What I have to do now is inspect their work and show them how to test and make work. Sometimes life just aint fair.
You can get BaseAddress from PEB. For geting Peb use NtQueryInformationProcess with ProcessBasicInformation for selected process.
Much faster way to get PEB.
FS
FS
Much faster way to get PEB.
FS
How does work for getting PEB for remote process? :)
It doesn't - I must have been tired when I wrote that.
It doesn't - I must have been tired when I wrote that.
Happens to us all - I was starting to wonder if you knew something I didn't, though ^_^
You can get BaseAddress from PEB. For geting Peb use NtQueryInformationProcess with ProcessBasicInformation for selected process.
So you use GetProcessID first? Then use the handle?
So you use GetProcessID first? Then use the handle?
No, GetProcessId return process identifier, you need a process handle. Also GetProcessId requires Windows Vista or Windows XP SP1. For geting handle use NtQueryInformationProcess, or ToolHelp API+ OpenProcess.
Are you sure it requires XP? I can't check it now, but I know I used it in 2000. It returned something I was able to use anyway :lol:
Are you sure it requires XP? I can't check it now, but I know I used it in 2000. It returned something I was able to use anyway :lol:
Well, seeq's above post is most likely a reflection of how MSDN has also fallen victim to Microsoft marketing strategies.
I've noticed late last year, or since the newest version of MSDN has been online, that Microsoft has edited MSDN content/entries so that "Client Requirements" indications only mentioned XP and above.
So, in this respect mrgone, you are most likely correct... and this should be a warning to everyone who blindly depends on what MSDN says anymore :P
Seriously though, it sucks that we may not be able to fully depend on future versions of MSDN for older versions of Windows. Keep your archives handy ;)