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.

The name of the API is IFileIsInUse, an interface. It resides in Shobjidl.h, Shobjidl.idl and newly in JwaShlObj.pas. This is the translation:

{$IFDEF WINVISTA_UP}
const
  IID_IFileIsInUse: TGUID = (
    D1:$64a1cbf0; D2:$3a1a; D3:$4461; D4:($91,$58,$37,$69,$69,$69,$39,$50));

type
  {$ALIGN 4}
  tagFILE_USAGE_TYPE = (
    FUT_PLAYING = 0,
    FUT_EDITING = 1,
    FUT_GENERIC = 2
  );
  FILE_USAGE_TYPE = tagFILE_USAGE_TYPE;
  TFileUsageType = FILE_USAGE_TYPE;

const
  OF_CAP_CANSWITCHTO     = $0001;
  OF_CAP_CANCLOSE        = $0002;

type
  IFileIsInUse = interface(IUnknown)
    ['{64a1cbf0-3a1a-4461-9158-376969693950}']
    function GetAppName(out ppszName: LPWSTR) : HRESULT; stdcall;
    function GetUsage(out pfut : FILE_USAGE_TYPE) : HRESULT; stdcall;
    function GetCapabilities(out pdwCapFlags : DWORD) : HRESULT; stdcall;
    function GetSwitchToHWND(out phwnd : HWND) : HRESULT; stdcall;
    function CloseFile() : HRESULT; stdcall;
  end;

{$ENDIF WINVISTA_UP}

The interface can be used as a client and also can be implemented by a server. A client usually checks if a file has a lock and retrieves a pointer to this interface to access the methods. A server usually holds a lock on a given file and implements the interface to provide the methods to the client. This article will discuss only the client side.
You see that this API only works if both sides do their jobs. A process that locks a file must also implement this interface and register it, so a client can receive a status information. There is no direct link between a file lock and the process name. If a process holds a lock on a file but does not implement the interface you are on your own again. 
Eventually, this is only a shell helper for the nice Windows Explorer deletion dialog.

  IFileIsInUse = interface(IUnknown)
    function GetAppName(out ppszName: LPWSTR) : HRESULT; stdcall;
    function GetUsage(out pfut : FILE_USAGE_TYPE) : HRESULT; stdcall;
    function GetCapabilities(out pdwCapFlags : DWORD) : HRESULT; stdcall;
    function GetSwitchToHWND(out phwnd : HWND) : HRESULT; stdcall;
    function CloseFile() : HRESULT; stdcall;
  end;

The methods of the interface are really easy to understand.

• GetAppName retrieves the name of the process that holds the file. It can be any chosen name by the application designer. To get the name use always a PWideChar and don’t forget to free it with CoTaskMemFree (it uses the interface IMalloc). Don’t forget to check for the result. If you like exception you can also rewrite the code using safecall (convert the function to a procedure then).
• GetUsage returns the reason why the file is locked. It can be one of the enumeration constant of  TFileUsage. Either it can be playing a video or music or editing a file. If these are not sufficient the value FUT_GENERIC must be used. Maybe there will be more values in future.
• GetCapabilities returns a set of flags in a DWORD. They define whether the file can be closed (OF_CAP_CANCLOSE) by calling CloseFile or the we can put the application into foreground (OF_CAP_CANSWITCHTO). Be aware that you should inform the user that you are about to switch the window. Otherwise she could get nervous about her missing application window. Switching the window can be done by SetForegroundWindow. But your application must have a focus (and some other rules, see MSDN SetForegroundWindow) to switch the window; otherwise nothing happens.
• GetSwitchToHWND returns a window handle of the other process. Only use this handle to switch to the window. You don’t really know what window is returned here. Don’t try to close it or anything else because this is just bad behaviour. At all costs, check the return value. Otherwise you don’t know whether the returned window handle is valid or just an random number. In worst case it is an existing window from your process. Well, COM rules tell us to nullify the out parameters but usually it is better to check.
  Of course, the call is only valid if GetCapabilities returns the bit OF_CAP_CANSWITCHTO.
• CloseFile implements the server side of closing the file. The call is only valid if GetCapabilities returns the bit OF_CAP_CANCLOSE. Well, this is really nice. However, don’t trust it! Always recheck the lock on the file instead of continuing blindly.

To retrieve an interface on the file you have to lock it first. Either you download and compile the MSDN example IsFileInUse or you open up an application that implements the interface (e.g. a PDF Reader, MS Office).

