KVR :: DSP and Plug-in Development » current thoughts on install paths on Windows. [View Original Topic]
There are 41 posts in this topic.

---

Galbanum - Mon May 07, 2012 10:28 pm

---

Hi guys,

What are everyone's thoughts on the proper location to install the various components of your products on Win?


Does everyone generally agree with:

\Program Files\ should contain only executable,

\Program Data\ only generic supporting files

\Users\username\AppData\ the data created for the specific user's invocation of the program....

It bothers us that \Users\username\AppData\ and \Program Data\ are hidden folders. So we did not use these locations in the past. But writing things to \Program Files\ is a security no-no for some OSs it seems.

It seems some companies also use: C:\Users\Public\Documents\ or C:\Users\user\My Documents\ for user presets.

What's the consensus as of May 2012?

Thanks for your insights!

---

mystran - Tue May 08, 2012 6:11 am

---

I'd store settings to %appdata% and anything that's a "logical file" into Documents (by default). I'd draw the distinction to whether the user is expected to manipulate something as a file. Ie, if you can load presets from any directory then I'd default the save dialog to Documents. If you rely on a particular path only, then %appdata% seems more logical (possibly with import/export dialogs that don't rely on paths, though as far as plugins go most hosts have one anyway).

As far as Program Files/Program Files(x86)/Program Data, my view is that if you have both 32 and 64 bit versions, then it kinda makes sense to put anything that's specific to one version into the relevant Program Files, and anything that's common goes into Program Data, unless it takes a lot of space, in which case I'd allow the user to customize the path.. all the weird people (and there's a lot of them) that insist on having multiple drive letters will get angry if you dump a multi-gigabyte sample library to Program Data without asking them first.

---

koalaboy - Tue May 08, 2012 10:38 am

---

As partially stated above... it's broken.

As a developer, I like standard paths, but as a heavy user of a desktop PC, I like things to be customisable.

I run a 60GB SSD as my main drive, and am constantly frustrated at the crap that is dumped in ProgramData or Users, without the option to relocate onto the lovely 3TB drive I have next to it on a different drive letter. Most of this is Microsoft's fault by not offering a simple 'relocate directory' option, especially for User and ProgramData, but I therefore *expect* my programs to be flexible.

It's obviously a no-no to put any configuration under ProgramFiles, as Windows denies even the Administrator access and does all sorts of stupid virtualisation. If flexible isn't an option, I suppose Users is better than the abysmal abhorrent fudge that it ProgramData and the atrocities of *roaming* profiles.

If I'm sounding agitated, it's because it's a subject very close to my heart.

Me - I have two VST directories on my E: drive (yeah - the whole 32bit/64bit shenaningans) and *try* to keep VST data under there. I have additional top-level directories for samples (which has things like NI, Spectrasonics, etc.) and a couple of others for things like the Ableton Live library (yeah, geniuses, install the whole damn thing where *you* like then make *me* move it) and other slightly-flexible stuff (and my Steam games library, although current 'play' is often hardlinked onto the SSD).

By all means, offer 'My Documents' or some other Users location as default, but let me choose where everything goes. Even the executable. It's *MY* computer, and it should make no difference to you where I put it - you can stash a registry key for the locations if you like, just prompt me for the location if it's not there, so when I restore my backup, you don't force a re-install of everything

(Just a note: very few developers actually get all of this right, but soliciting thoughts is a huge step in the right direction, and much appreciated)

---

whyterabbyt - Tue May 08, 2012 11:13 am

---

What he said.

Seriously, dont be one of 'those' developers who go in the 'stupid installer and the buggers need to be junction-filed' list.

---

larm - Tue May 08, 2012 11:34 am

---

+1 to above. I also use a smaller SSD for the OS and then larger +TB disks for sample data. SSD:s really make the computer fast and silent.

Also I prefer to install "simpler" VST synths/effects manually into the vstplugins directory (not on C!). If developers provide an installer-less .zip file I always choose that.

