reactos-kernel

Re: [ros-kernel] Attempt at fixing gets

[David W. <we...@cw...>]

On Wed, May 01, 2002 at 08:48:55PM +0200, Jason Filby wrote:
> FILE: reactos\lib\kernel32\file\rw.c: (At about line 103, function ReadFile)
> 
> Add two new variables:
>    DWORD oldStdinMode;
>    WINBOOL consoleResult;
> 
> Then replace the first few lines of code with:
> 
>    if (IsConsoleHandle(hFile))
>      {
>  GetConsoleMode(hFile, &oldStdinMode);
>  SetConsoleMode(hFile, ENABLE_ECHO_INPUT | ENABLE_PROCESSED_INPUT);
> 
>  consoleResult = ReadConsoleA(hFile,
>        lpBuffer,
>        nNumberOfBytesToRead,
>        lpNumberOfBytesRead,
>        NULL);
> 
>  SetConsoleMode(hFile, oldStdinMode);
>  return consoleResult;
>      }
> 
> NOTE: What it does is set the stdin to echo all input (that was missing if it's not specified). Also save and load the previous stdin settings, otherwise when you go back to the command line it's broken.
> 
> Comments please
> 
I don't see that the second change is correct; where is it documented that
ReadFile always reads in non-raw, echoed mode? Shouldn't the library 
implementing the libc interface set the console mode themselves?

[ros-kernel] message from ntoskrnl\mm\npool.c, line 208

[Hartmut B. <har...@te...>]

Hi,

I make some test with gcc on ros. If I compile a large project (msvcrt from 
ros), after some compiled files (>100) I get many messages from 
ntoskrnl\mm\npool.c line 208 'previous c1145dcd' (or with other adresses 
greater 0xc1000000). What does this mean?

- Hartmut

[ros-kernel] Attempt at fixing gets

[Jason F. <ja...@gl...>]

Technically gets is not at fault... the problem is downstream as =
everyone knows. I have what appears to me to be a fix. Before I submit =
it, please would those that know console code better than I do make sure =
I'm not just fixing a symptom. Thanks!

FILE: reactos\lib\msvcrt\stdio\stdhnd.c:

 // stdin
{
 NULL, 0, NULL,
  _IOREAD | _IOLBF | _IONBF,
  0, 0,0, NULL
},

NOTE: For the definition of stdin I added the _IONBF flag, which seems =
to be required to make pressing Enter work right.

FILE: reactos\lib\kernel32\file\rw.c: (At about line 103, function =
ReadFile)

Add two new variables:
   DWORD oldStdinMode;
   WINBOOL consoleResult;

Then replace the first few lines of code with:

   if (IsConsoleHandle(hFile))
     {
 GetConsoleMode(hFile, &oldStdinMode);
 SetConsoleMode(hFile, ENABLE_ECHO_INPUT | ENABLE_PROCESSED_INPUT);

 consoleResult =3D ReadConsoleA(hFile,
       lpBuffer,
       nNumberOfBytesToRead,
       lpNumberOfBytesRead,
       NULL);

 SetConsoleMode(hFile, oldStdinMode);
 return consoleResult;
     }

NOTE: What it does is set the stdin to echo all input (that was missing =
if it's not specified). Also save and load the previous stdin settings, =
otherwise when you go back to the command line it's broken.

Comments please

Thanks!
- Jason

Re: [ros-kernel] Re: [ros-general] Testing, are the lists on sourceforge now?

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

At 19.41 01/05/2002, you wrote:
>[...]
>What's this about?

my error. I sent the message to this list by mistake. The sourceforge lists 
are starting to really get on my nerves...

Re: [ros-kernel] Re: [ros-general] Testing, are the lists on sourceforge now?

[Jakob E. <ja...@vm...>]

On Wed, May 01, 2002 at 02:44:20AM -0400, TJ Easter wrote:
> On Tuesday 30 April 2002 09:29 pm, KJK::Hyperion wrote:
> > At 03.04 01/05/2002, you wrote:
> > >I have not recieved any mail from the reactos.com addresses. So I assume
> > >this is the correct new address?
> >
> > yup, technically. Ah, watch out for the missing Reply-to header: when you
> > reply to a message in this mailing list the message is addressed by default
> > to the sender, not to the list
> >
> > And while we're at it, second call: everyone subscribed to this list that
> > hasn't replied to the first call, please reply
> 
> 
> I'm watching...
> 

?

What's this about?


-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

Re: [ros-kernel] Ton-O-Bugs

[Eric K. <ek...@rz...>]

"Jason Filby" <jas...@ya...> wrote:

> >Btw, I'm currently replacing the hard-coded loading system boot
> >drivers. They will soon be loaded according to the services list in
> >the registry. This is one of the major showstoppers for booting
> >ReactOS into an installation program.
>
> I'm also glad to know that the registry has progressed to a point
> where it can be used for something like that!

I deferred the work on registry-based driver loading because the whole
driver management is a chaotic piece of crap. We will need to clean it up
before additional features can be added. Of course, I can commit the patches
but it is just a quick-and-dirty hack on top of the current crap.

Eric

AW: [ros-kernel] gets and console input

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	Kohn Emil Dan [SMTP:em...@cs...]
> Gesendet am:	Mittwoch, 1. Mai 2002 16:35
> An:	Jason Filby
> Cc:	rea...@li...
> Betreff:	Re: [ros-kernel] gets and console input
>
> 2) Another problem is with the _istty() function.
> _istty(_fileno(stdin)) is supposed to return non-zero if stdin is
> redirected to the keyboard, and zero otherwise. _istty(_fileno(stdin))
> always returns zero on REACTOS.
>
Isatty calls fstat and fstat returns a correct filled stat structure only 
for files. Fstat must use GetFileType for detecting pipes, character 
devices or files. I will fix this.

- Hartmut
 

AW: [ros-kernel] Re: gets and console input

[Hartmut B. <har...@te...>]

I think, getchar can not use getc for getting one character. Getchar must 
set the console to non line buffered mode, wait for one character and read 
it, and restore the old console mode.

- Hartmut

> -----Ursprungliche Nachricht-----
> Von:	Phillip Susi [SMTP:ps...@cf...]
> Gesendet am:	Mittwoch, 1. Mai 2002 01:50
> An:	rea...@li...
> Betreff:	[ros-kernel] Re: gets and console input
>
> Consoles by default are line buffered, so they only return an entire line 

> when \n is hit.  If you want to, you can change the console mode to not 
be
> line buffered with SetConsoleMode(), but I don't think that CRTs usually 
do
> this: they just leave it as line buffered.
>
> At 12:30 AM 5/1/2002 +0200, you wrote:
> >Hey all
> >
> >I'm trying to track down a bug in gets (in msvcrt). Here's the problem,
> >based on the calls made:
> >
> >1: gets calls getchar to get each character, checking for \n or EOF
> >2: getchar calls getc, using STDIN as the file handle
> >3: getc calls _filbuf, again passing the file handle (STDIN)
> >4: _filbuf calls _read
> >5: _read calls ReadFile
> >6: ReadFile calls ReadConsoleA because IsConsoleHandle returns true
> >
> >ReadConsoleA gets a series of characters from the keyboard and only
> >returns when it gets a \n. So in effect, getchar is getting an entire
> >string from the console instead of a single character.
> >
> >At which point is the fault? Should ReadFile call ReadConsoleA? Or 
perhaps
> >is the fault in calling _filbuf? I don't know... I really need some 
advice
> >on this.
> >
> >Thanks!!
> >
> >- Jason
> 

Re: [ros-kernel] Re: File system struct

[Kohn E. D. <em...@cs...>]

On Tue, 30 Apr 2002, Phillip Susi wrote:

> 1, and 2 are reserved for stdin/out/err, but NT has opaque HANDLEs to all
> sorts of objects, not just files, and there are no reserved HANDLE values
> for stdin/out/err.BTW: win32 apps can open the CON or CONIN$ or CONOUT$
> files to get a handle to their console for IO, but they still get the
> console, even if stdin or out has been redirected.I think that this
> should be fixed in ReactOS to return the handle that stdin/out has been
> redirected to.
>

Why do you want to do this? You may break existing programs if you do
this.

If you want to access the redirected stdin/stdout/stderr, use

the GetStdHandle() function.


								Emil

Re: [ros-kernel] gets and console input

[Kohn E. D. <em...@cs...>]

On Wed, 1 May 2002, Kohn Emil Dan wrote:

> There are two more problems with REACTOS' stdio:
>
> 1) stdin does not translate the end-of-line characters correctly
>
> If stdin is redirected to the keyboard, stdin has to translate the
> ENTER key ('\r') into '\n'.