The next step is to know where the locked files are placed. The location is the running object table, short ROT (ActiveX.GetRunningObjectTable() retrieves it). It is a global* (on machine) table that holds running COM objects. You can implement your own interfaces and put it in this table. Because interfaces can be arbitrary in its structure and reason to be,  they are attached to monikers (IMoniker) which describe them uniquely. There are several types of monikers like class, item and file moniker (more information provides IMoniker in MSDN). We are interested in the latter only.
So the whole work is an enumeration over all monikers in the ROT.  Usually there are not that much in there (I got 5 here). Each moniker is checked for its type (IsSystemMoniker) and if it is a file moniker (MKSYS_FILEMONIKER) the path is compared to the input parameter FileName. Honestly, I cannot tell why there is a comparison of the prefix at first followed by a comparison of the moniker itself, sorry. 
The object itself is retrieved from the moniker by GetObject. It may fail with E_ACCESS_DENIED so a check is done using Succeeded. In the end, we can try to retrieve the IFileIsInUse interface. There may be such a file registered but without the implementation of the interface, thus an additional check.

I didn’t create this whole source by myself. In fact, there is a FileIsInUse example in MSDN that is the base of this article. The original source is located in the docx file in the download. The example FileIsInUse will create a server.

function GetFileInUseInfo(const FileName : WideString) : IFileIsInUse;
var
  ROT : IRunningObjectTable;
  mFile, enumIndex, Prefix : IMoniker;
  enumMoniker : IEnumMoniker;
  MonikerType : LongInt;
  unkInt  : IInterface;
begin
  result := nil;

  OleCheck(GetRunningObjectTable(0, ROT));
  OleCheck(CreateFileMoniker(PWideChar(FileName), mFile));

  OleCheck(ROT.EnumRunning(enumMoniker));

  while (enumMoniker.Next(1, enumIndex, nil) = S_OK) do
  begin
    OleCheck(enumIndex.IsSystemMoniker(MonikerType));
    if MonikerType = MKSYS_FILEMONIKER then
    begin
      if Succeeded(mFile.CommonPrefixWith(enumIndex, Prefix)) and
         (mFile.IsEqual(Prefix) = S_OK) then
      begin
       if Succeeded(ROT.GetObject(enumIndex, unkInt)) then
        begin
          if Succeeded(unkInt.QueryInterface(IID_IFileIsInUse, result)) then
          begin
            result := unkInt as IFileIsInUse;
            exit;
          end;
        end;
      end;
    end;
  end;
end;

Conclusion

This whole API has some caveats

• This API relies on a server that registers an interface in the ROT honestly. If an application doesn’t do the effort, you will be unable to aquire the name of it.
• If you lock a file on a shared folder and you want to access the very same file on the local file system, you cannot determine the process if you access the shared folder from localhost. The reason is Windows itself. Windows is the provider of the file to the outer world (even if it is a loopback) so Windows Explorer shows “System” as origin. In the ROT you will see the the UNC path instead of the local file system path. Thus the comparison and our function will fail.
• *Security: A ROT is not really global. In fact, there are several ROTs in the system. ROTs are divided by a user and then the mandatory integrity control (MIC) or integrity levels (IL) high, medium and propably low (didn’t check). If you run as a user, your processes get an medium level and as an Administrator you’ll get an high integrity level. A server that runs with an medium integrity level will only be allowed to register itself into the medium ROT. So it must be started at least once as Administrator to be allowed to create some Registry keys for COM (LOCAL_MACHINE\Classes\AppID\guid). In this way it will be available in all ROTs if it wants. Unfortunately, this is not the end. On a multi user system, every object in a moniker has a security descriptor that tells COM who is allowed to access it. If Alice wants to access an object in the ROT that was created by Bob, Bob has to explicitily grant Alice access to it. By default the security, which allow access to SYSTEM, Administrators and the creator, is copied from the global COM security settings and can be changed either in the registry for an AppID, at process startup or for each registered object by the server. JWSCL provides all of them in JwsclComSecurity.pas (only Subversion trunk and >= 0.9.4). In this way a server can change the settings to, say, allow all authenticated users access to the object.

Downloads

You can download the example file from the Subversion directly.

https://jedi-apilib.svn.sourceforge.net/svnroot/jedi-apilib/jwapi/trunk/Examples/FileIsInUse/Client/FileIsInUseClientExample.dpr

Sequel

The next article discusses the the implementation if the interface IFileIsInUse.

You may read on if you ever wanted to…

1. have this cool progress bar feature in the taskbar.
2. have an overlay icon onto your application’s icon in the taskbar.
3. multiple tabs for each window or control of your application in the taskbar.
4. have thumb buttons inside the preview of your form (like the Windows MediaPlayer).

You want your application to look like that?

Are you using Windows 7? What a lucky (wo)man you are.

