Linux has had a unified directory tree since the early 90's where it completely doesn't matter which drives host which directories. Implementing such a tree on Windows and mapping "C:", "D:" etc. as pseudo-roots to suitable locations to make it backwards compatible would not be an insurmountable task. Surely not trivial, but even on Windows application programs do not write to physical drives directly which gives the filesystem an opportunity to do any path translations it wants to. Thus, the question becomes a matter of will: Why hasn't Microsoft considered it important to fix their drive accesses?
What do they see as the advantage of having drives mapped to drive letters? It's certainly not usability: Linux can produce "drive icons" for each mounted drive. You plug in a USB stick and its icon shows up on the desktop――all this regardless of whether the USB stick is actually mounted in /mnt/$STICK or /media/$USER/$STICK or wherever.
They could also support mounting extra drives to directories under C: so that the user would never have to deal with other drive letters. The "C:" would just be a historical prefix but in practice it wouldn't matter because you could mount your second disk at C:\Program Files\ and the applications wouldn't even know about it. I vaguely remember that WinNT kernel could actually do this, however it's apparently well-hidden from users because I don't see this having been set up anywhere.
Windows can indeed do this (since Windows 2000). It's not necessarily hidden, but the OS defaults to using drive letters for (new) partitions and most people don't mind. In Disk Management you can assign not only drive letters but also mount points for a partition (or both). I suppose you are left with the C-drive to be more or less / like you mentioned. I don't know if programs run into trouble because of hard coding of paths but that wouldn't be so much Microsoft's fault I think. I used to mount a USB-stick this way because it only contained a Truecrypt container, which would get its own drive letter thru Truecrypt so I didn't care to have two drive letters for one piece of storage. :)
[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
I think it's a perfectly fine distinction to make, and having devices always mount at the root seems a very reasonable restriction that actually helps novice users.
One could of course also argue that the unified tree is merely an artifact of having to store all kinds of OS information as files in that same tree, when they are not really actual files...
WINE already does it just fine.
And yes, you can trivially mount volumes in folders [⅜] (at least since Windows 2000, if not for longer). I did this for quite a while, although currently I've gone the other way and use drive letters as short forms for some folders I regularly use (H: is my home directory, for example, also mapped to Home: in PowerShell).
So to shorten all this: From a user perspective there is little difference. A normal Windows user certainly wouldn't care about whether his documents are in C:\Users\Foo\Documents or in \Users\Foo\Documents. For many people nowadays there is only one volume anyway, so C: is just a prefix to the only filesystem hierarchy people care about. From a kernel standpoint things don't need to change either, because there is only a single hierarchy at that level. Which leaves applications running on Windows, where I'd also not see a particularly compelling benefit except for the rare case to iterate all files on all drives which is a two-step process instead of starting at the hierarchy root. So marginal benefit on one side, and the potential to break thousands, if not millions of existing applications, scripts, etc., of which many are probably in use but not supported or updated anymore.
I'd encourage you to read Raymond Chen's blog some day. For an ecosystem as old as Windows (which does not rely on published source code of applications, which could be patched indefinitely to make it run on incompatible newer versions) backwards compatibility is a major reason why it's still used and relevant. And at that point you learn to live with minor historic design issues (MAX_PATH is another; on the other side of the fence, just look how long and painful the way away from X is).
___________
[π] https://blogs.msdn.microsoft.com/oldnewthing/20101011-00/?p=...
[−1] https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=...
[⅜] http://www.howtogeek.com/wp-content/uploads/2014/05/clip_ima...
"C:" is just shortcut for "\DosDevices\C:" which is just an alias to "\Device\ActualDeviceName".
See https://msdn.microsoft.com/en-us/library/windows/hardware/ff...
Once I moved the games to SSD, load times improved tremendously.
I'd love to upgrade all my storage to SSDs, but the cost/benefit ratio isn't that great IMO (it's improving, so may be a non-issue in a few years). FWIW, photos/videos/movies get stored on my NAS (4x3TB;RAID5) unless I'm editing them in Premiere.
Edit: fixed typo.
Of course it's just a gui on junction points, so you don't need it but it's free and easy to use.
[edit: not only for Steam, so should work for Oculus as well.]
Frequently played or smallish games I keep installed on the boot drive, but plenty of them get bumped to the data drive. It's either that or uninstalling them.
On my gaming PC, the SSD is only 128GB; which can fit the OS on it and not much else. I then have a 2TB hard drive for games (which is 60% full).
documents/photos/videos/movies I keep on my NAS where I can back them up and sync between devices.
C:\program files(x86)\
is where 32 bit programs go on Windows. Just like fstab goes in \etc on Linux. Generally, putting program files elsewhere winds up being a user managed pain in the ass at best and breaking dependencies at worst...by which I mean that eventually a user winds up with some program that won't run from K:\my programs\, if you don't believe me, well here's an example.Pretty sure the user reqs for the Rift require a 64-bit CPU.
That said, SSD boot drive isn't super uncommon.
All of my games go on a secondary drive. Of course, I also didn't spend $600 on a early version VR headset, so I guess I've got time to wait for the update. :)
edit: typos
Then they just got to building and it just never got on the update finished list, and many developers started using it internally. Now it is hard to do, or there are so many devs noone thinks it is their job as it isn't completing their milestones for ship. These situations probably got thicker when they were purchased by Facebook.
Could have taken 1-2 days in early development max or even 5 minutes at the start, but now it is layers thick. This can happen to many systems either from external libraries, quick prototyping without cleanup or other reasons that just stick around. Then some unluckly schlup gets stuck with the 'Pathing Issue' that turns into a 3 month ordeal, everyone feels sorry for the coder and his life is ruined for months.
It could also be those situations where everything was done in '5 minutes' but ends up sapping 3 months of dev time fixing. This happens often in game development, 'Hey dude I whipped up an AI system in five minutes' and then it works but doesn't work, then ends up being the source of bugs for most of the project. Watch out for the '5 minutes' architecture.
Hopefully this isn't a sign of quality across the project.
The support article in question is (presumably) referring to Oculus Home / Oculus Store, which (presumably) don't date back that far.
Limiting you to running off the system drive sidesteps a lot of those problems, and lets you make certain assumptions (e.g. it's probably NTFS and reasonably fast).
Also, drives that are not C: tend to disappear and reappear relatively frequently. Having a launcher have to check and handle it semi-gracefully is not simple. If you make people keep things on C:, they are more likely to stick around.
Can't imagine software created by such companies to have stupid hardcodings like these..
Valve pulled a similar move a while back where they prevented people on OS X from playing games they had paid for (Portal), because the combination of macbook IGP and OS X's OpenGL implementation dropped framerates to unplayable levels. The game ran fine on Windows on the same hardware.
You or I can immediately see the need for a symlink and implement it. The average gamer has probably never heard of such a thing, and it might take several hours of increasing frustration to discover that Oculus won't install on their game drive, look for solutions, learn what a symlink is, and figure out how to make one.
And even without that, if you fucked up but it's easy for the customer to fix, you still fucked up. That's not an excuse.
It's an annoyance for users that use SSDs or multiple partitions; I know I can use a symlink (I doubt all Oculus users will though), but the fact that this was overlooked is a little absurd. Fingers crossed for a day one fix, or at least an actual explanation.