Menu
▾
▴
reactos-kernel
|
From: Casper H. <ch...@us...> - 2002-04-30 00:15:19
|
> From: KJK::Hyperion <noog@li...> > Re: File system struct - ENOUGH ALREADY > 2002-04-28 14:55 > > At 18.59 28/04/2002, you wrote: > > Premise: I give up. Something must be terribly wrong with me. I try to > be reasonable. I try to be understanding. I try to explain rationally > my point of view. I try to bring real-world examples as proof of my > design choices. > I try to come at compromises with your ideas. And it never works. So, > I give up. Just do whatever you want, I won't waste my time anymore, > because it just doesn't work. You all seem pretty smart guys, so I > must be the problem > Go ahead and be happy, the annoying troublemaker finally shut up. I'll > never question whatever future choice of yours, this will be my last > message I think you give up to easily. One problem is that you are trying to turn ReactOS itself into a POSIX environment, instead of taking advantage of the ReactOS subsystem abillity. This is my major concern when I happen to disagree with you. To my knowledge only two people are working on the POSIX subsystem. You two probably have the most knowledge of POSIX, so any design issues that only affects the POSIX subsystem and POSIX applications, I do not (currently) care about. I may make suggestions when I believe something could be done better, but since I'm probably not going to implement them I won't be mad or even force you to do it. Nor will any other developer on this list. You don't have to implement what is suggested on this list. However, it may be that someone disagrees with you and eventually provides a different implementation of something you have implemented. If this is unacceptable to you, the project coordinators may have to make a decission about which implementation to keep. If you think someone does not have good reasons for doing something a specific way, then ask them to explain further. If you think you have a better way of doing things, then prove the other developers wrong. |
|
From: KJK::Hyperion <no...@li...> - 2002-04-30 02:51:52
|
At 02.14 30/04/2002, you wrote: >I think you give up to easily. One problem is that you are trying to turn >ReactOS itself into a POSIX environment, instead of taking advantage of >the ReactOS subsystem abillity. My point of view, which I won't try to defend any further (at least for a very long time), is to mix the best of all subsystems. The Win32 "standard" for filesystem structure is hardly the "best". Drive letters are hardly the best way to identify devices. Multiple roots are bad, they are the inheritance of an era (DOS) when there was no distinction between the operating system and the user interface, but we don't need them anymore Ah, and don't forget we aren't the only OS to have a POSIX subsystem, still we are the only to question whether its root directory should match the "system" root, whether /dev is visible to other subsystems, and so on. Designers of MacOS/X had no doubt, apparently, and they solved the "usability" issue (i.e. the user wondering what are all those strange directories in the root) raised by some by just... hiding the POSIX directories in the GUI. MacOS/X is a Unix you say? Partially true, but BeOS wasn't at all. Still, also its POSIX subsystem accessed the same namespace of native programs, and /dev was visible to all programs. One wonders why those fools at Be and Apple decided so, given the elaborate rationales the members of this project use to justify the opposite approach One more thing: NT is NOT a microkernel, so please stop considering it such. It may make sense to have special filesystems (think /proc) implemented by subsystems, ON A MICROKERNEL SYSTEM, that will surely provide facilities to implement system calls as IPC calls. But, alas, NT isn't, so it's just not going to work. At least, not to the extent you'd hope |
|
From: Phillip S. <ps...@cf...> - 2002-04-30 03:36:47
|
At 04:20 AM 4/30/2002 +0200, you wrote: >Ah, and don't forget we aren't the only OS to have a POSIX subsystem, >still we are the only to question whether its root directory should match >the "system" root, whether /dev is visible to other subsystems, and so on. >Designers of MacOS/X had no doubt, apparently, and they solved the >"usability" issue (i.e. the user wondering what are all those strange >directories in the root) raised by some by just... hiding the POSIX >directories in the GUI. MacOS/X is a Unix you say? Partially true, but >BeOS wasn't at all. Still, also its POSIX subsystem accessed the same >namespace of native programs, and /dev was visible to all programs. One >wonders why those fools at Be and Apple decided so, given the elaborate >rationales the members of this project use to justify the opposite approach They decided to do so because their entire systems were based on POSIX, our is not. It is easy enough to use a single posix filesystem when the kernel and applications are all based on posix, it is not when the kernel and applications are based on NT. Windows applications assume that there are drive letters, that files have extensions to indicate their type, and that they have an ACL, not a chmod mask. Trying to run these apps on a posix filesystem requires dirty compromises - just look at WINE. The issue here is not what the user sees in the gui, but what the applications see the filesystem as, and win32 apps expect to see a win32 type filesystem, not a posix one. OSX and BeOS apps expect to see a posix filesystem, which is why they have no problems doing so. >One more thing: NT is NOT a microkernel, so please stop considering it >such. It may make sense to have special filesystems (think /proc) >implemented by subsystems, ON A MICROKERNEL SYSTEM, that will surely >provide facilities to implement system calls as IPC calls. But, alas, NT >isn't, so it's just not going to work. At least, not to the extent you'd hope This is something I have been asserting for a long time now, yes, NT is NOT a microkernel despite what MS says. It is a modular kernel. 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? It makes sense to me to just leave it in the posix subsystem in user space in that case. If win32 and native apps could also see it, then sure, put it in the kernel, but I don't think you can do this, as /proc is a posix filesystem, and as mentioned above, win32 and NT native apps can't deal with posix filesystems. 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. If you are ever on irc, we could discuss this in #ReactOS. |
|
From: KJK::Hyperion <no...@li...> - 2002-04-30 23:55:53
|
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? |
|
From: Steven E. <ste...@ya...> - 2002-05-01 01:32:57
|
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
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-01 01:59:09
|
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 |
|
From: Phillip S. <ps...@cf...> - 2002-05-01 01:51:10
|
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. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-01 03:53:07
|
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...) |
|
From: Martijn S. <ma...@uv...> - 2002-05-01 06:23:38
|
> -----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?? |
|
From: Kohn E. D. <em...@cs...> - 2002-05-01 15:12:39
|
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 |
|
From: Casper H. <ch...@us...> - 2002-04-30 12:17:17
|
tir, 2002-04-30 kl. 04:20 skrev KJK::Hyperion: > At 02.14 30/04/2002, you wrote: > >I think you give up to easily. One problem is that you are trying to turn > >ReactOS itself into a POSIX environment, instead of taking advantage of > >the ReactOS subsystem abillity. > > My point of view, which I won't try to defend any further (at least for a > very long time), is to mix the best of all subsystems. The Win32 "standard" > for filesystem structure is hardly the "best". Drive letters are hardly the > best way to identify devices. The /dev directory on my Mandrake Linux look like this: crw------- 1 root root 10, 10 aug 30 2001 adbmouse crw------- 1 root audio 14, 14 aug 30 2001 admmidi0 crw------- 1 root audio 14, 30 aug 30 2001 admmidi1 ... crw-rw---- 1 root disk 27, 17 aug 30 2001 zqft1 crw-rw---- 1 root disk 27, 18 aug 30 2001 zqft2 crw-rw---- 1 root disk 27, 19 aug 30 2001 zqft3 5699 entries! Why is this way so much better than the NT way, where drivers register device objects with the object manager? Also the root directory on the Mandrake Linux has the following entries: bin boot dev etc home initrd lib lost+found mnt opt proc root sbin swap tmp usr var Why is this a better layout than that on my Windows NT partition? Documents & Settings Program Files Windows And finally, why shouldn't I be able to assign my CD-ROM a drive letter? Is /mnt/cdrom better than D: for accessing my CD-ROM? Your arguments: "The Win32 "standard" for filesystem structure is hardly the "best". Drive letters are hardly the best way to identify devices." are not good enough for me to agree with you. Multiple roots are bad, they are the > inheritance of an era (DOS) when there was no distinction between the > operating system and the user interface, but we don't need them anymore Sure we need them. You talk of DOS as if we did not learn from it and it is not usable when really, DOS has survived for many years. Consumers are used to have drive letters. Changing them will cause confusion. If ReactOS is ever going to reach Windows users, the project must focus on the users. > One more thing: NT is NOT a microkernel, so please stop considering it > such. It may make sense to have special filesystems (think /proc) > implemented by subsystems, ON A MICROKERNEL SYSTEM, that will surely > provide facilities to implement system calls as IPC calls. But, alas, NT > isn't, so it's just not going to work. At least, not to the extent you'd hope Yes, NT is not a microkernel. NT has microkernel principals in it's design, but it is not a true microkernel because it is comercially impractical. AKAIK, no comercial operating systems implement a true microkernel design. Since someone claim that MS says it is, I would be glad if someone would post a link to some official statement from MS, because I have never heard them say this. The only information I have about this is from Inside Microsoft Windows 2000 published by Microsoft Press. |
|
From: KJK::Hyperion <no...@li...> - 2002-04-30 18:17:50
|
At 14.16 30/04/2002, you wrote: > > >I think you give up to easily. One problem is that you are trying to turn > > >ReactOS itself into a POSIX environment, instead of taking advantage of > > >the ReactOS subsystem abillity. > > My point of view, which I won't try to defend any further (at least for a > > very long time), is to mix the best of all subsystems. The Win32 > "standard" > > for filesystem structure is hardly the "best". Drive letters are hardly > the > > best way to identify devices. >The /dev directory on my Mandrake Linux look like this: Linux has a flat /dev, except for the USB root. It's not /dev the bad idea, a flat /dev is >Also the root directory on the Mandrake Linux has the following entries: [...] >initrd nonstandard >lost+found ext2 crap >root nonstandard >swap nonstandard >Why is this a better layout than that on my Windows NT partition? >Documents & Settings >Program Files >Windows Read the FHS: <http://www.pathname.com/fhs/> I have no patience to explain something that *books* have been written about >And finally, why shouldn't I be able to assign my CD-ROM a drive letter? never said this > > Multiple roots are bad, they are the > > inheritance of an era (DOS) when there was no distinction between the > > operating system and the user interface, but we don't need them anymore >Sure we need them. You talk of DOS as if we did not learn from it and it >is not usable when really, DOS has survived for many years. Consumers are >used to have drive letters. Changing them will cause confusion. If ReactOS >is ever going to reach Windows users, the project must focus on the users. no comment. Remember that the posts to this list are archived |
