[jr2]

You can have Carl beat me with a stick if this doesn't help us at all, but I *think* this is somewhat related to FS / FSO and running on Vista / 7 .. how do we stand in regards to FSO playing nice with Vista / 7's habit of creating virtual copies of files modified in the \Program Files directory?  Keep in mind, GOG.com installs there by default so we may be dealing with any potential issues more in the future.

Copied from http://www.vbforums.com/showthread.php?t=643588

Windows seven won't let me write text files to the program files directory (without virtualisation), so I need to find an alternative.
I was thinking of a common area, although the file should not be able to be changed by the user, only a member of the admin group...

This link shows that CSIDL_COMMON_APPDATA might work to allow any file created to be read only by users and updateable only by those with admin rights.

http://msdn.microsoft.com/en-us/library/ee419001.aspx

http://www.vbforums.com/showthread.php?t=564256

Folders created under CSIDL_COMMON_APPDATA default to "owner access" which means whatever user creates a new file there has full rights and others have read-only access.

A file created there by whatever "special user" you want won't be alterable by others.


However, and this is a big however, the actual operation will vary depending on whether your program has a manifest with a trustInfo section in it. This is required in order to declare your program "Vista aware" (and Windows 7 is really just an updated Windows Vista, make no mistake about it).

If you create a folder and a file under ProgramData (the new name for the CommonAppDataFolder) as an administrator your legacy (non-Vista aware) program run by a non-admin will be able to read and write to it. However writes will result in a virtualized copy of the original file, which is what then gets altered. From then on that user will always see their own private virtualized copy... or at least until it is removed.

You also don't need the half-page of code shown in the FAQ to retrieve special folder paths.

Just set a reference to Microsoft Shell Controls and Automation to get the Shell Special Folder constants and use a late-bound Shell object:

Code: [Select]

    With CreateObject("Shell.Application").NameSpace(ssfCOMMONAPPDATA).Self
        strProgramData = .Path
    End With
Late binding is recommended because the Shell32.dll did not maintain binary compatibility across all Windows versions.

Hmmm I just tested writing to CSIDL_COMMON_APPDATA by running my app without a manifest file in Windows seven, and while I was logged into an account with admin rights it could create and modify files in C:\ProgramData\My App directory without virtualisation, and regular users cannot modify or delete this file, which is the functionality I was looking for.
The strange thing was when I added another admin account, it was able to delete the files my app created even though it could not modify these files directly and as a result any changes resulted in a virtualised copy instead.

According to MS (http://msdn.microsoft.com/en-us/library/ee419001.aspx) all accounts with admin rights should have read/write permission.

It seems to me that:
Admin accounts cannot directly modify any textfiles in c:\ProgramData unless they are also the creator of the file (it results in virtualisation instead), although they can still delete any files stored here.

When I ran the my app as a compiled exe with a manifest file it allowed both members of the admin group to directly modify the text files stored in C:\ProgramData\My App directory without virtualisation (and prevented users from changing the file), and it had the same effect on files stored in C:\program files.
I was hoping that CSIDL_COMMON_APPDATA would allow me to avoid having to include a manifest file soley to alter text files linked to my application.

There are several things going on here.
The "owner security" that folders created under ProgramData inherit.
User membership in the Administrator group.
Running as an elevated user vs. as a standard user.
Having an application manifest that specifies executionLevel.
Having an application manifest specifying executionLevel = requireAdministrator.
To make things work as you wish you need to use an "asInvoker" manifest. Then to perform administrative actions (like altering your ProgramData files) you need to run the program requesting elevation.

When run without elevation your program will encounter security exceptions (errors 70 and 75 if not others) so you'll want to trap and handle those.

It is also possible to have your program run without elevation but have certain actions (via menu, command button, etc.) that request elevation "just in time." This can be done by having the main program start a separate elevated program or even another copy of itself elevated (passing a command line parameter to tell it what it is to do this instance).

But you aren't going to get away from needing an application manifest if you want anything besides the legacy behavior - such as file and registry virtualization.

Although I can see how a virtualised ini file allows a single file to be customised for each user, most of the time it is just annoying and non virtualised folders would be a much more preferable default.

The only way I could get around virtualisation was to include a manifest file with a <trusted info> section and then a "requireAdministrator" requested execution level. Seeing as it is such a pain to get working I am thinking about using the %program files% directory which is where most admins would first look for such information.

Is there no other way for all members of the admin group to read and write directly to a textfile without virtualisation?

Quote:

Originally Posted by Witis 
Is there no other way for all members of the admin group to read and write directly to a textfile without virtualisation?

What do you mean by "directly" though? Are you asking about using Notepad or something?

If a program has any trustInfo level defined there will be no virtualization. In most cases asInvoker should be used. Only programs that only perform administrative functions should have requireAdministrator.


The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC) is one of the intro articles on these topics, and it has a link to a download of a CHM Help file that covers more.

