httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keijser, Jan Just" <KEIJSE...@logica.com>
Subject Win32/1.3.9, Windows 9x, CGI batch files and 16bit CGI programs
Date Tue, 19 Oct 1999 14:41:50 GMT
As you may know, batch files and 16bit CGI programs no longer work with
Apache 1.3.9 on Windows 9x; they did work with Apache 1.3.6, however.

After some digging around I found the cause, but I am not sure what the best
solution would be. Can somebody give advice, please?

The problem
-----------

In main/util_script.c, the 1.3.6 Win32 source code uses 

if (CreateProcess(NULL, pCommand, NULL, NULL, TRUE, 0, pEnvBlock,
                  ap_make_dirstr_parent(r->pool, r->filename),
                  &si, &pi)) {

to start a CGI program, whereas the 1.3.9 code uses

if (CreateProcess(NULL, pCommand, NULL, NULL, TRUE, DETACHED_PROCESS,
pEnvBlock,
                  ap_make_dirstr_parent(r->pool, r->filename),
                  &si, &pi)) {

i.e. the only difference is the DETACHED_PROCESS flag; why was this added?
Is this traceable in the CVS repository?

I *think* I know what this flag does, but as far as I can tell it does not
add any value: 

If a Win32 console process which itself is running as 'DETACHED_PROCESS'
starts another process and does _NOT_ specify the DETACHED_PROCESS flag, the
new process will also have no console (which is what you want). However, if
the Win32 console process does have a console then the child process will
inherit the console. This is why batch files and some 16bit CGI program work
on Windows 9x:

With the 1.3.6 code, you could only run Apache as a console app on Windows
9x; hence all CGI programs would inherit their parents' console and they
would work without too many problems (see note below on 16bit CGI programs
and long path names).

In the 1.3.9 code however, the CGI children never inherit their parents'
console and this causes batch files and 16bit program to fail - they
absolutely *NEED* a console in order to function properly. Hey, this is MS
Windows, so what did you expect ;-) ? 

In the 1.3.9 code, you could also only run Apache as a console app on Win9x.
With my patch to run Apache as a Win9x service however, we're back at square
one: when Apache starts as a services, it detaches itself from the console
and as a result batch files and 16bit CGI programs will never work unless
you run them through an application which explicitly creates a new console.
Should a sample application that does this be supplied (I have one lying
around) ?


The Solution
------------
Remove the 'DETACHED_PROCESS' flag from the CreateProcess call. I tried this
and it works for Apache 1.3.9 on Win9x.
The question is, why was it added in the first place? What will we break if
we remove it again?

For the release notes
---------------------
How to use 16bit applications as CGI programs on Windows 9x with Apache:

In order for the 16bit application to correctly pipe its output to Apache,
the 16bit application _MUST_ be located in a fully 8.3-compliant directory.
For example, if Apache tries to read the output from a 16bit application
which is located in C:\Program Files\Apache Group\Apache\cgi-bin then pipe
from the 16bit application will fail. This is a design constriction (bug?)
of Windows 9x. This does not apply to Win32 console applications, as they
run fine in any directory.

If the 16bit application is located in e.g. C:\Apache\cgi-bin then the
application will be able to correctly pipe its output to Apache.

For some reason, configuring the cgi-bin directory to be 
  C:\PROGRA~1\APACHE~1\APACHE\CGI-BIN 
does not have any effect, nor modifying DocRoot in a similar fashion - the
CGI's still report as being started from 
  C:\Program Files\Apache Group\Apache\cgi-bin
and hence 16bit applications will fail.

Regards,

JJ Keijser
Logica Inc
Lexington MA

Mime
View raw message