What I wanted to say is that this does not happen. So in order to make
gets return, you have to hit CR+LF, that is

ENTER followed by CTRL-J


								Emil

Re: [ros-kernel] gets and console input

[Kohn E. D. <em...@cs...>]

There are two more problems with REACTOS' stdio:

1) stdin does not translate the end-of-line characters correctly

If stdin is redirected to the keyboard, stdin has to translate the ENTER
key ('\r') into '\n'.
   On the other hand, if stdin is redirected from a file, and the file
is opened in text mode (which is the default for stdin), the end-of-line
sequence is CR+LF ('\r' + '\n'). This squence must also be translated to
'\n'. However if we want to be nice with UNIX text files, it's a good idea
to support a single '\n' as the end-of-line marker as well.

2) Another problem is with the _istty() function.
_istty(_fileno(stdin)) is supposed to return non-zero if stdin is
redirected to the keyboard, and zero otherwise. _istty(_fileno(stdin))
always returns zero on REACTOS.


								Emil


On Wed, 1 May 2002, Jason Filby wrote:

> Hey all
>
> I'm trying to track down a bug in gets (in msvcrt). Here's the problem, based on the calls made:
>
> 1: gets calls getchar to get each character, checking for \n or EOF
> 2: getchar calls getc, using STDIN as the file handle
> 3: getc calls _filbuf, again passing the file handle (STDIN)
> 4: _filbuf calls _read
> 5: _read calls ReadFile
> 6: ReadFile calls ReadConsoleA because IsConsoleHandle returns true
>
> ReadConsoleA gets a series of characters from the keyboard and only returns when it gets a \n. So in effect, getchar is getting an entire string from the console instead of a single character.
>
> At which point is the fault? Should ReadFile call ReadConsoleA? Or perhaps is the fault in calling _filbuf? I don't know... I really need some advice on this.
>
> Thanks!!
>
> - Jason
>

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