Note that this article a growing old fast and some of the links are broken now. This is old information developers are supposed to know by now. There was once a whole Web site covering these topics but it is entirely gone now. It had white papers, PowerPoint presentations, videos, CHM Help "e-Books" and so on as well as links to different tools.

I can see how anyone who waited this long to start developing for Windows after XP would be frustrated. Not much to be done about it though, it's been 5 years since these materials became available.

yep, I avoided vista mainly due to all of these UAC changes - I even sold my copy of Vista, although windows seven feels more like an updated XP, so it is easier to work on.
To summarise the articles so far combined with my testing (in relation to virtualisation and UAC (user account control)):

1. Any 32bit exe running in Vista/Seven will run in legacy mode ie all vb6 exes - this means all writes to locations such as %program files% and registry sections such as HKEY_LOCAL_MACHINE will be virtualised. Virtualisation means each user gets their own virtual copy of the files/registry keys stored in these locations, making it difficult for programmers to update the files or keys for all users, as this would mean updating all the virtualised versions as well.

2. To avoid/disable virtualisation every exe, not just exes that need admin rights to perform admin tasks such as writing to %program files% or HKEY_LOCAL_MACHINE, must include a manifest files (which includes a requested execution level) in the same directory as the exe.
- For applications designed to be run by regular users this means including a text file which has been renamed: myapplication.exe.manifest which contains the following XML text designed to set the requested Execution level to "asInvoker" (minimum requirements):

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>After the manifest has been created and placed in the application's directory recompile your application.
When the manifest is incorporated it tells Vista/Seven that the application is designed to run in Vista/Seven as a standard user (even for members of admin group), and legacy virtualisation is disabled.

- For applications that need to perform admin functions, change the corresponding line from above by altering one word -> change "asInvoker" to "requireAdministrator", the altered line should then be:
<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Then place the manifest file in your applicatons directory, then recompile your application, and when it is finished there will be a blue and yellow shield displayed on the bottom right side of the icon representing your application's executable file indicating your app is now set so that only user with admin rights can run it.
Although as such an application can only be run by a user who is a member of the admins group, this manifest is therefore not suited for regular applications.

3. Even the application common data folder (CSIDL_COMMON_APPDATA = &H23) requires a manifest containing requestedExecutionLevel level="requireAdministrator" in order to write to files stored there.

4. As a result, just about every application needs to contain at least two exes:
- one for regular users with a manifest containing "asInvoker" security section,
- and one for performing admin tasks such as writing files to C:\Program or c:\AppData with a manifest containing a "requireAdministrator" security section.


Now the only issue is: which directory allows all users (both regular users and admins) to read and write to the same file in an exe using the asInvoker security tag ie where do regular data files go - perhaps CSIDL_COMMON_DOCUMENTS ("All Users\Documents")?

Well let's see what I can add to help out here. I'm surprised nobody else chimed in yet, because a ot of people have already had to deal with the issues.


1. Doesn't apply to just VB6 programs, but all 32-bit EXEs.


2. Manifests should really not be in an external file, that was originally a hack in Win XP to allow administrators (as in people administering the machines and software, not as in access rights) to override the program's compiled-in manifest. On modern versions of Windows this override doesn't work anymore, the internal manifest takes precedence.

Manifests should normally be internal. They can be compiled in just like other resources or added to the EXE after compiling through use of appropriate tools.

