[ros-dev] FreeWin95

[Phillip Susi]

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

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.

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