Added files:
    services/fs/cdfs/misc.c

Modified files:
    services/fs/cdfs/cdfs.h
    services/fs/cdfs/close.c
    services/fs/cdfs/create.c
    services/fs/cdfs/dirctl.c
    services/fs/cdfs/fcb.c
    services/fs/cdfs/finfo.c
    services/fs/cdfs/fsctl.c
    services/fs/cdfs/makefile

Fixed FCB management functions.
Added file and directory information.
Fixed several minor bugs.
Disabled most debug messages.


Eric

Re: [ros-kernel] Re: [ros-general] Testing, are the lists on sourceforge now?

[TJ E. <tj...@us...>]

On Tuesday 30 April 2002 09:29 pm, KJK::Hyperion wrote:
> At 03.04 01/05/2002, you wrote:
> >I have not recieved any mail from the reactos.com addresses. So I assume
> >this is the correct new address?
>
> yup, technically. Ah, watch out for the missing Reply-to header: when you
> reply to a message in this mailing list the message is addressed by default
> to the sender, not to the list
>
> And while we're at it, second call: everyone subscribed to this list that
> hasn't replied to the first call, please reply


I'm watching...

-- 
TJ Easter
USNet Systems Engineer - East 
tj...@us...

RE: [ros-kernel] Re: File system struct

[Robert C. <rob...@it...>]

> -----Original Message-----
> From: Martijn Stegeman [mailto:ma...@uv...]=20
> Sent: Wednesday, May 01, 2002 4:23 PM

> Well, any Win32 applications should not be using that because=20
> then they will not be able to run on Windows NT+. And you=20
> wouldn't be able to run POSIX+ on WinNT??

Sure they can, just install the file system driver on NT.

