You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Keijser, Jan Just" <KE...@logica.com> on 1999/10/19 16:41:50 UTC
Win32/1.3.9, Windows 9x, CGI batch files and 16bit CGI programs
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
Re: Win32/1.3.9, Windows 9x, CGI batch files and 16bit CGI programs
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
This bug was fixed in Apache 1.3.10-dev a few days after the Apache 1.3.9
release. The code was a misguided attempt to fix some really strange
behaviour some people were seeing with CGIs under Win9x (all the output
being sent to stdout rather than the network). Try downloading the latest
development version of Apaceh 1.3.10-dev and let me know if you see any
problems with it. (http://dev.apache.org/from-cvs/apache-1.3/)
Bill
----- Original Message -----
From: Keijser, Jan Just <KE...@logica.com>
To: 'apdev' <ne...@apache.org>
Sent: Tuesday, October 19, 1999 10:41 AM
Subject: Win32/1.3.9, Windows 9x, CGI batch files and 16bit CGI programs
> 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