Phillip Susi wrote:
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.
Not all parts are.
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.
Multiple-driver capability could be considered a feature and used for
other purposes later. While making win32k load multiple times might be a
"mistake", having the ability to do would, in my opinion, result in a
much better driver (just like it did for MS:, win32k became a lot more
portable, unloadable, etc).
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.
Modular doesn't mean microkernel. Linux is not a microkernel, it's a
monolothic kernel. Nor is NT, which is why it's called a Hybrid
Microkernel, which is still a subclass of microkernels.
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.
Erm, the posix subsystem has been removed since Windows 2000. Had SFU
not been including one all along, then all those utlities would've never
worked...so yes, SFU -does- include psxss. That part is called SUA
(Subsystem for Unix Applications). One of the big improvemnts is that it
now supports 64-bit.
Best regards,
Alex Ionescu