News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

creating a wrapper for a DLL

Started by bigrichlegend, November 01, 2006, 07:11:13 PM

Previous topic - Next topic

bigrichlegend

Does any one know of any tutorial or link I can follow as to how to create a wrapper for an existing DLL?

sluggy

In general, we do not condone the writing of wrappers for third party dlls, as that is subverting their intended functionality. However, in the real world this is sometimes needed.

I suggest you search the current and old forums for asm specific stuff, and then use Google. Most of the info returned by google will be using C++/VB, but that is irrelevant because the techniques are the same no matter what language you use in the wrapper.

Normally you would name your dll the same as the old dll, rename the old dll to something different, then have your dll load the original one. Of course there could be many pitfalls with this, too many to go into here, but if you make Google your friend you will find out about them  :U


Vortex


zooba

It shouldn't really be any different to writing a normal DLL. You're simply using the functions of the existing one in your new one, and using the new one in your other program.

There shouldn't be any need to replace the original at all, as Sluggy suggested, unless you're up to something bad  :naughty:. I can't see any problem with writing a wrapper to, for example, handle buffer allocations or variable 'boxing' (eg. DWORD to VARIANT). I wrote a wrapper for SQLite to allow VB to use it (VB can't allocate memory or pass pointers well enough to be usable, plus I later added a COM interface (mostly for fun :wink ) which wasn't in the original). OpenGL extensions often have wrappers written for them too.

Forwarded functions are useful for removing overhead, as long as the original function is fine. Otherwise, just write your own function and call the original one in it. Define your own interface and design your program around it (or document it so other people can design around it). I can't think of any other (legitimate) applications of a DLL wrapper.

Cheers,

Zooba :U

PBrennick

There is no need to  allocate memory in one DLL to access another one. You would just do that in your application. You could write a library to do that as well but that is not necessary, either. Do the allocations, create any necessary pointers and buffer stuff in a procedure with a descriptive name. Add that procedure to your library of procedures in somename.inc and then you can use it whenever you need it. A much better method, IMO.

Forwarded functions are the only legitimate and useful thing I can think of as it prevents the need to duplicate effort and is a well-documented method used by Microsoft. If you know another one, please share it as we all like to learn from others. We are NOT the gods of assembly and you may have discovered something we ALL could use!

Paul
The GeneSys Project is available from:
The Repository or My crappy website

zooba

Simply forwarding the function isn't creating a wrapper. A wrapper/adapter either has to change the order or type of the parameters, or do some extra work which can be abstracted from your main code. As you said, Paul, this is as simple as creating a function to call the other function with new parameters. If this adapter is desired in a number of projects, a DLL or LIB is the obvious place to put it.

Keeping in mind that when using some higher-level languages, the memory access abilities available to C and assembly may not be available. In this case, a wrapper which will allocate memory on behalf of the application is invaluable. For example, VB internally uses OLE memory allocated with specific functions. It is very difficult to handle a C style array, since VB expects a SAFEARRAY created using SafeArrayCreate. It is just as difficult to handle a C style string, since VB expects a BSTR created using SysAllocString. A wrapper that will handle these conversions allow the functions to be used as if they are intrinsic to VB.

Forwarded functions are one aspect of this, where if you simply want to 'rename' a function to make it consistent with the rest of your wrapper, forwarding is simplest and most efficient. However, a DLL which simply forwards all of its functions is relatively pointless.

Cheers,

Zooba :U

PBrennick

Zooba,
I just read this...
Quote
Keeping in mind that when using some higher-level languages, the memory access abilities available to C and assembly may not be available. In this case, a wrapper which will allocate memory on behalf of the application is invaluable. For example, VB internally uses OLE memory allocated with specific functions. It is very difficult to handle a C style array, since VB expects a SAFEARRAY created using SafeArrayCreate. It is just as difficult to handle a C style string, since VB expects a BSTR created using SysAllocString. A wrapper that will handle these conversions allow the functions to be used as if they are intrinsic to VB.

You are, of course, correct. I keep forgetting that there are other languages that can be used to create very professional applications. I 'live' in assembly and do not treat other languages with the respect that they deserve. I appreciate you pointing this out to me (and others) This is a VERY legitimate use for a wrapper. I think a lib might be better but after being wrong once...

Paul
The GeneSys Project is available from:
The Repository or My crappy website