I currently have Windows XP installed to the Location C:\SBIN, making the shared 32-bit system libraries C:\SBIN\System32... my biggest pain, but I have that Junctioned to C:\lib.
My Profiles are stored in C:\home, I keep all temporary data in C:\tmp, and all installed applications default to C:\bin... does this sound familiar to anyone?
I have C:\man, C:\share, C:\dev, C:\contrib, C:\download and C:\ftproot, C:\pub and C:\wwwroot all point to the same drive.
Yes, all my drives, Hard, floppy or optical are mounted somewhere under C:\ which I treat like a *nix "/" root.
It's not hard to do. Most drives are mounted in several places, not least of which being C:\dev\hda, C:\dev\ide\0\0 etc type locations.
Yes $temp$ and $tmp$ point to C:\Temp, but so does the registry. I have mounted several block devices directly from "\\.\" addresses, and mounted an entire drive as my main user profile... All "RECYCLER" folders / Directories on my system are also linked to C:\tmp.
This all makes perfect sense to me. If we can't do away with drive letters, lets at least mount all drives under the one letter. <shrug>
I can confirm that compatibility is limited very little by this. Most problems arise from programs written in Visual Basic... usually Versions below 6. It does happen a lot with 16-bit applications that assumptions about system folders locations are made... the other big culprits are "Games", and not your PopCaps flash games, but the big commercial ones. Stuff that effectively mount a virtual drive in your filesystem to "speed access to the graphics and sounds that make our game so amazing"
when actually if you crack the code of the "virtual filesystem"
and store the files in their native form on an NTFS or e2fs system the game runs faster.
Again, it's more often the installer than the program which baulks at weird directory structures than the Application it's self, so a temporary hard-link / junction usually does the trick, if not, a little post install reg-tweaking, or binary hack on the exe will finish it.
Speaking of which, API calls to the filesystem are easily patched... even when you don't control the source to the OS. Don't Microsoft keep a huge database of [/i]"Application Compatibility"[/i] information to do similar tweaks automatically behind the users back?
So for compatibility, I presently have more problems with ROS not supporting ACLs in the file system than with my *very* *very* OEM'd Windows XP.
And I don't think you are getting the point Forart is making. I used BeOS (Haikus' predecessor) for a long time, and the standard is that if something needs registering (an context menu extension for example) then it's unzipped into the Context Extensions folder, either in the system folder for all users, or your users one if you just want it for this user... If a program is so complex that it needs to install context menus, thumbnail filters, lib.so's etc then it will have an install.sh bash script in the folder which you run right after unzipping, or is run by the program it's self on first execution when it finds stuff isn't registered.
We did also have the Software Valet which would install packages OS X style.
Windows programs can do this too, you don't just have to throw a complete wobbly and spew some nonsensical error message at the user when you can't find the font, dll, ocx or registry key you are looking for, you can just run a mini setup that fixes it and get one with it.
Unfortunately, that is all down to ethos, and the ethos of the Windows user and development community is not something that can be changed by a project like ROS. At least, not alone. If ROS were to develop a community of users and developers behind it with such an ethos, that could have a bearing on developers looking to write applications which work well on both ROS and Windows systems, and that in turn could knock on to die hard Windows users demanding such features as standard in all Windows programs.
Such was the power of the Amiga community of users and developers, who, like the Linux community at present, had a far closer relationship than do Windows Developers and Users.
If you want to make a system that isn't even at Beta testing stage yet better than the system it's attempting to "clone" then giving the user some control over how and what (s)he installs right from the get go would be a good place to start. Windows true starts by asking you if you want to install a third party SCSI or RAID driver on floppy disk (how many PCs still have floppy disks?) and then treats the user like a complete idiot from there until the end of the OOBE, installing everything on automatic. No chance for a change, no choice... Oh yea, I have to tell it that I'm British 15 times in different places, and manually correct the way it thinks I should use dates and times, but that's about it for customisation.
Hacking profiles, and user programs on to a different drive or partition to the OS, is a real nightmare after it's installed... where as if I could say that Program Files was D: Profiles E: and pagefile.sys (formerly 386smart.par formerly swap.bin or WHY) was on F: then all would be hunkey dorey and the whole system would run smoother. Way less background defraging or downtime for a complete system defrag.
Here's another idea, NT4/5/6 only enable compressed/encrypted files and ACLs on NTFS volumes, yet I remember using per-file background compression and encryption on floppies and the hard disk when all I had at my disposal was DOS. It wasn't even vFAT just FAT12 or FAT16. I had TSRs that managed the extra data. Meta data like comments could be stored in 4DOS and other programs in a DESCRIPT.ION file... utilise similar systems to allow ACLs and extended streams in FAT! We've all seen Macs do it with DOS floppies / USB Thumbdrives. The Resource Fork has to go somewhere! Right?
My point is that you can be, at once, less sophisticated AND better.
Microsoft still haven't gotten WinFS off the ground and yet Google Desktop Search comes pretty close to rivalling Apples Spotlight without using extended metadata in the filesystem. And, again BeOS was there long long ago doing it better than we have it today.
What happened to dynamic folders? They worked so well on Longhorn, I can't figure them on the final Vista and I'm back to saved searches.
How about a "Recycled Bin"
which was actually a zip/7z/bz2 file storing all the information about trashed items in an archive. You can delete the archive if you want to empty the bin, and at least you've saved some space by throwing stuff in it.
There are a million and one simple things Microsoft forgot, and while we can add Context Menus and toolbars, widgets and docks to the existing system, it would be so much easier and nicer to build those into a system from the start.
The don't affect compatibility, because the extension don't, why would building them in? It wouldn't, it would just make them load faster, and take up less space by using shared code.
My hope is that the 0.5 new Explorer replacement will be based on "Calmira II
" or Directory Opus
, and begins (much like early Red Hat distributions) looking very much like Windows, but rapidly becomes apparent that it can be configured to be pretty much anything you want.
My 2 cents.
Peace for now.