Crash on ROM load/Does not save to AppData

[MenaceInc]

What steps will reproduce the problem?
1. Install Snes9x into Program Files under it's own folder
2. Load any ROM, don't touch settings

What is the expected output? What do you see instead?
ROM is meant to load and play and any files to be written to the Program
Files folder should go to AppData instead under Local/VirtualStore exactly
like 1.51 behaviour.
Snex9x crashes instead.

What version of the product are you using? On what operating system?
1.52fix4 on Windows 7

Please provide any additional information below.
It works if run as Admin but this is really not desired if the User Account
is intended to be a limited account.

I also forgot to mention that it doesn't start at all unless Valid.ext is included but that is created if you run as admin once.

[MenaceInc]

No replies after nearly a week... nice. o.0

[OV2]

Snes9x requires write access to its directory. You really think that silently writing into the virtual store is a desired result?

I'd have to modify the manifest so that windows recognizes snes9x as a legacy application.

[MenaceInc]

Snes9x requires write access to its directory. You really think that silently writing into the virtual store is a desired result?

I'd have to modify the manifest so that windows recognizes snes9x as a legacy application.

It was the behaviour in 1.51 and also supports mutliple users using different settings on the same computer. I shouldn't have to give a regular user access to an admin account just to play a SNES game.

Just out of curiosity, what was your reasoning for changing that behaviour?



EDIT: Just read over the thread again and realised I may of came across as a bit of a dick so I'm sorry if I caused any offence OV2 and the rest of the Snes9x team. I know all too well what it's like to be putting your free time into coding only to have to deal with complaints.

[Deathlike2]

Snes9x requires write access to its directory. You really think that silently writing into the virtual store is a desired result?

I'd have to modify the manifest so that windows recognizes snes9x as a legacy application.

It was the behaviour in 1.51 and also supports mutliple users using different settings on the same computer. I shouldn't have to give a regular user access to an admin account just to play a SNES game.

1.51 was more like a 2k/XP friendly app than Vista/Win7 app.

Just out of curiosity, what was your reasoning for changing that behaviour?

It might sound obvious, but making it more like a Vista/Win7 native program was probably why.

EDIT: Just read over the thread again and realised I may of came across as a bit of a dick so I'm sorry if I caused any offence OV2 and the rest of the Snes9x team. I know all too well what it's like to be putting your free time into coding only to have to deal with complaints.

I think you're misunderstanding the intent of the change. I understand you liked the "legacy" behavior of the older versions and that might be a better solution for you, but the change was probably to make it more compatible and friendly with the more current OSes... because people have had problems with not being about to read/write for save and other directories. This is the kind of change that is needed to sort these kinds of issues out.

[MenaceInc]

Snes9x requires write access to its directory. You really think that silently writing into the virtual store is a desired result?

I'd have to modify the manifest so that windows recognizes snes9x as a legacy application.

It was the behaviour in 1.51 and also supports mutliple users using different settings on the same computer. I shouldn't have to give a regular user access to an admin account just to play a SNES game.

1.51 was more like a 2k/XP friendly app than Vista/Win7 app.

Just out of curiosity, what was your reasoning for changing that behaviour?

It might sound obvious, but making it more like a Vista/Win7 native program was probably why.

EDIT: Just read over the thread again and realised I may of came across as a bit of a dick so I'm sorry if I caused any offence OV2 and the rest of the Snes9x team. I know all too well what it's like to be putting your free time into coding only to have to deal with complaints.

I think you're misunderstanding the intent of the change. I understand you liked the "legacy" behavior of the older versions and that might be a better solution for you, but the change was probably to make it more compatible and friendly with the more current OSes... because people have had problems with not being about to read/write for save and other directories. This is the kind of change that is needed to sort these kinds of issues out.

If it was intended to make it more 'native' as you put it then it shouldn't need Admin account access to use the program. I don't want to have to give my password to my family just so that they can play SNES games. That's why I can't get why they would change it to explicitly disallow writing to the AppData folder instead.


This would be fine if the program was located on a Users desktop where they have full access but for multiple users, there needs to be a standardised common location which is the Program Files folder.



