From a 32Bit application, Windows makes sure that you cannot access the Windows\System32 folder because this is the place where Windows has all its 64bit DLLs and other files. Since a 32Bit app cannot load 64Bit DLLs, Windows redirects the access to Windows\SysWOW64 folder which is (nearly) a 32Bit copy of the System32 folder. Therefore if you call ShellExecute on the e.g. Windows\System32\osk.exe you actually run Windows\SysWOW64\osk.exe. However the 32Bit version of OnScreenKeyboard refuses to run on a 64Bit system.

Fortunately, we can disable the redirrection with Wow64DisableWow64FsRedirection.

That leads us to a problem with ShellExecute. It uses internal functions that are located in DLLs. And there is the problem. If a winapi function wasn’t called before, it will be setup by calling LoadLibrary and GetProcAddress. However, since redirection is offline, LoadLibrary will load a 64Bit DLL which, of course, fails. In such a case ShellExecuteEx returns GetLastError  $7E (127) which defines the error  “The module specified could not be found “. I wondered what module was not found and used ProcessExplorer to compare pre- and post situation of ShellExecute. There were many, but only one made ShellExecuteEx work with disabled redirection: MPR.dll (multi protocol router). Step by step disasm returned the that WNetGetConnectionW was loaded from the DLL. So the fix is to load this library before ShellExecuteEx (also ShellExecute) is called.

uses
  JwaWinType,
  JwaWinBase,
  JwaShellAPI,
  JwaSHFolder,
  JwaShlObj;

function Wow64DisableWow64FsRedirection(out OldValue: PVOID): BOOL; stdcall; external 'Kernel32.dll'; //only for JWA < 2.4
function Wow64RevertWow64FsRedirection(const OldValue: PVOID): BOOL; stdcall; external 'Kernel32.dll'; //only for JWA < 2.4

procedure RunOnScreenKeyBoard;
  function GetNativeWindowsDirectory : String;
  var
    P : array[0..MAX_PATH] of Char;
  begin
    SHGetFolderPath(0, CSIDL_SYSTEM, 0, SHGFP_TYPE_DEFAULT, @P);

    result := P;
  end;
var
  oldValue : Pointer;
  Path : String;
  hMpr_DLL : HMODULE;
  ShInfo : SHELLEXECUTEINFO;
begin
  //CoInitializeEx(nil, COINIT_MULTITHREADED or COINIT_DISABLE_OLE1DDE); //*1

  hMpr_DLL := LoadLibrary('mpr.dll'); //*2
  try
    if not Wow64DisableWow64FsRedirection(oldValue) then
      RaiseLastOSError;
    try
      Path := GetNativeWindowsDirectory + '\osk.exe';

      ZeroMemory(@ShInfo, sizeof(ShInfo));
      ShInfo.cbSize := sizeof(ShInfo);
      ShInfo.lpVerb := 'open';
      ShInfo.fMask := SEE_MASK_FLAG_NO_UI or SEE_MASK_NOASYNC;
      ShInfo.lpFile := PChar(Path);

      if not ShellExecuteEx(ShInfo) then
        RaiseLastOSError;
    finally
       Wow64RevertWow64FsRedirection(oldValue);
    end;
  finally
    FreeLibrary(hMpr_DLL);
  end;
end;

*1 Has no use here if it was already called. But it is a reminder that it should be called for ShellExecute due to MSDN docs.
*2 Make sure you don’t call LoadLibrary when redirection is offline.

Delphi (addition)

I forgot to mention that in my experiences, a simple call to ShellExecute works if you run your app in Delphi. You’ll see that the app already has mpr.dll loaded if you check with Process Explorer. However, running the same app in Windows Explorer it will fail.
You see that Delphi can have an effect on your application. Therefore, always test your app separately.

Download

You can download this file from here.

Remarks

I tested this code on my Win7 64bit System only.

The string “%windir%\sysnative\osk.exe” was a first guess. However, ShellExecute fails with Error 2 (File Not Found).

