RE: os-windows/6296: Long directory names prevent CGI from running properly

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

Please try replicating this problem by building apache from the current
source tree.  We are T+0700 hours from a new release, which should fix
this bug.

Two problems occured ... redirected std pipes are not closed properly
unless a program is launched in a command window.  Apache 1.3.14 had
no child command window, the tree and soon-to-come 1.3.15 release will
have a hidden child command window.

The second aspect was in long pathnames.  The CGI process is now created
with long paths in the command line -if- the arg is quoted, so a script
#!perl        uses the short path
#!perl "%1"   uses the long path
The same is now true for ScriptInterpreterSource Registry ... if the
command is "someapp.exe "%1"" then it is invoked with the long path, if
the registry command is "someapp.exe %1" it is invoked with a short path.

Batch files under NT's CMD.EXE is always give long paths, COMMAND.COM is
always given short paths.

Hope this resolves your issues.

Bill

> -----Original Message-----
> From: TOKILEY@aol.com [mailto:TOKILEY@aol.com]
> Sent: Tuesday, July 11, 2000 11:53 AM
> To: dan@thelewishouse.com
> Cc: new-httpd@apache.org
> Subject: Re: os-windows/6296: Long directory names prevent CGI from
> running properly
> 
> 
> 
> In a message dated 00-07-11 12:27:32 EDT, Dan Lewis writes...
> 
> > Subj:  Re: os-windows/6296: Long directory names prevent 
> CGI from running   
> > properly
> >  Date:    00-07-11 12:27:32 EDT
> >  From:    dan@thelewishouse.com (Dan Lewis)
> >  Reply-to:    dan@thelewishouse.com
> >  To:  TOKILEY@aol.com
> >  
> >  Kevin,
> >  
> >  Thanks for the tip.  What I think I understand about this 
> is that DJGPP-
> > compiled
> >  programs load as 16-bit applications, then switch to 
> protected mode rather 
> > than
> >  being loaded that way to start with.  But what's still odd 
> to me is that I 
> > don't
> >  have this problem with Xitami.  Apparently they've found 
> some sort of 
> > workaround
> >  to put inside their webserver.
> >
> >  Dan
> 
> I believe the Xitami stuff uses Win32S which is the transitional
> kludge between old Win 3.1 16 bit stuff and the newer 32-bit.
> Win32S allows access to SOME ( not all ) 32-bit OS features
> from 16 bit DPMI protected mode applications... but it is still
> not full blown 32-bit flat model API access.
> 
> Win32S does have support for 'long' filenames but it has to
> be linked into the MZ 16-bit output binary.
> 
> If DJGPP would do that then long filenames would be OK
> with their gcc.exe as well.
> 
> Question for you... ( I'm a little confused )....
> 
> Even if you have a 16 bit APP that doesn't support long 
> filenames being used a CGI script it should STILL get the
> filenames right. The Win32 NTVDM virtual machine, which
> is what all 16-bit programs run under, is the guy who is
> translating all the 'long' filenames into the 'short' name
> and it generally gets it right every time as long as the
> STDLIB parameters was simply a 'pointer' to a NULL
> terminated filename.
> 
> This all falls down if your are using something like
> findfirst/next, however, since the 16 bit FFBLK structure itself
> only has room for 8.3 filenames and the rest is lost
> but other IO calls ( fopen, etc ) should be OK.
> 
> Is it that the filenames mentioned in the CGI script have
> SPACES in them? That might be the killer but if there
> are no spaces I'm curious as to why NTVDM might be
> falling down on the long/short filename translate.
> 
> Any chance you could post a copy of this funky CGI script?
> 
> Yours...
> Kevin Kiley
> CTO, Remote Communications, Inc.
> http://www.RemoteCommunications.com
> http://www.rctp.com - Online Internet Content Compression Server
>