Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: jr2 on March 07, 2012, 09:26:01 am
-
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:
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) (http://msdn.microsoft.com/en-us/library/aa905330.aspx) 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):
<?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). (http://msdn.microsoft.com/en-us/library/bb756929.aspx)
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 (http://msdn.microsoft.com/en-us/library/bb776463(VS.85).aspx) 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
<?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):
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):
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 (http://www.vbforums.com/showthread.php?t=643588)
-
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.
-
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 \ ?
-
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.
-
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.
-
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.
-
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.
-
It's not that hard.. you just copy/paste the whole directory...
-
i keep my freespace dir off of my c drive all together. i just dont trust any partition that windows thinks belongs to it.
-
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.
-
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.
-
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
-
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 --> :confused: <-- user } and yet somehow they are more afraid of their computer (instead of their 1-3 ton vehicle capable of traveling 100+ MPH :nono: )
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? ;)
-
If the user cannot copy one folder to another, than FSO is going to be one giant experience in pain.
-
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).
-
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.
-
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.
-
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)
-
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.
-
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.
-
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.
-
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.
-
Or, leave the log files themselves harder to find, and let wxLauncher retrieve it for you :)
-
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!
-
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).
-
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.
-
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.
-
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.
-
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.
-
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:\.
-
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."
-
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 :P
-
... 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 :p) . 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
Maybe...
The problem comes down to how does wxLauncher know where to find this config file? The config file that tells it where to find stuff like its config files? This is chicken and egg sort of stuff.
Two "eggs" that an application always gets are its compile options and its commandline which is why it almost always implemented as one of those two options.
-
Have it always search the working directory, and have that config file able to point to another config file if you don't want the config file there. You could also use the registry but that's not cross-platform friendly.
I wish OSX and Linux could use the filesystem as a substitute for Windows registry entries. e.g., <current dir>/HKLM or HKCU/Software/Microsoft/Windows/CurrentVersion/Uninstall.reg Just have Uninstall.reg contain all necessary values and have it compatible with Windows registry editor, so you can use that to import/export/edit/ yada..
-
id say place a file that only contains paths to other files/directories in the standard location (for example %APPDATA%\fspaths.cfg). then you can configure these paths in the launcher or use defaults (for example my games\fs2). then the actual settings/application/mods directories can be placed anywhere. though id default them to my games\fs2open\settings, program files\games\freespace 2\, and my games\fs2open\mods, respectively. you might want to install the launcher and the fs2open engine in different places, though, id prefer to keep stuff in as few places as possible, for ease of backup.
-
just for the record the secure file protections system (the stuff that keeps you from ****ing up OS files) works on the basis of an include list not a "everything on this drive!" semantic.
(i would know.. being that i have to turn off it protecting files when i install private binaries at work)