🚀 go-pugleaf

In article <1992Oct9.190931.20869@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:

>In article <1992Oct07.192423.2842@ans.net> db3l@ans.net (David Bolen) writes:
>>                                                    So if you want to
>>make sure and support backlevel applications, you have to at a minimum
>>have stub functions for all previous revisions of your DLL to get by
>>the load-time checking.

(we're in complete agreement - just a little clarification)

>The solution is to structure your DLL as an API.  That is, every
>function returns error codes, or zero for OK.  If values need to be
>passed back, use output parameters.

I don't think I'd necessarily agree that this is the definition of an
"API".  My "application programming interface" may return actual
usable values as the result of a function rather than an error code,
but it's still just as much an API as anything else if those results
are documented.

"Output" parameters are useful, but can be an unnecessary parameter
if, for example, a function could just as easily return the answer as
a result (with the ability to flag an error as a particular result).
Sometimes it's more convenient to just return the answer, rather than
requiring the caller to allocate temporary variables - often an
optimizing compiler can keep everything in registers throughout the
use of the result.

>passed back, use output parameters.  Now, you do not EVER delete a
>reference from the DLL.  Instead, you change the code so it just
>returns a constant (you should define a constant like
>FUNCTION_NOT_IMPLEMENTED for this purpose).

Yep - that's what I meant above about having to keep around stub
functions.  Whether you return a fixed numeric code, or just a
particular result that is recognizable as an error (such as NULL
value) shouldn't be a problem.

>This way, references are always resolved by the linker, and your code
>will always get far enough to check versions.  Plus, if you call a
>function that hasn't been implemented, you know it from the non-zero
>return code.

Well, if things are done right, you should never hit the function that
wasn't implemented.  Since the loader will resolve all DLL references,
if you are using an antiquated function, your version check should
detect it and also be able to provide an out for older applications.
If you want to support older applications, then you should handle the
older function as well.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/