Security and Privacy on the U3 Platform

Be Smart with U3

DLL Conventions: Issues and Solutions

We can try to solve these problems in different ways depending on how the Visual C++ DLL was developed. Don’t worry if you don’t know about that too, because we have a lot of tools at our disposal that make it visible to us.
So in the next part of this series we’ll discuss what these Calling Conventions are and how can we identify exported symbols and the used calling convention. And later we will discuss how to solve the problem.
This article presented the roadblocks that developers encounter while a Visual C++ DLL is to be used from a C++ Builder project.
You might have noticed that we’re discussing only “How to call C style functions in a DLL” and there is not a word about classes exported by DLLs, but in future articles we shall discuss them to the extent possible. This is done intentionally because Visual C++ DLLs present more problems, because linker names for classes’ member functions are mangled. The name mangling scheme is employed in order to support function overloading.
But again, there are differences in the schemes that different vendors adopt to mangle member names. The ANSI C++ standard does not govern the specifications of how a compiler should mangle class member names. Today, in absence of a strict standard in place, all the vendors have each developed their own techniques for name mangling, and the resulting conventions are certainly not compatible. But surely we now have ways to eradicate these subtle issues.

January 29, 2007 Posted by | Uncategorized | Leave a comment

DLL Conventions: Issues and Solutions – Where is the actual problem?

In a world where several vendors compete to make fabulous developer tools, it is certainly impossible to have interoperability, especially when there are no standards in place. In short, calling a DLL produced by Visual C++ would be not much different than calling a DLL built with Borland C++ Builder. But to my surprise, Borland and Microsoft disagree on several issues regarding the techniques they follow and embed in the developer tools they produce.
For instance, Borland and Microsoft disagree on file formats for intermediate object files (.OBJ files) and import library files (Visual C++ uses the COFF library format while Borland uses OMF). COFF stands for Common Object File Format and OMF stands for Object Metafile Format. This means that you can’t add a Microsoft generated import library to a Borland C++ Builder project. But we developers owe a big thanks to Borland for providing the IMPLIB (Import Library) utility, which means the file format differences are no longer an issue of great concern.

Further the two C++ compilers produced by these two companies also disagree on naming conventions of the exported symbols produced as a result of linking the final DLL or Libraries. This is the root cause of most problems which we developers face while we try to bridge the gap between the two.

Each exported function/symbol in a DLL or OBJect file bears a linker name. The linker uses this linker name to resolve function references that remained unresolved during compile time in order to make the final output executable or DLL. The linker generates an unresolved external error if it is unable to find a function with a linker name in the program’s code itself or in the list of import libraries provided to it.

As far as the linker names are concerned, Borland and Microsoft compilers disagree on the scheme that is used to generate the linker name. For example, the Microsoft Visual C++ compiler sometimes decorates exported __stdcall functions, while the Borland C++ Builder expects that only imported __cdecl functions be decorated. If you don’t understand what __stdcall and __cdecl mean, don’t worry; we’ll be discussing them shortly in detail.
So “How does that creates problems for us developers?” might be the question coming to your mind. Okay, let’s talk about that in plain words. Say you’ve created a DLL in VC++ that exports a function Foo() which uses the __stdcall convention. The linker name generated for this function looks like _Foo@4. When you try using this DLL in the Borland environment, the Borland linker first expects the .lib file (import library) to be in OMF format, and then looks for a name Foo only because it is not expecting to see a decorated name for a function using the __stdcall calling convention. Okay I told you that __cdecl and __stdcall are calling conventions, but let’s leave them here before we discuss them in detail. Next the Borland compiler reports an unresolved external for the name Foo.

January 29, 2007 Posted by | General Smart Cards | 1 Comment

DLL – Some Terms to Know