Hate it when installers leave uninstall crap data and folders everywhere, even when things are "un-installed"

---

aciddose - Tue May 08, 2012 11:49 am

---

application data already supports customization and there is a portable application data directory as well.

nothing about this is broken except for the way people due to ignorance incorrectly use a well defined, functional system.

---

koalaboy - Tue May 08, 2012 12:09 pm

---

I'm sorry, but that's plain wrong.

The 'portable application directory' is hidden by default (and not relocatable) and I love the way you're telling me (unless I'm misreading this) that my ignorance is causing problems on a well-defined system.

If you want to lock a user down to what you think they should do, go and write for the iPad market. My computer is just that - mine, and for my benefit. Nobody tells me where I should, or shouldn't, put things, and whether I should be able to write to a location or not.

Sure, if I screw things up, it's my fault, but I'm okay with that and so should you be.

Again, by all means, set defaults as Microsoft would like, but if you don't let me change them to my liking, you're being both ignorant and arrogant, and are unlikely to have me buy your software in the future.

When exactly was it decided that people should do what computers dictate, rather than the other way around ?

---

whyterabbyt - Tue May 08, 2012 12:13 pm

---

That definition of 'not broken' does not sufficiently overlap with 'is used consistently enough' and 'does not require workarounds to prevent operational problems with legacy behaviour' and 'interoperates simply with informed personal practices and procedures defined and refined over years'

---

DuX - Tue May 08, 2012 12:18 pm

---

IMO it's alright to store some data in "users" folders, but it shouldn't amount to more than a megabyte. So it should be used for preferences and simple things. Samples and presets location should be customisable. It's as easy as that. Why is it so hard for some developers to understand that or give us that is beyond me, and I don't support them. Simple as that. There are many plugins and developers around, so if they don't understand that we need to put the data somewhere else, other than on bloody C:/something that's their problem IMHO... I just won't cope with that. My C: is also on a small SSD and I prefer my sample data and presets data somewhere else. It's also easier to have a backup of the operating system that way, and all the data concerning the plugins you use is placed in one folder "somewhere". Easy to backup. There should be some kind of a standard about that. It would make our lives soooo much easier.

Cheers!

---

whyterabbyt - Tue May 08, 2012 12:43 pm

---

Agreed. And to inject some reality :

backing up one's presets on system with more than a tiny handful of plugins and software actually, in reality, entails picking through the bones of variations on at least a large subset of the following (on a 64-bit system)

\program files\<application>
\program files (x86)\<application>

\program files\common files\<application>
\program files (x86)\common files\<application>

\program files\<developer>\<application>
\program files (x86)\<developer\<application>

\program files (x86)\common files\<application>

\Users\<user>\AppData\Roaming
\Users\<user>\AppData\Local
\ProgramData\<developer>\<application>
\Users\<user>\Documents\<application>
\Users\<user>\Documents\<developer>\<application>

That's how it actually is for us. that 'well defined system' has legacy issues, and practical ones too (for example applications which want to leave all their massive-but-temporary media files on one's small SSD drive) Thank f**k for junction points.

If a developer doesnt want to give us the choice of saving our creative content somewhere convenient to us (like, say, L:\Presets\<VSTname> or even just /Documents/<VSTname> ) then they're part of 'the problem' and missing a big point about who ytheir users are and what they're doing.

---

aciddose - Tue May 08, 2012 3:09 pm

---

documents and data go in documents.

nothing you're saying has anything to do with fixed application data like skin files or sample sets / banks that are not portable and not user customizable.

for example, say you have a rompler. the samples are sold as banks and you get one file for each. these are not user customizable.

the system provides the application data directories for this. portable directories are available to be created for example on external disks or usb sticks.

the installer then only needs to ask to which destination[s] the data should be copied.

it's 100% up to the application developer to implement this correctly. if done correctly, you have no problem.

for user documents and data, that uses the standard systems and defaults to "my documents".

the "legacy issues" are just bad programming. the standards have been in place for over a decade.



