November 2008 – Icetips Blog

Why duplicate symbol error?

In Clarion 6.3 build 9058, Softvelocity added a bunch of new API function information to the WIN32.LIB and WININET.LIB library files. This caused a conflict with some other LIB files that included two shared function names, DLLInstall and DLLGetVersion.

There has been a fair amount of discussion about this, some confusion about who should fix this problem and even what exactly the problem is.

The problem

The problem, in a nutshell, is that two or more LIB files include the same function name and are both or all included into the same Clarion project or application. This results in the Clarion linker throwing a "Duplicate Symbol" error when it attempts to link in the second LIB file with the duplicate function name.

Can't we change the label and use NAME() to fix it?

No. That only takes care of issues with duplicate labels in Clarion. This is duplicate symbol which means that there are two libs that contain the same API function - in this case DLLGetVersion, DLLInstall.

This could be prototyped in two different places like this:

Module('IcetipsWhatever.lib')
  IT_DLLGetVersion  ...,NAME('DLLGetVersion')
  IT_DLLInstall     ...,NAME('DLLInstall')
END
MODULE('ABWHatever.Lib')
  AB_DLLGetVersion ...,NAME('DLLGetVersion')
  AB_DLLInstall    ...,NAME('DLLInstall')
END

This will give you two different (Clarion) labels for the functions, but they will still generate a "Duplicate Symbol" errors on IcetipsWhatever.Lib and ABWhatever.Lib which both include those two symbols. So this does not solve this particular problem. However it does solve the problem of possibly duplicate labels for the same (or different) API functions prototyped by different vendors.

This is kind of like the mail man trying to delive a letter to an address only to discover that there are two houses on the same street with the same number.

So, how CAN we fix it?

There are only two ways to fix this as far as I know.

Find the offending LIB(s) and remove these two entries using LibMaker and then PLEASE report it to the producer of the LIB
Dynamically load the DLLs and skip the LIBs altogether. This is what I use in our Iceitps Utilities for apis that are not included in the OLD Win32.lib and from now on I will use that as a base so anything that was not in the old win32.lib will be loaded dynamically. We also use this method in our Build Automator to load plugin dlls.

Finding the LIB files - what tools can we use?

The problem is finding the offending LIB files. Many search utilities won't search inside binary files. The version of the excellent Clarion Source Search that I have does not do it. I highly reccommend it for searching Clarion source though! The search in Total Commander DOES find it - one more reason to get that fantastic program!

I did find one freeware tool that does search binaries (or at least the Clarion LIB files!) without problems, called GrepWin. Very easy to use, supports both straight text search and regular expressions and it is FREE;

How do we fix the LIB files?

Search for the DLLInstall or DLLGetVersion in your Clarion\3rdParty\LIB folder and any other LIB folders you can find.
When you find the LIB, first MAKE A BACKUP of it in case you make a mistake and need to start over. Do not skip this step!
Load the LIB file into the Clarion LibMaker (located in the Clarion\Bin folder - there should be a link in the Startup menu as well) and carefully locate the function name and select it in the list.
Hit the Delete button to delete the function from the list
Save the file back to the same LIB file.
Repeat for the other function name.

Recompile your app to check if the error is gone. Repeat as necessary.

What about dynamically loading the functions?

While changing the LIB files can be done by the "end-user" developer, the dynamic loading has to be coded into the product or tool that makes use of the tool and is not reasonable for the end-user to deal with. In 2007 I posted an example application and classes that demonstrate how to do this. If you are interested in loading dlls dynamically at runtime, you can download this small, simple example and try it out yourself.

Hopefully this can help some people who are struggling with the "Duplicate symbol" error in Clarion 6.3 builds 9058 or 9059:)

-- Arnor Baldvinsson

What does "Elevated" mean?

One of the differences between Vista and XP is the User Account Control (UAC) in Vista. The UAC controls who has access to what folders and files. A normal user account in Vista does not have administrator privileges. Some access requires administrator privileges, such as writing to files in the Program Files folder, accessing certain control panel applications and write to certain CSIDL folders - see my last blog about where to put data under Vista. For that, Vista requires elevation to administrator privileges and will prompt the user to elevate. The elevation prompts the user for permission to use the software or requests an administrator login.

Require elevation

The elevation requirement is controlled from within the software by the vista manifest. The Vista manifest is an XML file, just like the XP manifest, but with some additional branches, most notably the trustinfo branch. Below is the Vista manifest that we use for our Build Automator It is generated with our AddVistaManifest extension template in our Icetips Utilities.


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
   xmlns="urn:schemas-microsoft-com:asm.v1"
   manifestVersion="1.0">
<assemblyIdentity
    processorArchitecture="x86"
    version="1.0.0.0"
    type="win32"
    name="BuildAutomator.exe"/>
    <description>Build Automator</description>
    <dependency>
    <dependentAssembly>
    <assemblyIdentity
         type="win32"
         name="Microsoft.Windows.Common-Controls"
         version="6.0.0.0"
         publicKeyToken="6595b64144ccf1df"
         language="*"
         processorArchitecture="x86"/>
    </dependentAssembly>
    </dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

The important part of the manifest is the RequestedExecutionLevel. The level attribute can have one of 3 possible settings:

requireAdministrator
asInvoker
highestAvailable

Normal programs should use asInvoker. Otherwise the program will prompt for elevation every time it is run and unless that is really required it should not be done. To force elevation of a program, the manifest should be set to requireAdministrator.

