In Linux world there is a sensible filesystem layout where variables go
under /var and programs generally go under /usr, etcetera.
In Windows world, this wasn't done. Unfortunately: logs, temp files, and even programs are all usually under a Windows directory. I don't think there is a place in the Windows file system that isn't a mix of stuff. Frankly, it seems that programs can be anywhere in Windows. This is only true in Linux world if you are root.
Can the file layout in ReactOS be different without breaking compatability?
Is there a trick, such as a second view of the filesystem to organize the
files in a more unix like way, that won't break things?
Also on the subject of file control:
Is it possible to make sure that software is installed in such a way that the
system can keep track of it? I'm thinking, don't trust binaries that aren't installed through the proper channels. One might even go so far as having a daemon in the background clear out improperly installed software from both the filesystem and the registry. This obviously is a down the road idea
and a risky one considering that there are many shared dependencies.
Filesystem layout...
Moderator: Moderator Team
You have to differ NT and Win32-subsystem; and Unix (as the architecture) and UNIX (the operating system) derivates like *BSD and Linux.
The VMS/NT architecture is far more advanced than Unix architecture. In Unix everything "is" a file. If you want to print you can pipe it to the printer which is in the system-file-tree-structure as a "file". In NT everything is a object. If you look at the screenshot-picture below I think you will get it.
NT has a for normal user hidden object structure, see screenshot. It is a lot better divided-up as Unix with its cryptical dir-names.
Most Unix user laugh about Windows volume drive letter. It's funny that those people don't understand that NT has a similar volume-naming schema as Unix, but even better as you don't need a man-page or doc to understand the cryptical names.
Many of the basic concepts and internal mechanisms of early versions of MS-DOS were patterned after those of CP/M. Internals like file-handling data structures were identical, and both referred to disk drives with a letter (A:, B:, etc.). The main innovation was MS-DOS's FAT file system. This intentional similarity made it easier to port popular CP/M software like WordStar and dBase. However, CP/M's concept of separate user areas for files on the same disk was never ported to MS-DOS. Since MS-DOS had access to more memory, more commands were built in to the command-line user interface logic, making MS-DOS somewhat easier to use.
As Win16 (as supported from Windows 1 to WinXP 32-bit), it use the same schema and most versions of windows use FAT as default filesystem.
Win32 has been an improvement of Win16 API, but for compatibility reasons many things are still around.
So to sum up, the NT architecture don't rely on drive letters nor and is more flexible than Unix by design. On top of NT sits the Win32 subsystem for compatibility reasons. Modern setup applications let you install apps on any location you choose, so no drive-letters are required anymore.
Using the registry, the NT objs and filesystem features link hard-links, it's possible design your own structure, pretty much how you prefer it and most applications will work fine too.
Only applications which have been coded in a bad way (hard-coded path, using outdated API functions, Win16 apps, etc.) won't work.
Unix-like and otherwise POSIX-compliant systems, including Linux-based systems and Mac OS X, have a simple system for managing individual file permissions. POSIX also specifies a system of access control lists, but it is only implemented by certain file systems and operating systems.
DOS variants (including the Microsoft products MS-DOS, Windows 95, Windows 98, and Windows Me) do not have permissions. There is a "read-only" attribute that can be set or unset on a file by any user or program.
Microsoft Windows NT and its derivatives (including Windows 2000 and Windows XP), as well as VMS and OpenVMS use access control lists (ACLs) to administer a more complex and varied set of permissions.
In NT you can set-up ACLs for anything you can think off.
Unix traditionally lacks advanced control mechanism by design. The only thing you have is "chmode".
Only recently the NSA added ACL support to Linux call "Security-Enhanced Linux" (SELinux). Another recently developed app is AppArmor ("Application Armor") by Novell. Both are additions, some call it hacks; other don't trust/like Novell and/or NSA.
Some resources say that WinNT is more POSIX compilant than Linux. I don't know if it is true, but it might be the case.
(POSIX or "Portable Operating System Interface for uniX")
I remember that there had been an emulator for Linux to allow to run basic UNIX apps, years before Wine become useable. In the early years, Linux had basically no application, as it was incompatible with UNIX in several ways.
The problem of WinNT is the user interface don't provide the functions to use all the advanced features. Also some command-line tools are cumbersome. That's a great chance for ReactOS to make it better.
[ external image ]
Edit: I forgot to add the screenshot before, sorry.
The VMS/NT architecture is far more advanced than Unix architecture. In Unix everything "is" a file. If you want to print you can pipe it to the printer which is in the system-file-tree-structure as a "file". In NT everything is a object. If you look at the screenshot-picture below I think you will get it.
NT has a for normal user hidden object structure, see screenshot. It is a lot better divided-up as Unix with its cryptical dir-names.
Most Unix user laugh about Windows volume drive letter. It's funny that those people don't understand that NT has a similar volume-naming schema as Unix, but even better as you don't need a man-page or doc to understand the cryptical names.
Many of the basic concepts and internal mechanisms of early versions of MS-DOS were patterned after those of CP/M. Internals like file-handling data structures were identical, and both referred to disk drives with a letter (A:, B:, etc.). The main innovation was MS-DOS's FAT file system. This intentional similarity made it easier to port popular CP/M software like WordStar and dBase. However, CP/M's concept of separate user areas for files on the same disk was never ported to MS-DOS. Since MS-DOS had access to more memory, more commands were built in to the command-line user interface logic, making MS-DOS somewhat easier to use.
As Win16 (as supported from Windows 1 to WinXP 32-bit), it use the same schema and most versions of windows use FAT as default filesystem.
Win32 has been an improvement of Win16 API, but for compatibility reasons many things are still around.
So to sum up, the NT architecture don't rely on drive letters nor and is more flexible than Unix by design. On top of NT sits the Win32 subsystem for compatibility reasons. Modern setup applications let you install apps on any location you choose, so no drive-letters are required anymore.
Using the registry, the NT objs and filesystem features link hard-links, it's possible design your own structure, pretty much how you prefer it and most applications will work fine too.
Only applications which have been coded in a bad way (hard-coded path, using outdated API functions, Win16 apps, etc.) won't work.
Unix-like and otherwise POSIX-compliant systems, including Linux-based systems and Mac OS X, have a simple system for managing individual file permissions. POSIX also specifies a system of access control lists, but it is only implemented by certain file systems and operating systems.
DOS variants (including the Microsoft products MS-DOS, Windows 95, Windows 98, and Windows Me) do not have permissions. There is a "read-only" attribute that can be set or unset on a file by any user or program.
Microsoft Windows NT and its derivatives (including Windows 2000 and Windows XP), as well as VMS and OpenVMS use access control lists (ACLs) to administer a more complex and varied set of permissions.
In NT you can set-up ACLs for anything you can think off.
Unix traditionally lacks advanced control mechanism by design. The only thing you have is "chmode".
Only recently the NSA added ACL support to Linux call "Security-Enhanced Linux" (SELinux). Another recently developed app is AppArmor ("Application Armor") by Novell. Both are additions, some call it hacks; other don't trust/like Novell and/or NSA.
Some resources say that WinNT is more POSIX compilant than Linux. I don't know if it is true, but it might be the case.
(POSIX or "Portable Operating System Interface for uniX")
I remember that there had been an emulator for Linux to allow to run basic UNIX apps, years before Wine become useable. In the early years, Linux had basically no application, as it was incompatible with UNIX in several ways.
The problem of WinNT is the user interface don't provide the functions to use all the advanced features. Also some command-line tools are cumbersome. That's a great chance for ReactOS to make it better.
[ external image ]
Edit: I forgot to add the screenshot before, sorry.
Last edited by frik85 on Wed Jan 03, 2007 11:56 am, edited 1 time in total.
![[ external image ]](http://img246.imageshack.us/img246/4941/ntobjdg7.jpg){kind=link}
Re: Filesystem layout...
oddly enough, I would say the exact opposite is true.nute wrote:In Linux world there is a sensible filesystem layout where variables go
under /var and programs generally go under /usr, etcetera.
In Windows world, this wasn't done. Unfortunately: logs, temp files, and even programs are all usually under a Windows directory. I don't think there is a place in the Windows file system that isn't a mix of stuff.
*nix is a bit crazy, Windows makes perfect sense.
And even certain Linux distributions dislike the old Unix layout. Specifically, GoboLinux. They discarded the old layout and used their own, providing a new degree of flexibility in the process. Just because something is tried and true doesn't make it the best. Usually, that just exposes more and more problems and weaknesses, which result in new ideas.
-
ThePhysicist
- Developer
- Posts: 509
- Joined: Mon Apr 25, 2005 12:46 pm
@frik85: I'm missing that screenshot, you were talking about.
I would prefer to keep the ReactOS folder completely clean. Only install ReactOS stuff there. If an app wants to put a dll in system32, simple move it to another folder (either the application folder, wich is probably hard to detect or in "program files\shared dlls" or something like that. Detect when a dll is not needed anymore and delete it automatically.
The dependency list could be a registry hive stored in "program files\shared dlls" and could be reused when reinstalling ReactOS.
There should also be a shared dlls section in the "Software" cpl. to quickly remove obsolete entries by hand if ever needed.
Just my 5 cents.
I agree. The most annoying thing is that most applications store all there dlls (and other stuff) in system32, even if no other app would ever make use of that dll. In much cases the uninstaller even does not delete that dll or gives stupid warnings like "Do you really want to delete that file?" wich scares noob users and they will leave it there.nute wrote:In Windows world, this wasn't done. Unfortunately: logs, temp files, and even programs are all usually under a Windows directory. I don't think there is a place in the Windows file system that isn't a mix of stuff. Frankly, it seems that programs can be anywhere in Windows.
I would prefer to keep the ReactOS folder completely clean. Only install ReactOS stuff there. If an app wants to put a dll in system32, simple move it to another folder (either the application folder, wich is probably hard to detect or in "program files\shared dlls" or something like that. Detect when a dll is not needed anymore and delete it automatically.
In windows, you can setup Users to not be able to write to "c:"or "c:\Windows\..." for example. The problem is: most users work as Administrator and default user profile is allowed to write there, IIRC.nute wrote:This is only true in Linux world if you are root.
In times of malware ReactOS should have some protection mechanism, checking what app/installer is trying to do and either allow, ask or deny (I currently use winpooch for that, works great) But something integrated could do even more (check what files are copied where, maybe put them to a different folder and really keep track of the number of instances of an installed dll, wich might be difficult, as an installer might first check if a file is present and if yes, not even try to install it's own one. But it might be done by checking if a PE file (exe or dll, or whatever) is loading a shared dll and then add that PE file to the dependency list of the shared dll. When a PE file get's deleted, remove the entry form the shared dlls dependency list and delete the dll if not needed anymore.nute wrote:Is it possible to make sure that software is installed in such a way that the
system can keep track of it? I'm thinking, don't trust binaries that aren't installed through the proper channels. One might even go so far as having a daemon in the background clear out improperly installed software from both the filesystem and the registry. This obviously is a down the road idea
and a risky one considering that there are many shared dependencies.
The dependency list could be a registry hive stored in "program files\shared dlls" and could be reused when reinstalling ReactOS.
There should also be a shared dlls section in the "Software" cpl. to quickly remove obsolete entries by hand if ever needed.
Just my 5 cents.
Sorry, forgot to add it before. I just added the screenshot to my first post.ThePhysicist wrote:@frik85: I'm missing that screenshot, you were talking about.
To make it a bit clearer, there is no single Unix directory layout nor a single Windows one. Although, in Windows World there have been only a few minor changes, especially NT come with a bit different structure than Win4 aka 9x.
On the other side all Unix implementations have sligthly different structures.
A bad negative example was always SuSE Linux which was different in several ways than Debian & Co. I haven't used SuSE since it belongs to Novell, but from screenshots not that much seem to have been changed since then.
In Unix hard-coding paths is a usual methode, which means that every package has to be tested for each distribution as the directory structure differ more or less a lot.
Sure there are movements to unify the dir-layout, but in some ways the battle have already been lost back in the 90ies.
ive alwyas quite fancies the way windows does filesystems over unix types regardless of how it works underneath it. you SHOULD be able to keep all kinds of different things in one folder.
throwing everything into random folders "just because it makes more sense!" doesnt exactly make much sense.
why should my apache sit in my /usr/ (by default) and hide my website in a very different location.
It should all be in one location if it wants to.. much easier to make sense out of. Hell i had to delete a few programs off my MAC a bit back. took me AGES to find it all. i was starting to think i might aswell have reinstalled it :S same with my webserver (unix) it took me ages to realise where the hell it hid everything i needed.
throwing everything into random folders "just because it makes more sense!" doesnt exactly make much sense.
why should my apache sit in my /usr/ (by default) and hide my website in a very different location.
It should all be in one location if it wants to.. much easier to make sense out of. Hell i had to delete a few programs off my MAC a bit back. took me AGES to find it all. i was starting to think i might aswell have reinstalled it :S same with my webserver (unix) it took me ages to realise where the hell it hid everything i needed.
The real problem is that what is logic to someone is madness to sombody else. It's really like peoples desks. Take mine for example it is cluttered with all sorts of junk. Papers, books, a powerball, a wallet, mobile phone, cds, dvds, pens, watches, gamepads and a normal phone. I know where everything is somewhere in my unconsious mind. Because when I reach for a pen I will always grab it instantly whitout thinking "where is it".
But if I clean my desk and orginise everything, so that it looks better. I cant find my pen, I have to search for my wallet and everything else. So I prefer my clutter instead of a highly organised desk.
Because I know where everything is. If somebody else sits at my desk they will have to search for everything. The same as I would have when I organise my desk.
The same goes for the location of files and programs in your OS. I want to decide where I want to put program X. I don't want somebody else whoes logic is very different then mine to decide that for me. I am quite capable to decide for myself where I want it.
That my Documents ends up whit all sorts of folders with names like junk, newjunk, junkA, School, Bla and bladibla is a good thing. I know what is in there. Nobody else does. So it gives just an extra bit of personality to your PC. Just like your desk or home. You know where everything is, no one else. And that is a very natural thing for us.
You don't like it when someone forces you to put your tools in a closet when you want it to be in another closet. So therefore you shouldn't decide for people where they have to put their files/ programs.
Of course you need some sort of structure for things to work properly like a system32 folder. But it must be as flixible as posible for people to decide where they want their files.
But if I clean my desk and orginise everything, so that it looks better. I cant find my pen, I have to search for my wallet and everything else. So I prefer my clutter instead of a highly organised desk.
Because I know where everything is. If somebody else sits at my desk they will have to search for everything. The same as I would have when I organise my desk.
The same goes for the location of files and programs in your OS. I want to decide where I want to put program X. I don't want somebody else whoes logic is very different then mine to decide that for me. I am quite capable to decide for myself where I want it.
That my Documents ends up whit all sorts of folders with names like junk, newjunk, junkA, School, Bla and bladibla is a good thing. I know what is in there. Nobody else does. So it gives just an extra bit of personality to your PC. Just like your desk or home. You know where everything is, no one else. And that is a very natural thing for us.
You don't like it when someone forces you to put your tools in a closet when you want it to be in another closet. So therefore you shouldn't decide for people where they have to put their files/ programs.
Of course you need some sort of structure for things to work properly like a system32 folder. But it must be as flixible as posible for people to decide where they want their files.
Everything you say is very interesting. But you should decide which is the purpose of reactos. Do you think that EVERY program that works in Windows should work in Reactos or just to have compatibility with Windows binaries?
In the first case we should keep exactly the same organisation and logic as Windows .
But if we choose the second case , I'm sure that when Reactos become stable and popular there will be different executables for Windows and reactos just like linux. I think that it should be avoided.
In the first case we should keep exactly the same organisation and logic as Windows .
But if we choose the second case , I'm sure that when Reactos become stable and popular there will be different executables for Windows and reactos just like linux. I think that it should be avoided.
You can just change some registry settings and all proper implemented Win32 apps will work on pretty much any tree-structure-layout.Smiley wrote:Everything you say is very interesting. But you should decide which is the purpose of reactos. Do you think that EVERY program that works in Windows should work in Reactos or just to have compatibility with Windows binaries?
In the first case we should keep exactly the same organisation and logic as Windows .
... think of "%SystemRoot%", etc.
As the registry get loaded in advance, even the WinNT/ReactOS kernel and other parts depend on it. So it's possible to change several settings and design your own tree-structure.
It's possible with WinNT series and it will be possible in an easier way in ReactOS.
Linux and Unix filesystems look like a mess.
There is a reason. Called execute only binarys. Windows can put resources and the like inside binarys. Linux and Unix this is most commonly not a option. Even the directory where the binarys are may not be user readable. It does not need to be for the operation of the Linux system. Stops user downloading binary and using software to attack it on another machine to find flaws then coming back to server.
So resources are split away from binarys. Its a old security thing.
Web site data is split away to where the demeaons are ment to store there changeable data. To backup a Linux system should be compact. Take a list of installed packages. Backup what has changed ie config file /etc then /var. If everything is right only /root and /home are left.
Linux does not look tidy at first but it mess has reason. Getting reason in head and it all suddlen makes sence. Then release the people who created it could not spell and got some things wrong.
/etc was ment to be for left overs. But it ended up configuration files.
/usr is user Meaning User Applications ... Once the names of Directorys make sence everything starts working.
SElinux is vaildated by the main Linux developers. AppArmor is not. You are not depending on NSA for SELinux. Please define recently for ACL support SElinux is release year 2000 So 6 years old. Thinking Linux only started in 1991. Not to bad. Patchs attemping ACL were around 1997-8 for linux some of them did not work exactly right either. Unix and BSD had ACL support long before Linux. Newer OS takes time to develop. We should know that well here. 8/9 years and reactos does not have secuirty yet. So Reactos is going to get it about the same time as Linux and Freebsd by the looks of it. Windows was lucky it started off with a running start from VMS. Ie the 8/9 years of early development to get up to doing secuirty. Reason why I am annoyed that windows is so poorly setup by default for such a long time.
Note there are 4 common ACL systems in Linux http://gentoo-wiki.com/Access_Control_Comparison_Table.
And three for them can be used in combination with each other RSBAC, grsecurity and SELinux. AppArmor is the least used. So if you don't trust SELinux the default there are other options. Linux supports secuirty modules so the secuirty of linux can be changed.
Only recently has it become part of the standard kernel if you class 2001 as recently. Support of ACL has been kicking around in linux since pre 1998 as prototype kernel patchs.
Linux is more Posix compilant than Windows now. That can be changed Windows never upgraded there Posix compilant code sections from the 1991 standard. In 1994 Windows was slightly ahead in Posix by 1996 its was behind and has stayed there. Thinking there are 2003 posix standard. Its over 12 years out of date is SFU. Really hard to build modern day Posix stuff on. The required features are just missing.
The emulator to run UNIX apps is still there in Linux. Its for commerical programs not built for Linux but only for Unix systems. It makes them run. This even lets different processor to platfrom binary and filetye run if a emulator exists.
Linux there is a Single Directory layout system. Its call the Linux Standard Base. Ok this covers a lot more than the filesystem layout.
The battle has not been lost. Its being won. Problem is Linux Standard Base is not exactly a fast moving thing.
Lot of binarys packages are not built to LSB standards for Linux. The Standard is built to cope with relocation of package or packages. Program still should operate relocated.
Love point finger at defects in linux that will be fixed. Or features that have been done in very partical ways for really good reasons.
Heck before pointing stick. There are bad programs that use c:\Windows\temp hard coded in binary. Even that they are not ment to.
Linux/Unix has the same problems stuff like that should not be hard coded.
/tmp was hard coded in linux because its base folder and changeable.
/etc should not be hard coded. Default relocations of /etc are /usr/etc that normally ends up a symbolic link to /etc /usr/local/etc and /opt/applicationname/etc ~/applicationname/etc ~ is the user home dirrectory for anyone who does not know it. Those are just default relocations defined in the Linux Standard Base. In theory a user should be able to place a applictions dirrectory struck block anywhere they like.
Basicly the only except able hard code in Linux is truely /tmp. Lets just say there are a lot of bad programs out there. Most come from Unix where there are not rules on things like this.
Even /dev and /proc is movable. And there are ways of asking where the current device interfaces are in linux.
In time as more things become LSB. Renaming of some directorys will become possable. And Single application per Dirrectory like in Opt will also become possiable.
All libs were stacked in one place in Linux for the same reason windows has a system32 directory code recycling.
There is a reason. Called execute only binarys. Windows can put resources and the like inside binarys. Linux and Unix this is most commonly not a option. Even the directory where the binarys are may not be user readable. It does not need to be for the operation of the Linux system. Stops user downloading binary and using software to attack it on another machine to find flaws then coming back to server.
So resources are split away from binarys. Its a old security thing.
Web site data is split away to where the demeaons are ment to store there changeable data. To backup a Linux system should be compact. Take a list of installed packages. Backup what has changed ie config file /etc then /var. If everything is right only /root and /home are left.
Linux does not look tidy at first but it mess has reason. Getting reason in head and it all suddlen makes sence. Then release the people who created it could not spell and got some things wrong.
/etc was ment to be for left overs. But it ended up configuration files.
/usr is user Meaning User Applications ... Once the names of Directorys make sence everything starts working.
SElinux is vaildated by the main Linux developers. AppArmor is not. You are not depending on NSA for SELinux. Please define recently for ACL support SElinux is release year 2000 So 6 years old. Thinking Linux only started in 1991. Not to bad. Patchs attemping ACL were around 1997-8 for linux some of them did not work exactly right either. Unix and BSD had ACL support long before Linux. Newer OS takes time to develop. We should know that well here. 8/9 years and reactos does not have secuirty yet. So Reactos is going to get it about the same time as Linux and Freebsd by the looks of it. Windows was lucky it started off with a running start from VMS. Ie the 8/9 years of early development to get up to doing secuirty. Reason why I am annoyed that windows is so poorly setup by default for such a long time.
Note there are 4 common ACL systems in Linux http://gentoo-wiki.com/Access_Control_Comparison_Table.
And three for them can be used in combination with each other RSBAC, grsecurity and SELinux. AppArmor is the least used. So if you don't trust SELinux the default there are other options. Linux supports secuirty modules so the secuirty of linux can be changed.
Only recently has it become part of the standard kernel if you class 2001 as recently. Support of ACL has been kicking around in linux since pre 1998 as prototype kernel patchs.
Linux is more Posix compilant than Windows now. That can be changed Windows never upgraded there Posix compilant code sections from the 1991 standard. In 1994 Windows was slightly ahead in Posix by 1996 its was behind and has stayed there. Thinking there are 2003 posix standard. Its over 12 years out of date is SFU. Really hard to build modern day Posix stuff on. The required features are just missing.
The emulator to run UNIX apps is still there in Linux. Its for commerical programs not built for Linux but only for Unix systems. It makes them run. This even lets different processor to platfrom binary and filetye run if a emulator exists.
Linux there is a Single Directory layout system. Its call the Linux Standard Base. Ok this covers a lot more than the filesystem layout.
The battle has not been lost. Its being won. Problem is Linux Standard Base is not exactly a fast moving thing.
Lot of binarys packages are not built to LSB standards for Linux. The Standard is built to cope with relocation of package or packages. Program still should operate relocated.
Love point finger at defects in linux that will be fixed. Or features that have been done in very partical ways for really good reasons.
Heck before pointing stick. There are bad programs that use c:\Windows\temp hard coded in binary. Even that they are not ment to.
Linux/Unix has the same problems stuff like that should not be hard coded.
/tmp was hard coded in linux because its base folder and changeable.
/etc should not be hard coded. Default relocations of /etc are /usr/etc that normally ends up a symbolic link to /etc /usr/local/etc and /opt/applicationname/etc ~/applicationname/etc ~ is the user home dirrectory for anyone who does not know it. Those are just default relocations defined in the Linux Standard Base. In theory a user should be able to place a applictions dirrectory struck block anywhere they like.
Basicly the only except able hard code in Linux is truely /tmp. Lets just say there are a lot of bad programs out there. Most come from Unix where there are not rules on things like this.
Even /dev and /proc is movable. And there are ways of asking where the current device interfaces are in linux.
In time as more things become LSB. Renaming of some directorys will become possable. And Single application per Dirrectory like in Opt will also become possiable.
All libs were stacked in one place in Linux for the same reason windows has a system32 directory code recycling.
-
cmoibenlepro
- Posts: 483
- Joined: Tue Nov 30, 2004 5:44 pm
- Location: Canada
Who is online
Users browsing this forum: No registered users and 4 guests