|Products Purchase Publishing Articles Support Company Contact|
Articles > COM > Dynamic Export Technology
Desaware's SpyWorks allows Visual Basic programs to create true function exports from Visual Basic dynamic link libraries. Frankly, we're not the only company to make this claim. But Desaware's approach is unique and has a number of advantages that make it a superior solution to others. In this short article, we'll show you the differences, and describe the advantages and disadvantages of each approach.
The approaches - in a nutshell
Other products that allow function exports from Visual Basic DLL's work by actually modifying the executable file that Visual Basic creates. This approach does have some advantages. For one thing, you need only distribute the Visual Basic DLL file - there is no secondary DLL to distribute. You also get the best possible load time performance.
However, these advantages come at a severe price. You are relying on the product to safely, correctly and reliably modify your compiled Visual Basic DLL. It must do so every time you build the DLL. This approach is very dependent on the version of Visual Basic that you are using. You may find that your program breaks on installation of a service pack, or that it will not work with newer versions of Visual Basic.
At Desaware, we specialize in offering "low level" solutions to VB programmers - but the reason we've been successful at this is that we bring a high level of paranoia to our development process. If a technology is not soundly based on documented standards, we won't release it.
So when it came to finding a way to export functions from VB DLL's, we looked for an approach that would not be dependent on a specific version of Visual Basic or a service pack, and would not require any modifications to the executables that Visual Basic creates. We found one.
We call it "Dynamic Export Technology" and it addresses our primary concern of reliability. The approach is simple: you define all of the information about the functions you wish to export using a standard Visual Basic class module. We provide a separate DLL (called an "alias" DLL) that knows how to read this information when it loads. A client application loads the alias DLL, which in turn loads your DLL by way of the object that you created. It reads the export information and rewires the internal export table at runtime so that the client will call your VB DLL directly. Once the load process is complete, all function calls go directly to standard functions in a public module in your DLL - the alias DLL is out of the picture completely.
The result: your VB DLL provides true function exports. But it does not modify your Visual Basic DLL in any way. More important, it relies only on standard documented mechanisms built into Visual Basic - so it is guaranteed to work with all versions of Visual Basic 5, 6 and those that come in the future.
What About Performance?
You may see performance figures that show the SpyWorks approach to be considerably slower than the other. As you might expect, those figures were based on benchmarks designed to show our approach in the worst possible light - and do not tell the whole story.
As you would expect from the above description, Dynamic Export Technology requires extra time during the initial load of the DLL in order to link up the export tables to the client. The alias DLL must load your DLL. It has to go to the object you created and read the exported information.
So if you wanted to show the greatest performance difference between the two approaches what would you do? You'd create a benchmark in which the DLL is loaded, performs a single exported function call, and then unloads the DLL.
But that's not how most programs work. Programs that use exported functions typically load the DLL and call the exported function multiple times. Ultimately the initial load times are irrelevant - what counts is how long the actual function call takes. Since Dynamic Export Technology does end up with the client calling your DLL function directly, the performance is as good as the other static export approach.
What about Dependencies?
Our approach does require you to distribute one extra DLL - the alias DLL that you create using the SpyWorks exporting tool. Once you've created it for a particular application, you won't need to change it again - you can add new exported functions through simple modifications to your Visual Basic DLL. The alias DLL does not itself have any further dependencies.
What are your priorities?
As you may tell, this article is a response to another company's claims that frankly, we think are unfair. Naturally, we're biased towards SpyWorks, but we also try to be fair and honest. There are advantages to their approach - we knew that when we were deciding how to provide this functionality to our customers. But our fundamental philosophy is that we would never ship something we wouldn't use. And we don't even trust ourselves to modify the executables that VB creates, much less anyone else.
If you can't afford even a small load time performance penalty, or can't stand the thought of distributing even one more small DLL ( 36K ), and are willing to take the risk that you won't be able to install later service packs or port your software to later versions of Visual Basic - then frankly, their approach is a better choice for you.
But if you demand a product that adheres strictly to Microsoft's standards, and does not modify the executable created by Visual Basic in any way, and is based on an architecture that can't be broken by Microsoft without them also breaking backward compatibility for every Visual Basic application ever written - then we think you'll find our approach is the right one.
For notification when new articles are available, sign up for Desaware's Newsletter.
|Products Purchase Articles Support Company Contact