All Oculus Software and VR applications must be stored in C:\ drive | Hacker News Reader

All Oculus Software and VR applications must be stored in C:\ drive

support.oculus.com

72 pointsjessfyi89 comments

Funnily enough, not just the fact that users and developers need to care about drive letters, the drive C: itself is called drive C: because drives A: and B: were reserved for floppy drives. And I don't think many machines have had floppy drives in the 2000's.

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.

You can mount a volume, even one that is already mounted with a drive letter, under any empty NTFS directory.

[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

While this is true, most Windows software is not prepared to treat this as a volume. And you still need the root to be a drive-letter in itself.

Most Windows applications don't know, since it's handled transparently by the filesystem driver, and a mounted volume need not have a drive letter at all.

> 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. :)

https://en.wikipedia.org/wiki/NTFS_volume_mount_point

As usual the problem is with badly behaving software. E.g. I have a bunch of software storing its crap in C:\Users\JohnDoe\Documents\ while I've changed the location of that folder to D:\JohnDoe\Documents.

That's what happens when a folder accesses the actual path when you've changed the CSIDL ID (relocating documents). If you've done it as an NTFS reparse point, there wouldn't be any such C:\Users\JohnDoe\Documents, and trying to navigate there would put you in D:\.

> would not be an insurmountable task

WINE already does it just fine.

Windows has, at the kernel level, a single hierarchy of all devices and filesystems. I'd still say the main reason for having drive letters in userspace is backwards compatibility. Remember how DOS allowed drive letters in front of UNC paths to trick path validation routines? Same thing here. Heck, cmd.exe even continues to support different current directories on different drives [π] (use set " to see the hidden environment variables [−1]) because presumably a bunch of batch files relied on that.

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...

You missed out the part "why would they do any of this". You can't just list the things Linux manages to do regardless of their unified tree, you got to explain the benefits.

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...

What are the user advantages to a unified directory tree? I've always found drive letters to be a moderately useful abstraction (I've been tripped up a few times on my Linux server when moving 20GB+ video files around - if I forget /home and /srv are mounted on different drives, a move operation takes a long time, but having separate drive letters makes it more immediately obvious).

windows does have a root hierarchy.

"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...

Probably not a deal breaker for most, but it seems a little weird that they didn't plan for this. Surely a relatively small SSD for OS + large HDD for games etc. isn't that unusual for Oculus' target market?

Isn't is the opposite? SSD for OS, programs and games, HDD for stuff like photos, videos, movies?

Once I moved the games to SSD, load times improved tremendously.

I'm in the top poster's category (as are many of my friends):

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.

Ideally, yes, the games would also be on SSD, but I've had my Steam library on a separate HDD for a while. I can get a 2TB HDD that is fast enough for me for around £60, which would store most of Steam library. Spending a similar amount on an SSD would only get around 240GB storage, which could be filled quickly depending what you want to play (random example from the Steam homepage: XCOM2 requires 45GB storage).

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.

While I'd like to keep games on an SSD and get those fast load times, you can only fit so many 40GB installs on a 128GB drive. Especially if you use the computer for anything else.

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.

With http://www.traynier.com/software/steammover you can physically move stuff to D: selectively, but leave them logically on C:.

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.]

You haven't need this sort of trick for ~3 years. Steam now supports multiple drives/steam folders

Thanks, didn't know that.

Can you move games after installation?

Not out of the box through the UI. You would have to cut/paste the game folders around, but Steam will automatically detect the move next time you restart the client.

Small SSD for OS, large, separate SSD for games and game delivery platforms.

Wow... The Sea Drive. Brings back memories of those weird systems I had to use in the dark, distant past, where programs had to inexplicably be aware of what physical device a file was on in order to access it.

This is what happens when your devs get the machines they want and not the machines their customers have.

Although, to be real, if you're running an Oculus, you have something similar to the machine the devs want.

That said, SSD boot drive isn't super uncommon.

If you have the specs for a Oculus Rift, and your C:\ drive ISN'T an SSD, you did something wrong when you specced out your PC.

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. :)

Unless you explicitly got a drive to put games on because you got sick of installing and uninstalling them all the time because you thought it wasn't 1995 any more.

