How to circumvent Windows security when app is installed in Program Filew (x86) ?

THERE IS A PROBLEM WITH WINDOWS 7 ULTIMATE SECURITY WHEN YOUR PROGRAM IS DEPLOYED IN Program Files (x86):
- IT WILL NOT LET YOU DOWNLOAD A FILE
- IT WILL NOT LET YOU CREATE A NEW DIRECTORY IN THE APP ROOT DIRECTORY (PROGRAM FILES (X86)) WITH CREATEDIRECTORY
- IT WILL NOT LET YOU MOVE FILES WITH MOVEFILE
THESE METHODS ALL WORK JUST FINE AS LONG AS THE APP ISN'T INSTALLED IN Program Files (x86).

WHILE TRUE THAT IT WORKS IF RUN AS ADMINISTRATOR DIRECTLY ON THE FILE, THE SHORTCUTS IN THE STARTUP AND DESKTOP DO NOT OFFER THAT OPTION.
WHAT IS THE PROGRAMMER TO DO TO ALLOW THE NON-ADMINISTRATOR TO GET THE APP WORKING PROPERLY ?

Have you tried to run the compatibility troubleshooter or run the app in compatibility mode?

Quote:

---

Originally Posted by Mike Pliam

WHAT IS THE PROGRAMMER TO DO TO ALLOW THE NON-ADMINISTRATOR TO GET THE APP WORKING PROPERLY ?

---

Implement it following Win7 programming guides? :) Like Do not write files/create folders where you're not allowed. Use user profile folders instead. Use manifests requiring admin level for running critical parts and be prepared to UAC screens urging user to confirm actions. Use services to run tasks requiring for elevated rights. And ultimately, test your programs in every OS and mode your end user may run.

Mike, troubles with \Program Files\ folder security started long before Win7. AFAIK first it was Win2000 that limited file/folder operations there to admins only. So I cannot see any reason to shout out in capitals about a thing everybody knows for more than a decade.

sorry about the caps. i was in a hurry and once i started, was too lazy to rewrite.

Quote:

---

Use user profile folders instead.

---

That presents a bit of a problem using the windows installer setup program - I havn't figured out how to do that but I'll work on it.

Quote:

---

use manifests requireing admin level for running critical parts

---

Not sure what you mean by this. How do I do that?

Quote:

---

Use services to run tasks requiring for elevated rights.

---

Sounds good if it works, but not sure how to build such a service.

Using more expensive and elaborate installers, it is easier to customize them, but the Windows Installer setup program that comes with VS 2010 is quite easy to use and is quite reliable albeit rather limited in documentation. It only appears to offer the user the Program Files (x86) directory install option, and unless the user knows enough to edit the default to his own user profile, it will install it where it won't work unless signed in as administrator, and even then in Win 7 ultimate, and on most office networks, it won't work as it needs to.

Quote:

---

Originally Posted by Mike Pliam

That presents a bit of a problem using the windows installer setup program - I havn't figured out how to do that but I'll work on it.

---

In fact that hardly has anything to do with installer. Typical strategy is: system wide executables go to %WINDIR%\system32, app binary files and other files you're never to change at runtime go to %PROGRAMFILES%, and mutable data, user specific settings/conf/ini, temporary files, downloads, etc. go to user profile folders like under %TEMP%, %APPDATA%. From the described files variety no user specific data/configuration becomes an installer responsibility. Instead, application must be able to seed user profile with initial folder structure and user specific settings.

Quote:

---

Not sure what you mean by this. How do I do that?

---

Manifest is the key word for googling. :)

Code:

---

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="requireAdministrator" />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

---

Quote:

---

Sounds good if it works, but not sure how to build such a service.

---

As any other technical thing it works being designed and implemented proper way.

Quote:

---

Using more expensive and elaborate installers, it is easier to customize them, but the Windows Installer setup program that comes with VS 2010 is quite easy to use and is quite reliable albeit rather limited in documentation. It only appears to offer the user the Program Files (x86) directory install option, and unless the user knows enough to edit the default to his own user profile, it will install it where it won't work unless signed in as administrator, and even then in Win 7 ultimate, and on most office networks, it won't work as it needs to.

---

Again, everything works being designed and implemented proper way. In case it does not, programmer is responsible for making it do what it should do. I dealt with MSI, InstallShield, Tarma and NSIS installer engines, and none of those can be called ideal or perfect for any thing you ever might need. And therefore, you need to put a good deal of labor to particular installer package to get the result you count on.

Igor, thankyou for your most valuable input. I have recalled all the problems I ran into in the past trying to install and run a shared program on a network. Many of the problems are similar. One key to a solution was to use the following method to obtain the User directory.

Code:

---

/// This routine retrieves the process's environment block
/// using GetEnvironmentStrings, parses that block pointed to
/// by the generic international text pointer LPTCH, and returns
/// the requested string lpszVarStr as a string.
/// Note that the block lpvEnv environment variable substrings
/// are separated by NULL byte, and the block is terminated by a NULL byte.
/// The header files <windows.h>, <tchar.h>, <stdio.h>, <string>, and
/// <iostream> need to be included.
/// http://msdn.microsoft.com/en-us/library/windows/desktop/ms683187(v=vs.85).aspx
/// http://msdn.microsoft.com/en-us/library/windows/desktop/ms682009(v=vs.85).aspx  //code fr example 3 here
CString MyAppDlg::GetEnvVar(wstring wsEnVar)
{
    // Get a pointer to the environment block.
        LPTCH lpvEnv = GetEnvironmentStrings();
    LPTSTR lpszVarStr = (LPTSTR) lpvEnv;

    // If the returned pointer is NULL, exit.
    if (lpvEnv == NULL) return _T("GetEnvironmentStrings failed (%d)\n");

        int n = -1;
        wstring wstr = _T("");
        CString cstr = _T("");
    while (*lpszVarStr)
    {
                wstr = wstring(lpszVarStr);
                n = wstr.find(wsEnVar);
                if(n >= 0) break;
        lpszVarStr += lstrlen(lpszVarStr) + 1;
    }
 
        FreeEnvironmentStrings(lpvEnv);

        n = wstr.find(_T("="));
        wstr = wstr.substr(n+1, wstr.size()-n);

        cstr = wstr.c_str();

        return cstr;

}// GetEnvVar(string wsEnVar)

---

Regarding using a 'Service', I have found that it's much simpler to build a Win32 project, hide the window, and incorporate whatever methods requiring special privledges (just get rid of the the main window loop and set your desired method(s) as a LRESULT CALLBACK). I have referred to this in the past, both here and elsewhere, as a 'poor man's service'. You can even get this thing to run at startup, etc, but that is not necessary for my purpose.

Quote:

---

Originally Posted by Mike Pliam

One key to a solution was to use the following method to obtain the User directory.

---

ExpandEnvironmentStrings function typically serves to my purposes much better. :)

Quote:

---

Regarding using a 'Service', I have found that it's much simpler to build a Win32 project, hide the window, and incorporate whatever methods requiring special privledges (just get rid of the the main window loop and set your desired method(s) as a LRESULT CALLBACK). I have referred to this in the past, both here and elsewhere, as a 'poor man's service'. You can even get this thing to run at startup, etc, but that is not necessary for my purpose.

---

I have to admit I do not understand what this your comment is about. One thing I know for sure, it's not about the services I know.