A Dynamic Link Library (DLL) is a file that contains C Style functions or whole C++ classes that you can use for developing your applications to lessen your development effort and to save time when testing problems in a normal SDLC.
Any function that is visible outside the DLL and is intended for use by external client applications is said to be an export from the DLL. Consequently any client using this function from the DLL is said to have an import from the DLL. Sometimes we call all exported C Style functions and Classes to be exported symbols as a collection.
An import library is a file with a .lib extension and provides the compiler with enough information to resolve function call references if you choose to link implicitly at compile time. You may choose to load the DLL at runtime (using LoadLibrary API) and resolve and call functions then, by locating them in the DLL (using GetProcAddress API).
The import library is the key element if you’re linking implicitly, and in most cases this poses a greater problem, as we’ll see shortly. Also required is the header file and the DLL you’re trying to use.
So now let’s recap all we’ve discussed until now and then we shall move to analysis of the problem. While using third party DLLs in an environment which poses certain problems in the usage, we start with three elements (please note that we’re stretching only to implicit linking, and that too with DLLs exporting C style functions, and explicit linking is not in the scope of our discussion right now. But we shall discuss it in the next article of this series):
  • The DLL built with any tool and exporting C Style functions only.
  • A header file that provides prototypes to all the functions exported by the DLL.
  • The import library that is emitted by the compiler when the DLL is built.
With these three ingredients we can have all the functions and classes at our disposal and use them freely in our code. We shall have real life problems so that we can see it all happen; so we’ll be using a DLL built with Microsoft Visual C++ 6.0 in Borland C++ Builder 6.0. This case will be similar to the problem mentioned above (the PDFLib case).

January 29, 2007 Posted by | Uncategorized | Leave a comment

DLL Conventions: Issues and Solutions – A simple problem

Before we move on I’ll explain a generic problem that you might have experienced first hand in your career as a developer, but dismissed because someone did that for you, or you took an entirely different approach to solve that problem.
Say you just downloaded the PDFLib PDF library and purchased the license to it. Prior to your purchase, you tried the sample applications and they all just compiled happily. Now when the development started, you realized that you’ll be developing the applications that use the library in Borland C++ Builder 6.0 rather than Visual C++ 6.0, in which all the samples were written and compiled. If you’ve been through such a situation you can surely appreciate the description of the problem above.
Let’s now analyze and find the cause and solution to the problem. If you’re reading this just to gain some knowledge, then you’ll surely find the basic terminology discussion beneficial.

January 29, 2007 Posted by | Uncategorized | Leave a comment

DLL Conventions: Issues and Solutions

As a developer we often find ourselves surrounded by problems that actually have nothing to do with our productivity or even the project we’re working on. One of them is the issue of compatibility between the Dynamic Link Libraries developed using different tools. Recently, while working on a project, I faced this problem, and in this article I’d like to present my analysis. We’ll also talk about writing DLLs that are easy for us develop and don’t cause others to face similar problems when they try to use them.
I assume that you’re familiar with using Microsoft Visual C++ and Borland C++ Builder, because these are the tools I’ll use to expose the nature of problem and the solution.What is the need to do so anyway?
Some people may argue that they can’t imagine why someone would ever need to use DLLs written using one tool in some different tool. An elegant solution would be to have a special build of the DLL for every other tool that can consume the DLL; but, like many other people, I don’t find it appealing. Moreover, there are circumstances where you’re bound to work on these issues, such as:
-You do not have the source to the DLL, or even the import library. Don’t know what an import library is? Don’t worry; we’ll talk about that shortly.
-You have existing applications to maintain and, to add a specific feature, you company has purchased a library. The source is, of course, not available, and you still need to figure out how to call the function when linker gives up saying there are unresolved externs.
I can add more to this list but I believe the above two points give you the idea. So let’s see what the problem is, apart from understanding the terminology used in the context and finding a working solution for all of these problems. What I explain here will be specific to the tools I’ve been using, but I’m sure problems related to other tools won’t be much different.

January 29, 2007 Posted by | Uncategorized | Leave a comment

Dynamic Link Libraries

Have you ever experienced compatibility issues between Dynamic Link Libraries developed using different tools? It is not irrational to use a DLL developed with one tool in a different tool; sometimes there are very good reasons to do so. This first article in a three-part series explaining how to resolve the issues presents the problem plainly.


January 29, 2007 Posted by | Uncategorized | Leave a comment