You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/20 02:23:02 UTC
The ?last? 1.3.15/Win32 discrepancy
With the last several commits, the Win32 build system is much cleaner,
and produces results far similar to make install on Unix. It's all
done with awk (except the hairy .dsp converters, which could also be
rewritten, but not tonight :-)
Win32's behavior is similar in almost every respect. There is only
one compatibility feature I'd like to implement tommorow morning, and
it requires a little bit of thought...
Unix admins just drop the /usr/local/apache/bin/httpd command in their
startup script for boot time startup. Win32 admins install Apache
with the -k install -n servicename [or the old -i -n servicename].
The difference is in boot-time options. Win32 doesn't have any. Now
it's possible to simply patch http_main.c to accept --ntservice followed
by arguments, but that entry in the registry is a pain to get at.
I'm considering changing our registry entry. Today, we store in:
HKLM/System/CurrentControlSet/Services/[ApacheName]/Parameters
the ConfPath value, of the .conf file location. I'm suggesting we take
my initial approach from Apache 2.0, and store the ConfigArgs value
instead, a multi-sz string of null terminated args plus the extra null
terminator at the end of the args list.
Now... I didn't like my 2.0 solution for one reason, and I think I've
got the solution for both. Setting up the ConfigArgs is a breeze, it
consists of the parameters passed along with -k install -n servicename.
To edit the ConfigArgs would have been a PITA. But I'm proposing a new
-k config[ure] -n servicename option that replaces the Service's old
ConfigArgs with whatever other args are passed on that command line.
This has also presented a problem (even <= 1.3.14) since the user doesn't
have easy access to those arguments (or the old ConfPath value). I'm
also proposing the syntax -k status -n servicename that would give the
user three bits of info; apache version, current status (running, stopped),
and the startup options.
Please ack if this does or doesn't sound like the sane way to accomodate
the discrepancy between Unix and Win32. Patch available tommorow a.m for
both 1.3.15 and 2.0, if we have no issues with the concept.
Bill
1.3 vs. 2.0 (was: Re: The ?last? 1.3.15/Win32 discrepancy)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 19, 2000 at 09:15:54PM -0600, William A. Rowe, Jr. wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Tuesday, December 19, 2000 8:34 PM
> >
> > Agreed. I'm somewhat dismayed by the large Win32 changes for 1.3 that are
> > occurring. That's a lot of revamping, with the potential for making 1.3 even
> > more wobbly out in the field (I'm sure it works great for OtherBill, but
> > what about our users?).
> >
> > On Tue, Dec 19, 2000 at 05:29:46PM -0800, rbb@covalent.net wrote:
> > >
> > > I am +1 for 2.0 -0 for 1.3. I really think we should just leave 1.3 alone
> > > as much as possible right now. I would like to see the byterange problems
> > > solved, but everything else should be left for 2.0 IMO. Apache 1.3 on
> > > Win32 will never be a great solution.
>
> Ok, two votes from the non-win32 crowd...
>
> <rant>
>
> Hmmm... so I'm scratching my itch, and not scratching yours?
I said "dismayed". I didn't say "stop", and I didn't veto, and I didn't
complain that it should be scaled back.
But you can rant all you want. I still get to raise my concerns about the
Win32 port whether or not I use it. It is called the "Apache Web Server" and
that means that I feel responsible for it. To some extent, just being a
member of the ASF and the HTTPD group means that other people expect me to
be responsible, too.
Let's flip this around. What is David Reid made the BeOS version a pile of
crap? Every time somebody tried to install it, it would crash. They couldn't
configure it. It would only serve the first 2kbytes of a file. What would
you think? I bet you'd be awfully concerned.
I'm not saying you're building crap. I said that I'm concerned about the
amount of change and, thus, the possible introduction of problems.
>...
> Win32 is near rock stable. It had two new glitches. The code I've introduced
> for 1.3.15 doesn't carry those sorts of new risks.
You probably would have said the same last time, too :-)
I know that I say all of my changes don't involve risks, but they do. Hell,
I made what appeared to be a small change from Joe Orton to fix some
byterange handling. It fixed it, but a small ripple broke another situation.
And when people dug in to resolve that, discovered a bunch of other
problems.
>...
> Yes... I can build on Linux and run the Apache server -I- want, but that's not
> my usual haunt. Yes... 2.0 resolves massive compatibility issues for Win32.
> Yes... 1.3.15 isn't being raced anymore. But no, 1.3.15 isn't a dead horse.
> It will be out there for years. I know neither of you two like that, and I do
> agree 2.0 is a superior solution. But we have many folks out there running
> 1.3.15, needing solutions (or having to hack their own) around things we do
> very, very easily with Unix in 1.3.15.
Another alternative world is: if you want to run 1.3 on Windows, then just
deal with the problems. If you want something that truly works, then you're
going to need to upgrade to 2.0. Tough luck.
Let's take an extreme position to clarify this point: if I say that 1.3
doesn't run right on my Apple ][, does that mean that I can go and revamp
the whole thing? "But 1.3 is going to be out there for a long time, so it
should work for those Apple ][ users!"
> These two last changes (module names, config/status of service opts) I believe
> are needed in 1.3.15 to put the tree to bed, from Win32's own perspective.
Those don't bother me. It's things like revamping the processing model: the
console hook, CGI execution bits, etc etc.
But seriously: I'm not vetoing them. I'm raising a point that it makes me
somewhat uncomfortable, and that I'd ask you to seriously consider whether
they ABSOLUTELY MUST go into 1.3.
>...
> There have been a number of times over the past two months that the Win32
> build of the 2.0 tree was so totally broken I just walked away. I try to
> be very cautious of the 'other' sources, and when I grep, I actually take
> the time to search *.in, unix directories, etc, even though they are totally
> irrelevant to the Win32 build. It would be nice to see more folks take the
> same time to include *.dsp,def,hw as well. I'd be happier fixing a broken
> .hw file where someone 'tried' to be thorough, than chasing down something
> that was ignored by the original committer in haste.
And it is great that you do so (and if we want to play the "well, I take
care" game :-), then I'll point out the apu_private.hw that I added for
you... I just couldn't hook the darn thing into the DSP build).
But I'd state that it is easier for you to change the Unix-ish files, than
it is for us to change a .dsp (since those are generated files needing a
specific format).
>...
> So if I was productive scratching my itch to see a clean 1.3.x Win32, then
> that's what it is. I'm off to 2.0 after tommorow morning ... to catch up
> with the rest of you. Maybe implement .asp on 2.0 - we'll see where my next
> itch is. For those with no technical justification other than 'not my itch',
> this sort of '-0 for 1.3.15' is nothing but irritating.
It isn't meant to be irritating. It is meant to convey concern about radical
change for a product that we feel responsible for. You perceive it as a bug
that must be fixed; we perceive it as something that could be punted (thus
avoiding possible destabilization) in favor of referring users to 2.0.
Again: nobody is asking you to stop, only saying that we're uncomfortable,
and ask that changes to 1.3 be minimized if and when possible. Consider
punting users to 2.0 rather than continuing to refine 1.3.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: The ?last? 1.3.15/Win32 discrepancy
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Tuesday, December 19, 2000 8:34 PM
>
> Agreed. I'm somewhat dismayed by the large Win32 changes for 1.3 that are
> occurring. That's a lot of revamping, with the potential for making 1.3 even
> more wobbly out in the field (I'm sure it works great for OtherBill, but
> what about our users?).
>
> On Tue, Dec 19, 2000 at 05:29:46PM -0800, rbb@covalent.net wrote:
> >
> > I am +1 for 2.0 -0 for 1.3. I really think we should just leave 1.3 alone
> > as much as possible right now. I would like to see the byterange problems
> > solved, but everything else should be left for 2.0 IMO. Apache 1.3 on
> > Win32 will never be a great solution.
Ok, two votes from the non-win32 crowd...
<rant>
Hmmm... so I'm scratching my itch, and not scratching yours?
This particular code doesn't touch your code path. I know Win32 stability,
and as you don't, this puts you in the uncomfortable position of allowing
in code that you don't understand. Bill n' Bill{r} can only review so much
code. I entrust W. Stoddard to know his stuff about winsock (and he proves it
often). The win9x Console hack is my ball of wax. Either way, I've had to
rely on my 'network' of Win32 testers, culled from the lists and bugs reporting
systems, to assure this stuff works on someone but OtherBill's PC.
Win32 is near rock stable. It had two new glitches. The code I've introduced
for 1.3.15 doesn't carry those sorts of new risks. As one example, loosing the
(hidden) console was a horrible thing that anyone following the list back in
12/99 should have caught (JJK did a great writeup about the issue.) The other
side, backslashes, goes to show how my testers 'get it' about the paths.
[Interesting observation, the only consistant problem seemed to be with JServ,
which didn't follow the '/' syntax on installation.] 1.3.15 puts both back
where they have to be, and cleans up other cgi execution issues. I plead
ignorance that I'd never seen the one and only KB article that addressed the
pipes and child console window issues.
All of that code is indirectly applicable to 2.0. None of it a straight-line
conversion due to the MPMs and The Bills(tm) mutual desire to keep Win32 hidden
in mpm_winnt :-) So 2.0 benefits if the solution works, it's a waste of a few
hours of my time to bridge it between the trees.
Yes... I can build on Linux and run the Apache server -I- want, but that's not
my usual haunt. Yes... 2.0 resolves massive compatibility issues for Win32.
Yes... 1.3.15 isn't being raced anymore. But no, 1.3.15 isn't a dead horse.
It will be out there for years. I know neither of you two like that, and I do
agree 2.0 is a superior solution. But we have many folks out there running
1.3.15, needing solutions (or having to hack their own) around things we do
very, very easily with Unix in 1.3.15.
These two last changes (module names, config/status of service opts) I believe
are needed in 1.3.15 to put the tree to bed, from Win32's own perspective.
Any testers that have been running my changes want to pipe up here... feel free.
1.3.14 worked for a whole lot more folks than OtherBill, now 1.3.15 already
resolves those few new issues that were introduced, and would bring Win32 to
parity with Unix in terms of flexibility.
There have been a number of times over the past two months that the Win32
build of the 2.0 tree was so totally broken I just walked away. I try to
be very cautious of the 'other' sources, and when I grep, I actually take
the time to search *.in, unix directories, etc, even though they are totally
irrelevant to the Win32 build. It would be nice to see more folks take the
same time to include *.dsp,def,hw as well. I'd be happier fixing a broken
.hw file where someone 'tried' to be thorough, than chasing down something
that was ignored by the original committer in haste.
So if I was productive scratching my itch to see a clean 1.3.x Win32, then
that's what it is. I'm off to 2.0 after tommorow morning ... to catch up
with the rest of you. Maybe implement .asp on 2.0 - we'll see where my next
itch is. For those with no technical justification other than 'not my itch',
this sort of '-0 for 1.3.15' is nothing but irritating.
</rant>
Re: The ?last? 1.3.15/Win32 discrepancy
Posted by Greg Stein <gs...@lyra.org>.
Agreed. I'm somewhat dismayed by the large Win32 changes for 1.3 that are
occurring. That's a lot of revamping, with the potential for making 1.3 even
more wobbly out in the field (I'm sure it works great for OtherBill, but
what about our users?).
Cheers,
-g
On Tue, Dec 19, 2000 at 05:29:46PM -0800, rbb@covalent.net wrote:
>
> I am +1 for 2.0 -0 for 1.3. I really think we should just leave 1.3 alone
> as much as possible right now. I would like to see the byterange problems
> solved, but everything else should be left for 2.0 IMO. Apache 1.3 on
> Win32 will never be a great solution.
>
> Ryan
>
> On Tue, 19 Dec 2000, William A. Rowe, Jr. wrote:
>
> >
> > With the last several commits, the Win32 build system is much cleaner,
> > and produces results far similar to make install on Unix. It's all
> > done with awk (except the hairy .dsp converters, which could also be
> > rewritten, but not tonight :-)
> >
> > Win32's behavior is similar in almost every respect. There is only
> > one compatibility feature I'd like to implement tommorow morning, and
> > it requires a little bit of thought...
> >
> > Unix admins just drop the /usr/local/apache/bin/httpd command in their
> > startup script for boot time startup. Win32 admins install Apache
> > with the -k install -n servicename [or the old -i -n servicename].
> >
> > The difference is in boot-time options. Win32 doesn't have any. Now
> > it's possible to simply patch http_main.c to accept --ntservice followed
> > by arguments, but that entry in the registry is a pain to get at.
> >
> > I'm considering changing our registry entry. Today, we store in:
> >
> > HKLM/System/CurrentControlSet/Services/[ApacheName]/Parameters
> >
> > the ConfPath value, of the .conf file location. I'm suggesting we take
> > my initial approach from Apache 2.0, and store the ConfigArgs value
> > instead, a multi-sz string of null terminated args plus the extra null
> > terminator at the end of the args list.
> >
> > Now... I didn't like my 2.0 solution for one reason, and I think I've
> > got the solution for both. Setting up the ConfigArgs is a breeze, it
> > consists of the parameters passed along with -k install -n servicename.
> >
> > To edit the ConfigArgs would have been a PITA. But I'm proposing a new
> > -k config[ure] -n servicename option that replaces the Service's old
> > ConfigArgs with whatever other args are passed on that command line.
> >
> > This has also presented a problem (even <= 1.3.14) since the user doesn't
> > have easy access to those arguments (or the old ConfPath value). I'm
> > also proposing the syntax -k status -n servicename that would give the
> > user three bits of info; apache version, current status (running, stopped),
> > and the startup options.
> >
> > Please ack if this does or doesn't sound like the sane way to accomodate
> > the discrepancy between Unix and Win32. Patch available tommorow a.m for
> > both 1.3.15 and 2.0, if we have no issues with the concept.
> >
> > Bill
> >
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
Re: The ?last? 1.3.15/Win32 discrepancy
Posted by rb...@covalent.net.
I am +1 for 2.0 -0 for 1.3. I really think we should just leave 1.3 alone
as much as possible right now. I would like to see the byterange problems
solved, but everything else should be left for 2.0 IMO. Apache 1.3 on
Win32 will never be a great solution.
Ryan
On Tue, 19 Dec 2000, William A. Rowe, Jr. wrote:
>
> With the last several commits, the Win32 build system is much cleaner,
> and produces results far similar to make install on Unix. It's all
> done with awk (except the hairy .dsp converters, which could also be
> rewritten, but not tonight :-)
>
> Win32's behavior is similar in almost every respect. There is only
> one compatibility feature I'd like to implement tommorow morning, and
> it requires a little bit of thought...
>
> Unix admins just drop the /usr/local/apache/bin/httpd command in their
> startup script for boot time startup. Win32 admins install Apache
> with the -k install -n servicename [or the old -i -n servicename].
>
> The difference is in boot-time options. Win32 doesn't have any. Now
> it's possible to simply patch http_main.c to accept --ntservice followed
> by arguments, but that entry in the registry is a pain to get at.
>
> I'm considering changing our registry entry. Today, we store in:
>
> HKLM/System/CurrentControlSet/Services/[ApacheName]/Parameters
>
> the ConfPath value, of the .conf file location. I'm suggesting we take
> my initial approach from Apache 2.0, and store the ConfigArgs value
> instead, a multi-sz string of null terminated args plus the extra null
> terminator at the end of the args list.
>
> Now... I didn't like my 2.0 solution for one reason, and I think I've
> got the solution for both. Setting up the ConfigArgs is a breeze, it
> consists of the parameters passed along with -k install -n servicename.
>
> To edit the ConfigArgs would have been a PITA. But I'm proposing a new
> -k config[ure] -n servicename option that replaces the Service's old
> ConfigArgs with whatever other args are passed on that command line.
>
> This has also presented a problem (even <= 1.3.14) since the user doesn't
> have easy access to those arguments (or the old ConfPath value). I'm
> also proposing the syntax -k status -n servicename that would give the
> user three bits of info; apache version, current status (running, stopped),
> and the startup options.
>
> Please ack if this does or doesn't sound like the sane way to accomodate
> the discrepancy between Unix and Win32. Patch available tommorow a.m for
> both 1.3.15 and 2.0, if we have no issues with the concept.
>
> Bill
>
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------