Date: Wed, 11 Nov 1998 02:53:10 -0500 (EST)
From: "Eric Prud'hommeaux" <eric@w3.org>
To: new-httpd@apache.org
Subject: Re: [PATCH] ApacheCore.def file
In-Reply-To: <3648B0BD.35F0766E@raleigh.ibm.com>
Message-ID: <Pine.LNX.3.96.981111022857.1364A-100000@tux.w3.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Tue, 10 Nov 1998, Bill Stoddard wrote:

> Martin Kraemer wrote:
> > 
> > 
> > BTW: How would a DLL module find out if it is compatible or not?
> > Wouldn't two versions of Apache by default create the same *.def file
> > automatically, and doesn't that mean they would automatically be
> > "compatible" (maybe without being aware about it)?
> 
> Win32 uses ordinals to resolve references to functions in dlls
> (ApacheCore.dll). Unless you tell the compiler to assign these ordinals
> in a certain way (via a .def file) it is free to assign them however it
> wants. VC++ seems to assign ordinals against the sorted (by function
> name)list of functions exported by the dll. If you add a new function,
> it is inserted into the list sorted by its name, and all following
> ordinals get bumped by 1. 
> 
> Inserting a new function into the API (and not changing anything else)
> should be reason to bump the MODULE_MAGIC_NUMBER_MINOR but it should not
> cause modules compiled against the earlier version of the server to
> fail.

In case this is helpfull: libwww uses a set of def files generate by a
perl script called config/makedefs.pl. All non-static libwww functions are
prefixed by PUBLIC (defined to nothing) so the script looks for those. It
could be easily changed to look for a lack of a static. I beleive it 
parses the sources as well as the existing def files and makes some
intelligent choices in allocating ordinals.

Why do I mention this? Mostly 'cause it triggered my memory, but partly in
case folks decide to have ordinals for specific functions be consistent
from version to version of a DLL. That way, the app has a fighting chance
of working with an older DLL and visa versa, which is the most you ever
get in the windows world anyways.

Beyond that, you would probably need to have an explicit LoadLibrary call
and a consistent version info function in each DLL that takes an array of
string requirements and answers yes or no for each one - probably serious
overkill.

-eric