Welcome to my Exjobb Blog!

Hi Everyone!

I have setup this blog for my exjobb (Masters Thesis) on the topic of “Security and Privacy on U3 Platform”. If that interests you please do not hesitate to comment on or contribute to this blog.

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.

Summary

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.

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.

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).

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.

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.

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.

Programming Custom Hardware for Windows – Points of Interest

Points of Interest

• Short is a 16-bit integer in Win32 C++ whereas int is 32-bit integer in Win32 C++ use (short) to force returning 16-bit integer back to VB. So as you’ll notice in the function InPort and OutPort I’ve used this convention.
• There exist similar functions to _inp( ) and _outp( ) that have capacity to read words and double words from the specified port. Maybe if you’re writing an I/O intensive application, for instance, a Data Acquisition card you might consider using them by changing the code in DLL appropriately.
• If direct I/O is not achieved through the giveio driver there are other system APIs that’ll allow you to do so but the process becomes very slow (approximately 20 times) so it’s worth considering the use of GiveIO driver.

The VB Client Program
The sample program to use this DLL is developed using Visual Basic 6.0 and with a quick look at the source you’ll know how can you perform I/O using this DLL. You’ll see the exports InPort, OutPort, GetDriverStatus, and GetDLLStatus in action with their usage.

Conclusion
So finally we’ve developed a library that’ll ease development of hardware accessing applications in VB and other RAD application development tools that may consume a DLL. I would not say that it’s the most efficient way but certainly the most straightforward to understand and implement. Any comments and suggestions can be forwarded to me at editor@onsmartcards.com .

References

