On 7/17/11 11:53 PM, Eli Zaretskii wrote:
> Could you please explain this part of the patch:
> 
>>    /* Create the dialog with PROMPT as title, using DIR as initial
>>       directory and using "*" as pattern.  */
>> -  dir = Fexpand_file_name (dir, Qnil);
>> -  strncpy (init_dir, SDATA (ENCODE_FILE (dir)), MAX_PATH);
>> -  init_dir[MAX_PATH] = '\0';
>> -  unixtodos_filename (init_dir);
>> -
>> -  if (STRINGP (default_filename))
>> -    {
>> -      char *file_name_only;
>> -      char *full_path_name = SDATA (ENCODE_FILE (default_filename));
>> -
>> -      unixtodos_filename (full_path_name);
>> -
>> -      file_name_only = strrchr (full_path_name, '\\');
>> -      if (!file_name_only)
>> -        file_name_only = full_path_name;
>> -      else
>> -	file_name_only++;
>> -
>> -      strncpy (filename, file_name_only, MAX_PATH);
>> -      filename[MAX_PATH] = '\0';
>> -    }
>> -  else
>> -    filename[0] = '\0';
>> -
>> -  /* The code in file_dialog_callback that attempts to set the text
>> -     of the file name edit window when handling the CDN_INITDONE
>> -     WM_NOTIFY message does not work.  Setting filename to "Current
>> -     Directory" in the only_dir_p case here does work however.  */
>> -  if (filename[0] == 0 && ! NILP (only_dir_p))
>> -    strcpy (filename, "Current Directory");
>> +  to_unicode (Fexpand_file_name (dir, Qnil), &dir);
>> +
>> +  to_unicode (build_string ("All Files (*.*)\0*.*\0Directories\0*|*\0\0"),
>> +              &filter);
> 
> AFAICT, to_unicode encodes the file name in UTF-16.  If so, this will
> not work in the native Windows build, because it does not use Unicode
> APIs for file names.

Not today, no.

> In the original code, ENCODE_FILE would use the
> ANSI encoding, not UTF-16.  So, unless I'm missing something, the
> replacement is not equivalent to the original, and could break the
> native build.

Yes, the change would make Emacs Unicode-only --- but every Windows OS
in common use supports unicode.  Why would requiring unicode support be
a problem? IIUC, Unicode is strictly a superset of all the single-byte
encoding schemes supported by Windows.

> If my analysis is correct, could you please explain the rationale for
> this change?

The change needed to be made anyway --- we need to translate between NT
and Cygwin paths now --- so why not transition to unicode at the same
time?  (I want to stub out the path conversion functions for native NT
builds.)