httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: cvs commit: apache-1.3/src/os/win32 service.c
Date Thu, 15 Jun 2000 21:44:16 GMT
> From: Keith Wannamaker []
> Sent: Thursday, June 15, 2000 4:02 PM
> |> I am -1 on this unless you have thoroughly, extensively 
> tested this on
> |> every Win32 platform on which Apache runs.
> |
> |-every- Win32 is reduced to -every- WinNT platform by the 
> first test :)
> Does isWindowsNT return true on all flavors of Win2000?
> Maybe the function should be renamed?

2000 is NT, of course.  Headers in Jan 2000 Platform SDK offer:

// dwPlatformId defines:

#define VER_PLATFORM_WIN32s             0
#define VER_PLATFORM_WIN32_NT           2

That's January... I don't see any -new- OS, they didn't even
ascribe a new ID to the 64-bit Windows, which might even become
problematic some day.
> |Two cases, and not hypthoetical...
> |
> |1) The service control code spawn, if one tells the child to run
> |   detached (-not- for consideration as a patch to the 1.3.x base,
> |   but as my own experiments for the 2.0 direction.)
> If it pertains to an experiment in the 2.0 tree, then put it there,
> not in the 1.3 tree.

The question is, does the test perform?  Yes, I have observed that it
does.  Now will others observe the same?  They certainly should.  
But if we decide in 2.0 to use this test, on the first production 
release of Apache Server for Windows, we will have much more empirical 
evidence that we don't have any obstacles.

> |2) A program spawning Apache without a console window.
> I grant that this is a problem with the AllocConsole() test.
> However, you are risking the stability of the 1.3 tree for
> one obscure feature request.

This is not a single request, it's the only one not blasted as a dup.
Look, I'm not faulting the concept of your test.  All these hacks
are due to a poorly thought out design of the SCM.  But I see fewer
issues with this new flavor.  We could have dropped the -k runservice
into the registry as the launch args for NT.  But I didn't care to do
that, and based on this new test, I'm entirely tempted to remove the
-k runservice method from 2.0, if we succeed.

> |Lastly, my most KEY concern is the stable release of 2.0.  
> ...
> |But I really, really want to 
> |know in the 1.3.x release that the 2.0 release will be golden.
> The 1.3 tree is not a sandbox in which to try out things before
> they appear in 2.0.

The 1.3.x code _is_ beta quality.  (The quality of support offered by 
the group for Win32 through has been even lower.)

But let's be absolutely clear, some things are broke in the Win32 port, 
some features have hung around for two years with no action, and there 
is nothing suggesting that the Win32 port of 1.3.13 is production ready.
We won't suggest it, and I hope others do not either.  If these patches
provide a wide body of early adopters of code that will be used
nearly verbatim in 2.0 for a successful production quality launch, 
without comprimizing the core of the 1.3 server, what is the issue?
> Do you disagree with what Roy said in April?
>   "So the answer is: commit it when you get three +1s from
>    people who have actually tested the code.  People who
>    just think its a good idea don't count -- I think its a
>    good idea, but that doesn't make it worth doing a series
>    of 1.3 releases just to make it work."
> You have made over fourteen code commits to 1.3 in the last
> week alone.. 


Documentation that clarifies some confusing concepts for Win32 
users (many of whom are not terribly conversant with installing 
programs from sources, never mind using a console window.)  

Significant overhaul of services targeted at 9x, that resolve 
piles of duplicated reports on Apache not allowing the pc to 
shut down, or run Apache hidden on win95.  All proposed by JJK
long ago with no action taken.

Cleanup of the structure of the services code to make the two 
(NT/9x) work well in tandem.  Very slight changes to the code
for NT services to perform a -real- restart and decrease the
interference of the isProcessService test. 

Cleanup of the discrepancies between the unix and win32 versions
of the httpd.conf-dist's.

Accept the interrupt signals Ctrl+C, and Ctrl+Break.

We won't even discuss the value of Mike's Netware patches, which
are probably in your count.

None of these affects the shared core code one bit.

ONE patch affected all platforms in a significant way.  That is
the patch to ap_get_local_host().  And this one was voted on,
and the final vote was +4 (including my own), and not a single
negative (as Bill's was turned around), with a few that chimed 
in that they don't care.

All of these patches are ment to reduce one thing, bug report
volume.  The patches I've submitted make the myrad Windows versions 
all behave in very similar manner without comprimizing the reliability.

> yet there have been other patches refused over
> the last few weeks in order to not taint the 1.3 tree.  
> Either it is a free-for-all or we need to do as Roy suggested, 
> but not both.

Clarification here... to paraphrase others, the 1.3.12 httpd
core server is rock solid.  There are problems, but these cannot
be fixed without breaking other things.  The refused patches
valiantly attempted to fix such issues.  I believe the value of
Roy's suggestion is consistency of the server engine.  Not one
of these patches touches that.

Final thought, there is one more item in the Status file to hold
the console window open on error.  I don't have a clean solution 
yet.  I don't know that I will.  But if you are about to object 
on the face of it please do so now, before I waste more hours.


View raw message