Over here, devs want two Samsung 950 Pro on M.2, raid-0, for a 1TB boot/OS drive. The rest of it is also going to be SSD space, but C: will only be 1TB (or maybe less if they dual boot to Linux).

edit: typos

Where is "here" and what would a dev do with that sort of disk IO other than perhaps video editing?

I don't know where is "here" but I have no problem using disk IO - my C++ builds are IO bound.

I don't believe it. Unless you are running some 1999's 20gig hard drives and a i7-6700k with high speed ddr4 rams and use a ccache and gold linker, that is very very unlikely.

I have ~1TB SSD and ~3TB HDD (so I suppose both been made quite recently) and a single 12 thread Intel CPU using clang-based toolchain under various build systems. In your opinion, this system is never IO limited on any possible C++ project?

Odd that the twitchy front page of /r/Oculus made it's way on the front page here, but I'll echo the ever-present Oculus founder's response that addressing this is pretty high on their roadmap. Sauce: https://www.reddit.com/r/oculus/comments/4bd31n/oculus_softw...

Palmer said that fixing it was nontrivial. I wonder if that's "nontrivial because all software needs to be tested carefully even though it's just adding a configurable path" or "nontrivial for reason that are deep into OS fundamentals"?

My guess would be that once you allow something other than C:, you're opening things up to running games off of all kinds of weird devices like external USB drives, flash sticks, weird legacy hardware, network drives. This makes the problem of streaming assets a lot more challenging. Some techniques, like mmap'ing resources in, might require a NTFS formatted drive.

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.

> e.g. it's probably NTFS

It has to be since Vista.

good lord .. he is saying its non-trivial !

Can't imagine software created by such companies to have stupid hardcodings like these..

What I really love is that it has to go in "Program Files (x86)" specifically, even though the Rift requires 64-bit Windows.

Believe or not, a lot of programs today still do that.

A lot of times this happens because the installer itself is 32 bit even if the payload contains amd64 binaries. (Similar situation occurred back in the Win16 -> Win32 transition.)

Not that big a deal, it's easy to use junction points / symlinks across drives.

Rule #1 of interface design: "Easy for me does not mean easy for the user."

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.

Oh, I certainly it's a UX travesty from that standpoint. I was more commenting from the perspective of why it's not quite as bad as the title makes it out to be.

>This is near the very top of our roadmap ... we are still in the process of rolling out our support pages, don't take anything as final yet.

The fact that this is hard to implement is a sad, sad, reminder of how shitty backwards comparability can be. How, over the past 30 years has someone at MS not taken the time to write a real abstraction for the file system? When I first switched to linux 10 years ago I though 'Oh cool, you can mount stuff wherever you want, why would you do that?!' Now it saddens me to realize that the vast majority of computer users have never actually learned to use a file system despite the fact that they are one of the most useful information management tools ever invented, probably second only to the card catalog.

Yeah, so much for their Linux support.

This is really AMD and NVIDIA's fault, not Oculus'. Hitting 90fps is hard enough without taking a sizable performance hit from the linux graphics stack.

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.

May be they can use Vulkan now.

OS X isn't getting Vulkan (as far as I can tell). Apple's pushing Metal instead.

I mean Oculus on Linux. I wouldn't worry much about OS X - it's being phased out by Apple apparently, and Apple's mobile hardware won't handle VR either way. So Apple's platforms won't really be a worthy target for it.

Phased out? Link?

http://www.osnews.com/story/29134/Today_s_Apple_event_spells...

Vulkan's lower-level access certainly allows performance concerns to become the domain of the engine rather than the driver. Games standardizing on a few big engines seems to be doing more for linux than when operating systems standardize on a few big APIs (which is necessary but not sufficient).

Coupled with other recent news (the AMDGPU effort, 900-series firmware for kernel 4.6, ..) i'm cautiously optimistic about the future for 3D on linux - but mostly i'm cautiously optimistic at the cross-vendor adoption of Vulkan. Today a lot of enablement comes via vendor-specific tech (LiquidVR/GameWorks), and Vulkan has kept the scope open for extensions just like OpenGL did. I hope the industry has learned to avoid fragmentation after some of the horror stories from early DirectX[1].