Also, the point about being more friendly with current OSs is moot since I've been using 1.51 with Windows 7 since the RC and never had issues with it's behaviour other than flickering in fullscreen and sound problems which were fixed by changing a single setting.

[Deathlike2]

If it was intended to make it more 'native' as you put it then it shouldn't need Admin account access to use the program. I don't want to have to give my password to my family just so that they can play SNES games. That's why I can't get why they would change it to explicitly disallow writing to the AppData folder instead.

You'd probably want to change its properties to run under XP mode or something.... I believe that's normally the solution or workaround for this.

This would be fine if the program was located on a Users desktop where they have full access but for multiple users, there needs to be a standardised common location which is the Program Files folder.

The app was meant to be placed anywhere in your system prior to Vista+Win7... so it's not really Snes9x's job to force that issue. Keep in mind this app is for multiple Windows OSes, not just your version.

Also, the point about being more friendly with current OSs is moot since I've been using 1.51 with Windows 7 since the RC and never had issues with it's behaviour other than flickering in fullscreen and sound problems which were fixed by changing a single setting.

MS has guidelines for Vista/Win7 apps in terms of where application storage should go. The old behavior (1.51 and prior) is meant for "legacy" apps... the new behavior (1.52) is for current/native apps.

They've had these guidelines for even older versions of Windows (to a limited extent) to ensure full read/write access.

[MenaceInc]

If it was intended to make it more 'native' as you put it then it shouldn't need Admin account access to use the program. I don't want to have to give my password to my family just so that they can play SNES games. That's why I can't get why they would change it to explicitly disallow writing to the AppData folder instead.

You'd probably want to change its properties to run under XP mode or something.... I believe that's normally the solution or workaround for this.

This would be fine if the program was located on a Users desktop where they have full access but for multiple users, there needs to be a standardised common location which is the Program Files folder.

The app was meant to be placed anywhere in your system prior to Vista+Win7... so it's not really Snes9x's job to force that issue. Keep in mind this app is for multiple Windows OSes, not just your version.

Also, the point about being more friendly with current OSs is moot since I've been using 1.51 with Windows 7 since the RC and never had issues with it's behaviour other than flickering in fullscreen and sound problems which were fixed by changing a single setting.

MS has guidelines for Vista/Win7 apps in terms of where application storage should go. The old behavior (1.51 and prior) is meant for "legacy" apps... the new behavior (1.52) is for current/native apps.

They've had these guidelines for even older versions of Windows (to a limited extent) to ensure full read/write access.

*facepalms*

I really don't think you get the issue here.
You cannot run Snes9x at all as a standard user without running it as admin with UAC on.
Even if you set it to compatibility mode.

Now I refuse to give up my password to my family just so they can play a SNES game every now and then because of this one change.


What is so difficult to understand about that?


Now, I'm not sure about Windows XP since I haven't used it since around 2007 but this would be an issue with Windows Vista as well I'm sure given Vista and 7's common system layout.

You're claiming that it's done to make it more friendly with Vista and 7 when all it's done is cause security issues.


Again, I shoud not have to disclose my password to another user just to run a program like this.





I'm sure OV2 understands what I mean a lot more.

[OV2]

It was the behaviour in 1.51 and also supports mutliple users using different settings on the same computer. I shouldn't have to give a regular user access to an admin account just to play a SNES game.

Just out of curiosity, what was your reasoning for changing that behaviour?

This wasn't a conscious decision - applications compiled with new Visual Studio versions automatically get the required manifest information so that Windows no longer sees them as legacy applications.

As you've stated, to comply with MS guidelines snes9x should store its information in APPDATA. I'm not really comfortable with changing this, since we'd probably get a lot of complaints that it no longer works in a portable way. The windows port was never designed to be multi-user-ready.

If you do not want to place it into a globally writable directory and cannot wait for the next version, I can probably send you a version with changed manifest.

[MenaceInc]

It was the behaviour in 1.51 and also supports mutliple users using different settings on the same computer. I shouldn't have to give a regular user access to an admin account just to play a SNES game.

Just out of curiosity, what was your reasoning for changing that behaviour?

This wasn't a conscious decision - applications compiled with new Visual Studio versions automatically get the required manifest information so that Windows no longer sees them as legacy applications.