that would be first, just plain retarded, and secondly would go against the standards. this would be a major bug. any user documents should be handled by the standard systems which default to "my documents".

---

aciddose - Tue May 08, 2012 3:23 pm

---

why? there is no limit to the amount of data stored in data directories.



actually that standard already exists, it's the "users" folders.

most software does not implement the standards correctly.

---

Galbanum - Tue May 08, 2012 6:24 pm

---

Thanks for the input.

...so the consensus as of May 2012, seems to be there still is no consensus?


Seems maybe the best option is:


C://Program Files/ (obvious stuff)

C://Program Data/ (stuff that might have to be written by the app/plug, but the user needs not know about or interact with under normal circumstances)

Then we are left with user data, (user presets, sample data, large libraries etc.) I agree this folder should likely be customizeable by the installer and should be able to located on drives other than the primary system disk.

And I really can't understand why /Users/user/AppData/ should be hidden? Why hide user's data from them? It is THEIR data?? So I think we will avoid that location.

So user data will be fully customizable, and will default to:

C:\Users\user\My Documents\


Can anyone tell me why this plan sucks? Foresee any problems?

---

koalaboy - Wed May 09, 2012 1:20 am

---

That sounds fine.

(Oh, and ensuring the correct 'Program Files' directory according to architecture - x86 in (x86), x64 in standard)

---

whyterabbyt - Wed May 09, 2012 1:23 am

---

read what I said about SSDs again, and think a little bit.

---

aciddose - Wed May 09, 2012 8:59 am

---

doesn't change a thing.

in fact using a ssd for static data is ideal because the load times will be greatly reduced, and writes will never happen.

---

aciddose - Wed May 09, 2012 9:02 am

---

the ideal is to eliminate the concept of a filing cabinet and replace it with something like a desktop, or a dock, or a... well they haven't really thought of it yet.

---

whyterabbyt - Wed May 09, 2012 9:10 am

---

Still missing the 'think a bit' bit. Never mind.

---

aciddose - Wed May 09, 2012 9:28 am

---

there is nothing to think about. static data belongs in a static data directory. user data belongs in a user data directory by default using something like an OpenFileName() dialog which allows the user to select the path to be used.

there is no discussion. no disagreement. no A vs. B.

there are the facts, the standards and the rules and nothing else. obey, or disobey.

---

koalaboy - Wed May 09, 2012 10:18 am

---

PC - Personal Computer

'standards' such as these will just lead us into the pile of crap that is Windows 8, and the destruction of everything the PC actually stood for. Welcome to the new 'dumb' future.

And the point you seem to be missing about SSDs is that while they may be very 'nice' for static data, they're also damn expensive for large capacities, so it's not really viable to put a couple of TeraBytes of sample libraries on them.

---

whyterabbyt - Wed May 09, 2012 11:28 am

---

Nebulous posturing shite.

---

Benutzername - Wed May 09, 2012 12:19 pm

---

If you want an Apple computer go out and buy an Apple computer and live with it how Apple has designed it to work.

If you want a Windows computer go out and buy a Windows computer and live with it how Microsoft has designed it to work.

If you want a personal computer go out and buy a box of PC components of your choice, assemble the PC yourself, install a Linux variant of your choice and configure the OS like you want. Now it's designed how you want it to work.

If you don't want to go this route then live with the design choices that Microsoft and Apple have made for you.

---

whyterabbyt - Wed May 09, 2012 12:30 pm

---

Compiled a lot of Linux kernels which don't have a /etc, /bin or /boot directory have you?

---

Benutzername - Wed May 09, 2012 1:35 pm

---

Yes.

---

aciddose - Wed May 09, 2012 4:25 pm

---

yes the idea that this is a recent invention is laughable and shows just exactly how stupid most windows users are.

the home directory and application data directories have existed for decades. uh, well, nearly four of them now actually.

FOURTY YEARS.

dude, some guy that looked like this invented this whole standard:

