Question

In a regular DLL, there's generally a 1:1 mapping of entry points and functions in the DLL. I have a DLL that has about 50 functions. It's a chore to maintain all of them, and if the signatures or types change, then they all have to be updated and so on.

I was thinking about creating 1 entry point for them all and sending in a code that directed the single entry point as to which function to call in the DLL. Can this cause any problems like bottlenecks, especially in a thread-safe DLL? I can't think of any drawbacks, as this approach would mimic a COM entry and/or lookup off a VTABLE or something similar with one entry point.

For example:

In a normal DLL, the following three functions might be exported:

Func1
Func2
Func3

All have different entry points

Proposed workaround:

Caller calls Func1(iCode) into DLL

Exported Func1 in DLL maps iCode to Func2 or Func3 or Func4, ... Func50 etc.

This way, there's only 1 signature (with explicit linkage) to maintain as opposed to 50. I can't foresee any real bottlenecks here. Am I missing anything obvious?

Was it helpful?

Solution

The transformation you propose will not change anything. The functions are still de facto functions with changing arguments and so forth.

A number which selects a function in a table is just another form of addressing a function.

The first thing that will happens is that the programmers using explicit "ioctl-like" dispatch with function numbers will not like it very much, and they will write stub routines which hide the dispatch, which will make their code more readable, and let them do things like place breakpoints on individual functions. Those wrapper stubs may well have exactly the same signatures as the original functions and so you're back to square one.

Oh, and on Windows, functions in a DLL are addressed by a numeric index already! A .def file assigns ordinal numbers to names, or something like that. Look at this MSDN entry.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top