A program with asInvoker in its manifest runs with the invoker's token by default. For normal sessions this is a standard user token no matter what group membership the user has. Such a program can always be run as administrator by users or other programs.

A program with requireAdministrator must always run with elevated rights. Canceling the UAC prompt means the program will not run.

There is a third option: highestAvailable. This means if an admin user runs it it should request elevation, if a non-admin runs it then it is run without elevation. This is considered a hack and not meant for use when it can be avoided.

These are discussed at Step 6: Create and Embed an Application Manifest (UAC).


3. Not for users who have proper rights to access the file(s) in the desired manner. As I mentioned a number of times above, you should create your folder under ProgramData in your installer. Your installer should generally set the rights your application needs on this folder or on individual files it places in this folder.

With the proper rights (for example write rights if you want to write to a given file) no virtualization will take place with or without a manifest. In many cases you end up giving full access on the folder to the Everyone group, and any files created there after you do this will also have those rights. There are lots of different rights: read, write, update, excute, delete, etc. so "full access" is often simpler than struggling over fine granularity.


4. Very rarely should you need two separate programs.

You can either rely on highestAvailable, or ask users to run as administrator when they want to run the program for administrative purposes. The program can detect which mode it is running in and hide options that unelevated runs cannot do. This works fine but isn't the recommended practice.

Or in the preferred approach you can use asInvoker and mark admin functions in the program (buttons, menus, etc.) with the UAC shield icon. When a user requests these functions (clicks on the button, etc.) the program will perform the function by starting a separate elevated process (which triggers a UAC prompt at that point).

This separate process can be another EXE, the same EXE with a command line parameter passed to tell it what mode it is running in, an ActiveX EXE, or an ActiveX DLL invoked via the COM Elevation Moniker (which runs it in a system-supplied surrogate process).

Usually the cleanest solution is to run that second copy of the same EXE, passing it a command line telling it "perform admin function X and then go away."


As for CSIDL_COMMON_DOCUMENTS, it has the same sort of "owner" based security as CSIDL_COMMON_APPDATA. This means the same rules apply there.

There is another new with Vista special folder that does what you're asking for but (a.) it isn't really meant for what you want to do, (b.) it doesn't exist in Windows XP or earlier, and (c.) there is no CSIDL value for finding it - you have to use new Shell calls that don't exist before Vista.

Quote:

dillettane wrote
I'm surprised nobody else chimed in yet, because a ot of people have already had to deal with the issues.

You used to point out that MS had since long prepared the developers to face the new arrangements starting from Vista, but isn't it reasonable for us to expect that at the same time MS should also have a good mechanism such as a particular API for the developers to tell whether the current program user is with the elevated status ("Run As Administrator")? From the earlier threads/postings, frustrating people here seem to be just running around seeking an answer to this point, but still to no avail yet.

Not sure what you're asking for there.

IsUserAnAdmin Function always tells your program whether it has admin rights or not.

Thst was covered in the "Vista for Developers" documents that came out in 2006. It's also been mentioned around here many times.

Thank you. (I had even added an ordinal 680 for safety purpose in case Win2000). What is borthering is that MS explicitly stated that:

Note This function is available through Windows Vista. It might be altered or
unavailable in subsequent versions of Windows
(http://msdn.microsoft.com/en-us/library/bb776463.aspx).

With a statement like that, the situation appears to be ambiguous (one tends to be reluctant to use a function in a program anticipating it might fail soon).

Yes, they don't really want you to program in ways where you'd need that call. I don't expect it to go away very soon though.

At least they offer an alternative if you want to write a few lines of code to be sure.

Hmmm, I am not so sure about the validity of the IsUserAdmin api function. In order to test it I created 3 accounts:
1. Network Manager with Admin rights
2. User with standard rights
3. A second Network Manager with Admin rights
In Windows Seven The IsUserAnAdmin function returned the correct boolean value only for accounts 1 and 2 i.e, it returned false for account 3 (the second network manager account). By contrast the IsUserAnAdmin function returned the correct boolean values for all three accounts in windows XP. I double checked these outcomes, and would thus look for an alternative function.

dilettante, I have worked my way through your post regarding manifests, uac and virtualisation, and I think you have finally answered my question.

Firstly
It was possible to include a copy of the manifest in the compiled vb6 exe by using the resource editor and following these steps:

0. Create the manifest file.
1. Critical: Make sure the size of the manifest file (in bytes) is divisible by four. If not append spaces at the end of the file and save it.
2. Select the Add-Ins menu (to the right of the Tools Menu) -> then select add-in manager -> scroll down and double click the VB6 Resource Editor (or check the load/unloaded check box).
3. Click on the green resouce editor button now displayed in on the toolbar.
4. Select the "Add custom resource" (button on the far right) then browse to the manifest file and select it.
(There should now be folder called "custom" and a file with the number 101 displayed in the resource editor.)
5. Double click (or right click -> properties) the file called 101.
6. Change the type to #24 (Critical: make sure you include the #) and set the Id to 1.
7. Then click the Resource Editor's save button.
8. Compile your application.

Secondly
I tried adding a manifest containing a security section requesting the highestAvailable execution level. As you indicated this automatically elevated members of the admins group, while regular users do not run with admin elevation unless they right click and select "Run as Administrator" and then supply admin credentials. This would allow my app to unenable or hide the admin features from regular users while allowing any admins to use the "run as administrator" functionality to gain access within a user session, or to display an "admin button" which if clicked launches an admin elevated version of the app. So why is the use of highestAvailable requested execution level considered a hack?

Thirdly
The reason for this thread was due to having difficulties regarding the permission attached to folders such as CSIDL_COMMON_APPDATA, and you indicated the easy way to deal with this problem was to allow the installer to set the directory permissions. I use inno setup and so the process was relatively painless.
In order to set folder permissions on the CSIDL_COMMON_APPDATA directory it is:

[Dirs]
Name: "{commonappdata}\test"; Permissions: everyone-modify

Where:
admins    Built-in Administrators group
authusers   Authenticated Users group
everyone   Everyone group
powerusers   Built-in Power Users group
system    Local SYSTEM user
users    Built-in Users group

full
Grants "Full Control" permission, which is the same as modify (see below), but additionally allows the specified user/group to take ownership of the directory and change its permissions. Use sparingly; generally, modify is sufficient.

modify
Grants "Modify" permission, which allows the specified user/group to read, execute, create, modify, and delete files in the directory and its subdirectories.

readexec
Grants "Read & Execute" permission, which allows the specified user/group to read and execute files in the directory and its subdirectories.

I tested this and it works to allow all users access to read and write without virtualisation and without any manifest, and was thus a solution to my problem, thank you. The same solution applies to writing to the HKLM section of the registry. The question then becomes: is there even a need for a manifest file at all (perhaps they are still useful for something else such as visual styles)?

IsUserAnAdmin reports the rights of the process, not the user. As far as I can tell it is always correct. "Admin" means the same thing as "elevated." Feel free to look for another function, but the preferred way is also given (with a C code sample) and does exactly the same thing.

I think you're looking at the issue wrong maybe? It means "am I running elevated?"


Of course you still want a manifest. Just to begin with it avoids virtualization, and this means that when a user specifies to write a file someplace they can't you'll get expected behavior (errors 70, 75, etc.) instead of succeeding but putting the file in a vistualized location. You need a manifest with trustInfo unless you want appcompat behavior. Another example is to avoid inaccurate legacy installer detection. This is a just do it option for development these days.

Beyond that a manifest does many other things. Visual styles are actually a byproduct of one of the things you specify in manifests: Side by Side assembly selection.

They can also be used to specify High-DPI awareness of an application, OS compatibility among current versions of Windows, registration-free COM and application isolation to help free you from DLL Hell, DLL relocation for non-COM DLLs, and many other things.


I agree that granting full permissions on a folder is usually overkill. It was just the most "eyes shut make this work" example.


As far as highestAvailable goes, it's a hack because you're expected to write applictions so they never need elevation until the user wants to perform a specific function requiring elevation. These functions should be marked with the UAC Shield icon, and request elevation only to perform that function.

In other words elevating the entire application is considered bad form. The main reason for this is that Microsoft knows darned well a lot of home users are going to always log on with an admin account. Writing programs the "right" way means they'll only see UAC prompts when required.

dilettante are you sure that IsUserAnAdmin reports the rights of the process, not the user, as according to the link you provided:
"IsUserAnAdmin Function Tests whether the current user is a member of the Administrator's group."
I feel I should reiterate my findings after checking again, in Windows Seven the IsUserAnAdmin returned false when I logged into the second network manager's account with administrator rights. If you have any code that depends on this function to determine if the user is an admin, it will break in Windows Seven Ultimate Edition and perhaps others too.

btw, I'm not convinced it is bad form to shell an elevated version of my app for admin purposes in a user session, do you have any references on that one, I would like to look into it further.

I have to agree with you regarding the potential essentiality of manifest files after trying windows styles.
Step 1: Add this to a text file

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
   version="1.0.0.0"
   processorArchitecture="*"
   name="MicrosoftWindowStyles"
   type="win32"
/>
<description>Manifest for Window Styles</description>
<dependency>
   <dependentAssembly>
     <assemblyIdentity
       type="win32"
       name="Microsoft.Windows.Common-Controls"
       version="6.0.0.0"
       processorArchitecture="*"
       publicKeyToken="6595b64144ccf1df"
       language="*"
     />
   </dependentAssembly>
</dependency>
</assembly>Step 2 Save the file as myapp.exe.manifest

Step 3 Add this code to your project's sub main if you don't have any user controls in your project (and change form1 to the name of the first form displayed in your project-highlighted in blue):

Code: [Select]

Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Sub Main()
InitCommonControls
Form1.Show
End SubOr this code if your project contains user controls (and change form1 to the name of the first form displayed in your project-highlighted in blue):

Code: [Select]

Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long
Private m_hMod As Long

Sub Main()
m_hMod = LoadLibrary("shell32.dll")
If m_hMod Then
    InitCommonControls
    FreeLibrary m_hMod
End If
Form1.Show
End SubStep 4 Optional: add the manifest file into the exe via the resource editor as I previously described to internalise the manifest.

Sources: http://support.microsoft.com/kb/309366
http://www.vbaccelerator.com/home/vb...wn/article.asp

Note: Enabling a Theme or Visual Style in Visual Basic 6.0 Is Unsupported.
If you enable a Windows XP theme in Visual Basic 6.0, you may encounter unexpected behavior.
For example, if you place option buttons on top of a Frame control and then enable a Windows XP theme or visual style, the option buttons on the Frame control appear as black blocks when you run the executable file.

Although I only looked for a little time so I wouldn't be surprised it is also possible to do this without needing a manifest.

Witis,

I am not so sure about the validity of the IsUserAdmin api function. In order to test it I created 3 accounts:
.....
.....

Sorry for getting back to you a bit late. I concur to what Diletantte has meanwhile explained; actually it was aiming at the "elevated privilege" that I made my earlier posting.

If the user is with Admin status, but has not "elevated" as Admin through "Run As Admin" or via an equiv setting elsewhere, IsUserAnAdmin would return False still.

Since IsUserAnAdmin is only a wrapper, some people directly use TokenMembership as an alternative.

I am far from being a fan of manifest (I do not program for a living and I don't intend to make my life that more complicated and difficult), hence cannot participate in the disussion on manifest deployment.

The rest of the thread is here

[Herra Tohtori]

I believe it has always been a recommendation to NOT install to Program Files, and instead somewhere like C:\Games\FreeSpace2\ or other similar location, outside of the system-nannied directories.

[jr2]

Isn't the root directory also system-nannied though?  Or does Vista / 7 leave subfolders in the root directory alone once the permission is given to create them?

Also, yes, I know the recommendation has been given, however, by the time a user goes to get FSO from here and sees that, are they going to be adventurous enough to move their GOG FS2 folder from \Program Files to \  ?

[chief1983]

I have no such issues using G:\Games\FreeSpace2 on my home PC.  G: is not my boot drive, but I think C:\Games\FreeSpace2 should work just as well.

[Fury]

Isn't the root directory also system-nannied though?  Or does Vista / 7 leave subfolders in the root directory alone once the permission is given to create them?

You can create folders to C without any additional permissions.

[Dragon]

C:\Games\Freespace2 works perfectly for me. I never intstall to Program Files if I don't have to anyway, since I like to keep my programs organized a bit.

[redsniper]

by the time a user goes to get FSO from here and sees that, are they going to be adventurous enough to move their GOG FS2 folder from \Program Files to \  ?

They'll kind of have to be if they want to avoid problems.

[mjn.mixael]

It's not that hard.. you just copy/paste the whole directory...

[Nuke]

i keep my freespace dir off of my c drive all together. i just dont trust any partition that windows thinks belongs to it.

[chief1983]

Microsoft thinks every partition belongs to it, especially the one with the largest amount of free space.  That's where it decides to put a bunch of Office cache files apparently.

[Nuke]

i routinely delete things that crop up on my d drive, cause i police the thing like a hawk. i do allow a swap file on it assuming its the only partition on the drive, but if ms puts anything there i will probably just hit the delete key on it. as soon as reactos hits beta i can give ms the bird.

[chief1983]

as soon as reactos hits beta the Cubs win the World Series, pigs fly, monkeys climb out of my butt, hell freezes over, etc i can give ms the bird.

ftfy

[jr2]

It's not that hard.. you just copy/paste the whole directory...

I'm aware, however, the average user is going to be very afraid that they will lose:

a) their saved games
b) FreeSpace
c) their OS (what if I mess something up...)
d) the Pentagon's OS (what if I mess something up and my computer goes crazy and tries to take over the world?!)

