Alex Ionescu wrote:
That was my point. Since Win32 exes need to load ntdll, that's why it's marked as such.
What I was trying to say is that ntdll could easily be marked for the native subsystem and it would change nothing. AFAIK, LoadLibrary() does not check the subsystem tag, so win32 apps could still load ntdll just fine. It is only CreateProcess() that checks the subsystem type, so that it can correctly launch executables marked for OS2 or POSIX.
Note that not all of win32k is actually loaded again. Some parts of it are only visible in certain sessions and isolated from each others. I don't see why it's a bad thing.
AFAIK, it IS simply loaded again. Obviously the read only sections like .text will share physical pages in the same way that user mode code is shared between processes at the physical page level. I'm sure that some parts of the .data segment don't really need to be session specific, so it is a waste to duplicate that data. As for isolation, what good does it do to give each their own complete .data segment? It isn't like if one session crashes, it won't bring down the others. It is still kernel mode code afterall, and as such, it should not be perverted to behave more like user mode modules.
That might be true, but I still like the isolation it provides. But by the way, the kernel changes that were needed for session spaces and loading win32k multiple times are extremly complex and "fixing win32k" would've probably been much easier, so I doubt this was the reason.
I would think so too, but the fact remains that win32k already appeared to have window stations in place specifically for the purpose of supporting multiple consoles ( be they physical or virtual ), so I can see no good reason to go through the trouble of hacking up the kernel to be able to load a driver multiple times. Unless you know of a good reason, then ReactOS should not make that same mistake.
One good technical reason NOT to use session space is that the pages therein can't be marked with the global page bit, so they must be flushed from the TLB on every context switch. Then the page tables themselves take up more memory, though a relatively small amount.
Ah c'mon, I hope you don't mean that. That's the typical mistake people make when a monolithic kernel can load modules. That doesn't make Linux modular.
Then what does? The definition of modular means the system is broken up into multiple pieces which can be mixed and matched as desired. Both systems meet that definition. Unless you are using a definition like microkernel purists use, whereby only the most basic primatives should be in the kernel and everything else, including device drivers, should be user space. Of course, such purists consider both to be monolithic.
Considering they've been actively improving it, and now in R2 we've been working to make it even more powerful and compatible, and that in Vista it will be part of the OS, I think it's a bit more then just DOD compliance at this point.
They have been actively improving it? I have not seen any improvement ever. I remember back in NT 3.50 out of the box, NT only was posix.1 compliant to meet the DOD requirements. If you wanted to run any kind of real posix code, you needed to buy some third party software, whose name now escapes me. I am not aware of any improvements to the posix subsystem since then.
If you are refering to Services For Unix, that isn't a posix subsystem, it's just a bunch of utilities to network with unix systems, like an NFS client/server and a telnet server. It seems they have been working on that lately, but not a posix subsystem.