14 Oct
2005
14 Oct
'05
5:50 p.m.
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.