1. "The pixel shaders of Shader Model 1.0 were extremely specific to NVIDIA's hardware. There was no attempt made whatsoever at abstracting NVIDIA's hardware; SM 1.0 was just whatever the GeForce 3 did." -- http://programmers.stackexchange.com/a/88055

> I hope the industry has learned to avoid fragmentation after some of the horror stories from early DirectX[1].

They learned it so well, that except for urban legends OpenGL isn't used at all in game consoles and if it wasn't for Apple's adoption of OpenGL ES for iOS gaming, it would have been ignored as well.

And now it has been shown the door on Apple platforms.

Except Apple's platforms will die out as high end gaming targets. As VR developers already said multiple times. Apple doesn't care about it apparently.

The only VR guys that said that are Valve, which is just a studio in a sea of AAA studios.

How well are they selling those Steam machines?

What about that OpenGL and Vulkan support on the PS4, Wii and XBox?

The games industry cares about delivering game experiences and selling IP, not FOSS APIs.

> The only VR guys that said that are Valve

No one argued with that because what they said is true. Apple are simply out of the VR picture. At least for now.

> How well are they selling those Steam machines?

Good enough I suppose, given that soon after Steam Machines were released, Sony and MS rushed to announce that they plan to update their hardware more frequently. Competition works. It doesn't mean it won't get even better.

> The games industry cares

You keep talking about it as if it's some single mind. It's not.

> What about that OpenGL and Vulkan support on the PS4, Wii and XBox?

You can forget about OpenGL. I expect Sony to add Vulkan supprot first, and then MS add it under pressure a few years later.

> No one argued with that because what they said is true. Apple are simply out of the VR picture. At least for now.

Until they release their own VRKit.

> Good enough I suppose, given that soon after Steam Machines were released, Sony and MS rushed to announce that they plan to update their hardware more frequently. Competition works. It doesn't mean it won't get even better.

So what are those dangerous the numbers of Steam Machines running SteamOS sales?

Sony and MS have little to fear from those sales on a global scale, specially since most Steam Machines were actually being sold with Windows.

> You keep talking about it as if it's some single mind. It's not.

I was an IGDA member, attended a couple GDCE bot at London and Cologne, was part of the regular meetings of a game developments degree, had the opportunity to visit a well known AAA studios, including SCEE.

Didn't stay as my position in regards to private life is not what the industry expects from the majority of developers.

What is you experience on the industry?

> You can forget about OpenGL. I expect Sony to add Vulkan supprot first, and then MS add it under pressure a few years later.

Sony will only add Vulkan on their Android phones, because Google added it.

They will never replace LibGCM with Vulkan, when their API and existing tools can do so much more.

> Until they release their own VRKit.

Possible. Let them.

> So what are those dangerous the numbers of Steam Machines running SteamOS sales?

No idea, but MS and Sony's fear is telling. They are scared that their comfortable grip on the market will be busted. And that's good. Without competition they would have kept their 7 year hardware refresh cycle. Monopolists don't like change and move forward only under the pressure of competition. In result, consoles hardware will be more up to date, and games won't be held back by it like they often were until now. Thanks to Steam Machines.

> had the opportunity to visit a well known AAA studios

You mean controlled by legacy publishers and old media? Those are bad examples. It's not where innovation happens.

> What is you experience on the industry?

I'm interested in innovative studios, not in the old media controlled ones. For instance Cloud Imperium are working on adding Vulkan support to CryEngine at present. That's interesting.

> Sony will only add Vulkan on their Android phones, because Google added it.

Sony will only benefit by adding Vulkan on their PS#, and in the processing giving MS a kick in the rear. Wait and see.

opengl is often faster on GNU/Linux. Also, there's Vulkan.

FWIW, this looks like it might only apply to games purchased through Oculus Home, the Steam equivalent for the Oculus Rift (or perhaps the UPlay equivalent). Games/experiences that aren't distributed via Oculus Home (SteamVR, Steam games w/ Oculus support, independently distributed games) appear to not be beholden to this limitation.

