[ros-dev] FreeWin95

[Alex Ionescu]

Phillip Susi wrote:

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

Nothing. Deviating from NT design is a bad thing.

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

That was my point. Since Win32 exes need to load ntdll, that's why it's 
marked as such.

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

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.

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

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

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.

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

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.

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

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.

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

Best regards,
Alex Ionescu