Re: [openvrml-develop] parse-vrml97.exe crash

[Braden M. <br...@en...>]

On Sat, 2010-07-03 at 20:55 -0400, Sam Url wrote: 
> >> -rw-r--r-- braden/users 4598 2009-07-04 17:20 openvrml-0.18.6/ide->>projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
> 
> 
> Well, that's strange.  This pathname is only 115 characters.  Windows can support up to 260 characters for MAX_PATH:

Windows can actually support path lengths a good deal longer than that;
but various tools impose an artificial restriction because they use an
obsolete API.

> "openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-environmental-effects\x3d-environmental-effects.vcproj"
> 
>  
> 
> Length of the path should not be a problem here.

As far as Windows' limitation is concerned, it shouldn't--in theory.
But I wonder if the path to the current working directory has any
bearing on this.

> I also tried GnuWin32 tar and gzip commandline tools, and it still doesn't list those files.

Now that's especially interesting; because GnuWin32 tar should (I think)
be the same codebase as Cygwin GNU tar (which is the same codebase as
Linux GNU tar).  That sort of thing makes me suspect that this might, in
fact, be an issue of the affected programs using an (arguably
malfunctioning) Windows POSIX API that's imposing an artificially short
path length.

For what it's worth, I think I've decided to move the Visual C++ project
files under the src directory in the distribution to be near their
related source files.  The main reason for not doing this in the past
was some anticipation that lots of (possibly conflicting) project files
might be maintained.  In practice, that hasn't happened.  In particular,
there's never been sufficient interest to maintain project files for
more than one version of Visual C++.

So I'll be making that change when migrating to Visual C++ 2010.  But
there needs to be a Boost release with a shared_mutex that works with
that compiler before I can make an OpenVRML release with Visual C++ 2010
project files.

-- 
Braden McDaniel <br...@en...>