httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: apache-2.0/src/modules/mpm/winnt winnt.c
Date Mon, 15 May 2000 15:56:00 GMT

Here is my take on this.  Windows NT and Windows 9X are very different
platforms.  create two different MPMs.  They should be very similar to
each other, and should most likely contain some of the same code, so a new
directory structure may be required.  However, NT/2000 will always have
features that 95/98 don't have, and we want to take advantage of those
features.  Trying to squeeze them all into one MPM becomes ugly
quickly.  I suggest a layout similar to:


All of the common code goes into a dll in the common directory so that we
aren't duplicating too much code.  This doesn't even need to be a dll, it
could just be a set of C files that get compiled in with the stuff in the
other directories.

In th win32 directory is a Win32 MPM that does everything the current MPM
does (AcceptEx, CompletionPorts, etc.)

The win9x MPM is a very lightweight version of the Win32 MPM, that does
just what 9x can do.

I may be completely out of line, but this is my opinion.  This also keeps
us from opening up the ap_get_oslevel stuff.  Of course, if a Windows
person wants to explain why these should be in the same file, then we need
to re-evaluate opening up the ap_get_oslevel API's.


On Fri, 12 May 2000, William A. Rowe, Jr. wrote:

> > From: Bill Stoddard []
> > Sent: Friday, May 12, 2000 11:44 AM
> > 
> > Eeeuuuuu... -1 as is. I'll try to offer some constructive 
> > advice later...
> You were warned :-)
> The key issues for Win95 (to assure everyone parsed them)
> A) We cannot load in 95 if we have a static link to CancelIo
>    from the kernel32 api library.  The one liner fixes that,
>    but frankly, it stinks.  Dup the code instead, or export
>    the ap_load_dll_func?  I would rather do as I suggested
>    in the short term.
> B) TransmitFile is not guarenteed to be implemented on -any-
>    Win32 platform, it's up to the winsock author to implement,
>    and at that it's an optional feature.  It doesn't work with
>    my Win95 winsock2.  (It's harmless to have a static link,
>    however.)
> C) TransmitFile is plain stupid if the winsock author toggled
>    the TDI_PROVIDER_INFO.ServiceFlags member bit flag
>    TDI_SERVICE_INTERNAL_BUFFERING.  This is because the file
>    will be buffered, not streamed from file to port.
> D) We have two tests to decide which iol we will use in Win32
>    (with/without sendfile).  B) is easy, it returns a not
>    implemented error.  The second is a pain.  We should do
>    this all once, at startup, and use that decision.
> That's all...  I'm working on the invocation/service issues myself.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message