Because this is a 64Bit Problem only, I did not make extra effort to check for a 64Bit Windows. The function Wow64DisableWow64FsRedirection is not available on a 32Bit platform, so using static linking is a bad idea if you want to use your app on 32Bit.

If you find this code useful, you may consider a donation? As usual, a donation can be also a WinAPI conversion, examples, bug fixes etc.

… I get my dialog and all runs well – *except* I’ve lost theming
on this particular dialog. This means the application’s main windows shows
up correctly themed, the progress dialog does not. I’ve already added the
XP manifest to the progress dialog, too, but to no avail so far.

A theme is only applied if an EXE or DLL file has a manifest that explicitly enables theme support. If Windows cannot find this manifest, the process is only shown with the regular window design.

However the Vista elevation is done by creating a COM object and offers its methods through a seperate process. A seperate process is necessary because the same process cannot get assigned the ncessary administrator token. In our case a service in the service container svchost.exe has the task to host the COM object. The contained service is called dllhost.exe (service name: “COMSysApp”) and does not run until requested. It does not matter whether the service is deactivated or not because it is started directly by svchost.

The COM method and the dialog will run in the process space of the newly elevated dllhost.exe. And because there is no manifest information in this file you cannot get a themed dialog layout.

So how can you get a themed dialog anyhow?

The task is done by using the basic principles of COM. COM knowns Callback interfaces and other stuff. By using a Callback interface you can turn around the server – client principle.

1. Define a well known interface that is implemented by the client only. But also known to the server.
2. Add a parameter to your elevated COM method that receives a pointer to this interface.
3. Before calling an elevated method, create the interface and
4. apply a pointer to the method’s parameter you added.
5. Call the method and use the methods in the given callback interface. COM will automatically transfer the method calls to your non-elevated process. In this way you can create themed windows, do window management stuff (progress bar) and eventually close the window.

If you prefer to read code instead of text you should study this code excerpts.

Define a callback interface for your client and add it to the server’s TypeLib. Delphi will generate code for it automatically in a file called <Name>_TLB.pas (TLB Header). Do not create the interface by using the Delphi’s ActiveX expert. Just add it manually.

IMyCallback interface is known to both the server and the client, because we use the TLB Header in the client and the server. The client will implement and the server will receive a pointer to it and then call the included method ACallBackMethod everytime it wishes to do so.

The server implements a method to allow a callback interface to be passed to it.

Of course you have to implement both interfaces: IServerInt and IMyCallback. However IServerInt is implemented on server side and IMyCallback is only implemented on the client side.

On client side (namely your application) write..

Install the COM object anywhere before you’re going to use it.

After all implement the callback method…

…and anywhere you like, call the method to use our Callback interface.

I’m using TComObject and TComObjectFactory on the client side , because this way works for console applications, too. If you need the possibilities of TAutoIntfObject, you will have to write a standalone COM server with TApplication. However this is not necessary here. The method ACallBackMethod will be run in the client’s process space rather than the elevated helper process. You can check whether the callback method runs in the correct process (elevated or not?) with the following code.

Second way, still on the client side:
If you already have a form class, you can add the interface to it.

Instead of creating the COM object, you pass a self-pointer to the method parameter.

Be aware that in a multi thread environment, you have to make sure that resources in that specific form are accessed only by one thread at a time.

Eventually the server side calls the methods within the callback interface:

The callback method will be called in the context of the client. So it will not be elevated. This is because there is no ordinary method call here. COM will pack the function stack and all its parameter into a stream, send it to the client, unpack it and restore a proper function stack to be executed. This happens in the client process of course.
Get more information about COM callbacks here.

If you start the program without any parameter, you’ll get the help screen.

RunEl V1.0 – Run application elevated
by Christian Wimmer @ 2008
Visit us at http://blog.delphi-jedi.net

RunEl [/INSTALL][/UNINSTALL][/W[D][G]] [AppName] [Parameters]