Rob

RE: [ros-kernel] Re: File system struct

[Martijn S. <ma...@uv...>]

> -----Original Message-----
> From: KJK::Hyperion
> At 03.47 01/05/2002, you wrote:
>
> >even kernel mode drivers. They don't see /proc, only posix apps
> do, that's
> >the difference.
>
> Frankly, I don't understand what does that demonstrate. If you implement
> /dev and /proc as devices with special filesystems attached, you'll have
> objects like \Device\Proc, \Device\Dev, \FileSystem\Proc and
> \FileSystem\Dev
>

Well, any Win32 applications should not be using that because then they will
not be able to run on Windows NT+. And you wouldn't be able to run POSIX+ on
WinNT??

Re: [ros-kernel] Re: File system struct

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

At 03.47 01/05/2002, you wrote:
>>>As for implementing /proc in the posix subsystem vs. the kernel, why 
>>>should it be implemented in the kernel if it is only going to be seen by 
>>>the posix subsystem?
>>because it's a filesystem. Why don't you implement named pipes and 
>>mailslots in user mode inside kernel32 and csrss? what's the difference?
>ALL subsystems, and native applications see named pipes and mailslots, 
>even kernel mode drivers. They don't see /proc, only posix apps do, that's 
>the difference.

Frankly, I don't understand what does that demonstrate. If you implement 
/dev and /proc as devices with special filesystems attached, you'll have 
objects like \Device\Proc, \Device\Dev, \FileSystem\Proc and \FileSystem\Dev

>>And I don't want to explain yet another time why /proc and /dev should be 
>>visible to all subsystems. Let's just say they could all benefit from it. 
>>Just like they should all benefit from NT security, Windows device 
>>management (try, just for fun, to read a floppy disk under any Unix - try 
>>Solaris for added fun), DDI drivers, etc.
>/dev CAN't be visible to anything but posix applications, because only 
>posix applications have any concept of what /dev is.

Most of them don't. They receive /dev paths as parameters and open that 
stuff like they would open files

>Win32 apps only understand that devices are files with special names, such 
>as COM1, and native apps understand that they are device objects in the 
>\Devices directory.  A posix /dev directory contains device nodes, which 
>do not exist in the NT kernel, and therefore, the kernel can not export to 
>user mode.

if /dev has its own filesystem, I don't see why it can't do device nodes 
and whatnot

>While the /dev and /proc directories themselves can not be directly 
>visible to native and win32 apps, some equivalents can be.  For instance, 
>/dev/null is seen by win32 as the NUL device.  /dev/fd0 is seen as 
>\\.\Floppy0, and so on.  On the other hand, you talked about it being 
>useful for a win32 app to have access to /proc/pid/fd/0 to read from 
>stdin, but this simply can not be done, because NT and win32 have no 
>concept of file descriptors.

I expected this answer. You forget that handles for stdin, stdout and 
stderr (file numbers 0, 1 and 2, as explicitely defined by the standard) 
are easily accessible from other processes, since they have a well-known 
location, based on the PEB. Non-POSIX processes will only have 
/proc/pid/fd/0, 1 and 2, ok? However, there's more to /proc than just file 
descriptors

Of course, /proc digs inside the kernel, so we shouldn't be too worried to 
match the Linux /proc structure exactly

>>I think I already explained this:
>>  1. introduce a new file information class (FilePosixInformation) for 
>> attributes common to all Unix filesystems (owner, primary group, access 
>> bitmask, file type bits). File attributes specific to some filesystems 
>> (sparse, immutable, append-only, compressed, etc.) will be retrieved and 
>> set through NtFsControlFile()
>This is the sort of kludge/compromise that I was talking about.  If this 
>were done, then posix apps and native/win32 apps would not see the files 
>in the same way.

Clarification: FilePosixInformation is primarily intended for Unix 
filesystems (Ext2, Ext3, Reiser, etc.). Other filesystems need not 
implement it, in such cases it's the subsystem's responsibility to decide 
what to do: return an error, or reconstruct the information by mixing other 
information classes

