[chief1983]

FSO should use its directory as the location for things specific to FSO and be made constant to do so across the platforms.

Yeah, that's just not really right.  Even on Windows now, apps are not supposed to write data to their install folder.  For a program to be usable without elevated privileges, all file i/o should be done within %APPDATA%.  All configs, logs, and profiles need to be moved to the user's folder basically.  Mod installation could be performed by wxLauncher and it would install them in the program's folder, requesting elevated privileges as needed.

[Tomo]

For those who haven't seen them yet, the Windows Vista/7 special folders are listed here:
http://msdn.microsoft.com/en-us/library/aa370813.aspx

They are well described and very easy to use*, and we actually only need bother with two of them anyway:

Screenshots should be going into "MyPicturesFolder"

"AppDataFolder" (%APPDATA%) is the place that user-specific, persistent data that isn't a "document" goes into (well, there's also the local one, but why not roam anyway?)
So that's clearly where we should be putting all cache files, pilots and config files. Possibly mods as well(!)

Debug Log files probably should go into My Documents - %APPDATA% is a hidden folder (C:\Users\%USERNAME\AppData\Roaming by default English install), so better to put them where they are more easily found.

Is this as currently done in OSX and Linux?

_{*SHGetFolderPath and SHGetKnownFolderPath are much easier than ITaskBarList1/2/3 - I crashed Explorer a few times with those... Don't delete icons early, Windows dies.}

[chief1983]

Or, leave the log files themselves harder to find, and let wxLauncher retrieve it for you

[KyadCK]

Or, leave the log files themselves harder to find, and let wxLauncher retrieve it for you

Or not until wx fully works on windows. wx cant do multi for whatever reason and we need logs. Relying fully on something that doesn't work completely yet is bad.

wxLauncher and FSO will have a portable mode.

Hell ya!

[Iss Mneur]

Has anyone actually read the guides from Microsoft for what to do for Application/User specific data and where/how to install things? This has been an FSO bugbear for me for a very long time. Now that FSO is starting to use STL strings all over the place and thus the pathlength issue is disappearing, why not start installing in Program Files and using the Microsoft guidance.

(burn the heresy! Games/Freespace2 4eva)

Hi, long time, no see.

Yes I have.  Notice that wxLauncher follows them correctly (to the best of my knowledge).

Because FreeSpace2 Open is available on more than just Windows. And the best compatibility is the "does what it is supposed to do on all supported platforms with a minimal of fuss".

No, the best compatibility is to do it as the platform standards dictate, so that we do things the same as everyone else.  That is, be consistent with everyone else.

At least, that is my take on it. I don't want to see a MS-ification of FSO. GOG not withstanding, I don't happen to believe that storaging in the registry or %appdata% is necessary at all. Point in fact, I find the idea abhorrent. FSO should use its directory as the location for things specific to FSO and be made constant to do so across the platforms. This is the easiest to accomplish objective.

Its not MS-ification.  These ideas are not new to MS, in fact MS is slowly reinventing how POSIX systems already work.  Also, even when FSO was new, writing to the applications own directory was frowned upon by MS.  Yes, this has been incorrect for over a decade and only recently has MS started to enforce their own policy, but even then they temper it by providing the compatibility features that they do.

This prevents it from being complicated or broken across revisions of OSes and introduces fewer support issues regarding what goes where. And as FSO only needs the assets from FS2 Retail, how or where that was installed initially does not matter in the slightest.

No, by following what MS says we will not get broken by new revisions of the OS.  Had FSO followed Microsoft's suggestions back in 2001 with respect of where to write data, we would not be having this discussion, it is only because Microsoft forced the issue with Vista that the error of how FSO deals with this stuff is being brought to light.  If you want to rant that Microsoft is always changing things, sure I agree and could probably add to your list of complaints about changes.

Yes, you are correct, because FSO only needs the assets from FS2 Retail  it really doesn't matter where FSO gets installed, however that is not what happens.  FSO gets installed to where FS2 is, for various reasons.

And yes, you can start playing both Retail and FSO in one directory location, change the directory location and continue playing. If we start investing in tighter integration to the OSes conventions, that will not remain the case.

True, which is why most applications that do follow the MS's recommendations will have a portable mode that resolves this particular issue.  wxLauncher and FSO will have a portable mode.

"AppDataFolder" (%APPDATA%) is the place that user-specific, persistent data that isn't a "document" goes into (well, there's also the local one, but why not roam anyway?)
So that's clearly where we should be putting all cache files, pilots and config files. Possibly mods as well(!)