1. Direct Port I/O and Windows NT by Dale Roberts(http://www.ddj.com/documents/s=961/ddj9605a/)
2. LoadDrv program and source code by Paula Tomlinson

Programming Custom Hardware for Windows – The Code

Here is the easy part!

Once we know what exactly what we need to do, the rest becomes easy. So I’ll now take you on a quick walkthrough of the DLL code that I’ve written.

You can always modify it for better performance or anything that you find suitable. For details about the device driver you’ll need to read the article that I just mentioned above. The code in the DLL takes some code from the LOADDRV program by Paula Tomlinson.

Even if you’re not concerned how it works and you just intend to use the DLL in your application I’d recommend browsing through the code once so that you’d be able to use it better in your own code.

The DLL contains a total of 11 Functions of which only 5 are exported (made available to applications using the DLL). First we’ll discuss the functions that are not exported and later the exported ones. I’ve named the DLL and the workspace as RADHWLib a short name for Rapid Application Development for Hardware Library. The functions that are not exported are listed below with their descriptions.

DllMain This function is special because this allows us to perform DLL specific initialization/cleanup, as the DLL is loaded/unloaded. This is basically the first function that is invoked when the DLL is loaded and we use it to determine if the hosting OS is of NT family by using the GetVersion( ) API. If it is then we install the GiveIO driver and allow for unrestricted I/O which otherwise would not allow applications to execute I/O instructions. But now the task of I/O resides with our DLL. We should allow our DLL to use the I/O instructions by using the GiveIO driver by making a call to CreateFile( ) API. This will allow our DLL to execute privileged instructions and effectively will make the application written on top of it to access hardware directly.

InitSCM This function initializes the Service Control Manager using the OpenSCManager API. This returns a handle (a 32Bit value) that we use later to perform different operations regarding driver installation and service creation/deletion. This return value is stored in a global variable in the DLL.

ShutDownSCM This function just closes the handle we obtained in the InitSCM function using the CloseServiceHandle API.

AttachDrv If Windows NT is hosting the DLL this function is invoked and this opens the giveio device just created by the device driver in it’s initialization routine. This will modify the IOPM (Input Output Port Map) so that our application, which is using our DLL, has unrestricted I/O even under Windows NT family of operating systems. This function tries to open the giveio device through the CreateFile( ) API and that in turn allows the driver to do a IoGetCurrentProcess( ) in order to access the address apace of the application using the DLL and modify the IOPM.

DriverInstall This function installs the giveio driver and returns 0(Zero) on success. You’ll notice a magic value of 0x00000431 in the DllMain code. That is because of the fact that GetLastError( ) returns this value if the driver is already installed. It returns meaningful values as documented in the header file.

DriverRemove This function removes the giveio driver provided no applications are using our DLL. You’ll notice a global variable nNumberOfApplications in the code. I’ve put this variable in a shared segment in the DLL so that this is not private to any application and holds the total number of applications that use our DLL. This can be useful if you write some code to manipulate the giveio driver.

Now we’ll take a look at the functions that are exported from the DLL. These are of real concern to the developers because if a function is not exported it can’t be invoked by any application that uses it.

OutPort This function is used to output a byte to a port. It takes two arguments the port number and the value to write to port. It internally uses the C run-time library _outp routine to do the real I/O and returns the value it gets back from it. As per the MSDN, the value that _outp returns is the data written to the port and that there is no error code.

InPort Just as with OutPort( ) this function reads a byte from a port specified in the function argument and returns it. It doesn’t return any error code. It uses the CRT function _inp( ) for its implementation. The input value can be any unsigned short integer in the range 0 to 65,535 because the function _inp( ) is capable of reading byte, word, or double word from the specified port. (See points of interest for details)

DoDriverAction This function takes DDA_LOAD or DDA_UNLOAD as it’s single argument and does the job of Installing or Uninstalling the giveio driver on request. It returns several meaningful values as documented in the header file. For making it clear I’d list them again here in a format like:

Return Value
Value
Meaning

DRIVER_ALREADY_INSTALLED
100
Driver is already installed

DRIVER_INSTALL_SUCCESS
101
Driver installed successfully

DRIVER_INSTALL_FAILURE
102
Driver installation failed

DRIVER_ALREADY_UNINSTALLED
103
Driver already Uninstalled

DRIVER_UNINSTALL_SUCCESS
104
Driver uninstalled successfully

DRIVER_ININSTALL_FAILURE
105
Driver uninstallation failed

DRIVER_NOT_INSTALLED
106
Unknown ERROR: Driver not installed

DRIVER_IN_USE
108
Driver is in use and nNumberOfApplications is not zero

GetDriverStatus This function returns TRUE or FALSE depending on whether it is loaded or not. 0 implies not loaded and 1 implies that it is loaded.

GetDLLStatus This function returns the number of active applications that are using our DLL. As this returns a value that is kept in a shared section in DLL the value is transparent to all applications when this function is called.

Programming Custom Hardware for Windows – The Design

In order to meet all the requirements above and to get all the questions answered we need to design one solution that we can reuse on application-by-application basis. In the figure below (Figure 1) you can see the conceptual representation of the link between a DLL and a process using it. What we need to do is to exploit this flexible architecture!

What happens behind the scene is that the DLL is loaded as a separate module in the memory and is mapped in the address space of each process that loaded it. There can be n number of processes using a DLL at the same time. So what advantage do we get? Trust me its more than just one!

• First, by careful design of the DLL we can make it reusable by different application. For example if we place the basic functionality of Just Reading and Writing to ports we can use it probably in any application in Visual Basic if required.

• Secondly, if somehow we can make the DLL execute I/O instructions correctly It’s not possible to execute I/O instructions (or, I should say, any of the instructions marked privileged in a user mode process on NT family of systems), then any of the applications that link to our DLL for performing I/O would be able to perform I/O as they’d do on Windows 95/98 operating systems without generating an exceptions.

On the x86 CPU (above 386) family the instruction set contains a set of instruction marked privileged and the hardware also provides four different privilege levels in which code can execute, generally known as Ring0 through Ring3. Windows 95 and 98 doesn’t make use of these advanced features because the design goal of Windows 95 was not robustness and security but to get the system running with minimal resources. On the contrary, the Windows NT or any member of NT family uses these privilege levels for secure execution of code and defines two modes for code execution namely, the user mode and the kernel mode. The Kernel mode is implemented using the Ring0 and the User mode is implemented using the Ring3. As the applications we create run in the user mode or as Ring3 code it doesn’t have the permission to execute I/O instruction and if an attempt is made a privileged instruction execution exception is raised terminating the program. For more details you can refer to the article by Dale Roberts on Direct Port I/O and Windows NT published in DDJ may 1996 issue.