>Another problem is what if someone does an mknod() to create a device 
>node?  What does win32 see this file as?  Just a useless 0 byte file?  Or 
>would win32 be able to somehow open the device node, and get a real device?

Device nodes are still an open issue, but more generically special files 
(sockets, pipes, etc.) will be handled by the filesystem

>>  3.2. Windows app accessing Unix filesystem. File attributes are 
>> translated into the nearest equivalents (file name beginning with dot -> 
>> hidden, ext2 immutable attribute -> read-only, etc.). Access masks are 
>> translated into the equivalent ACLs and viceversa. But, if an ACL cannot 
>> be translated into an access mask, an error is returned. The biggest 
>> problem is that there's no reliable way to translate from user ids and 
>> group ids to SIDs. It could be implemented by extending the LSA, but is 
>> it worth it? The solution is simple: don't use Unix filesystems. Support 
>> them for compatibility only. And implement special filesystems, like 
>> /proc, /dev, but also named pipes and mailslots, with NT security semantics
>We aren't running on a posix filesystem, we are running on an NT 
>filesystem.  If you want to emulate win32 on posix, then that's what WINE 
>is for, the goal of ReactOS is to provide an actual NT system.  I for one 
>certainly don't want to give up ACLs.

It's exactly what I meant. If NT security cannot be implemented over Unix 
filesystems, fine, they'll have no security (but the only limit is the 
translation between uids/gids and SIDs...)

Re: [ros-kernel] File system struct

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

At 03.32 01/05/2002, you wrote:
>Please dont make it to confusing. Try to keep the windows/unix files the 
>do the same things in the same places. The whole C: D: and / are just 
>virtual anyway right? as long as my data is in a place I am used to as a 
>linux and windows user I dont care how you do it.

We'll try both models and see which works better, ok? we could go on 
forever discussing on something that doesn't exist

> > >If you are ever on irc, we could discuss this in
> > #ReactOS.
>irc.openprojects.net
>Jason, Rex, Eugene and I are on atleast once a week.

forgot to ask: what's your timezone? I'm GMT+0100

Fwd: Re: [ros-kernel] File system struct

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

>Date: Tue, 30 Apr 2002 18:32:55 -0700 (PDT)
>From: Steven Edwards <ste...@ya...>
>Subject: Re: [ros-kernel] File system struct
>To: "KJK::Hyperion" <no...@li...>,
>   ReactOS-Kernel <rea...@li...>
>X-Hamster-To: account:Hyperion
>X-Hamster-Info: Score=0 UIDL=aannsh.148.1 Received=20020501033649
>
>Please dont make it to confusing. Try to keep the
>windows/unix files the do the same things in the same
>places. The whole C: D: and / are just virtual anyway
>right? as long as my data is in a place I am used to
>as a linux and windows user I dont care how you do it.
>
>I would suggest the PSX file system but located under
>%SystemRoot%\system32\psx and use some sort of hidden
>symbolic linking. ala
>
>C:\ -> /boot (I dont think this is in the unix spec)
>%SystemRoot% -> /bin
>%Program Files% - > /sbin and linked to /usr/sbin
>%SystemRoot%\system32\reg* -> /etc
>%SystemRoot%\system32\psx\lib -> /lib
>%SystemRoot%\system32\ -> /usr/lib
>%homes% -> /home
>%User_Profiles% -> ~/home/User/.ros_profile
>%User Registry settings -> ~/home/User/.ntreg
>
>This is what you end up with. Now its not everything
>but I think you get the idea. As long as I dont have a
>mess (see the whole LSB document) then I am happy.
>
>/boot
>/bin
>/etc
>/home
>/lib
>/proc
>/usr/sbin
>     -lib
>
> > >If you are ever on irc, we could discuss this in
> > #ReactOS.
>
>irc.openprojects.net
>
>Jason, Rex, Eugene and I are on atleast once a week.
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Health - your guide to health and wellness
>http://health.yahoo.com

[ros-kernel] Re: File system struct

[Phillip S. <ps...@cf...>]

