Mix 'n Match DLLs - Visual 'C' & Borland 'C'

This article is a series of notes which may be useful to anyone wishing to link code built using two different development environments - in this case between Visual Studio (V6) and Borland C++ (v5 - the old version NOT Builder) although I imagine many of the techniques can be applied to newer and in fact different compilers.

Much of Playout is developed (still) under BC5 because it still serves my needs and I prefer it over the VC environment. However I have had to often link in 3rd party code which is either pre-built or has projects in the VC format so it has been necessary to cross this hurdle without porting the whole lot to VC (and lose some of the features that only BC offers).

Static Code Linkage

Compilers (and assemblers) untimately convert source into object files (.obj), these are then linked together by the linker to form the final executable. Often 3rd party packages create static libraries - which are simply a collection of .obj files which may be linked with your application. The first hurdle here is that the format of the object files differs between compilers - VC produces them in COFF format whilst BC writes them in OMF. The linkers for either environment will fail then because they cannot read the files (and by inference any static library produced by the 'other' toolset). This first problem is actually not to difficult to solve - you can obtain tools to convert between either format (COFF2OMF for example and I think versions of Borland Builder include this tool as standard).

The story doesn't end here however because this simply serves to highlight another problem - that of the underlying run time library (RTL). Unless you are converting code which doesn't make use of any of the 'C' (or langugage equivalent) RTL (calls such as 'printf', 'scanf' etc.) odds are the application still will not link (or if it does will crash in use) because of the differences between the implementation of these. The RTL is part of the development environment, created independently by each vendor so 'printf' for example under Borland will be implemented differently to VC. This includes naming conventions and the underlying data structures used by each RTL. For this reason then, it's really not worth trying to statically link code together in this manner. Fortunatly there is an alternative - using DLLs. Static libraries can easily be converted to DLLs, simply by putting them in a DLL project and exporting the necessary functions with a module definition (.def) file.

DLL Linkage

The easiest way to link code build by different toolsets is to build the code into a DLL and have the other compiler load it (either statically or dynamically). Here I'll discuss linking VC build DLLs with Borland EXEs (because this is probably more common) but will also touch on the other way around later on.

Calling Convention

If you have access to the sources of the code you wish to use, its worth declaring all the functions to be exported to use the WINAPI (or __stdcall) convention. This is the Windows 'standard' and ensures code built under any toolset will be callable from most Windows applications (this includes things like Visual Basic [VB] used under MS-Office etc.). If you've ever built GPL or Open Source software from the likes of Sourceforge you'll find many of the builds include VC projects which create DLLs and explicitly export the functions (normally with a #define like DLLEXPORT or similar) in this format for Windows platforms:

__declspec(dllexport) WINAPI void FuncA ( int A, int B ) ;

Static (DLL) Linkage

When the DLL is built, accompanying it will be an import library. This is then included in the project which will use the DLL (top level .EXE) to inform the linker where the unresolved symbols are located. However as with static libraries VC and BC write their import libraries in differing formats making them unreadable by the other toolset. As before, it is possible to convert the library however it is more straightforward with BC to simply create the library from the DLL using the IMPLIB tool.

This is a command line tool with the syntax:

IMPLIB <name of lib> <name of dll>

so is invoked:

IMPLIB mydll.lib mydll.dll

This creates the import library (mydll.lib) from the DLL (mydll.dll) which was built under VC. Include this library into the BC project and all should be well. Make sure though that the declarations for these functions (normally in header files) as seen by the Borland compiler also has the WINAPI declaration in front of them.

'C' Calling Convention

Code not explicitly exported as WINAPI will default to the usual 'C' calling convention. Also, if you need to export functions with variable argument lists, the 'C' convention needs to be used as WINAPI does not support this.

Historically, 'C' calls internally have an underscore prefixed to each function name (presumably to differ them from say Pascal symbols with the same name). Thus:

void FuncA ( int A ) ;

is exported as:

_FuncA

BC adopts this approach however VC does not add the underscore.

This then causes a problem because the BC linker will be looking for a function named (_FuncA) in the import library whereas the library will only have (FuncA) listed in it. So the link fails.

There are two solutions to this - the first is to adopt dynamic linking using the LoadLibrary/GetProcAddress approach. Here you can supply the VC exported function name in the parameter passed to GetProcAddress.

The second approach is to drop the import library and use a little known feature of module definition files - the IMPORTS directive. Oddly, VC has dropped support for this which is strange because it is a useful feature.

The IMPORTS directive allows you to explicitly import functions from DLLs using the following syntax:

<internal name> = <dllname>.<dllfunc>

Thus you can include lines as follows:

_FuncA = mydll.FuncA

This effectivaly maps 'FuncA' to '_FuncA'. Remember, you don't need an import library (.lib) for this approach.

This approach can also be used to gain access to new Win32 API calls that were not available when the toolset was released. For example, the API call 'GetDiskFreeSpaceEx' is not available in the earlier releases of BC5. However you can still call it if you know the syntax and library to use:

From MSDN - GetDiskFreeSpaceEx

Requirements

BOOL WINAPI GetDiskFreeSpaceEx(
  LPCTSTR lpDirectoryName,
  PULARGE_INTEGER lpFreeBytesAvailable,
  PULARGE_INTEGER lpTotalNumberOfBytes,
  PULARGE_INTEGER lpTotalNumberOfFreeBytes
);

#include <pshpack8.h>    // force quadword struct alignments (VC default)
#include <windows.h>
#include "metadata.h"
#include <poppack.h>     // restore packing

// really a 64 bit return
unsigned long Test64BitProc ( int Val ) ;

void Proc ( void )
{
  LARGE_INTEGER Ret ;

  Ret.u.LowPart = Test64BitProc ( 123 ) ;
  Ret.u.HighPart = _EDX ;

  printf ( "%08x\n", Ret.u.LowPart ) ;
  printf ( "%08x\n", Ret.u.HighPart ) ;
}

#ifdef  __BORLANDC__  // jrb: for Borland v5.01 w/out 64 bit ints
typedef short FLAC__int16;
typedef int FLAC__int32;
typedef LARGE_INTEGER FLAC__int64;
typedef unsigned short FLAC__uint16;
typedef unsigned int FLAC__uint32;
typedef LARGE_INTEGER FLAC__uint64;