reactos-kernel

[ros-kernel] Re: csrss explained

[Aliberti E. <ea...@us...>]

> /* Pseudo code for a call:
> 
> CSR_CCS svrapi;
> NTSTATUS Status;
> DWORD data[16];
> 
> svrapi.ServerId = CSR_SERVER_WINDOWS_CONSOLE;
> svrapi.Index = 0x0208; // GetConsoleMode()
> 
> Status = CsrClientCallServer (data, NULL, svrapi, sizeof data);
> 
> */

I made a mistake: for 1/0x0208 the correct data size is

DWORD data[4];

that is 16 bytes.

Re: [ros-kernel] csrss explained

[KJK::Hyperion <no...@li...>]

At 00.46 22/05/2002, you wrote:
>A thing to keep in mind is that, at the origins of NT, there was a single 
>user-mode server that made environment subsystems live. That is why the 
>meta-server is still called "client/server runtime" (CSR) even if actually 
>now is the runtime exclusively for the Win32 server.
[...]

I like the old architecture more. I find it more flexible, and it has less 
overhead, as it uses only one process. It can be programmatically 
controlled better. The subsystems can interoperate faster. I think it's 
generally better

>%SystemRoot%\system32\csrss.exe
>   ObjectDirectory=\Windows
>   SharedSection=1024,3072
>   Windows=On
>   SubSystemType=Windows
>   ServerDll=basesrv,1
>   ServerDll=winsrv:UserServerDllInitialization,3
>   ServerDll=winsrv:ConServerDllInitialization,2
>   ProfileControl=Off
>   MaxRequestThreads=16

Ever tried to modify some of the parameters? Just for fun?

Re: [ros-kernel] csrss explained

[KJK::Hyperion <no...@li...>]

At 00.46 22/05/2002, you wrote:
>A thing to keep in mind is that, at the origins of NT, there was a single 
>user-mode server that made environment subsystems live. That is why the 
>meta-server is still called "client/server runtime" (CSR) even if actually 
>now is the runtime exclusively for the Win32 server.
[...]

I like the old architecture more. I find it more flexible, and it has less 
overhead, as it uses only one process. It can be programmatically 
controlled better. The subsystems can interoperate faster. I think it's 
generally better

>%SystemRoot%\system32\csrss.exe
>   ObjectDirectory=\Windows
>   SharedSection=1024,3072
>   Windows=On
>   SubSystemType=Windows
>   ServerDll=basesrv,1
>   ServerDll=winsrv:UserServerDllInitialization,3
>   ServerDll=winsrv:ConServerDllInitialization,2
>   ProfileControl=Off
>   MaxRequestThreads=16

Ever tried to modify some of the parameters? Just for fun?

Re: [ros-kernel] csrss explained

[KJK::Hyperion <no...@li...>]

crud. I ended up sending three copies of this. Apologies

[ros-kernel] Disk layout continued

[Robert K. <ro...@ko...>]

Hi, I'd like to warm up the theme about Directory structure and multiple
installations, again.

Hyper and I had a discussion in this context, and I want to give us a base
via posting it.
Conclusion up to now is:
-very different views for some ss
-multiple distinct installations should be possible on one partition but
cause dir-inconsistency (who has the true view)

Let's start clearing this problem.,


do you think we should continue that discussion about directory structure?

