Hacker News Reader

Comment by valine | Hacker News Reader

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

  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.

Hard coded paths in a library, maybe?

Reply on news.ycombinator.com