At 01:56 AM 5/1/2002 +0200, you wrote:
>At 05.33 30/04/2002, you wrote:
>>As for implementing /proc in the posix subsystem vs. the kernel, why 
>>should it be implemented in the kernel if it is only going to be seen by 
>>the posix subsystem?
>
>because it's a filesystem. Why don't you implement named pipes and 
>mailslots in user mode inside kernel32 and csrss? what's the difference?

ALL subsystems, and native applications see named pipes and mailslots, even 
kernel mode drivers.  They don't see /proc, only posix apps do, that's the 
difference.

>And I don't want to explain yet another time why /proc and /dev should be 
>visible to all subsystems. Let's just say they could all benefit from it. 
>Just like they should all benefit from NT security, Windows device 
>management (try, just for fun, to read a floppy disk under any Unix - try 
>Solaris for added fun), DDI drivers, etc.

/dev CAN't be visible to anything but posix applications, because only 
posix applications have any concept of what /dev is.  Win32 apps only 
understand that devices are files with special names, such as COM1, and 
native apps understand that they are device objects in the \Devices 
directory.  A posix /dev directory contains device nodes, which do not 
exist in the NT kernel, and therefore, the kernel can not export to user 
mode.  For this reason, devnodes have to be implemented in the posix 
subsystem.

While the /dev and /proc directories themselves can not be directly visible 
to native and win32 apps, some equivalents can be.  For instance, /dev/null 
is seen by win32 as the NUL device.  /dev/fd0 is seen as \\.\Floppy0, and 
so on.  On the other hand, you talked about it being useful for a win32 app 
to have access to /proc/pid/fd/0 to read from stdin, but this simply can 
not be done, because NT and win32 have no concept of file descriptors.  In 
posix, open files have integer descriptors starting from 0, and numbers 0, 
1, and 2 are reserved for stdin/out/err, but NT has opaque HANDLEs to all 
sorts of objects, not just files, and there are no reserved HANDLE values 
for stdin/out/err.  BTW: win32 apps can open the CON or CONIN$ or CONOUT$ 
files to get a handle to their console for IO, but they still get the 
console, even if stdin or out has been redirected.  I think that this 
should be fixed in ReactOS to return the handle that stdin/out has been 
redirected to.


>I think I already explained this:
>  1. introduce a new file information class (FilePosixInformation) for 
> attributes common to all Unix filesystems (owner, primary group, access 
> bitmask, file type bits). File attributes specific to some filesystems 
> (sparse, immutable, append-only, compressed, etc.) will be retrieved and 
> set through NtFsControlFile()

This is the sort of kludge/compromise that I was talking about.  If this 
were done, then posix apps and native/win32 apps would not see the files in 
the same way.  A posix app could chmod() a file to be read-only, but win32 
would not see it being marked read-only.  Conversely a win32 app could set 
the ACL of a file go grant read-only access to someone, who then logs into 
the posix subsystem, only to wonder why they can't write to it when the 
mode bits say they can ( because noone updated the FilePosixInformtion 
class when the ACL changed ).  Another problem is what if someone does an 
mknod() to create a device node?  What does win32 see this file as?  Just a 
useless 0 byte file?  Or would win32 be able to somehow open the device 
node, and get a real device?

>  2. Microsoft, amazingly, supports and documents translation between 
> Windows SIDs and POSIX uids and gids. Refer to the PSDK for details
>  3. while NT ACLs cannot be translated into access masks, the inverse is 
> true. We have two cases here:
>  3.1. POSIX app accessing Windows filesystem. All required fields, except 
> user id, group id and mode, can be retrieved without interpolation. For 
> files without an ACL, S_IRWXU | S_IRWXG | S_IRWXO will be returned as 
> access mask (that is, the file is freely accessible). Otherwise, the user 
> and group id are translated from the owner SID and the primary group SID. 
> If the ACL has a structure compatible with access masks, it is translated 
> directly, else a null mask can be returned, or a mask can be built 
> euristically. When the access mask is changed, the existing ACL on the 
> file is dropped and replaced with an ACL that is compatible with the 
> access mask (this is the standard behavior on ACL-enabled Unix systems)

OK, you have sold me on this point, the chmod mask can be emulated, but 
that means it is the posix subsystem that does the emulation, it wouldn't 
be stored in special attribute of the file.

