Backward compatibility in dlls

Question

I do have three dlls.

• a.dll - released many years ago
• b.dll - released not so many years
• c.dll - released shortly

Each one contains the same function - unfortunatelly with different parameters. so I do have the following Methods

aMethod(param1)
aMethod(param1, param2)
aMethod(param1, param2, param3)

My Task is to make a new dll (or new dlls) wich is backward compatible. But as far as I've learned from Google there is no possibility to overload methods in a dll.

Does any one have a tip how I can solve this problem elegantly?

Answer 1

Until I know you can use method overloading, you only need to implement the previous and new versions in the same dll. In Delphi you need to use the overload directive. See this link:

http://delphi.about.com/od/objectpascalide/a/overloading.htm

Answer 2

Make this method more generic - change it to something like that - I'm not familiar with Delphi, so this example is in C#:

aMethod( int version, object args)

or in C:

aMethod (int version, void** args)

Then according to the version you can use casting. Note that args can be also a collection object.

HTH.

Answer 3

You can overload function signatures in a DLL. However, the function names exported from the DLL must be unique - this is a Windows requirement, not a Delphi requirement. So, declare your functions in Delphi as overloads, but make sure they are exported with specific, unique names that you define. Clients that import from your new all-in-one DLL will need to import using those unique names you defined.

The default behavior in Delphi is that exported functions are exported by the name of the function, plain and simple. If you want to do overloads, you need to get more involved and define the export names yourself.

Note however that this will not produce a DLL that can be dropped into an older application that is expecting your a.dll. This solution is backward compatible for source, but not backward compatible for binaries.

You will most likely not be able to create a new DLL that is binary compatible with all three of your past DLL versions, because the old exe binaries are referring to the same function name but expecting different behavior (different param lists).

Note also that if your three dll versions actually have different file names (a,b,c) then the point is somewhat moot - static function binding binds to dll name + function name. If you want your new DLL to work with the old exes, are you planning to copy the new dll three times to filenames a, b, and c? That seems odd and counterproductive. As with sleeping dogs, let the old DLLs lie. Leave them alone unless you absolutely have to fix some critical bug.