Running programs

In Clarion we have been able to use the RUN statement to run external programs without much problems. However, with Vista, a problem comes up if you want to run a program that either needs to be elevated by the program running it or the program to be run is using requireAdministrator. Either way it needs to be elevated.

Unfortunately RUN cannot handle this properly. The reason is that RUN uses the CreateProcess API internally and it cannot trigger the elevation process. If you try to use RUN to execute a program that requires administrator privileges is that nothing happens! This can cause support issues that are easily avoided.For that either ShellExecute or ShellExecuteEx must be used. In addition to that, if you want the calling program to wait for the called program you need to use WaitForSingleObject to force the process to wait.

Code sample

The following code sample is from our ITRun method in the ITShellClass of the Icetips Utilities. This is the main code that optionally elevates the program using the RunAs verb for ShellExecuteEx. It will also automatically trigger elevation if the called program uses requireAdministrator manifest.

    Verb = IT_SE_Open   !! Defaults to not elevated
    If Elevate
      If SELF.IsVista
        Verb = IT_SE_RunAs  !! Elevate to requireAdministrator
      End
    End
    !SELF.ODS('  Verb = ' & Verb)
    
    SHi.fMask                  =  IT_SEE_MASK_NOCLOSEPROCESS !!ULONG
    SHi.hwnd                   =  0{Prop:Handle}             !!IT_HWND       ! UNSIGNED
    SHi.lpVerb                 =  Address(Verb)              !!Long
    SHi.lpFile                 =  Address(cCmdLine)          !!Long
    SHi.lpParameters           =  Address(cParam)            !!Long
    SHi.lpDirectory            =  Address(P)                 !!Long
    SHi.nShow                  =  IT_SW_SHOWNORMAL           !!IT_int        ! SIGNED
    !SHi.hInstApp               =                            !!IT_HINSTANCE  ! UNSIGNED
    SHi.lpIDList               =  0                          !!IT_LPVOID     ! ULONG
    SHi.lpClass                =  0                          !!Long
    SHi.hkeyClass              =  0                          !!IT_HKEY       ! UNSIGNED
    SHi.dwHotKey               =  0                          !!IT_DWORD      ! ULONG
    SHi.DUMMYUNIONNAME         =  0                          !!Long          ! Pointer to union...
    !SHi.hProcess               =  !!IT_HANDLE     ! UNSIGNED
    SHi.cbSize                 =  Size(SHi) !!IT_DWORD       !! ULONG
    !SELF.ODS('  Before ShellExecEx')
    If Not SELF.ShellExecEx(SHi)
      hProc = 0
      SELF.ODS('  ShellExecEx failed in ITShellClass.ITRun.')
    Else
      hProc = Shi.hProcess
    End
    !SELF.ODS('  After ShellExecEx')
    If hProc
      If pWait
        RetVal = IT_WaitForSingleObject(hProc,-1)
        If IT_GetExitCodeProcess(hProc, lRetCode)
          RetValue = lRetCode
        Else
          RetValue = RetVal
        End
        RetVal = IT_CloseHandle(hProc)
      End
    End
    If Not cCmdLine &= NULL
      Dispose(cCmdLine)
    End

The WaitForSingleObject is called with a handle to the running process if you want the calling program to wait for the called program. The called program will wait and practically be completely dead until the called program is terminated. When that happens the next line of code uses GetExitCodeProcess to retrieve the exit code from the called program and places it into a variable that is returned from the ITRun method.

Running with the Icetips Utilities

With the Icetips Utilities it is very easy to implement the ITRun to make running programs under Vista a non-issue. First you need to add the Global Utilities extension to your application - also to the data dll, or exporting dll so the classes are included and compiled.

In your procedure data embed you add an instance of the ITShellClass:

ITS  ITShellClass

Now you are ready to use it in the procedure:

 Code
 ITS.ITRun('"C:\Program Files\Icetips Creative\' &|
           'Build Automator\BuildAutomator.exe"',True,'/E',,True)

That is all there is to it!

Running without...

To demonstrate this and show how you can do this easily, we have uploaded a small sample app written in Clarion 6.3. It uses some of the code in the Icetips Utilities methods to let you select a program and run it, with optional parameters and option to wait for the called program to terminate. It also has a button where you can use the standard Clarion RUN statement and observe the differences under vista. I would suggest that you try to run something that requires administrator privileges - most installers do - and see what happens when you use the RUN statement and when you use the ITRun procedure instead.

You can download the ITRun.zip from the Icetips website at http://www.icetips.com/downloadfile.php?FileID=89 Please note that this is a simple ZIP file. Unzip it to a folder and read the docs.txt file in it. Compile the application and run it and try out for yourself how it works.

We have used those methods to run elevated applications, for example Web Updates for Setup Builder installs, for several years without any problems. We hope this little app helps you to get your applications running under Vista.

Our Icetips Utilities mentioned here is a collection of classes and templates for Clarion developers. They are part of our Gold Subscription plan.

The Build Automator is a developer tool to automate compiling and building applications and installs. It works with many developer tools such as Visual Studio, Delphi/RAD Studio 2008, Clarion, SetupBuilder, Inno Setup, Setup Factor and MSI Factory.

Some Interesting Links:

UAC Elevation in Managed Code: Guidance for Implementing COM Elevation

We welcome and appreciate your comments on this entry:)