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!

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.

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)

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.

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

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.

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 ?

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'

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!

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.

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

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.

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?

That sounds fine.

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

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