I am having trouble getting the Wholehog Connectivity Driver correctly working on my x64 machine. I have tried un-installing & re-installing, but no luck. Any help will be great.
It could be that the registry is pointing ESP in the wrong direction. Try these instructions:
1. Select Windows Start\Run, type regedit and press Enter.
2. Go to [HKEY_LOCAL_MACHINE\SOFTWARE\Flying Pig Systems\Wholehog III ESP] for XP-32bit, or [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Flying Pig Systems\Wholehog III ESP] for Vista-64bit
3. Doubleclick on "Location".
4. Add a single slash in the end of line, for example: "C:\Program Files\Flying Pig Systems\Wholehog III Connectivity\". Press Enter.
[QUOTE=c_muenchow;48738]It could be that the registry is pointing ESP in the wrong direction.
dear chris:
i'm quite curious to learn which functional / technical spec is satisfied by applying LockPermissions during a 3PC install.
to persuade you to assist me in challenging that choice, i'll share with you a true piece of history - a real treasure, with the power to solve problems ten years into the future:
Application Specification for Microsoft Windows 2000 for Desktop Applications
published over a decade ago, Chapter 4 holds all the answers to avoiding every single one of today's LUA issues.
especially notable is the prescribed testing as a standard user...
please help.
please let me know how i can help.
because i want to help.
inevitably, the rant, quoted in its entirety: [QUOTE=quinn;42666]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.