Seriously.  Many people know as little about their computers as they do about their cars, { user -->    <-- user } and yet somehow they are more afraid of their computer (instead of their 1-3 ton vehicle capable of traveling 100+ MPH )

EDIT: I would also like to point out, that if Windows stores a virtual copy of any files that are modified in \Program Files\, cut + pasting could possibly break a) and b) from the above list.  as well, the launcher6.ini likes to point to absolute paths, and will throw an error if FS isn't in the directory that it was in when launcher6.ini was created (solution is to delete launcher6.ini or manually edit it to point to the new path).

AmIRite? 

[Rga_Noris]

If the user cannot copy one folder to another, than FSO is going to be one giant experience in pain.

[jr2]

Ya.. however, how about my point?  If the actual copy of your pilot (saved game) is in some virtual directory, will windows copy (or move) the virtual directory (modified) one, or the original?  Will the pilot file even display in the FS2 directory in Windows Explorer??  Of course, in addition, unless Windows does copy the virtualized versions, any .ini files will revert back to original or disappear (by virtue of there not being any actual file in the FS2 directory to copy).

[Nuke]

as soon as reactos hits beta the Cubs win the World Series, pigs fly, monkeys climb out of my butt, hell freezes over, etc i can give ms the bird.

ftfy

i dont know what you mean about that, they released a new alpha recently. so they seem to be making progress.

[Iss Mneur]

Ya.. however, how about my point?  If the actual copy of your pilot (saved game) is in some virtual directory, will windows copy (or move) the virtual directory (modified) one, or the original?  Will the pilot file even display in the FS2 directory in Windows Explorer??  Of course, in addition, unless Windows does copy the virtualized versions, any .ini files will revert back to original or disappear (by virtue of there not being any actual file in the FS2 directory to copy).

Yes, you point is valid.  It is well understood by SCP that this is a problem, however, it has a workaround that does work very well and this will be fixed at some point "soon" for two reasons.

1) The compatibility features that FSO utilizes will be going away in a future version of windows.
2) The compatibility features that FSO utilizes horribly complicate wxLauncher's ability to interact with FSO.

And yes, we are using more than just the compatibility feature is being discussed in this thread.

Yes I will know what is needed to fix it, and yes it will get done when I have some time to work on FSO, from how things are lining up that is looking like will be this summer.

[portej05]

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)

[Zacam]

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

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.

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.

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.

[The E]

Sorry Zacam, but that's just wrong. Using %appdata% is a) the right thing to do and b) in line with what we already do on Linux and MacOS.