Virtual Library Interfaces

Virtual Library Interfaces

Delphi provides extensive support for interoperability between Win32 and .NET applications, including COM interop through runtime callable wrappers (RCWs) and platform invoke (PInvoke). With Delphi 2005, this support has been advanced through the support for virtual library interfaces (VLI). Virtual library interfaces permit you to call routines in Win32 DLLs from your .NET applications much more easily than the mechanism provided by .NET's PInvoke.

Normally, managed code in the .NET framework can call routines in unmanaged libraries through the .NET platform invoke service, or PInvoke. With PInvoke, you import the exported routines of an unmanaged DLL by using the [DLLImport] attribute to identify the DLL in which the function is located, as well as other characteristics of the exported function.

There are several drawbacks to using PInvoke. First, using the [DLLImport] attribute you cannot resolve the DLL name or location (path) at runtime. Second, if the specified routine in the DLL cannot be loaded, for whatever reason, a runtime exception is raised.

Third, the [DLLImport] attribute is somewhat verbose and repetitive, especially when you have many routines that you are importing from a single DLL.

Consider the following two functions, which are implemented and exported from a Win32 DLL created using Win32 Delphi:

function ConvertCtoF(CentValue: Integer): Integer; stdcall;
function ConvertFtoC(FahrValue: Integer): Integer; stdcall;

A unit that imports these routines using PInvoke has, at a minimum, an implementation block that looks something like the following (assuming that these routines were exported from a DLL named Win32DLL.dll):

function ConvertCtoF; external;
[DllImport('Win32DLL.dll', CharSet = CharSet.Auto,
  EntryPoint = 'ConvertCtoF')]
function ConvertFtoC; external; 
[DllImport('Win32DLL.dll', CharSet = CharSet.Auto,
  EntryPoint = 'ConvertFtoC')]

With virtual library interfaces, importing routines from an unmanaged DLL is easier, is less prone to raising exceptions, and permits your code to resolve the name and/or location of the DLL at runtime. There are three steps to importing one or more routines from an unmanaged DLL using virtual library interfaces. These are:

Adding the Borland.Vcl.Win32 namespace to your uses clause

Creating an interface declaration where each method in the interface maps to one of the routines exported from the DLL

Calling the Supports function from the Borland.Vcl.Win32 unit, passing to it the name of the DLL (including an optional path if the DLL is not located in a location where Windows will find it), the Interface you created in the preceding step, and a variable of that interface type

If the Supports function determines that the methods of your interface map to functions exported from the named DLL, the variable you pass in the third parameter of the call to Supports will point to an object that implements the interface you passed in the second parameter. You can then use this object reference to execute the unmanaged routines of the DLL.

If one or more of the methods of the interface are not exported by the named DLL, or the named DLL does not exist or is somehow compromised, Supports returns a Boolean false without raising an exception.

Here is a sample interface that declares the two exported functions of the unmanaged DLL example used earlier in this section:

type
IWin32DLLInt = interface
  function ConvertCtoF(CentValue: Integer): Integer;
  function ConvertFtoC(FahrValue: Integer): Integer;
end;

If Win32DLL.dll is located in the mylib subdirectory of the application's executable, the following code returns an implementation of IMyWin32DLL, after which one of the methods (ConvertCtoF) of the returned object is executed:

var
  MyDLL: String;
  MyWin32DLL: IWin32DLLInt;
begin
MyDLL := ExtractFilePath(Application.ExeName) + 
  '/mylib/Win32DLL.dll' ;
if not Supports(MyDLL, IWin32DLLInt, MyWin32DLL) then
  MessageBox.Show(self, 'Could not load Win32DLL.dll')
else
  NewInt := MyWin32DLL.ConvertCtoF(100);

  Support for Partially Trusted Callers

The VCL for .NET assemblies now support partially trusted callers. A partially trusted caller is an application that does not reside on the same workstation as a managed assembly that it calls.

For example, an .exe being executed from a network share or from a URL is a partially trusted caller. By default, the .NET security model prevents a partially trusted caller from invoking unmanaged code, such as that in the Windows API, unless that caller includes the appropriate declarations and checks.

The Delphi 2005 assemblies of the VCL for .NET now include the additional security declarations and checks that permit the VCL for .NET to be called from a partially trusted caller without violating .NET security.