(he didn't really, but just to give an impression of how f***ing long 40 years is.)

then some amatures randomly implemented a bunch of crap, and 25 years later microsoft finally implemented the standards instead for the first time with their mass market products.

that was already twelve years ago.

---

MadBrain - Wed May 09, 2012 9:57 pm

---

Dunno... personally I like folders on the root drive and I think stuff like /My Documents/Download is retarded. Sure it "works right now", but the second you copy it to a second drive, or mount the original drive on a second computer, all of your fancy paths break, whereas if you just used paths relative to 1 root folder, it would still work. That's also why I hate installers (break on drive copy) and I like straight EXE files in ZIPs (still works like it should). Windows registry also disappears on drive copy so I'm not sold on that one either.

---

Marcus-21 - Wed May 09, 2012 10:29 pm

---

This is a subject I feel strongly about, too. I, for one, prefer to be able to specify where I want things to be put, and have a system for determining where I install different types of files. I therefore much prefer to be allowed to change any default location to one of my choosing.

I do NOT want presets, samples, etc., installed to my C: drive - ANYWHERE on my C: drive. I reserve the C: drive for the operating system essential files. Apps go on a different drive, data on another one. Most programs I buy allow me to do this, either through options in the install routine. Those that do not, and install a bunch of crap to my C: drive with no option for an alternate location, get uninstalled and I don't purchase software from that company.

Fortunately, most enlightened companies and software authors are realizing that different people have different needs, and allow for alternatives. A few are even providing an alternative 'portable install' that you can unzip and move to wherever you want, which is pretty much ideal, in my opinion.

---

koalaboy - Thu May 10, 2012 12:20 am

---

So forty years ago, you couldn't easily move your applications and personal data onto a different disk ?
Twelve years ago, you were forced (by a standard) to use a hidden 'ProgramData' directory ?

Strange, I don't remember that. I remember being able to put my data wherever I liked on most mainframes, and certainly on Unix/Linux machines. I seem to remember back in 1989, having plenty of choice where things went on a PC, running DOS, and then Windows. It would even let me write to 'Program Files' without complaining about security.

It *is* a recent mass-market effect that things are being locked-down more, and constrained to 'save users from themselves'. It's understandable that most users these days don't really have a clue how computers work, but that doesn't mean those of us who do should be forced into the same black hole.

Linux is obviously an option (although the most recent versions are going down the same stupid path) except for the fact that you're then faced with software not running on it. Again, choice.

See, this is the point - we want choice. If we can make that choice, everyone is happy (okay, not the big companies, as they can't control us) and you can still stick to your stupid 'standards' whilst the rest of us can use our computers how we want.

---

whyterabbyt - Thu May 10, 2012 1:08 am

---

How does an idea which noone has posited except you, as a strawman, prove anything?

---

Marcus-21 - Thu May 10, 2012 10:07 am

---

Exactly! Choice is what is essential. I have no real problem with installers defaulting to certain locations, as long as I can change it if I need to. I can even live with a company like Cakewalk, that installs things to a specific location, but provides information on how to hack the registry to change that default location if you need to do so.

What I object to is, for example, a program that installs 20 GB of clipart to my C: drive without giving me the option to put it somewhere else, or that dribble a few hundred files each to 8 different locations that are all hard-coded in the software itself and not changeable.

There are shareware/freeware/open-source installers available which offer all the options that users want, for a reasonable price - why some developers insist on writing their own, poorly written install routines is baffling to me. (I do some testing/beta-testing of shareware and freeware, and this is a long-standing pet peeve - sorry if I got carried away)

---

aciddose - Thu May 10, 2012 5:36 pm

---

no. twelve years ago you could move this directory to anywhere you want by applying two minutes of research effort using a tool like google search.

not sure about at&t unix but i'd be comfortable to assume it's likely that you could have changed it, even if it required a recompile.

---

matt42 - Fri May 11, 2012 1:58 pm

---

Deleted

---

aciddose - Fri May 11, 2012 2:04 pm

---

i should have also mentioned it doesn't have to be hidden. that's a filesystem flag that you can change as you wish. there are other flags too, rarely used these days but still useful. for example the archive flag used to flag whether or not to track a file in backups.

show hidden directories, click on the directory, uncheck hidden, hide hidden directories, problem solved.

the feature in unix uses a period at the beginning of the name. so if you want to hide mydirectory, you just change the name to .mydirectory.

if you want it to show up you specify that in the browser or when you use ls or whatever. that eliminates the need for using a flag for such a common function. ms-dos and it's crappy implementation was limited to 8.3 filenames and this legacy like many others has continued all the way up to windows 8.

the purpose of hidden directories is not to make them secret. no, that's moronic.

the purpose is to solve the issue of when you have a lot of extra directories or files that you couldn't care less to see over and over again. for example you could go into your vst plugins folder and mark hidden all files that aren't dlls themselves. not a very practical application but one that would make sense assuming the list of vst dll files was useful in some way.

or in my case, applications install all this useless shit into mydocuments instead of using the proper application data directory. i don't want to see that stuff, it's useless to me and why the hell did they think it had anything to do with user documents? they're clearly bat-shit insane. so i can mark those folders as hidden and continue without being bothered by their idiocy.

---

Galbanum - Sun Jul 15, 2012 2:38 pm

---

So it seems there is some potential issue even with this plan...



It seems not all users can write to this folder. Even an account with Admin rights, can not always write to this location if UAC is on? And yet the same account can do this successfully if "run as admin" is used... even though the user already has admin rights. WTF?

/program files/ of course is no-no also.

So where should preference files and similar things be kept so that users are NOT blocked to write to them as needed?

C:\Users\User\AppData\Roaming\Company\Product\potOfGold

??

What is the point of \programdata\ if it can not be written to?

This stuff is headache inducing, and by far the largest cause of support issues for us... At least 10:1, prob more like 100:1, as compared to any actual product support issues...

---

arachnaut - Sun Jul 15, 2012 3:03 pm

---

Windows File System Namespace Usage Guidelines:

http://www.microsoft.com/en-us/download/details.aspx?id=22322

---

mystran - Sun Jul 15, 2012 3:29 pm

---

%appdata% yes, don't hardcode though, use CSIDL_APPDATA (with SHGetFolderPath or similar).

---

Galbanum - Sun Jul 15, 2012 3:31 pm

---

Thanks. This seems to be the most thorough info of the subject I have read thus far...

however, even this seems to give conflicting information.



and



...so if \programdata\ is meant to store data for ALL users, why can't a host app write to it when the current user using the host app even has admin rights??

---

Galbanum - Sun Jul 15, 2012 3:39 pm

---

Thanks. We will look into it.

---

arachnaut - Sun Jul 15, 2012 3:57 pm

---

There is a difference between having the rights and using them. When the application runs as a user that has administrative rights, it can inherit those rights and use them. But a user can't write into adminitrative folders without 'becoming' the administrator.

Actually, I know very little about these details, I came from a Unix programming background and I've pretty much forgotten everything.

The application should, I believe, create the AppData folders with the owner permissions of the user, not the administrator.

But, as I said, I'm not a Windows programmer.

---

Jace-BeOS - Sun Jul 15, 2012 4:09 pm

---

My current thoughts: the whole system sucks in terms of organization and complexity. File system layout, registry, program access, system feature access, etc. It's a pile of bad ideas, based on shallow-copying of other products, then changed in order to be arbitrarily different and unique to its own culture (that of verbosity and "correct but useless information" and to be able to say "we didn't copy anyone, we innovated"), then changed several times again to try to barely fit the ages-old standards that have survived the test of time (though also convoluted themselves; the unix culture isn't my ideal either but it functions when a good GUI is laid on top, like Mac OS X, though I felt classic Mac OS was ideal in layout and simplicity of management).

but you're not looking for my opinion.

---

arachnaut - Sun Jul 15, 2012 5:21 pm

---

You have to love the way Mac OS X makes gcc generate a.out as a package. That's real innovation.

---

There are 41 posts in this topic.