1.3.15 win32 issue: resolution to follow ASAP

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Ok, 

  The folks complaining about Win9x aren't hallucinating (well,
maybe they are, but it has nothing to do with their Apache issue.)

  There is some interaction in CreateProcess lauched _from the child
process only_.  That is, running as a single process (-X) the problem
never surfaces.  When lauched from the child, any command.com scripts 
fall into deep space, and some .exe authors (esp VB) are reporting 
strange side effects.

  Digging deeper... some script interpreters on win32 are expecting
backslash-delimited paths ... I have a patch to correct this issue.
But mod_cgi@333 does an ap_chdir_file but it was ifndef'ed out of win32,
can anyone tell me why?

  Also, ap_call_exec is horribly different between the mod_include and
mod_cgi, only the mod_cgi looks far more accurate, and that mod_include
just hasn't kept up.  I'd attack this, but first, any thoughts?

Bill

RE: 1.3.15 win32 issue: resolution to follow ASAP

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Tuesday, November 14, 2000 7:07 PM
> 
> On Tue, 14 Nov 2000 17:21:28 -0600, William A. Rowe, Jr. wrote:
> 
> > But mod_cgi@333 does an ap_chdir_file but it was ifndef'ed 
> > out of win32, can anyone tell me why?
> 
> I'd guess that would be for thread safety. A chdir affects 
> all threads in the process.

Thanks, I have an even better answer - it's an arg to the 
CreateProcess call :-)  

(sound of hitting head into wall)

Just checking everything, because this is a very goofy bug.  It
even seems that a file handle isn't properly closed by the kernel 
or by command.com, which really, really wouldn't surprize me.

Re: 1.3.15 win32 issue: resolution to follow ASAP

[Brian Havard <br...@kheldar.apana.org.au>]

On Tue, 14 Nov 2000 17:21:28 -0600, William A. Rowe, Jr. wrote:

>But mod_cgi@333 does an ap_chdir_file but it was ifndef'ed out of win32,
>can anyone tell me why?

I'd guess that would be for thread safety. A chdir affects all threads in
the process.

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------

RE: Win32 Users please read: 1.3.15 win32 issue resolved?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Thursday, November 16, 2000 9:00 AM
> 
> Finally, the reason the Win9x command.com and many other cgi's don't
> work is documented in mskb report Q150956, with a workaround. According
> to the document, our app should work.  Simple issue: file handles aren't
> closed properly by 16-bit dos apps, or for some other very obscure
> reason they mess up the pipe file so we end up with a terminally blocked
> ReadFile after the app terminated.  Since our app -doesn't- work, I'm
> looking at the mechanics of -why- we don't, and how we can.

We would have worked, except that we had freed our child processes' console.
This bug, in retrospect, made perfect sense.  I'm working up a solution now.

The solution, of course, breaks the win9x services (go figure.)  At least to
the user's perception, but it doesn't really :-)

Logoff scenario:  The user is warned that the APACHE program must be stopped.
So it is.  But - the child process is terminated (along with any CGIs it's 
trying to run.)  Once that process is terminated, the logoff is completed, 
but a new Apache process is spawned.  Not a bad behavior, just obnoxious 
messages at the user, to which I'm suggesting ... who cares?

While I'm working this up, please think about and respond to my earlier
request for thoughts on shortpaths and shebang lines.  Thanks,

Bill

Win32 Users please read: 1.3.15 win32 issue resolved?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, November 14, 2000 5:21 PM
> 
>   Digging deeper... some script interpreters on win32 are expecting
> backslash-delimited paths ... I have a patch to correct this issue.

That patch is applied ... on to part 2 of the problem.  First, for NT
users, a variety of this problem is easy to replicate on w2k or nt,
since /winnt/system32/command.com provides very straightforward
compatibility, simply set comspec and you are off to the races.

One problem is quoted long pathnames - some script interpreters will 
not accept them.  In fact, any interpreter pulled from the registry 
that has a "%1" arg should recieve the long path, but any entry with 
simply %1 should recieve the short path.  This is a simple fix, I've
already coded the patch.  The %1 and %* args from the registry are
now returned in the interpreter strings from ap_get_win32_interpreter
on Win32.  The psuedocode looks like:

if !strstr(interpreter, "\"%1\"")
    getshortpathname
    if strstr(interpreter, "%1")
        s/%1/shortpath/
    else
        append " " shortpath
else
    s/%1/longpath/

Q: what do we do for shebang-invoked scripts?  I would argue that we 
   use the shortpath, but allow a shebang format of #!executable "%1" 
   if they would rather get at a longpath.

[For anyone who is wondering (again) what the h@|| he's talking about,
 since win32 accepts spaces in path/file names, the NT convention is to
 quote the filepath, but this isn't consistently supported. Alternately,
 the 8.3 dos filename formats are used for shortpath aliases.  If you
 don't use Win32, ignore the Q and be greatful you don't have this issue.]

Finally, the reason the Win9x command.com and many other cgi's don't
work is documented in mskb report Q150956, with a workaround.  According
to the document, our app should work.  Simple issue: file handles aren't
closed properly by 16-bit dos apps, or for some other very obscure
reason they mess up the pipe file so we end up with a terminally blocked
ReadFile after the app terminated.  Since our app -doesn't- work, I'm
looking at the mechanics of -why- we don't, and how we can.

I expect to finish today so we can begin the process of rolling a tarball.
Win32 users, pease comment on the shebang line question above, and thanks, 
everyone, for your patience.

Bill

RE: 1.3.15 win32 issue: resolution to follow ASAP

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, November 14, 2000 5:21 PM
>
>   There is some interaction in CreateProcess lauched _from the child
> process only_.  That is, running as a single process (-X) the problem
> never surfaces.  When lauched from the child, any command.com scripts 
> fall into deep space, and some .exe authors (esp VB) are reporting 
> strange side effects.

The black hole is in buff.c@269 ... the ReadFile never returns after the
output is finished.  I'm continuing to pursue.  Even though we close the
client ends of the input/output/error handles (I even went so far as to
create the process suspended and closed them the moment afterwards), as we 
are processing the script results we hang at ReadFile().

Still fighting, hints appreciated.

Bill