For the DK2 maybe, but for CV1 this limitation is probably imposed by firmware (something that would be widely known if not for the NDA). Wouldn't surprised if this happens to be the result of whatever DRM they're employing.

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.

Minimum viable product.

Well that's weird. Must have something to do with the Windows registry. Maybe someone who knows more can elaborate.

Hard coded paths in a library, maybe?

  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.

Sorry but this is just not true. Steam, Origin, UPlay, and just about every other gaming marketplace allows you to install the gaming library anywhere you went. Heck steam allows you to straight up and move the steam folder anywhere, delete everything but the games and the steam.exe and it will repair itself.

Steam only added the ability to store games elsewhere relatively recently. It was a long sought after feature that took ages to implement. I doubt it was really easy and just a case of no-one caring.

By recently you mean in the last 5-10 years. It has been around for ages.

Is it easy? Probably not but that is irrelevant because the competition already does it.

Yeah, I had a look back and it's been around longer than I thought. I was so used to symlinking I didn't realise the feature has existed since 2011 or 2012.

It's '/etc'

Key words: 32 bit. 64-bit stuff should go in `C:\program files\`

Pretty sure the user reqs for the Rift require a 64-bit CPU.

  C:\program files(x86)\

Only exists on x64 versions of Windows, hence an x64 CPU is always present [or emulated]. Unlike Linux, for example, Windows x64 can execute programs compiled for x86. To do so, Windows x64 uses something called WoW or "Windows on Windows". The exception was Windows XP x64 [not to be confused with Windows XP Professional x64 Edition] which only ran on Intel Itanium processors and therefore lacked x86 mode. It was rather short lived.

> Unlike Linux, for example, Windows x64 can execute programs compiled for x86.

Linux can do this easily too.

> Unlike Linux

What? Linux has always had better multiarch support than Windows. Running x86 code on x86_64 has never been a problem on Linux, unless you custom built your OS to exclude it. Not to mention it doesn't require anything like LoL or "Linux on Linux", as you claim Windows seems to.

Most likely there is just a dumb reason behind it, like a coder just forgot to account for the drive letter in some new code. And they don't want to roll out a new version right now when they're about to start shipping.

Seems fair enough for a fairly new software.

Oculus VR was founded in 2012, and bought out by Facebook in 2014. It's not like they just bashed out a demo on the weekend, this is meant to be production-ready code.

Until recently (CV1 engineering samples), the only publicly available software that could be reasonably considered "Oculus Software" was the driver and its configuration utility, clocking in at about ~50MB installed.

The support article in question is (presumably) referring to Oculus Home / Oculus Store, which (presumably) don't date back that far.

Don't think so. It looks more like some really bad choices mostly like bad dependencies or hard-coded things or something else. But to me this reflects the product quality and most importantly a big yellow warning on software quality.

To me, closely following the standards for Windows means less code and in particular less code that introduces edge cases for the sake of edge cases.

Is "installing only to C:\" an actual Windows standard? I'm fairly certain Windows doesn't have a problem installing software to different drives.

Per the article Occulus installs to

  C:\program files(x86)\

and that is the standard location for 32 bit (x86) program installation on Windows 64 bit systems. Many, but not all programs [obviously] can be installed at non-standard locations.

See Installer and Logo Certification Requirement 2.4 here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

It's not standard - at least not per any official MS documentation. There are specific API calls you are supposed to make to query the program files directory, which will be different depending on whether you are a 32bit or 64bit program, and where the user/administrator has configured the program files folder to be.

This is also like windows programming 101, so I'm honestly a bit shocked to see oculus dropping the ball on this.

Specifically https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...

https://code.msdn.microsoft.com/windowsapps/CppShellKnownFol...

hr = SHGetKnownFolderPath(FOLDERID_ProgramFiles, 0, NULL, &pszPath);

It probably started with a // TODO add file path system.

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.

Party like it's 1999 !!

I haven't had a C:\ drive in a decade.

Obviously "I'm proud I'm not a Windows user" comments are kinda irrelevant for an article about a device that currently only works on Windows, am I right?

Reply on news.ycombinator.com