current thoughts on install paths on Windows.
- KVRAF
- 2621 posts since 12 Sep, 2008
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!
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!
- KVRAF
- 8511 posts since 12 Feb, 2006 from Helsinki, Finland
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 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.
- KVRAF
- 2674 posts since 18 Mar, 2006 from The Void
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)
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)
- Beware the Quoth
- 35520 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
What he said.koalaboy wrote: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)
Seriously, dont be one of 'those' developers who go in the 'stupid installer and the buggers need to be junction-filed' list.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
-
- KVRian
- 852 posts since 28 Oct, 2004
+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"
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"
- KVRAF
- 12615 posts since 7 Dec, 2004
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.
nothing about this is broken except for the way people due to ignorance incorrectly use a well defined, functional system.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- KVRAF
- 2674 posts since 18 Mar, 2006 from The Void
I'm sorry, but that's plain wrong.aciddose wrote: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.
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 ?
- Beware the Quoth
- 35520 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
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'
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
- KVRAF
- 3846 posts since 15 Mar, 2002 from Underworld
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!
Cheers!
It is no measure of health to be well adjusted to a profoundly sick society. - Jiddu Krishnamurti
- Beware the Quoth
- 35520 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
Agreed. And to inject some reality :DuX wrote: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 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.
Cheers!
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.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
- KVRAF
- 12615 posts since 7 Dec, 2004
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 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".
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 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.
If a developer doesnt want to give us the choice of saving our creative content somewhere
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".
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- KVRAF
- 12615 posts since 7 Dec, 2004
why? there is no limit to the amount of data stored in data directories.DuX wrote:IMO it's alright to store some data in "users" folders, but it shouldn't amount to more than a megabyte.
actually that standard already exists, it's the "users" folders.DuX wrote:Samples and presets location should be customisable. ... 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.
most software does not implement the standards correctly.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- KVRAF
- Topic Starter
- 2621 posts since 12 Sep, 2008
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?

...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?
- Beware the Quoth
- 35520 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
read what I said about SSDs again, and think a little bit.aciddose wrote: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.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
