Hog3 PC, cant get it to start

What version of Windows are you using?

on my Laptop im using Windows Vista 32bit

Did you try to run it as administrator?

Yes, i talked to a Friend and he said that its not running on all Computers, it doesnt work for him too, and we dont know whats wrong

You need to do one of two things. Turn of Window's UAC (user access controls) or right click and run Hog3PC as adminitrator.

what do you mean with windows UAC ? im not so adicted to computers ;-)

www.howtogeek.com/howto/windows-vista/disable-user-account-control-uac-the-easy-way-on-windows-vista/

UAC is an acronymn for User Access Controls. It's a security measure that was introduced in Windows Vista and has been carried over into Windows 7 aimed at improving the security of Windows PCs by limiting applications to standard user privileges until an andminstrator authorizes an increase in control.

So why is this causing problems with Hog3PC?
When an application is launched by either an administrator or standard user, the application must be validated as a resource the current user has priviledges to access. If Windows determines the application requires "elevated" user priveledges, Windows will pop up a dialogue box asking for credentials to do so. Unfortunately this is failing when launching Hog3PC. The reason for this is not yet fully known.

Until we resolve this issue the easiest way to run Hog3PC on Windows 7 is to right click the desktop icon for Hog3PC, go into properties, select the priveledges tab, and check the option that says "run as administrator", then hit apply. This will allow Hog3PC to run without changing the UAC settings in the control panel. I believe this works in Windows Vista as well.

ok thank you alot i'm gona try that tomorrow when ive got some time
i'll respond here if it worked or, not.

Cya

[quote=c_muenchow;42660]The reason for this is not yet fully known.


i've pointed this out a couple of times, but here's some more info, a quick fix, and a test for acceptance that you can perform yourself.


UAC auto-elevation
[INDENT]User ACCOUNT Control (and Windows NT, since inception) works slightly differently from what you've described.

there's a very important distinction between a PRIVILEGE and a PERMISSION - a PRIVILEGE describes access to an operation (i.e. a set of functions) and a PERMISSION describes access to a resource such as a file or registry key.


the RegOpenKey() function is what one calls to act upon an interest in a registry key or its value.

considering that standard users have unlimited access to their own HKCU registry hive, it follows that RegOpenKey() does not assert that a standard user have any elevated PRIVILEGEs assigned to their tokens.


in other words, standard users are allowed to call the RegOpenKey() function.


however, if a standard user asks RegOpenKey() to operate on a resource under HKLM, that resource will likely have a permission set applied that allows a standard user "Read Only".

so if a standard user uses RegOpenKey() to open a "Read Only" resource for Writing, RegOpenKey() will correctly return "Access Denied".


this is where the distinction betweeen PRIVILEGE and PERMISSION becomes important -

UAC will not auto-elevate a 3PC process because: a standard user token holds all PRIVILEGEs necessary to call every function that 3PC imports from the Win32 API's; even if a function returns "Access Denied", that function has successfully been called, run to completion, and returned a value to its caller.


Again, the auto-elevation aspect of UAC is intended to solve problems with PRIVILEGEs, not PERMISSIONs.

for examples of PRIVILEGEs that will cause UAC to auto-elevate, see Privilege Constants (Windows)
[/INDENT]

UAC Virtualization
[INDENT]in addition to auto-elevating when PRIVILEGE requirements are detected, UAC provides facilities for dealing with an application's PERMISSION requirements.

specifically, when a standard user tries to write to "Program Files" or HKLM, they should get "Access Denied".

instead, UAC intervenes by redirecting those write operations to targets located in an area that the standard user *does* have permission to modify.


in the case of a standard user attempting to create a file named "~lock" in "C:\Program Files\Flying Pig Sytems\Hog3PC", the file "~lock" is instead written to "C:\Users\Standard User\AppData\Local\VirtualStore\Program Files\Flying Pig Systems\Hog3PC"

similarly for "HKLM\SOFTWARE\Flying Pig Systems" registry entries, there are standard-user-accessible keys under "HKEY_USERS\{SID}_Classes\VirtualStore\MACHINE\SOFTWARE\Flying Pig Systems"


both operations, reading to and writing from these redirected resources, are handled by UAC Virtualization, and are completely transparent to the 3PC applications.


So why is this causing problems with Hog3PC?

well, it's because of some permissions set on the registry by the 3PC installer.

specifically, the MSI LockPermissions table applies permissions to the ProductVersion, EnlargeToolbarButtons, and InstUpgrade entries.

the set of permissions applied "forget" to allow standard users "Read" access.

and, unfortunately, since the actual "Software\Flying Pig Systems" keys are non-existant until these values are created with their errant permissions, the actual "Software\Flying Pig Systems" key assumes the permissions used to create ProductVersion, etc.

so, when 3PC is run as a standard user, it: does not have permission to read its own registry values, throws an fps::exception when trying to read its own registry values, and is unable benefit from UAC Virtualization when writing to these values.
[/INDENT]


please find attached a set of MSI transforms that cause these registry keys/values to be created with the default permissions inherited by HKLM\SOFTWARE.



to use them:[LIST=1]
provision a "greenfield" Windows 7 or Windows Vista machine, which has never had 3PC installed to it (because other registry values are created at runtime, the 3PC installer does not know to remove them during an UNINSTALL, and the errant permissions will still be in place)
place Hog3PC-Win32-golden_3-1-0-2672.msi and 2672-LUA.mst into a single folder
open a command prompt
cd to this folder
msiexec/i Hog3PC-Win32-golden_3-1-0-2672.msi TRANSFORMS=2672-LUA.mst
drive the install sequence as normal
launch launcher as a standard user
there are a few other areas that need their permission sets refined, such as the Services - these need to be modified to allow standard users to control starting and stopping.

but overall, the adjustment of a few permissions is very, very little work required to achieve compatibility with a standard user context.


Chris - i'd very much appreciate it if you took this to Robbie's attention.