>  3.2. Windows app accessing Unix filesystem. File attributes are 
> translated into the nearest equivalents (file name beginning with dot -> 
> hidden, ext2 immutable attribute -> read-only, etc.). Access masks are 
> translated into the equivalent ACLs and viceversa. But, if an ACL cannot 
> be translated into an access mask, an error is returned. The biggest 
> problem is that there's no reliable way to translate from user ids and 
> group ids to SIDs. It could be implemented by extending the LSA, but is 
> it worth it? The solution is simple: don't use Unix filesystems. Support 
> them for compatibility only. And implement special filesystems, like 
> /proc, /dev, but also named pipes and mailslots, with NT security semantics

We aren't running on a posix filesystem, we are running on an NT 
filesystem.  If you want to emulate win32 on posix, then that's what WINE 
is for, the goal of ReactOS is to provide an actual NT system.  I for one 
certainly don't want to give up ACLs.

>  4. make the ACL editors recognize both standards for ACE order in a 
> DACL: POSIX and Win32
>
>>If you are ever on irc, we could discuss this in #ReactOS.
>
>sounds fine. What server?

irc.openprojects.net.

[ros-kernel] Re: [ros-general] Testing, are the lists on sourceforge now?

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

At 03.04 01/05/2002, you wrote:
>I have not recieved any mail from the reactos.com addresses. So I assume 
>this is the correct new address?

yup, technically. Ah, watch out for the missing Reply-to header: when you 
reply to a message in this mailing list the message is addressed by default 
to the sender, not to the list

And while we're at it, second call: everyone subscribed to this list that 
hasn't replied to the first call, please reply

Re: [ros-kernel] File system struct

[Steven E. <ste...@ya...>]

Please dont make it to confusing. Try to keep the
windows/unix files the do the same things in the same
places. The whole C: D: and / are just virtual anyway
right? as long as my data is in a place I am used to
as a linux and windows user I dont care how you do it.

I would suggest the PSX file system but located under
%SystemRoot%\system32\psx and use some sort of hidden
symbolic linking. ala

C:\ -> /boot (I dont think this is in the unix spec)
%SystemRoot% -> /bin
%Program Files% - > /sbin and linked to /usr/sbin
%SystemRoot%\system32\reg* -> /etc
%SystemRoot%\system32\psx\lib -> /lib
%SystemRoot%\system32\ -> /usr/lib
%homes% -> /home
%User_Profiles% -> ~/home/User/.ros_profile
%User Registry settings -> ~/home/User/.ntreg

This is what you end up with. Now its not everything
but I think you get the idea. As long as I dont have a
mess (see the whole LSB document) then I am happy.

/boot
/bin
/etc
/home
/lib
/proc
/usr/sbin
    -lib

> >If you are ever on irc, we could discuss this in
> #ReactOS.

irc.openprojects.net

Jason, Rex, Eugene and I are on atleast once a week.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Re: [ros-kernel] File system struct

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

At 05.33 30/04/2002, you wrote:
>As for implementing /proc in the posix subsystem vs. the kernel, why 
>should it be implemented in the kernel if it is only going to be seen by 
>the posix subsystem?

because it's a filesystem. Why don't you implement named pipes and 
mailslots in user mode inside kernel32 and csrss? what's the difference?

And I don't want to explain yet another time why /proc and /dev should be 
visible to all subsystems. Let's just say they could all benefit from it. 
Just like they should all benefit from NT security, Windows device 
management (try, just for fun, to read a floppy disk under any Unix - try 
Solaris for added fun), DDI drivers, etc.

>Note that it is currently my opinion that the posix and win32 filesystems 
>are too different to reconcile them ( without unacceptable sacrifices in 
>functionality ), but if you think it can be done, then figure out how to 
>do so, and implement it and/or explain how to the rest of us.  Who knows, 
>maybe you can come up with a way to reconcile them, if so, I'd love to hear it.

I think I already explained this:
  1. introduce a new file information class (FilePosixInformation) for 
