14 Oct
2005
14 Oct
'05
3:07 p.m.
Phillip Susi wrote:
That was my point. Since Win32 exes need to load ntdll, that's why it's
marked as such.
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.
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.
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.
I totally agree. The main thing to realize, as you've said, is that
ReactOS is an -NT clone-. Steven and I and others are preparing a talk
to be delivered to universities which want to give an OS course based on
Windows, so that ReactOS's code base can be used as an example and
learning base for the actual NT kernel. If we do everything differently,
and I'm not talking about small internal algorithms, this is a big
design decision, then such possibilites will vanish.
Best regards,
Alex Ionescu
Alex Ionescu wrote:
Nothing. Deviating from NT design is a bad thing.
(Note for others: The KISS principle is "Keep it simple, stupid" or
sometimes "Keep it simple and stupid")
If you really want to argue using Ockam's Razor (note for others:
Ockam's razor basically says that the simplest assumption is usually
the correct one), then I'm afraid I'm the one winning this argument.
My assumption is that CSRSS has always been built to service Win32's
needs. This has much evidence, as you've added and agreed with me,
mostly importantly:
- The fact that other subsystems have their own *ss.exe
- The fact that CSRSS is specially "polluted" for Win32
Your assumption, as far as I could understand, is that CSR was
"originally supposed to be somethign else" and was later "polluted".
Now, what makes more sense and seems the easiest assumption, by using
Ockam's Razor:
- CSR is what all evidence to it points, a Win32 subsystem runtime
manager. (Alex)
- CSR is everything but what it currently seems to be. CSR was
actually designed to be something totally different. It was later
polluted and became what it is now.(Emanuele)
Ockam would agree with theory #1, and your assumption would become
the unnecessary one.
I don't see why it matters whether csrss was originally intended to be
more generic, or win32 specific. You can argue about that until the
cows come home, without much purpose. If the real quesion is should
ReactOS's csrss be generic or win32 specific, then I think the obvious
answer is that it should probably be just like windows is, unless
there is a good technical reason, not a philisophical one, to
deviate. It seems that MS implemented the posix and os2 subsystems as
seperate processes, so what would we gain by not doing as they did? (Note to others: 3 is
IMAGE_SUBSYSTEM_WINDOWS_CUI)
I've always found it strange that ntdll.dll has the CUI subsystem,
and not IMAGE_SUBSYSTEM_NATIVE.
Of course, the most plausible reasons for this are that due to some
kernel/loader semantics, it's simply easier to use this flag for X, Y
reasons. Even simpler, perhaps it's just the default used for
building other DLLs. You can note that basesrv.dll and winsrv.dll
also have the same flag set, even though they are not CUI DLLs. I'm
not going to go in some theory that "Oh God, oh God, ntdll has the
Win32 Console flag set, it must be a hidden console DLL!".
Funny you should mention that. As far as I know, the subsystem
identifier means nothing to dlls. The only thing I know of that it
has any impact on is that win32's CreateProcess() will only load
executables marked as either win32 gui or cui. Because it doesn't
seem to have any actual impact, I don't see why one should spend much
time worrying about it.
All subsystems run in more then one instance if multiple Session IDs
are used. This is by the very own design of "Sessions" in NT.
Sessions are completely seperate entities. They run their own set of
programs, have their own desktops, windowstations, windows, etc. Even
their -memory- is seperated. Memory in one session is usually
seperated from memory in another session. Even the Paged and Nonpaged
Pools are seperated! It makes perfect sense that even subsystems are
seperated. Plus, this is a feature that I personally LOVE. It allows
me to debug csrss.exe on a -live- system, simply by connecting to
another session. Without this wonderful design, such abilities would
be lost. Also, assume csrss.exe crashes in one session. The others
sessions are still ok. There are a myriad of reasons why having an
isolated environment for each session is a good thing. It's why
windows terminal services are probably one of the best features of NT.
IMHO, the session support they added to win2k is an abomination. I
remember when I first read about winstations in NT 3.51 and figured
that must be there so they can support multiple heads and remote login
sessions. The winstation encapsulates a display device and input
device(s) so it seems perfectly logical to create a windowstation for
each physical or virtual set of human I/O devices in the system.
Kludging the kernel to be able to load multiple instances of
win32k.sys made my skin crawl the first time I read they were going to
do that in win2k. I still don't know why they would do such a thing.
I've allways had the opinion that ReactOS should do it the right way,
and make use of the winstation support rather than load win32k.sys
multiple times. Running multiple instances of csrss seems fine, it's
a user mode process after all, but win32k.sys should not be.
Win32k is made to load into every session by DESIGN, and it comes
with a share of benefits. Did you also know that other drivers can be
made session-specific as well?
And again, I think that is a horrible design, and that it provides no
benefits. The kernel runs the entire system. It exists in every
process, and in no process. That is how things should be, and
'session space' seems a horrible kludge created because someone
figured it would be easier to load win32k.sys multiple times than to
fix any bugs in it that prevented it from properly connecting to
multiple I/O devices and routing them to the correct windowstation. I think you
define it as "secure, isolated, scalable design". Which
is quite different from Linux's monolithic, unscalable design.
Ok now really, this is falling off into religion. Linux is just as
modular/monolithic as NT. NT is not MACH as much as it was originally hailed to
be. And with
good reason.
Yes, NT was originally designed with subsystems in mind. It seems
likely that this was either because Cutler thought it to be a better
design, or MS didn't know whether they were going to make NT use an
OS/2 interface, or something else, or probably both of these. Either
way, MS has never really supported the posix subsystem, so it seems
that they only created it for compliance with the DOD ( which they did
require ).
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.
The original PSXSS.EXE was, as you know, a nice trick. MS had to
show that NT was POSIX 1003.1 compliant, to get DOD contracts.
Possibly true, although it sounds like a conspiracy theory. I'm sure
a big part of POSIX compliance was also compatibility, and also to
prove that NT is a solid design. Remember that NT was originally
built for non-x86 CPUs only because Cutler thought it was the best
way to catch bugs and make a solid OS. Subsystems were a design
choice in NT for a long time.
Ah, finally we get to a point where I'll agree you with you on
pollution! Yes, POSIX only works with Win32 loaded. But can we easily
work around this later on, when we have a POSIX subystem? Sure! Does
it have anything to do with CSR? NO!
I agree. The reason microsoft's posix subsystem requires win32 is
because the posix subsystem needed a means of conducting I/O with the
user, and the win32 subsystem already provided that, so they didn't
have to invent such a means for the posix subsystem, and both
subsystems could not control the I/O devices at once, and win32 was
decided the "main" subsystem. The same arguments apply to ReactOS.
If you really wanted to be able to run without win32, then you could
extend the posix subsystem to use its own code to manipulate the
display and read the input devices, but the first goal should be to
get it to run with win32 doing those things, and seperate it later if
you really, really want to. Our target base however, expects ReactOS
to run win32 apps, and those who want to run posix apps will most
likely be quite happy to be able to run them allongside win32 apps.
This requires that the posix subsystem communicate with the win32
subsystem, not be completely isolated.
Well, when NT was first publically shipped its job was to run Win32
applications. Allowing Win32 to be removed might've caused many
technical/support headaches apart from the marketing stuff. I
wouldn't jump to conspiracy theories right away. The design of NT is
much different from the shell/ie.
Not to mention that they did not disallow disabling the win32
subsystem, they just saw no reason to fully develop the posix
subsystem to be capable of living without win32.
Polluted, connected, I still disagree. There is almost nothing in NT
which makes Win32's life easier, apart from some win32k.sys stuff.
Yes, there are certaintly some things which help out win32, but
that's because NT is PRIMARLY DESIGNED to be a Win32 OS. By
definition, so must ReactOS, at least until 1.0 when our goal, to
clone Windows NT, is reached. After that, we are free to explore
other areas, if compatibility can remain intact.
Agreed.
_______________________________________________