Apologies if seem to have completely ignored this. There's a simple
explanation: I have. As I mentioned in a test mail last night, my main
mail server died. Unfortunately, this arrived during the time when it
was sufficiently dead that I couldn't log in, but not so dead it
couldn't receive mail (weird, sometimes, these Unix boxes). We revived
it about an hour ago, so now I've seen it. Too late, unfortunately.
Let's see what we can salvage from the wreckage.
Alexei Kosut wrote:
> On Sat, 12 Jul 1997, Ben Laurie wrote:
>
> > I actually followed a slightly different path from Alexei, though.
> Firstly, I
> > started afresh to do the DLL (which I called ApacheCore.dll, BTW),
> and included
> > the bare minimum. The only modules included are http_core and
> mod_dll.
> > Everything else is dynamic, which is kinda fun. I'm slightly divided
> as to
> > whether this is actually a good idea, but it does seem like the
> logical thing
> > to do (Captain).
>
> It does. However, what I'd like to see is Apache distributed with all
> the "core" modules (the ones we that are uncommented in
> Configuration.tmpl) compiled in, and the others (or some of them) as
> DLLs. (maybe in a modules/ directory, so they don't clutter up the
> root Apache dir). I think that the sourceless releases of Apache
> should still be full-featured as distributed.
I don't see why this can't be accomplished with DLLs, however, given the
tedium of creating and maintaining all those makefiles, I'm inclined to
agree. On the other hand, it does give a rather wonderful flexibility to
be able to replace any component...
>.
Apache.exe, agreed. I've called it ApacheLaunch.exe for now, simply
because I didn't want to disturb the working non-DLLed version until all
the modules were DLLified.
The namespace problem is that Win32 completely ignores the path
component of a DLL except when it has to load it from disk. So using
names like status.dll or cgi.dll is fraught with risk.
> > VC++ 4.2 doesn't like a completely empty source file, nor one
> containing a
> > void static function, it seems - it causes an internal error in the
> linker, so
> > I had to add a global dummy function. I called the exe
> ApacheLaunch.exe, so
> > as to avoid splatting the existing makefile (and still follow the
> convention
> > that the makefile has the same name as the thing it makes) but if
> this is the
> > way we're going to go, I'll happily obliterate apache.mak...
>
> Well, I didn't actually use a completely empty source file, to be
> honest. I used one I just happened to have lying around that had
> something on it. But yeah, my instructions were for "convert the
> existing Apache to try out mod_dll", not "this is how the Apache
> distribution should be." apache.mak and libapache.mak are of course,
> the poper names for makefiles.
>
>.
Funny echo in here ;-)
> > There are a few things I'd like to resolve before we start
> committing:
> >
> > 1. Not using a .def for ApacheCore.dll, but doing it in the code,
> #defined,
> > of course.
> >
> > 2. #define the __declspec(dllexport) to avoid #ifdeffing.
>
> I used a .def because it was easier. It let me do an nm (on Unix) of
> the non-mod_* C files, run it through perl to create a list, add in
> the global variables, and it worked. If you want to go through the
> source and identify all the needed functions (don't forget about regex
>
> - I'm not quite sure how to do that if we keep them as seperate
> projects), and tag them, that's fine.
I've started, so I'll finish. ;-)
Well, someone will.
> I agree that conf.h should get a nice:
>
> #ifdef WIN32
> #define Dllexport __declspec(dllexport)
> #define Dllimport __declspec(dllimport)
> #else
> #define Dllexport
> #define Dllimport
> #endif
>
> That's handy for the modules, even if we don't do it for the core.
You'll note that I've dispensed with dllimport (in fact, it is
effectively synonymous with dllexport), and have added __stdcall (which
you can't do with a .def, so it has to be done this way anyway).
Phew! Doesn't look there was too much in the way of roadkill...
Cheers,
Ben.
--
Ben Laurie [Normal service will be resumed as soon as possible]