attributes common to all Unix filesystems (owner, primary group, access 
bitmask, file type bits). File attributes specific to some filesystems 
(sparse, immutable, append-only, compressed, etc.) will be retrieved and 
set through NtFsControlFile()
  2. Microsoft, amazingly, supports and documents translation between 
Windows SIDs and POSIX uids and gids. Refer to the PSDK for details
  3. while NT ACLs cannot be translated into access masks, the inverse is 
true. We have two cases here:
  3.1. POSIX app accessing Windows filesystem. All required fields, except 
user id, group id and mode, can be retrieved without interpolation. For 
files without an ACL, S_IRWXU | S_IRWXG | S_IRWXO will be returned as 
access mask (that is, the file is freely accessible). Otherwise, the user 
and group id are translated from the owner SID and the primary group SID. 
If the ACL has a structure compatible with access masks, it is translated 
directly, else a null mask can be returned, or a mask can be built 
euristically. When the access mask is changed, the existing ACL on the file 
is dropped and replaced with an ACL that is compatible with the access mask 
(this is the standard behavior on ACL-enabled Unix systems)
  3.2. Windows app accessing Unix filesystem. File attributes are 
translated into the nearest equivalents (file name beginning with dot -> 
hidden, ext2 immutable attribute -> read-only, etc.). Access masks are 
translated into the equivalent ACLs and viceversa. But, if an ACL cannot be 
translated into an access mask, an error is returned. The biggest problem 
is that there's no reliable way to translate from user ids and group ids to 
SIDs. It could be implemented by extending the LSA, but is it worth it? The 
solution is simple: don't use Unix filesystems. Support them for 
compatibility only. And implement special filesystems, like /proc, /dev, 
but also named pipes and mailslots, with NT security semantics
  4. make the ACL editors recognize both standards for ACE order in a DACL: 
POSIX and Win32

>If you are ever on irc, we could discuss this in #ReactOS.

sounds fine. What server?

[ros-kernel] Re: gets and console input

[Phillip S. <ps...@cf...>]

Consoles by default are line buffered, so they only return an entire line 
when \n is hit.  If you want to, you can change the console mode to not be 
line buffered with SetConsoleMode(), but I don't think that CRTs usually do 
this: they just leave it as line buffered.

At 12:30 AM 5/1/2002 +0200, you wrote:
>Hey all
>
>I'm trying to track down a bug in gets (in msvcrt). Here's the problem, 
>based on the calls made:
>
>1: gets calls getchar to get each character, checking for \n or EOF
>2: getchar calls getc, using STDIN as the file handle
>3: getc calls _filbuf, again passing the file handle (STDIN)
>4: _filbuf calls _read
>5: _read calls ReadFile
>6: ReadFile calls ReadConsoleA because IsConsoleHandle returns true
>
>ReadConsoleA gets a series of characters from the keyboard and only 
>returns when it gets a \n. So in effect, getchar is getting an entire 
>string from the console instead of a single character.
>
>At which point is the fault? Should ReadFile call ReadConsoleA? Or perhaps 
>is the fault in calling _filbuf? I don't know... I really need some advice 
>on this.
>
>Thanks!!
>
>- Jason

[ros-kernel] gets and console input

[Jason F. <ja...@gl...>]

Hey all

I'm trying to track down a bug in gets (in msvcrt). Here's the problem, =
based on the calls made:

1: gets calls getchar to get each character, checking for \n or EOF
2: getchar calls getc, using STDIN as the file handle
3: getc calls _filbuf, again passing the file handle (STDIN)
4: _filbuf calls _read
5: _read calls ReadFile
6: ReadFile calls ReadConsoleA because IsConsoleHandle returns true

ReadConsoleA gets a series of characters from the keyboard and only =
returns when it gets a \n. So in effect, getchar is getting an entire =
string from the console instead of a single character.

At which point is the fault? Should ReadFile call ReadConsoleA? Or =
perhaps is the fault in calling _filbuf? I don't know... I really need =
some advice on this.

Thanks!!

- Jason

[ros-kernel] CVS Commit: reactos

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

Modified Files:
     tools/helper.mk

Fixed order of TARGET_LFLAGS in the command lines of rules for kernel-mode 
targets
Added "nostrip" rule for static libraries, currently does nothing new