[ros-dev] FreeWin95

Phillip Susi psusi at cfl.rr.com
Fri Oct 14 07:13:14 CEST 2005


Alex Ionescu wrote:

>
> (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.
>

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 ). 

>
> 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. 



More information about the Ros-dev mailing list