Parameters:
/INSTALL – installs the RunElCOM.dll. Needed for parameter /D
RunElCOM.dll must be in the same folder as RunEl.
/UNINSTALL – uninstalls the RunElCOM.dll.
W – Wait for called process to be finished.
D – uses own elevation COM Class. Before using must be setup with /INSTALL .
G – uses foreground window to display UAC Prompt on.
Parameters W, D and G must be mixed up with only one “/”

Despite the INSTALL parameter, you do not have to install the program! I implemented two different ways to elevate an application. There is on the one side ShellExecute, which can elevate an application by passing “runas” as a parameter. On the other hand, I implemented the usual way by registering a COM DLL. In the last case, you have to register the DLL first. We get back there later.

Let’s see how we can use it. Open a command line window and type:

RunEl cmd

This command starts the Windows command line interpreter as an Administrator. You get the UAC prompt, allow the action and a new cmd window is opened. If you disallow the action, RunEl will return an error value through its process return value. This us useful if you want to check the errorlevel in a batch file.

Elevation failed. (2147943623) The operation was canceled by the user.

If you need to wait for the process to be closed, you can add the wait parameter. This is also mandatory if you want to check your application’s return value. Because it is clear that we have to wait until the process’ end to get the return value.

RunEl /w cmd

Sometimes the UAC prompt does not appear and just blinks in the task to get attention. This is because there is no available window. In this case you can specify parameter “g”, which uses the foreground window. The UAC prompt will appear again then.

RunEl /g cmd

Of course you can also combine both parameters. However there must only be one slash.
All these combinations are the same, so it ignores the case-sensitivity and the order of the three options letters.

RunEl /wg cmd
RunEl /gw cmd
RunEl /Gw cmd
RunEl /GW cmd

The last parameter “d” takes the usual way to get elevated privileges. It runs a COM method as the elevated user, creates the process, returns to non-elevated status and then eventually waits for the process or returns immediately.
However you have to install the provided DLL RunElCOM.dll at first. This is done by using RunEl.

RunEl /install
The COM DLL was successfully installed.

Now you are able to run applications with the “d” parameter in the nearly same way as shown above.

Run /d cmd
Run /dw cmd
Run /dwg cmd
…

I say nearly because of two issues:

1. You always have to use /d parameter. Otherwise ShellExecute is used
2. A major problem of ShellExecute is that it ignores the current directory if it is used for elevation. I circumnavigated this problem by using the following command line internally.
   

   cmd /C cd /d <current dir> & <your application> <parameters>

   The disadvantage of this solution is that you do not get the application’s return value. Cmd is the main process, so we get its return value instead of <your application>.
   If you need the correct return value directly, you have to use /d switch.

In the end you can uninstall the COM library.

runel /uninstall
The COM DLL was successfully uninstalled.

If you try to run an application using runel /d you’ll get the following error message.

RunEl /d cmd
Elevation failed. (2148007959) The class is not configured to support Elevated activation.

1. Do nothing and accept this dialog
2. Wait until I buy or get the very expensive sign certificate. I tell you that it will last a really long time.
3. Use your own certificate to sign the file

Download and Sourecode:

You get the newest version of RunEl in the JWSCL Download section of RunEl.

RunEl is also available through Subversion repository:

https://jedi-apilib.svn.sourceforge.net/svnroot/jedi-apilib/jwscl/trunk/examples/runel

You can browse the repository or download it with a Subversion client.

Please send bugs to mail@delphi-jedi.net , the mailinglist or the forum.

These are the subjects:

1. Part I: The Primer
2. Windows API calls are just calls to dynamic link libraries
3. Loading a dynamic link library
4. Dynamic loading at runtime
5. Resource only dynamic link libraries
6. Stack usage and dynamic link libraries
7. Callback functions
8. The Hook functions
9. Data storage in dynamic link libraries
10. Instanced addresses and thunking
11. Part II: Getting our hands dirty