Where Should I Write Program Data Instead of Program Files?

When I'm working to resolve compatibility issues, there are always multiple options to mitigate. The solution we prefer to use is to update the code.

A common application code update is this: "my application used to write files to program files. It felt like as good a place to put it as any other. It had my application's name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?"

The answer, as it turns out, is: it depends.

Let's look at the options, and when you might want to choose each.

First, you'll want to use the SHGetKnownFolderPath API function to pull the function if you are using native code. If you are using managed code, System.Environment.GetFolderPath will do the trick for you.

FOLDERID_ProgramData / System.Environment.SpecialFolder.CommonApplicationData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You'll want to create your directory and set the ACLs you need at install time.

FOLDERID_Public / FOLDERID_PublicDocuments / System.Environment.GetEnvironmentVariable("public")
The user would want to browse here in Explorer and double click to open the file. The default location is %public%, which has explicit links throughout Explorer, on an installation of Windows Vista. You'll want to create your directory and set the ACLs you need at install time.

FOLDERID_RoamingAppData / System.Environment.SpecialFolder.ApplicationData
The user would never want to browse here in Explorer, and settings changed here should roam with the user. The default location is %appdata%, which is a hidden folder, on an installation of Windows Vista.

FOLDERID_LocalAppData / System.Environment.SpecialFolder.LocalApplicationData
The user would never want to browse here in Explorer, and settings changed here should stay local to the computer. The default location is %localappdata%, which is a hidden folder, on an installation of Windows Vista.

FOLDERID_Documents / System.Environment.SpecialFolder.MyDocuments
The user would want to browse here in Explorer and double click to open the file. The default location is %userprofile%documents, which has explicit links throughout Explorer, on an installation of Windows Vista.

Now, you'll note that FOLDERID_Public is kind of the oddball here. System.Environment.GetFolderPath just calls SHGetFolderPath, which takes CSIDLs. There is no analogue for %public% here. However, we could have gone after CSIDL_COMMON_DOCUMENTS (FOLDERID_PublicDocuments) and dropped things there, but even though we just need to pass 0x2e (46) as the int argument, we don't offer that. Because we have this subset going, I'd probably start thinking about using p/invoke if I needed to support public documents (http://www.pinvoke.net/default.aspx/shell32.SHGetKnownFolderPath).

If you're using Visual Basic, you can also use My.Computer.FileSystem.SpecialDirectories, but it also doesn't seem to get any public documents love...