The guys from TheUnknownOnes just released some components to use the new features introduced in Windows 7. 
Of course, these components are based on the JEDI Windows API. At the moment (until the next release of JWAPI), you’ll have to checkout the trunk of the JWAPI in order to get the code compiled.
To get these components, checkout the source out of their svn repository.

And if you want to discuss something about them in German: use this thread.

A first short demo was published here. Stay tuned for some more.

Of course we need a tool function that starts our service

Finally we can adjust the main application to install, uninstall or run the service.

Visit the Get Service site on SourceForge for more information like pricing.

The SetThreadDesktop function will fail if the calling thread has any windows or hooks on its current desktop (unless the hDesktop parameter is a handle to the current desktop).

Though there is a workaround to make VCL work with SetThreadDesktop and SwitchDesktop. The Application variable defined in unit Forms must be freed and then renewed. Here is the correct order :

1. Close all your forms so the Application is going to quit.
2. Free the Application instance in your DPR file.
   Application.Run;
   Application.Free;
3. Then call SetThreadDesktop and SwitchDesktop
4. Recreate the application object – now on the new desktop:
   Application := TApplication.Create(nil);
   Application.Initialize;
5. Call all the usual stuff that has to be done to show your forms

…follow the same way as described to get back to the original desktop and forms (in this order!). However this has to be done in the main project file (DPR) (except you’re going to source it out) because you cannot just free Application in the event method of a button click. You have to shutdown your application (not your process) and continue right after :

In this way the process does not shut down and you can use VCL on one desktop at a time.

A second possibility is to use VCL on one desktop and NonVCL on the other. However in this way you have to create a new thread and use your own message loop (located in the new thread). Then you can call SetThreadDesktop in this thread and show the NonVCL windows.

A third possibility is to execute another or the same application with CreateProcess. This function allows you to specify the target desktop name for the new process in lpDesktop of the TProcessInformation structure.

JWA declares it as followed:

The function returns an identifier (not a handle) and also may set lpdwProcessId to the identifier (again not a handle!) if it is not nil. Be aware that identifiers aren’t handles, so you must not close them by using CloseHandle. Identifiers are only numbers that makes an object distinguishable from other objects of the same type.

Tell me how you liked this blog entry by adding a comment.

Then you can submit the headers to us by mail.

You must setup JEDI API first before you can start with JWSCL! Otherwise if you set Delphi source path to include JwaWindows.pas you’ll get an error like:

Incompatible types: JwaWindows.XXX and JwaWinNT.XXX

JWSCL works with JwaWindows from the JEDI API. However this only works with some compiler directives defined in the packages in the package folder of JEDI API. Use these packages to compile and create a JwaWindows.dcu file.
ERROR: Adding the source path of JWA (folder Win32API) to your project options and then use JwaWindows and JWSCL does not work!

1. Adapt this source path to include some necessary files for JWSCL:

"path to JEDI API"\"version"\COM
e.g. C:\Projects\jwapi\2.3\COM

2. Make sure that you have added the path of JwaWindows.dcu to your project or general library path. After this step you can also add the source path to the JWSCL source folder (\source) to the project or general library path so all projects can easily use JWA and JWSCL.

3. Eventually you can start using JWA and JWSCL in the simplest way: Just add the units to your uses clause.

4. Consider to update your JEDI files using Subversion (with a Subversion client like TortoiseSVN). With TortoiseSVN you can just right click on the JEDI JWSCL folder and hit “SVN Update” (not Checkout or Import!). The code is then updated.

Source and Library Path Settings – Overview

This is a quick overview of the path settings you can use.

• Replace <path> with your absolute path settings to your download location of JWA and JWSCL.
• Replace <version> with your downloaded JWA  and JWSCL, e.g. by 2.3 and 0.9.3 or even trunk.

The JWSCL sources can be added in this way:

These settings are also available as documentation in the Subversion Repository.

You are finished here or you can read on to get some more information:

Be aware that the order of including units may change Delphi’s behavior if an identifier with the same name is declared in several units.

1. JwaWindows instead of Borland’s Windows unit.
2. JwaVista for Vista enhancements. (This unit is no more available in newer versions than 2.2)

Some types in these JWA units are duplicate. JwaVista recreates and extends them to add Vista support. Example:
The new _TOKEN_INFORMATION_CLASS type from JwaVista.pas has several new additions:

However, if you add JwaVista and JwaWindows in this order into your uses clause you will only use the types from JwaVista. Some functions in JwaWindows or other libraries that use JWA won’t not know these types. To get the correct type you have to explicit adress the JwaWindows type.

JWSCL does not really need an order of its units.

Newer versions of JWSCL and JWA do no more support JwaVista.

