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

[TO...@aol.com]

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

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
>