Comments (27)

  1. Did you see the post at blogs.msdn.com

  2. Angry Ted says:

    "…I’d probably start thinking about using p/invoke if I needed to support public documents…"

    Dear Microsoft .NET Framework Developers: Thanks so much for once again omitting something useful from the .NET framework. I take a great deal of pleasure in wasting part of the day researching my way around the potholes in your framework.

    P/Invoke this.

  3. Ganesh says:

    Angry Ted:

    Try this

    IDictionary iDict =


    Enumerate & get the needed physical location

  4. Daniel says:

    This whole situation is really annoying.

    Yes, of course, data — especially read/write data — don’t belong in the programs directory and should be installed elsewhere … but there isn’t any suitable place.

    It’s blindingly obvious that there will be apps that require a single set of data files to be usable by multiple users, and that there should therefore be ‘standard’ location for those shared data to be installed.

    On the face of it the CSIDL_COMMON_APPDATA directory looks tailor-made for this use, but as it’s hidden by default it’s not ideal. In Vista the %public% directory is a strong contender … but it’s not available in XP so application developers whose users are still using XP or even 2k (and that’s most of us) aren’t going to touch it.

    My advice would be to use the CSIDL_COMMON_APPDATA directory … and to un-hide it if users are going to need to browse to it.

  5. cjacks says:

    Hi Daniel,

    For XP and Vista compat, why not use CSIDL_COMMON_DOCUMENTS for documents you want the user to browse using Explorer? The idea is to have a hidden place for data and an explosed place for documents.



  6. Andrew says:

    Please STOP putting application folders into the <User>/Document folder!

    that should only EVER have things the user has put into it.

    do you think i want to see "SQL Server Management Studio express" or "BlueTooth Exchange Folder" or ANY of that crap? not a chance.

    Work it out people.

  7. Lex says:

    Had an interesting situation the other day. I was using FolderShare and decided to share a utilities folder I have on my work PC so that I don’t need to continually maintain it between the various machines I use.

    Now at work I use XP/2003 but at home I have a Vista Laptop and PC; so you can probably guess what happened. Foldershare happily shared the folder on the 5.x Windows but barfed on trying to create a program files folder in Program Files; even when creating that folder manually for it – since the main point of this excercise was to make it easy to get a new machine up to speed and in sync I didn’t want to fiddle too much – but then the dilemma of having actual program files that couldn’t exist in program files. In the end I went with App Data under Users<user> but it still felt a little unclean.

  8. cjacks says:

    Hi Lex,

    That’s not an issue where 5.x works and 5.0 doesn’t. Rather, your 5.x is clearly running as admin, where we limit when you run as admin on Windows Vista. Run XP as a standard user, and it won’t work there either.

    I actually keep utilities that I use in users<me>DocumentsProgram Files. users<me>appdata is hidden by default, and I like to get to them in Explorer. (I don’t take the time to create shortcuts.)



  9. Ganesh says:


    Its strange that SUA catches file writes to

    ProgramData location?

    ‘You’ll want to create your directory and set the ACLs you need at install time’ <-Can you elaborate on this perhaps this is where I went wrong.


  10. cjacks says:

    Hi Ganesh,

    Not strange at all. ProgramData is per-machine, so it’s shared. The first standard user to create a file will be OK because of the CREATOR OWNER ACE, but the second won’t be as lucky – it’s an app bug that we can only fix for the single user scenario without some action on the part of the developer / installer.

    At install time, you are running elevated, so you can modify ACLs within ProgramData to grant whatever permissions you need (and no more if you are following LUA principles).



  11. cquirke says:

    Andrew said "Please STOP putting application folders into the <User>/Document folder!" and I agree, though for slightly different reasons.

    I want the "documents" location to be safe to backup, full-share, and restore after a melt-down of unknown cause.  To me, that means keeping incoming material and infectable code out of that location.

    However low the user account rights, they will always allow writes to the user’s data location – suggesting that any code files in this location could be infected by generic code infecting viruses.  Then if the system is "just" wiped and rebuilt, the virus gets restored with the backed-up "data".

    PS: I’d love to "shim" The Sims 2 so that it doesn’t dump its 500M of game state into what would otherwise be an easy-backup 20M data set   :-/

  12. Don says:

    After quite some time figuring out how to get VB.Net 2005 and a Setup Project to be able to install an SQL Express .mdf/.ldf file to C:ProgramData, use an Installer class in the application to set the ACL for the directory, modify the install to use the custom action and then change install to set the NoImpersonate bit, I am now stuck on this very topic. How can I get the Setup Project to know about the folder "C:ProgramData" (I have hard coded it for now)?  The special folder list does not have a reference that will resolve to ProgramData. In the VB.NET code I can reference CSIDL_COMMON_APPDATA, my problem is with the install package.

  13. dcrn says:

    Thank you very much Chris.  I changed the DefaultLocation to [CommonAppDataFolder] for the Custom Folder I made in the setup project and it worked.  That was the last of the hurdles for me on this project.  I am happier than a tornado in a trailer park right now.  Thanks again.

  14. Chris Long says:

    Hi Chris,

    Not that you care what I as another developer think, but I am starting to go crazy with all the 5,000 rules on Vista that don’t make any sense and just seem to serve to cause me as a developer major headaches…I’m sorry, but this is the major problem with Vista.  It’s a pain in the butt for developers.  And it’s a pain in the butt for users.

    I found this topic because I was baffled as to why, when I FOLLOWED MS advice of using common app data to store my data, why in the world user A could read/write, but user B could only read.  The whole flippin’ point of a common data file is for everyone to share the data!  I can see no clear way to solve this except to have my setup program create the folder and modify the ACL, which is ludicrous!

    Unless I want to create a folder directly in C: like

    C:MyFolder, just like in the old DOS/Win3.1 days, which for some STRANGE reason seems to ALLOW full R/W access for everyone.  So basically, if I ignore MS and go backwards, I am fine.  But to do things the right "proper" way I am forced to do all these quirky things that are a pain the butt.  It makes no sense.

    Vista was a nice attempt and it moved in the right direction, but it was about 3 years away from when it should have been released.  It feels sometimes like there’s 500 new "ideas" in it that just were never really thought through fully.  

    This is about the 1000th example I’ve dealt with as a developer alone!  (I can list many more if you’d like – such as my personal pet-peave as to why in the world if App Data is the new recommended data place because no data should be in prog files – why in the world is this folder still hidden by default so users can’t even find this application data???  crazy….)

    And people wonder why developers are resorting to putting data in my documents…it’s because MS hasn’t given any good answer to this problem yet and their "recommended practices" have lots of problems with them!

    Sorry for the rant…..just fed up with all this nonsense!

  15. cjacks says:

    Hi Chris,

    None of these things are the new places to put things – they’ve all been around for a while. It’s just that, before, people kind of depended on users being an admin all the time, so they could put things in program files and have it just work. Once you have standard users, that doesn’t work out so well. With Windows Vista, there are just a lot more people with standard-user-like privileges.

    You can simplify the rules somewhat. I think of it like this. A standard user can hork their data, and hork their session. But they can’t hork other users. So, any time you’re exiting a boundary where you can possibly impact other users, that’s crossing the line.

    Now, crossing the line is OK, it just should be done explicitly. If you want to share data, you just have to do so intentionally. That means configuring the security descriptors on the files or directories which will be shared, which is an admin-level activity and should be done at install time.

    As for hiding it, well, that’s absolutely on purpose. ProgramData is a place for you to store data that only the program is interested in, not the user. If you want the user to see it, then %public% is the place to put it. Same thing goes for per-user data. You can stick it in the user’s documents, or the user’s appdata – the difference being whether the user would ever have an interest in stubling upon it. Most users have little interest in poking around ini files and such, so why clutter up their documents directory with things they’ll never ever have a desire to double click?

    There aren’t many "ideas" that weren’t thought through, but I admit that the "curse of knowledge" is present in great abundance. We have technology that, given a couple hours to describe, most everyone I talk to thinks is a fantastic idea. But it was so opaque that without that personal touch, it was utterly incomprehensible. So, great technology, lackluster implementation. We certainly have the opportunity to clear that up. But the rules, overall, are reasonably consistent, though we sometimes have to bend those rules for the sake of app compat.

    But rant away – get the annoyance off your chest and we can figure out how to do it better. I wrote this post specifically because I think it’s too hard to find guidance on where to put stuff, even though internally we’ve had these locations set up for several verisons of Windows now. Clearly, if you think it’s new after stumbling upon this, you’ve validated my point. That’s why I’m still writing!



  16. kyle77 says:

    I’ve created an .msi installer that establishes an application data folder in [CommonAppDataFolder] and several sub-folders and files within it.  As mentioned above, less privileged users do not have write / modify permissions to those shared files.  

    How can I grant those permissions as a part of the installer?  I’m using a Visual Studio 2008 Setup & Deployment project.  Basically I want everything in the application shared folder to be modifiable by all users.

    I agree with both of you, Chris L. and Chris J..  I understand the reasoning behind locking this down, but at the same time it does make it awful inconvenient.  Since it is such a frequent scenario that an application developer would want to install shared data available to all users, it seems like this option should be more easily supported, or at a minimum documented in more detail.  I’ve been looking all over the place and have yet to find a definitive, or even reasonable, answer to how this is to be accomplished.  Instead I’ve just read posts from a bunch of frustrated developers either giving up or compromising.

    Hopefully someone can give a detailed answer as to how this is to be accomplished as part of an .msi installation.  Someone mentioned something about a LockPermissions table, someone else mentioned using custom actions, and someone else mentioned using the acls tool — but nowhere has anyone gone into any detail or actually demonstrated how this should be done.  Can anyone elaborate on this please?



  17. Chris Long says:

    Hi again Chris,

    Thanks for the response.  🙂  As you could tell, I was frustrated about all this stuff.  For the record, I DO know what MS’s recommended practices have been for several years, long before Vista.  I was referring to them being new for ME because as you noted, prior to Vista, a person (like ME) could still stick everything in Program Files (and I did, too!) 🙂  I followed Vista through the entire beta process and read all of MS’s recommended practices/compatibility docs relating to Vista, etc.

    Honestly Chris, the whole situation just really bothers me.  I mean we’ve now got everything so delineated that the program EXE/read-only program files are in Program Files, program data such as INI’s, etc. that need write access are in app data, UNLESS they need to be shared in which case they’re in common app data (which doesn’t even WORK by default and requires special security changes at install time for one’s program which many don’t know how to do), user data that the user needs to see in my documents, common data for all users in common documents (public), etc.

    And I DO understand the rationale.  I DO understand what you’re saying about hiding ProgramData/user AppData folders (though I don’t agree – see below).

    But what’s happened Chris, is that because of all this stuff, there are MANY developers that don’t really understand all of this.  It took me a while and it still drives me nuts.  Thus you have developers putting program data in my documents, etc.

    And honestly, Chris, these rules that MS has established have caused some of this stuff.  For instance, you stated why ProgramData/AppData are hidden: you think it is because users shouldn’t need to bother with INI’s/program data, etc.  But there are many developers who WANT their users to be able to see these things for any number of reasons.  There is no 1 size box here.  But because MS has forced the folder as hidden, developers end up instead putting things in My Documents that really shouldn’t be there, etc. Before AppData/ProgramData, ALL OF THIS was written in Program Files.  The user saw them there and I don’t recall hearing anyone ever complain about that!  But by hiding these folders, it just serves to create even MORE confusion, both for users (not all of them are dumb – many want to SEE everything!) and for developers.

    Another example: I know of a Setup program (not MSI – a 3rd party installer) that puts programs specified to work for non-admins (i.e. Standard / Limited users) IN the user’s App Data folder instead of Program Files.  The reason this was done was because the developer was sick of getting complaints from developers that their programs weren’t working for limited / standard users.  It was easier to just install the whole program in App Data (bypassing Program Files) rather then splitting things up.  And, sadly, I do understand that point of view.

    This is all way too complicated (for everyone!)

    I have taken the liberty, since you mentioned about figuring out how to do this better, of coming up with what I believe is a very reasonable plan of action/solution to ALL of this.  I will post it below.  At the very least, perhaps it will stimulate something or some thought…

    I encourage you/anyone to give it full consideration…you might be surprised.  🙂

    Chris Long

  18. Chris Long says:

    Chris Long’s Application Folders Plan for Windows


    I estimate this to be worth about $10 Billion to Microsoft.  Please send me a check (I’ll be waiting.)

    Here we go:

    First their are 4 folders:

    "C:Users<username>My Documents"  – all user documents can be here, but they are put there by USER’s, *NOT* programs for program data – program’s won’t need to put anything here anymore because of the changes below!

    "C:UsersAll User’sPublic Documents" – again, all shared documents can be here (R/W for everyone) if user’s CHOOSE to put things here

    "C:Users<username>Program FilesProgramA"  – The Program Files is NOT HIDDEN!

    ProgramA is installed per-user and goes here.  The program itself (EXE, etc.) AND Program Data can be here.  A recommended situation could be: Documents subdir, ProgramData subdir, but programs can do whatever they want here.  It’s all R/W by the user and the program is COMPLETELY isolated from other users!

    "C:UsersAll User’sProgram FilesProgramB" – Again, the Program Files is NOT HIDDEN!

    ProgramB is installed for all users and goes here.  Again, the program itself (EXE, etc.), Program Data, OR documents can be here.  Now, how to solve whether it is R/W, Read only, read/write only for first user?

    Here’s my solution, which requires several steps to be in place:

    1) There should first be a very simple API call with no complexities established that simply makes a folder available for all users, only current user, or read for all users and writes to be redirected to user Program Files (see #4 below).  I’m talking a simple API function that accepts 1 parameter, either a 1,2,3 corresponding to these 3 options.  This allows 3rd party setups/utilities to easily do what MSI will do in #2 to ensure full compliance with everyone.

    2) MSI installs would have a simple dropdown-type option for programs made for all users, to make the program’s folder be either read-only for all users, read-write for all users, or read for all users and writes redirected to their user Program Files (see #4 below – this will be the default)

    3) By default Windows would make everything going under the common Program Files folder be read only and any writes would get redirected to the user Program Files. (again, see #4 below)

    4) Now here’s the beautiful part:  

    So assuming the example program above, ProgramB, which has its subfolder as:

    C:UsersAll User’sProgram FilesProgramB

    if when installed, it kept the default of making it read-only, but writes redirected, then when UserA runs the program and say an INI is written, it will get written to:

    C:UsersUserAProgram FilesProgramB

    When UserB runs the program, it will get written to:

    C:UsersUserBProgram FilesProgramB

    and so on.

    Now, the PROGRAM would only still have to READ from:

    C:UsersAll User’sProgram FilesProgramB

    Why?  Because Windows will automatically REFLECT the data from the user folder of the same name, MUCH like it currently does with the Virtual Store folder for non-Vista-ready apps.  If the INI in C:UsersUserAProgram FilesProgramB, is newer then the INI of the same name in C:UsersAll User’sProgram FilesProgramB, then Windows will return the user INI to the program, otherwise it will return the common INI to the program.  

    All of this is of course transparent to the user AND the program.  Users are happy.  Developers are happy.  MS is happy because they don’t have to keep hearing gripes from people like me.

    With this plan, All user data is still 100% isolated from other users UNLESS the developer explicitly made the common program folder r/w for everyone during Setup!  But now, everything is a lot simpler and much better organized!  It makes much more sense for user program files/data to be in one place under their user name and for all common program files/data to be in one place under the all user’s name, with the ability for the common to also get reflected write data from the user folder.  Developers won’t have to deal with 15 different folders to put things, but just a few simple options, and users will always know and be able to see their programs!

    Note this plan also will cause less UAC-related issues!

    I just spent about 30 minutes on the above plan.  Microsoft has had years and years.  I think my 30 minute plan is better than Microsoft’s years-in-the-making plan.  But at the very least, I don’t think I did any worse.  Please let me know when I should be expecting my check. 😉

    Chris Long

    P.S. – Also another note regarding the current situation of AppData/ProgramData hidden.  I wanted to give you a personal example so you can understand the problem with this.  I’ve got a program that keeps different "projects" that the user creates.  Even though they are worked with in the program, the user also needs to be able to see the project files.  If I put the Projects folder in App Data, half-of-my-users won’t know where they are and I’ll have to explain in help about unhiding the folder, etc.  If I put it in My Documents, then I as a developer have just put data the user doesn’t want in My Documents in that folder!  People like their My Documents for their documents, not program-related documents!  So what does that leave me?  Currently I have them in Program Files, which forces my app to require admin so the user can work with them!  Note: My plan as specified above SOLVES this, and the millions of similar issues faced by many developers! Everyone wins! 🙂

  19. Chris Long says:

    Sorry, I posted my plan without proofreading (oops.)  Ignore the stuff about documents being in

    C:Users<username>Program FilesProgramA

    No user documents should be here (though they COULD under this plan – that’s up to the user – just like it is now for appdata)

  20. cjacks says:

    Hi Chris L.,

    Let me throw some requirements at your "solution" and perhaps you’ll start to see that we do have incredibly smart people agonizing over these decisions. 🙂

    – Avoid mixing executable files and program data. There is a vastly different security implication of modifying files in each. If I can modify an executable file, I can trick another user into running malicious code. That violates a rule. If I can modify a shared data file, I have to depend on a vulnerability in the appliation to run malicious code, and figure out how to craft the malicious input. The latter is harder to do.

    – Simplify finding things for the user by surfacing things they need to find. Every time they have to sort through hundreds of DLLs and INIs to find a single DOC, they get frustrted.

    – Avoid redirection as much as possible, as multiple copies not managed by the application itself create a management problem for the IT Pro in an Enterprise. Certainly don’t depend on it as part of the target development platform.

    – Accomodate the maximum possible amount of existing software. Much of this has hard coded paths.

    In your example, with the projects: would the user ever want to double click on this? If so, drop it in their Documents. I’m not sure why you wouldn’t want to put it there. Every document is a program-related document. Do you just not think your program is as important as other document-rendering programs, like Word? Just create your own directory there so you aren’t mixing in with the root of the documents and store away. You’re program is as good as any other one.

    And, as with any other guidance, we’d then have to disseminate this guidance. You, of course, know the rules, so of course it’s easy for you. But the problem with the current guidance is that so many people don’t get it, and consequently don’t do it. You’d have the same challenge.

    I’d assert that we’d be better off fixing the problem of how to share and drive implementation of the guidance than changing the rules around arbitrarily… 🙂


  21. Bz says:

    So has anyone been able to find an answer to Kyles question regarding the best way to set RW permissions on the CommonAppFolder sub directory for your app during installation.

  22. cjacks says:

    Bz – I’m going to address that in a separate posting – I’ve just been a bit swamped…

  23. Bz says:

    Great news, Good luck and may the patience be with you.

    Also seems as though the problems dont end there.

    Some Globalisation issues to boot(see below).


  24. Chris Long says:

    Hi Chris J,

    With all due respect (and I DO mean that – I’m not being condescending!), this type of thinking is EXACTLY the problem.  The problem is not one of developer education, the problem is the implementation is confusing, complicated, and non-sensical!

    If I apply your "requirements" to my plan, then OF COURSE it won’t pass muster.  I (and I would suspect many others) however, take issue with these "requirements"….I would seriously suggest that these "requirements" be re-thought – quite honestly, you all need to start thinking outside of the box you have forced yourselves to think in!

    – "Avoid mixing executable files and program data"

    WHY?  You say there’s security issues.  I certainly can’t see any.  What’s in the user’s domain is in the user’s domain and what’s in the system domain is in the system domain.  A user can mess up their application and/or data, but not other users with my plan – there is no boundary crossing unless explicitly declared.  Who cares if the exe’s and data themselves are in the same folder (or more likely, subfolders under the main program folder)?  In my plan, the entire program is entirely in the user’s domain and thus CAN’T be modified by other users; the exception is if the program is installed for all user’s but even there the program data could only be modified PER-USER (because of the redirection).

    – "Simplify finding things for the user by surfacing things they need to find. Every time they have to sort through hundreds of DLLs and INIs to find a single DOC, they get frustrted."

    With my plan, there won’t be any DOC files here unless they are a part of the program.  All user documents will be in the user’s documents folder.  Further, it is a very RARE program (I don’t believe I’ve ever seen one!) that has hundreds of DLL’s, INI’s, etc. all in the same folder with a file that the user might want to read/access.  For years, programs were done with everything in Program Files….I don’t believe there was a big outcry of people who couldn’t find a file…..this is a "made up" requirement that has no bearing on reality!

    – "Avoid redirection as much as possible"

    In general, I believe this to be a good goal, but NOT in this context.  There’s very little management problem with the plan as I specified it and is much easier to manage for IT people then the current situation!!  With the current situation, the user data is under app data and may or may not be under the same "foldername" as the program.  With my plan, the entire program and  user data for program A, exists under the user’s C:Users<username>Program FilesProgram A, UNLESS it is installed for all users, in which case the user data will still be under "C:Users<username>Program FilesProgram A", and the program will be under "C:UsersAll User’sProgram FilesProgram A".  This is EASIER from a management perspective because you will always know where things are, as opposed to the current situation.

    – "Accomodate the maximum possible amount of existing software. Much of this has hard coded paths."

    Really?  Although this used to be true, I doubt this is very true any more, at least not with any programs that actually matter (i.e. non-hobbyist programs).  Yes, back in the 90’s this was common practice, but honestly I can’t imagine too many people are still hardcoding "C:Program Files", "C:Documents and Settings", etc….And if they are, quite honestly, they have ignored MS’s recommended advice and commonly accepted practices for the last 10 years!  MS has forced people (i.e. developers) to make lots of changes for Vista to get programs working right on Vista, so I don’t buy this argument that somehow MS is concerned about supporting programs with the hardcoded paths.  MS doesn’t apply this logic anywhere else and it shouldn’t be applied here.  Certainly, I don’t think one should limit their thinking about rational folder/file structure simply because there might be a few old programs that have ignored common practice for 10 years…And for the few programs that do do this, those programs (even large ones) can be changed in literally minutes to use an environment string instead of the hardcoded part.

    > "In your example, with the projects: would the user ever want to double click on this? If so, drop it in their Documents"

    Most users (and I’ve read the many gripes on this over the years and feel the same way) want their documents folder to be for their personal documents (pictures, videos, doc’s, etc.)  Many take great offense at programs dumping MB’s (or GB’s) of program documents in their personal folder even if they’re something they might want to click on.  Just read further up this blog for a few people that griped about this with the Sims 2!  With that said, I concede that I COULD have done this/could do it.

    > "And, as with any other guidance, we’d then have to disseminate this guidance. You, of course, know the rules, so of course it’s easy for you. But the problem with the current guidance is that so many people don’t get it, and consequently don’t do it. You’d have the same challenge."

    No, actually, I don’t think I’d have the same challenge at all.  You all are trying to explain something that fundamentally is flawed/illogical/contains many variables, which is WHY it has been several years and still people don’t know what to do!  I think it would be VERY easy to get my type of plan’s guidance out because there’s only a few folders and few simple rules.  It would be much easier than trying to explain (which is how this page started by you!) the current situation where things are all over the place, there are no concrete rules because everything "depends on the situation", you can’t do things that would seem logical (sharing common program data) without resorting to modifying the ACL via the program’s installer, etc.

    The type of changes outlined by my plan ARE much easier IMHO than all the folder/file changes made for Vista and so I don’t think there will be much problem at all getting this adopted.  Plus, applications would still would function WITHOUT needing to really know all this since they are using the environment strings/API to get appdata, common appdata, etc.

    I will concede that there would need to be some education relating to "there’s no more C:Program Files", etc. – but this could done.  In fact, the next OS could even use a shortcut (or maybe a junction) to point to the user’s Program files, etc.

    > "I’d assert that we’d be better off fixing the problem of how to share and drive implementation of the guidance than changing the rules around arbitrarily… :-)"

    I’d assert, again with all due respect, that MS would be much better off trying to think outside of their self-made box and looking at all of this stuff with "fresh eyes".  My plan may not be the best (I don’t know), but I do know that what’s needed is a serious change from the way it currently is and a willingness by those at MS to think outside of their long accepted "logic"/"requirements".  I have no doubt that you have some very smart people looking at all this (much smarter than me I’m sure), but sometimes people can be too smart for their own good…

    Anyway, we may just end up having to agree to disagree.  I think I’ve probably said all I could say, so I won’t keep this going back-and-forth (we could probably do it forever! 😉 )  I do thank you for your time and willingness to think about/look at these issues, and also to help others via this blog with your insights into the way it currently is, etc.  Thank you Chris! 🙂

    Chris Long

Skip to main content