🚀 go-pugleaf

I have encountered a problem on Vista with one of my company's applications. 
Internet Explorer seems to be "sandboxing" an ActiveX control that we've 
written denying it the ability to create files in the OS.  Has anyone else 
seen this behavior and know of how to work around it?

Here is a complete description.

Background:

A user will connect via a web browser to launch one of our client 
applications.  The web page has an embedded ActiveX control (an Active Form) 
that is served by the web server via a signed CAB.  We call this ActiveX app 
our "Universal Client Launcher".  The param tags on the web page inform the 
launcher of what client needs to be run.

When the launcher opens it connects to a server to check for the current 
installed version of a client.  If the current version doesn't exist on the 
user's machine it is downloaded and extracted to the user's application data 
directory.  Then the client is launched.  In our current implementation the 
clients are all Win32 EXE applications.

What works:

This scenario has been working flawlessly with XP (2000 and Win98 worked 
with an earlier version of this scenario but we haven't tested it recently). 
For systems where the users have limited privileges (ie, they can't install 
ActiveX controls) the system admin needs to install the launcher for them. 
From that point the user can get the latest versions of our clients as they 
become available.  And because the launcher rarely changes the system admin 
is hardly ever involved in the process after the initial install.

The problem:

With Vista the administrator is able to install our ActiveX launcher without 
problem.  The administrator can also install and launch any one of our 
client applications.  A user can also launch our ActiveX launcher.  The 
problem happens when the client is extracted and executed.  The OS claims 
that the files exist on the user's system.  However, checking the 
appropriate directories the files do not exist.  When the launcher opens the 
application, ShellExecute() returns an error code of 5 
(SE_ERR_ACCESSDENIED).

Sample code:

Following is a modified version of the launcher.  I have provided enough 
code here to show the logic flow and the main functions that we use.

  String prodPath = ConstructFileName(GetSpecialFolder(CSIDL_APPDATA),
    "OurCompany\\" + ApplicationName + "\\" + Version);

  if (!DirectoryExists(prodPath)) // (A)
  {
    // Create the directory to place the files
    if (!ForceDirectories(prodPath))
      throw Exception("Couldn't create path: " + prodPath);

    // Download and extract the files to 'prodPath'
    // ... internal stuff
  }

  // Determine the EXE name to run
  String exeName = // ... internal stuff

  if (!FileExists(exeName)) // (B)
    throw Exception("EXE doesn't exist: " + exeName);

  int res = reinterpret_cast <int> (::ShellExecute(NULL, NULL,
    exeName.c_str(), parameters.c_str(), prodPath.c_str(),
    SW_SHOWNORMAL));
  if (res <= 32)
  {
    RaiseLastOSError();
  }

ConstructFileName() is a function that correctly appends argument two to the 
end of argument one for use as a folder or file name.  GetSpecialFolder() is 
a function that makes calls to SHGetSpecialFolderLocation(), etc to retrieve 
the full path to a special system folder.  On my XP development machine 
'prodPath' contains:

  c:\Documents and Settings\username\Application Data\
    OurCompany\appname\version

On our test Vista machine 'prodPath' contains:

  c:\Users\username\AppData\Roaming\OurCompany\appname\version

The first time the launcher runs the 'prodPath' doesn't exist.  The line 
marked (A) evaluates to true.  This results in the files being downloaded 
and extracted into 'prodPath'.  At line (B) the file check evaluates to 
false (meaning the file exists) and ShellExecute() is called returning 5. 
RaiseLastOSError() throws the following exception:

  System Error.  Code: 5.
  Access is denied.

If I run the launcher again this time when it reaches (A) the evaluation 
results in false (the directory does exist).  The files are not extracted 
again.  Line (B) results in false again and ShellExecute() produces the same 
result.  A quick peek at the file system shows that the directory 
"c:\Users\username\AppData\Roaming\OurCompany" does not exist and therefore 
neither do any of the sub directories or files.

What else I've tried:

I created a test application that loads the ActiveX control.  This 
application represents the part that IE would be playing.  The ActiveX 
launches, retrieves the files, and runs the client just fine.  So, it would 
seem that the ActiveX control running in IE has limited permissions or the 
operations are somehow being "sandboxed".

Has anyone encountered a situation such as this with Vista yet and know of 
any solution?

BCB6 Pro
- Clayton