As you've stated, to comply with MS guidelines snes9x should store its information in APPDATA. I'm not really comfortable with changing this, since we'd probably get a lot of complaints that it no longer works in a portable way. The windows port was never designed to be multi-user-ready.

If you do not want to place it into a globally writable directory and cannot wait for the next version, I can probably send you a version with changed manifest.

I wasn't aware that Visual Studio did that...seems strange on Microsofts part. The portability that you want though shouldn't be affected by a change back to the old method of writing to the AppData folder since if I user runs Snes9x from their desktop then the writes should be going to the snes9x folder on the desktop and not AppData.

Unless you are refering to people who manually copy+paste the snes9x folder into Program Files from one Windows installation to another. That would be a different matter since typically most users wouldn't know of or think to copy the settings from AppData and they would have to setup their settings each time they copied it.

Hmm...interesting. Basically it's a decision between make a change to benefit people with multi-user systems and keep increased security or allow more chance for snes9x to be portable among windows systems.





Maybe we could setup a poll to decide if it becomes a permanent change to the program?
As for the manifest change, I'd really appreciate it if it's not too much bother. I'm really aware of how annoying and pretentious I may be coming across in this thread so I am really grateful that you'd help with that. I swear I'm not this annoying normally in other forums xD

[OV2]

I wasn't aware that Visual Studio did that...seems strange on Microsofts part.

The assumption is that if you develop a new application you know about UAC and the application data guidelines. What I'm doing now is basically removing the information that snes9x knows anything about UAC.

The portability that you want though shouldn't be affected by a change back to the old method of writing to the AppData folder since if I user runs Snes9x from their desktop then the writes should be going to the snes9x folder on the desktop and not AppData.

The problem is the fact that we are relying on a compatibility fix provided by windows. MS could remove it in a future windows version, and it doesn't allow for multi-user setups on pre-vista versions or with UAC disabled.

Here is a version with an updated manifest.
http://download.sessionclan.de/overfien ... -nouac.zip

[MenaceInc]

I wasn't aware that Visual Studio did that...seems strange on Microsofts part.

The assumption is that if you develop a new application you know about UAC and the application data guidelines. What I'm doing now is basically removing the information that snes9x knows anything about UAC.

The portability that you want though shouldn't be affected by a change back to the old method of writing to the AppData folder since if I user runs Snes9x from their desktop then the writes should be going to the snes9x folder on the desktop and not AppData.

The problem is the fact that we are relying on a compatibility fix provided by windows. MS could remove it in a future windows version, and it doesn't allow for multi-user setups on pre-vista versions or with UAC disabled.

Here is a version with an updated manifest.
http://download.sessionclan.de/overfien ... -nouac.zip

You are absolutely brilliant, thanks a lot. Having talked about the desire for snes9x to be portable I know better about why the change was made. I don't necessarily agree with it but I understand that it's something that a great number of users would want in comparasion to the behaviour of 1.51 and who may not be so paranoid with their systems security.

Again, sorry for seeming like a dickhead, especially as I hadn't posted on the snes9x forums before.


Just tested it out on all my systems and it works perfectly, thanks a lot OV2. Is there a donation paypal account setup for the snes9x team or I could even maybe throw a few dollars your way for the effort and time spent helping make the emulator better? Up to yourself.

Cheers again OV2.

[Camo_Yoshi]

I wasn't aware that Visual Studio did that...seems strange on Microsofts part.

The assumption is that if you develop a new application you know about UAC and the application data guidelines. What I'm doing now is basically removing the information that snes9x knows anything about UAC.

The portability that you want though shouldn't be affected by a change back to the old method of writing to the AppData folder since if I user runs Snes9x from their desktop then the writes should be going to the snes9x folder on the desktop and not AppData.

The problem is the fact that we are relying on a compatibility fix provided by windows. MS could remove it in a future windows version, and it doesn't allow for multi-user setups on pre-vista versions or with UAC disabled.

Here is a version with an updated manifest.
http://download.sessionclan.de/overfien ... -nouac.zip

We might just want to make this an option, like in the .ini or as a option in the GUI.