[KeldorKatarn]

As you all know, Vista and Windows 7 do not allow access to program files folder, HKey Local machine registry and other folders and keys.
For older 32bit binaries the access is virtualized, which already can cause a lot of trouble (like the runtime expecting to write for all users, but virtualization working on a per-user level)

Also it doesn't work at all for 64bit runtimes.


I know you guys are already working on getting rid of Registry stuff, but I thought you might find the fact interesting that I just listened to an official MS webcast about the virtualization feature in which an MS employee stated, that the virtualization feature is temporary and will not be supported for long, and most likely not be in a future Windows version, which means,
any programs which try to write to unauthorized places will simply seize to function with that OS generation.

Also if there were a 64bit version of FS_Open that one would already not work anymore.


As I said, I know you guys are already working on this, I just thought this might be interesting enough to post.

(It probably means a lot of old games and tools that are not in development anymore will most likely not work anymore with the next windows, if the devs made the mistake to write to admin-only places, like Voltion and probably most other game dev studios did)

[chief1983]

This came up in IRC again recently, unless we move to an INI system I'm still pushing for a dual change to the launcher and FSO, whrere FSO tells the launcher that it's using HKCU, otherwise it defaults to HKLM to maintain compatibility with previous builds.  The new FSO builds will require the newer launcher though, which shouldn't be as big of a problem.

[Tomo]

An INI system is a better solution, but still has issues as Windows 7 doesn't like write access outside of of the User folder.
(Actually, even Windows XP didn't let a limited user write to %ProgramFiles% among other things)

Access to the game folders is being virtualised at the moment, but if MS are considering taking away virtual HKLM Registry stuff then virtualised folders will probably vanish soon as well.

So we should really put all of the INI files into a user folder (probably "%APPDATA%/FSOpen" or similar), including cmdline_fso.cfg and the debug log files.

[The E]

In other words, do it the same way it is done on Linux and MacOS? 

It's definitely the way to go, though.

[Tomo]

In other words, do it the same way it is done on Linux and MacOS? 

Heck yes!

There's a reason why *nix does that. MS were just late to the multi-user party.

[chief1983]

Actually the *nix way of doing it is what I was referring to, was thinking it was an INI in the user's folder or something.  Speaking of, PCS2 needs to put the ini in the user folder too

[KeldorKatarn]

Access to the game folders is being virtualised at the moment, but if MS are considering taking away virtual HKLM Registry stuff then virtualised folders will probably vanish soon as well.

Only if you put the game in the progam files folder. if you put it in C:\Games or whatever that is perfectly fine. However it is simply the case that windows reserves certain places for purposes of configuration data. That's the user's folder and I think there's a global AppData folder too, that can be user for setting stuff for all users. All of these folders can be automatically retrieved by using the win api and that is how it was supposed to be done since very early in windows development. only recent versions have started to enforce it more.

[KeldorKatarn]

What't the status on this? Is this on the agenda for 3.6.12?

[chief1983]

It may not make it into 3.6.12 but it's part of discussion about a larger overhaul of file locations.

[KeldorKatarn]

FYI, Saga considers this a "need"

[chief1983]

Well it can't function without simultaneous modifications to the launcher and to the command line querying of the FSO engine.  Plus we need to move to a file based config anyway, which might be happening with the new launcher in the works, but it's not ready yet.  I'd like it if someone could figure out the temporary solution the way I've requested it previously, where the engine tells the launcher if it's using HKLM or HKCU or whatever but no one's gotten around to that yet.  Is there someone you need to run WCS that doesn't have an admin account?  I have no trouble running FSO currently on Windows XP, Vista, or 7.  Not sure how this is really breaking things that badly.

[The E]

Indeed. Until Microsoft shuts off the virtualization functions, the use of HKLM is just unclean coding, not serious breakage.

[KeldorKatarn]

First of all we are writing our own launcher. And the problem is very simple... the locations for write change whenever the user logs in. If he logs in as admin it writes to local machine, if he logs in as user it write to virtual-HKLM. So our launcher wouldn't know where to look for the information, let along write it. you cannot purposely write to the vurtualization and expect the engine to look it up exactly there.
What if the launcher writes to HKLM because the user was in admin when he made the settings, maybe wisely chose to launch the launcher with admin level, and later the engine is started in user mode and the engine doesn't find the settings.

Sorry but I call that a serious problem and not just unclean coding. Violating access rights and not being able to guarantee where the written data ends up is more than just an inconvenience.
Let along the fact that if Saga uses 3.6.12 it's release package would be 100% incompatible with the next version of windows and simply not run anymore, and no we don't expect our users to go try to find an updated exe. Most people will simpl doesnload it from some game magazine's page and if it doesn't run or has problems in certain user modes they simply will not play it.

To us that is inacceptable so if this isn't fixed by SCP, this is ANOTHER candidate for custom build.


As a solution maybe: What if for now the game looks at HKCU first and if that entry doesn't exist it tries to access HKLM (with handling of access forbidden situations which WILL happen in future windows builds).

To be honest I don't really see the problem here. The linux build already uses an ini file doesn't it? So why not copy that code 1:1 and add a "fallback to registry" option if that ini doesn't exist? that would be compatible with all future launcher options. Any future launcher would create an ini file, so the engine would ignore the registry.

[chief1983]

It's virtualized, the engine shouldn't care whether or not it is.  Whatever user is logged in, the launcher and engine should be looking in the same place.  Isn't that the point?  I hear what you're saying about the virtualization going away and this not working anymore though, that's a very valid concern.

I don't think the engine should be responsible for checking both places, I think the launcher should be responsible for asking the engine where it stores its info, that is if we care to have a launcher that works with multiple versions of FSO.  We could probably phase that out after a release or two more but just so we don't need to have two copies of the launcher sitting around for testing old versions, I think it would be great it if it was backwards compatible.

[portej05]

Keldor: Be aware that if you use an executable that is not an SCP executable that we will not provide any support for it. This includes end-users.
Also, 3.6.12 is feature complete, so no changes will be made now until the next release.

Sorry.

[Tomo]

The engine should move to using an INI file in %APP_DATA%/fs2_open just like the Unix builds use - and that should happen straight after 3.6.12 is released.
Even under Windows XP HKLM was *not* supposed to be used - it only worked because almost all home users ran as Admin all the time.
- Many businesses forced their staff to run as limited user accounts. Of course, your staff being unable to play FreeSpace was probably a good thing!

However, it's a lot more than just the config data.
There is also:

• flags.lch
• cmdline_fso.cfg
• log files
• cache files
• mission backups

.. And probably some other stuff I've missed.
All of that would need to move for proper Windows 7 compatibility.
- You can pretty much test this under Windows XP by copying FS2 Open into Program Files, then running under a limited user.

Keldor:
A launcher still has to find flags.lch - this is a problem, as under Windows XP (at least) FS2 Open doesn't respect the 'Start In' folder (at least for flags.lch). Thus the launcher can't tell FS2 Open where to put the info to get the executable capabilities, and it's therefore impossible for you to ask FS2 Open where to look.

We'll need to have a discussion about how best to handle that, after 3.6.12 is released.

[chief1983]

So it sounds like a lot of work is needed to make sure FreeSpace is more standards compliant, and most of  this stuff I've been talking about doing for the last couple of weeks now.  But they're right, 3.6.12 is not where these are going to happen.  portej and I both agree that taking care of issues like this immediately following 3.6.12 would be a great idea, as well as sorting out linking to get VS 2010 working as it will be released shortly.