NonVolatil: yes
KJK::Hyperion: I have five queued messages
maybe we should ask first :-)
NonVolatil: I think we should define the structure as early as possible
and diverge the sturcute to have no overfilled dirs
*** KJK::Hyperion signed off at Wed Apr 24 21:38:43 2002.
*** KJK::Hyperion signed on at Wed Apr 24 21:38:53 2002.
KJK::Hyperion: yes, I agree
the earlier, the better
KJK::Hyperion: about Unix dirs...
I think they *really* should stay in the disk root. All systems with a
POSIX subsystem (MacOS/X, QNX, BeOS) do that, I don't see why we have to
differ
NonVolatil: here agein
KJK::Hyperion: heh
NonVolatil: moment I have a call......
KJK::Hyperion: that's ok
NonVolatil: Here I am again. Female phone partners never find an end
KJK::Hyperion: hehehehehehehehe
how true
NonVolatil: what now............
NonVolatil: I don't want to pollute the root
KJK::Hyperion: the root is no-one's land
NonVolatil: This is one of the advances of NT over OS/2 for example. You
can install multiple installations on one parttion
NonVolatil: W2k gave this adv. away in some parts
NonVolatil: AND I want to have a subdir for each sub system, also win32
KJK::Hyperion: Win32 can, by design, be installed everywhere
Unix systems cannot. They have a rigid structure, and more important
there's no way to determine dynamically the location of directories
NonVolatil: thats ok and unchangeable. But with virtual dirs there is a
possibility to locate the real dirs under the OS' dir
KJK::Hyperion: virtual directories are an administration and programming
hell
NonVolatil: i don't think so
NonVolatil: 'cos a programmer of a certain ss knows what he knows
KJK::Hyperion: they introduce yet another special file system object, for
example
NonVolatil: not needed
*** Error while sending IM: Rate to client
NonVolatil: for example NT's os2 ss does souch a thing with CONFIG.SYS
NonVolatil: The os2 ss creates a virtual config.sys form a key in the
registry.
KJK::Hyperion: this is hideous
NonVolatil: So every NT installation has its own config.sys - which was
the intention
NonVolatil: hideous?
KJK::Hyperion: horrible
KJK::Hyperion: what path has this fake config.sys?
NonVolatil: X:\
NonVolatil: ?
NonVolatil: I know...you are imaging yourself a posix only version
KJK::Hyperion: do they take in account all the possible paths?
X:\dir\..\config.sys? X:\config.sys.? X:\dir1\dir2\..\..\config.sys?
NonVolatil: OS/2's config.sys resides in the boot drives root
KJK::Hyperion: what if some program reads it with an "indirect" path like
those? do you have to check every damn file open?
NonVolatil: whats an indierect path?
KJK::Hyperion: the dot and double-dot entries, for example
NonVolatil: the ss's open implementation has to monitor if a special file
is opened and treat that differently.  - Its possible but hard
KJK::Hyperion: X:\..\..\dir\.\dir2\..\.\..\config.sys....

this is the same as X:\config.sys
NonVolatil: oh, yes, they are
NonVolatil: I don't know if it is possible in nt
NonVolatil: but it is pain
KJK::Hyperion: with a little sacrifice no more problems
NonVolatil: Its difficult if you think of a posix or os2 only version. But
this would mean that you can boot different systems with win32 but the
other ss remain the same - or even more evil refuse to function in the
other version
KJK::Hyperion: there's another problem with the "every SS has its root"
approach. That they cannot work together
NonVolatil: was it you who told us about the other POSIX 2 compiant ss
taken by M$
NonVolatil: if they share the same root ?
KJK::Hyperion: if they share the same root, file paths can be exchanged
freely with little or no processing required
NonVolatil: what do you mean with  that?
KJK::Hyperion: POSIX+ for example already accepts both the backslash and
forward slash as path separator. A path like \home\hyperion\desktop is
both a valid Win32 and a valid POSIX path
NonVolatil: lets talk baout your ss. which dirs are required?
KJK::Hyperion: technically, none. Only the root and /tmp. But for an
usable system, it needs /bin, /dev, /etc, /lib and /sbin. For full FHS
compliance, /boot, /home, /mnt and /opt are also required
KJK::Hyperion: and /usr, and /var, by the way
NonVolatil: tmp and usr may share the root. the others I think not
NonVolatil: dev may exist but be 'filled' by the ss
KJK::Hyperion: why not? I can guarantee you that it poses no problem at
all for existing programs
NonVolatil: The parallel install thing.
 And, as you said, other ss that use the same names