The reason to not use the roam one is a matter of the size of data expected to be put in there and the value of that data (say its a cache file, or an index, something that can be regenerated on each computer and shouldn't be put on the profile server).  Admittedly the difference in practice is pretty minor for FSO because we are probably not used much on corporate computers where the difference is actually important.

Debug Log files probably should go into My Documents - %APPDATA% is a hidden folder (C:\Users\%USERNAME\AppData\Roaming by default English install), so better to put them where they are more easily found.

Well, it depends.  If wxLauncher provides a button to get the log dir then it doesn't really matter if it is hidden or not.

Is this as currently done in OSX and Linux?

It is.  On linux and OS X, everything that FSO writes is written to a dot directory in the users home directory, including things like the model cache, the various bits that are put in the registry on windows, etc.  Technically this is actually wrong on OS X (we are supposed to put most of these bits in the "Library" (iirc)) and on FreeDesktop compliant linux distros (we are supposed to use certain environment variables to pick where to put this stuff because some it if can get rather large).

[chief1983]

Or, leave the log files themselves harder to find, and let wxLauncher retrieve it for you

Or not until wx fully works on windows. wx cant do multi for whatever reason and we need logs. Relying fully on something that doesn't work completely yet is bad.

Doing otherwise is so dumb I assumed that was implied.

[jg18]

Is this as currently done in OSX and Linux?

It is.  On linux and OS X, everything that FSO writes is written to a dot directory in the users home directory, including things like the model cache, the various bits that are put in the registry on windows, etc.  Technically this is actually wrong on OS X (we are supposed to put most of these bits in the "Library" (iirc)) and on FreeDesktop compliant linux distros (we are supposed to use certain environment variables to pick where to put this stuff because some it if can get rather large).

On OS X, FSO uses a folder in ~/Library (namely ~/Library/FS2_Open) rather than a dot directory, so AFAIK it's doing things correctly on that platform. I don't know anything about FreeDesktop, though.

[Iss Mneur]

On OS X, FSO uses a folder in ~/Library (namely ~/Library/FS2_Open) rather than a dot directory, so AFAIK it's doing things correctly on that platform. I don't know anything about FreeDesktop, though.

Okay. I didn't have the source in front of me to check.

My point still stands however, we are actually doing things more correctly on non windows platforms than on windows.

[Echelon9]

On OS X, FSO uses a folder in ~/Library (namely ~/Library/FS2_Open) rather than a dot directory, so AFAIK it's doing things correctly on that platform. I don't know anything about FreeDesktop, though.

Actually, we are *almost* doing it correctly on OS X. We should really be using ~/Library/Application Support/FS2_Open and ~/Library/Caches/FS2_Open.
I have a reference to the Apple docs somewhere that support this.

[Nuke]

i really dont care, so long as us old skool types can put the thing wherever the **** we want and it will run. i never put anything important on c:\.

[Mongoose]

I understand that the accepted POSIX standard is to put program-generated files in %APPDATA% or the equivalent, but why is that the standard in the first place?  It's something that seems kind of counter-intuitive to me, other than the obvious user-folder portability advantage.  I mean, when I explicitly create a file like a Word document, obviously I'm going to put it wherever I choose (usually somewhere in my own user folder), but if you're talking about a config file or game save that's explicitly tied to a single program and (almost) never needs to be seen by the user, why wouldn't you put it in said program's own folder?  It certainly makes things easier to find instead of having to dig through nested hidden folders, for one.

I guess the real reason this bugs me is that, being an XP user, an irritating number of application developers have translated the "write to %APPDATA%" concept as "create another goddamn folder in My Documents."  I cannot describe how much this annoys me.  My Documents is where I keep my stuff, my personal files, and the last thing I want is a bunch of random ****ty programs plopping down folders in it and making it a cluttered mess.  Whatever you guys do to FSO in the future, please, for the love of God, never ever ever ever write anything into a folder labeled "Documents."

[The E]

On XP, %APPDATA% resolves to C:\Documents and Settings\username\Application Data by default. As for the "My Documents" thing, while it is irritating, it's also one of the few locations you can write to that is guaranteed to be unique for every user. On Vista and later, we have a "My saved games" meta folder for this purpose, but noone seems to be using it, a state of affairs I blame on people still using XP

[niffiwan]

... but if you're talking about a config file or game save that's explicitly tied to a single program and (almost) never needs to be seen by the user, why wouldn't you put it in said program's own folder?

Security & separation of privileges    A programs folder is meant for static, non changing data.  The location is writable only as an admin so that user accounts can't modify the program, i.e. when you get a drive-by trojan installed from your browser it can't insert a keystroke logger into your browser binary (it just installs it as a plugin instead  ) .  Because a normal user isn't allowed to update the programs folder, the data for the program needs to be written to somewhere else.  If there are multiple users of the computer, it also separate different users savegames.

At least, that's how I understand the rationale for doing this.

[chief1983]

Yeah, security is a big thing.  That and it allows it to play nicer with other platforms.  On OS X, all the things a program needs are put within a special folder with the .app extension, and a program is really really not supposed to write inside of itself.  All file writing should be done either in temp directories or somewhere in the user's folder.  Security is a big reason for that, and maintainability.  You can just replace the entire app folder with an upgrade, delete the app but have your preferences if you reinstall it later since they're not in the same place as the app, etc.  It's just nice to have the distributed data separate from the data the program creates after install.

[Nuke]

I understand that the accepted POSIX standard is to put program-generated files in %APPDATA% or the equivalent, but why is that the standard in the first place?  It's something that seems kind of counter-intuitive to me, other than the obvious user-folder portability advantage.  I mean, when I explicitly create a file like a Word document, obviously I'm going to put it wherever I choose (usually somewhere in my own user folder), but if you're talking about a config file or game save that's explicitly tied to a single program and (almost) never needs to be seen by the user, why wouldn't you put it in said program's own folder?  It certainly makes things easier to find instead of having to dig through nested hidden folders, for one.

I guess the real reason this bugs me is that, being an XP user, an irritating number of application developers have translated the "write to %APPDATA%" concept as "create another goddamn folder in My Documents."  I cannot describe how much this annoys me.  My Documents is where I keep my stuff, my personal files, and the last thing I want is a bunch of random ****ty programs plopping down folders in it and making it a cluttered mess.  Whatever you guys do to FSO in the future, please, for the love of God, never ever ever ever write anything into a folder labeled "Documents."

thats exactly why i never put anything of mine in my documents. im sure any user with admin privileges can set up a separate file area (like d:\stuff) to which they have full access from their standard user account. making software play nice from that is another matter, though i do keep certain programs there that can run from a single folder, so i dont have to install them every time i format c (freespace is one of them).

i dont bother with any of that though, i just run as admin. im sure you will get 50 people that will call me a moron for doing that. but i really dont care, if you do that and dont have the skills to fix it when it breaks, well then you are a moron. but i do and if the **** ever hits the fan (it never has), i could ghost the c drive with the backup image and if necessary restore a backup of the d drive. i just dont think its my os's buisness to dictate how i run my computer and will resist any attempt by any developer to enforce it.

[Iss Mneur]

Yeah, security is a big thing. 

This. (I know it is has been repeated several times, but fundamentally it comes back to security)

To bring this back to how this applies to windows.

Remember POSIX is a standard for a multi-user operating system from an era that most threats were local (ie. a user on the system trying to hack it). Windows, because it originally was a single user OS, went, "meh, this separation of application and data is overblown and costs performance, we only ever have one user so lets not implement it".

Admittedly, this "lets stay out of the users way" mentality and the extreme measures taken to provide compatibility with older software is a large part of Windows's dominance of the industry (never mind whatever less legal things MS did over the decades).

The disregard for security comes from DOS where there was no memory protection at all so even if they tried there was no point (that is, "the kernel" wasn't protected from user code).  The disregard was taken to an extreme with the 9x series in that the file system (FAT) wasn't capable of providing this separation of concerns even after 95 gained protected memory by moving to 32 bit (which then had massive holes blasted in it for the ability to continue running 16 bit applications).

If you look at software that was intended for Window NT (a multi user OS) it has always had this understanding of separation of privilege for the same reason that the POSIX compliant OSs have.

@Nuke: You probably are more than qualified however, we are talking about the defaults of the OS, which should never leave the machine in a position that is comprising. The defaults are the reality for 99.999% of the user base so we need to cater to and that is what this discussion is about.  Advocating something that most users have no clue about is just begging for trouble.

[Zacam]

Many applications that I have (such as FireFox or the like) have the concession of either following %AppData% (which is not the Documents folder, but that is useful for -Games- to save there in the "My Games" folder which keeps it a little cleaner) or in the Application Directory directly.

I mentioned in IRC (and I forget if I mentioned it here) allowing the option (within the appropriate implementation) for user choice should be the way to do it if at all possible. If that can then be coordinated with wxLauncher to read an attribute or something stored somewhere so it can pick up that location (instead of flat out assuming one way or the other) then that will make it a little more seamless and comprehensive for the end-user.

[jr2]

That sounds good; perhaps just include one location set by default, so users don't get afraid of "messing things up" (have %APPDATA% seclected, in bold with "(default)" beside it or something).  I've seen users stop at silly prompts that didn't matter and call me in a panic because they were afraid of messing something up.  Which, given that they don't have the slightest clue as to how their Operating System works (and don't really want to), I suppose I can't blame them.

[Iss Mneur]

wxLauncher will likely be doing it via a commandline flag.  I would imagine it would be the same for FSO.  Though we may want to make the feature only available at compile time and then offer two different downloads, we will have to cross that bridge when we get there I suppose.

[jr2]

How about make the default compile to w/e path you want, but be able to be overriden with a config file entry such as "UserDataPath=variable/absolute path" ?  I just think downloading an entire different program to change a setting is... wasteful?  IDK