You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <st...@raleigh.ibm.com> on 1998/11/10 19:12:27 UTC
[PATCH] ApacheCore.def file
Including ApacheCore.def in the src directory should enable Win32 Apache
modules to run, without recompile, across server updates that don't
change the MODULE_MAGIC_NUMBER_MAJOR. Any concerns with adding this to
the distribution?
Thanks,
--
Bill Stoddard
stoddard@raleigh.ibm.com
Re: [PATCH] ApacheCore.def file
Posted by Eric Prud'hommeaux <er...@w3.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
Re: [PATCH] ApacheCore.def file
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
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.
--
Bill Stoddard
stoddard@raleigh.ibm.com
Re: [PATCH] ApacheCore.def file
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Tue, Nov 10, 1998 at 01:12:27PM -0500, Bill Stoddard wrote:
> Any concerns with adding this to
> the distribution?
Of course not; go ahead, Bill.
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)?
I'm not so firm in the Win32 DLL field, so please be patient about my
ignorance.
Martin
--
<Ma...@Mch.SNI.De> | Siemens Information and
Phone: +49-89-636-46021 | Communication Products
FAX: +49-89-636-47816 | 81730 Munich, Germany
Re: [PATCH] ApacheCore.def file
Posted by Dirk-Willem van Gulik <di...@jrc.it>.
On Tue, 10 Nov 1998, Bill Stoddard wrote:
> Including ApacheCore.def in the src directory should enable Win32 Apache
> modules to run, without recompile, across server updates that don't
> change the MODULE_MAGIC_NUMBER_MAJOR. Any concerns with adding this to
> the distribution?
Cool. I never understood that; but it sure works.
Dw.
Re: [PATCH] ApacheCore.def file
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Tue, 10 Nov 1998, Bill Stoddard wrote:
> Including ApacheCore.def in the src directory should enable Win32 Apache
> modules to run, without recompile, across server updates that don't
> change the MODULE_MAGIC_NUMBER_MAJOR. Any concerns with adding this to
> the distribution?
Sounds good to me. I've been meaning to do this for some time. We just
need to remember to add to it when we add new functions.
(Why, oh why, doesn't VC++ have an option to make import libraries that
import symbols by name? It would make life easier.)
P.S. Did I mention that I now think the _MAJOR/_MINOR thing is the wrong
way to do it? It's too confusing, IMHO. I'd rather see us move back to a
single MODULE_MAGIC_NUMBER, and a LAST_BINARY_COMPATIBLE number that we
can check against. As it is now, I think there's some confusion about what
"major" and "minor" means (I've seen some commits of changes that break
binary compatibility, but only have minor bumps, because they 'seem'
minor).
Also, AFAIK, a module that wants to be source compatible with lots of old
and new Apaches has to do some not-minor gymnastics with the various
preprocessor defines, because the MODULE_MAGIC_NUMBER_MAJOR/_MINOR symbols
aren't defined for older Apaches.
Something to consider...
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *