14 Oct
2005
14 Oct
'05
5:13 a.m.
Alex Ionescu wrote:
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 ).
(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.
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.