KJK::Hyperion: no other subsystem uses these names
NonVolatil: I can imagine a carbon ss. This will have tmp as darwin has
one
KJK::Hyperion: Darwin is Unix
NonVolatil: yes and so it requires different usr var etc etc.
NonVolatil: I don't like this either
KJK::Hyperion: but Carbon doesn't define standard directories
NonVolatil: Do you know MacOS? I don't
NonVolatil: But take for example the Cocoa API
*** Error while sending IM: Rate to client
KJK::Hyperion: A bit. It has directories like System, Applications, and a
few others. I think, apart from System, that other directories have no
special meaning
NonVolatil: is this for os X true, too?
KJK::Hyperion: yes. The root is something like this:
/bin
/etc
/lib
...
/Applications
...
NonVolatil: so darwin+MacOS
KJK::Hyperion: it's just that /bin, /etc, /lib, etc. are hidden
KJK::Hyperion: yes. They effectively have four concurrent subsystems:
POSIX, Carbon (old Mac), Cocoa (NeXTStep) and Aqua (new Mac)
KJK::Hyperion: and they use a single root
NonVolatil: ? I thought Carbon are old but  improved binarys. They use
Aqua for display. Cocoa are native apps and they use also Aqua for
display. Aqua is not a subsystem
KJK::Hyperion: Aqua is the subsystem, the display is called Quartz
and to support the old Mac they both have an emulation subsystem with
binary compatibility (Classic) and a native subsystem with source
compatibility (Carbon)

Re: [ros-kernel] Disk layout continued

[Casper H. <ch...@us...>]

tor, 2002-05-23 kl. 00:35 skrev Robert K.:
> Hi, I'd like to warm up the theme about Directory structure and multiple
> installations, again.
> 
> Hyper and I had a discussion in this context, and I want to give us a base
> via posting it.
> Conclusion up to now is:
> -very different views for some ss
> -multiple distinct installations should be possible on one partition but
> cause dir-inconsistency (who has the true view)

There should be no trouble with multiple installations on one parition
unless you run badly behaving applications that expect \windows and
\program files to be there. Well-written applications use the OS APIs to
get these paths (which ultimately is saved in the registry).

> 
> Let's start clearing this problem.,
> 
> KJK::Hyperion: about Unix dirs...
> I think they *really* should stay in the disk root. All systems with a
> POSIX subsystem (MacOS/X, QNX, BeOS) do that, I don't see why we have to
> differ

The unix standard directories will show up in all subsystems then?

> NonVolatil: I don't want to pollute the root
> KJK::Hyperion: the root is no-one's land

What root are we talking about? The Object Manager root or the Win32
shell namespace root? System drive? POSIX subsystem root? Other?

> NonVolatil: AND I want to have a subdir for each sub system, also win32
> KJK::Hyperion: Win32 can, by design, be installed everywhere
> Unix systems cannot. They have a rigid structure, and more important
> there's no way to determine dynamically the location of directories

Yes, unix applications expect a certain disk layout. However the POSIX
subsystem can emulate this layout so the unix applications are happy.

> NonVolatil: thats ok and unchangeable. But with virtual dirs there is a
> possibility to locate the real dirs under the OS' dir
> KJK::Hyperion: virtual directories are an administration and programming
> hell
> NonVolatil: i don't think so
> NonVolatil: 'cos a programmer of a certain ss knows what he knows
> KJK::Hyperion: they introduce yet another special file system object, for
> example

Now I'm confused. Which special file system object? Symbolic links are
handled by the object manager in cooperation with it's clients.

> KJK::Hyperion: do they take in account all the possible paths?
> X:\dir\..\config.sys? X:\config.sys.? X:\dir1\dir2\..\..\config.sys?
> NonVolatil: OS/2's config.sys resides in the boot drives root
> KJK::Hyperion: what if some program reads it with an "indirect" path like
> those? do you have to check every damn file open?
> NonVolatil: whats an indierect path?
> KJK::Hyperion: the dot and double-dot entries, for example
> NonVolatil: the ss's open implementation has to monitor if a special file
> is opened and treat that differently.  - Its possible but hard
> KJK::Hyperion: X:\..\..\dir\.\dir2\..\.\..\config.sys....
> this is the same as X:\config.sys

The subsystem translates relative paths into fully qualified paths.

> KJK::Hyperion: there's another problem with the "every SS has its root"
> approach. That they cannot work together

Each subsystem can provide symbolic links to a central location.

> KJK::Hyperion: if they share the same root, file paths can be exchanged
> freely with little or no processing required

Just configure your subsystems to have the same view of your volumes
then.

Re: [ros-kernel] Disk layout continued

[Aliberti E. <ea...@us...>]

On 23 May 2002 at 1:40, Casper Hornstrup wrote:

> What root are we talking about? The Object Manager root or the Win32
> shell namespace root? System drive? POSIX subsystem root? Other?
> 
> Yes, unix applications expect a certain disk layout. However the POSIX
> subsystem can emulate this layout so the unix applications are happy.
> 
> Now I'm confused. Which special file system object? Symbolic links are
> handled by the object manager in cooperation with it's clients.
> 
> The subsystem translates relative paths into fully qualified paths.
>
> Each subsystem can provide symbolic links to a central location.
>
> Just configure your subsystems to have the same view of your volumes
> then.


I simply reproduce verbatim what Casper wrote. What is apparently 
missing in the original dialog is what Casper tries (desperately;) to 
affirm with his comments. By dropping the dialog text, I hope that 
obscure thing pops up itself.
.
.
.
.
.
.
.
.
What we are talking about is a "name space". Of course there is only 
one name space in every OS. In NT, the name space is the system name 
space, the one generated and maintained by the Ob manager in the 
executive. Whatever you create in NT, unless it is unamed, it has a 
fully qualified name from the root "\" down to its own (relative) 
name. One of the important tasks in Os simulation is name space 
simulation. As I just recalled, every OS has its own name space, 
{directory|folder|library} separator convention, file name convention 
etc. Do you really belive that "A:" really exist in your very new XP 
pro box? It is just what the Win32 subsytem show to you (dear) my 
windows process. Therefore what we really need is not "where do I put 
my files?", but "what is a complete and correct mapping of the system 
name space to project it, in full or partially, in my os name 
space?". Also, keep in mind that Win32 can NOT see the whole system 
name space. Therefore it is NOT required an isomorphism between the 
system name space and your own subsystem's name space.

Re: [ros-kernel] Disk layout continued

[Robert K. <ro...@ko...>]

Though, the primary question is not what projection will a ss make to its
sheeps, but the actual
directory structure in the filesystem. I beleve that one partition's root
directroy is something
special. It is the highest level to divert the strucure. I think that
multiple installations on one
partition is a valuable thing.
No question, WinNT's dir struct has to be resembled in a way.
However I refuse to pollute the root dir with ss specivic dirs. For this
reason
I am for emulating these dirs in the sub system's namespace.

You may argument: Why not also emulate win32-dir struct?
The answer would be: It behaves nice, 'cos it needs only one Folder whose
name is choosable.
PS.
 I think noone either beleves that driveletters actually exist in NT nor
likes them.

Aliberti Emanuele schrieb:

> On 23 May 2002 at 1:40, Casper Hornstrup wrote:
>
> > What root are we talking about? The Object Manager root or the Win32
> > shell namespace root? System drive? POSIX subsystem root? Other?
> >
> > Yes, unix applications expect a certain disk layout. However the POSIX
> > subsystem can emulate this layout so the unix applications are happy.
> >
> > Now I'm confused. Which special file system object? Symbolic links are
> > handled by the object manager in cooperation with it's clients.
> >
> > The subsystem translates relative paths into fully qualified paths.
> >
> > Each subsystem can provide symbolic links to a central location.
> >
> > Just configure your subsystems to have the same view of your volumes
> > then.
>
> I simply reproduce verbatim what Casper wrote. What is apparently
> missing in the original dialog is what Casper tries (desperately;) to
> affirm with his comments. By dropping the dialog text, I hope that
> obscure thing pops up itself.
> .
> .
> .
> .
> .
> .
> .
> .
> What we are talking about is a "name space". Of course there is only
> one name space in every OS. In NT, the name space is the system name
> space, the one generated and maintained by the Ob manager in the
> executive. Whatever you create in NT, unless it is unamed, it has a
> fully qualified name from the root "\" down to its own (relative)
> name. One of the important tasks in Os simulation is name space
> simulation. As I just recalled, every OS has its own name space,
> {directory|folder|library} separator convention, file name convention
> etc. Do you really belive that "A:" really exist in your very new XP
> pro box? It is just what the Win32 subsytem show to you (dear) my
> windows process. Therefore what we really need is not "where do I put
> my files?", but "what is a complete and correct mapping of the system
> name space to project it, in full or partially, in my os name
> space?". Also, keep in mind that Win32 can NOT see the whole system
> name space. Therefore it is NOT required an isomorphism between the
> system name space and your own subsystem's name space.
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel