Dewey Allen wrote:
>
> The following example script runs (and sometimes crashes) but for
> filenames with only ANSI characters, $FileInfo->{cFileName}, seems to
> contain only the first character. And for filenames that start with
> unicode, wide characthers, $FileInfo->{cFileName}, seems to contain
> only the leading unicode/wide characters. In the data dump output, the
> buffer seems to show the full 16bit unicode file name (e.g.,
> "t^!k i<ŠeQ›R_ H o s t I D _ 2 0 0 6 - 0 1 - 1 9 _ 2 1 4 3 5 8 . x l
> s"). I suspect that the spaces between the ANSI characters are null
> (\0) characters. And I suspect that the Perl Win32 interface layer
> treats these as null terminated C strings -- as opposed to 16 bit
> unicode characters -- and therefore terminates the string at the first
> null byte it encounters.
That's right - every other character is a null.
> Various Perl unicode documents indicate that the Win32 API unicode
> format is UTF-16LE. But decoding "$FileInfo->{cFileName}" using
> UTF-16LE doesn't seem to work any way that I've tried it.
>
> I'm also not sure of the proper array dimension for cFileName (and
> cAlternateFilename) in the WIN32_FIND_DATAW struct. In the ANSI version
> of this structure, cFileName is a TCHAR of dimension 260 (MAX_PATH)
> where TCHAR is a single byte (according to Win32:API::Type->sizeof). In
> the WIDE version (WIN32_FIND_DATAW, it's a WHCAR of the same dimension
> -- but WCHAR is 2 bytes. When I make cFileName and cAltnerateFile
> TCHARs of dimension 260 and 14 respectively, Perl crashes. And it also
> crashes when I make them WCHARs of the same dimension. Only when I
> double the dimensions to 520 and 28 does the script run without crashing
> - using either TCHAR or WCHAR.
>
> Any ideas on how to make these functions work correctly would be greatly
> appreciated. And if I'm missing something obvious or doing something
> dumb, please don't hesitate to point that out :-).
I would drop the use of the 'struct' and pack a pointer to your own block of
packed data. Win32::API::Struct is buggy and isn't handling the unpack of the
array properly - do the packing and unpacking yourself.