Subversion

Sourceforge gives a short introduction how you can access the Subversion repository of the JEDI project.

The download packages (from Sourceforge) contain Subversion information so you can use your subversion tool to just update them. (Tortoisesvn: Right click the JWSCL folder and choose Subversion Update)

To get the latest release updates you can use this path with your Subversion client. Be aware that new versions (currently 0.9.3) can make this path obsolete (but still valid). The downloadable release packages are already provided with Subversion information so you can just update them to get the newest updates.
Click on the turtle to checkout the repository with TortoiseSVN.

https://jedi-apilib.svn.sourceforge.net/svnroot/jedi-apilib/jwscl/branches/0.9.3

There is also a development branch that contains new untested features. Use it with care:

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

1. Single units use:
Single units are included into your project by adding the JEDI API source folder to your Delphi search path. Then you can use the units like

Be aware that some JEDI API examples use the single units approach. So if you want to compile them you have to add the folders to Delphi source path.
However, it is possible to use it in combination with the JwaWindows.dcu approach.

Add these folders to your Delphi source path (located in the JWA folder)

• \Common and
• \Win32API
• \COM

Thats all.

We suggest to add these paths to your global source path of Delphi. To do so open the options dialog of Delphi (menu Tools -> Options) and navigate to the tab Library or Library Win32 (in newer Delphi).
There you add the three folders to the library path edit. Of course, you need to add absolute paths here like shown in example.

Example

So you saved the download “JEDI API 2.3 and JEDI WSCL 0.9.3.zip“  in this location

C:\Program Files\JEDI\

The zip file contains two projects located in folder jwa and jwscl. So you need to find the folders above by following the directory structure to :

C:\Program Files\JEDI\jwa\branches\2.3

In this folder you’ll find the folders Common, Win32API and COM that you need to add to your Delphi source path.
(You must not add qotation marks (“) since the space in Program Files is not a separator.)

2. JwaWindows.pas (also for the use with JWSCL)

There is also the possibility to use only one file that includes all other Jedi API headers. It is called JwaWindows.pas.

Do not mix up the Jwa units like this:

It is possible to do so but in this way you will create duplicate and incompatible identifiers which will also collide with JWSCL.

We also suggest that you compile the file at first and then use the binary dcu file instead of the source directly. So you should add the location of JwaWindows.dcu to your Delphi source path to avoid rebuilding the file everytime you rebuild your project.

So again:
There are packages in the jwapi\Packages folder for the different Delphi versions. If not just use an older package version. That should suffice.

You can load the project group for your Delphi version and compile the different package types :

1. static debug = for static linked functions and debugger information and no optimization
2. static release = for static linked functions and optimization
3. dynamic debug = for dynamic linked functions and debugger information and no optimization (recommended for using with JWSCL for debugging)
4. dynamic release = for dynamic linked functions and optimization (recommended for using with JWSCL in releases)

The project group contains all four package types and are predefined to save the output in different folders.

After a successful compilation, copy the folder or point the compiler path to the directory of your choice e.g. \jwapi\trunk\Packages\d7\bin\debug\dynamic . Now your Delphi will use the dcu files instead of the source files.
The packages contains JwaWindows AND jwaVista. Both units must be included in a uses clause. JwaWindows does not contain jwaVista!

The JEDI Windows Security Code Library uses the second choice (JwaWindows.pas and JwaVista.pas (JwaVista is deprecated in future versions)) only. See here how to setup JWSCL. Furthermore it is recommended to use any of the dynamic linking packages for JWSCL.

Source and Library Path Settings – Overview

This is a quick overview of the path settings you can use.

• Replace <path> with your absolute path settings to your download location of JWA and JWSCL.
• Replace <version> with your downloaded JWA , e.g. by 2.3 or even trunk.

These settings are also available as documentation in the Subversion Repository.

Subversion

Sourceforge gives a short introduction how you can access the Subversion repository of the JEDI project.

The download packages (from Sourceforge) contain Subversion information so you can use your subversion tool to just update them. (Tortoisesvn: Right click the JWA folder and choose Subversion Update)

To get the latest release updates directly you can use this path with your Subversion client. Be aware that new versions (currently 2.2a) can make this path obsolete (but still valid). The downloadable release packages are already provided with Subversion information so you can just update them to get the newest updates.
Click on the turtle to checkout the repository with TortoiseSVN.

https://jedi-apilib.svn.sourceforge.net/svnroot/jedi-apilib/jwapi/branches/2.3

There is also a development branch that contains new untested features. Use it with care:

https://jedi-apilib.svn.sourceforge.net/svnroot/jedi-apilib/jwapi