On Mon, 09 May 2011 18:38:53 -0400, Richard Hipp <[email protected]> wrote:
> [...]
> Perhaps my windows i18n strategy is wrong. Perhaps I should only convert
> from utf8 to mbcs before making system calls (fopen(), unlink(),
> opendir(),
This is perhaps the greatest concern, since garbled Unicode filenames in a
big checkin are likely to go unnoticed until it is too late. The way to
go here is not conversion to local codepage, but rather conversion to
UTF-16 and usage of xxxW() functions. Off the top of my head, SQLite’s
os_win.c has some good code to borrow on this point!
> etc) and should not try to do mbcs-to-utf8 conversion for command line
> input
Besides what other persons have suggested, I once began trying to work out
my own Windows UTF-8 main() replacement using something along the lines of:
xyz = CommandLineToArgvW(GetCommandLineW(), &abc);
…and then converting the output thereof from UTF-16 to UTF-8. Potential
problems:
* Apparently, the output of CommandLineToArgvW() *lacks* a NULL at the
end of the array (i.e., equivalent of the usual argv[argc] == NULL).
* The pointer returned by CommandLineToArgvW() needs to be freed with
LocalFree() to avoid leakage.
* I have not verified it works any better than using _tmain(). For all
I
know, _tmain() might use this internally. I was more interested in
getting argv passed from Windows Explorer or from other programs in a
script, as (per the below) I gave up on cmd.exe Unicode handling long ago.
GetCommandLineW()
http://msdn.microsoft.com/en-us/library/ms683156.aspx
CommandLineToArgvW()
http://msdn.microsoft.com/en-us/library/bb776391.aspx
> or utf8-to-mbcs conversion for command-line output. Instead, of
> converting
> input and output, simply ask the user to run "chcp 65001" prior to
> running
> Fossil?
>
> Or, perhaps the command-line is just hopelessly broken on windows and we
> should simply ignore this problem all together? Just say that Fossil
> works
> in all languages on unix and in English for windows?
As an experienced Windows user, I avoid putting any non-ASCII characters
through the vagaries of cmd.exe. Perhaps there is a *good* way to do
this, but I have not found it. In Fossil, I edit commit messages in a
UTF-8 editor—even for basic punctuation (e.g., ’—“”)—and simply hope that
I will not need to handle any files with Unicode filenames.
That, again, is the greater concern—involving not only the console
interface, but also stdio functions. As to the latter, wrapping WinAPI
functions and juggling between UTF-8 and Windows’ UTF-16 is tedious; but
it really a matter of data integrity.
P.S.—I am using Fossil compiled with MSVC2010 (via the Windows SDK, not
actual Visual Studio). It works great (thanks, Rene!). Please don’t
cause any new MinGW dependencies while revising Windows-specific bits.
Also by the way, I never had a problem passing a * character for fossil
set crnl-glob; that is not a Windows problem, but rather probably a MinGW
bug.
Very truly,
SAMUEL ADAM ◊ http://certifound.com/ ◊ I read list mail sporadically.
763 Montgomery Road ◊ Hillsborough, NJ 08844-1304 ◊ United States
April 15, 2011 Courtroom Video in re Adam v. Supreme Court of N.J.:
http://www.youtube.com/watch?v=GPw2W2-Ujyc
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
