On Sat, Oct 04, 2008 at 06:31:37PM +0200, Abdelrazak Younes wrote: > On 04/10/2008 18:22, Peter Kümmel wrote: >> Abdelrazak Younes wrote: >>> On 04/10/2008 14:13, Peter Kümmel wrote: >>>> Until we know a better way to get the long path name >>>> I've checked in the patch: >>>> http://www.lyx.org/trac/changeset/26718 >>>> (bug http://bugzilla.lyx.org/show_bug.cgi?id=4693) >>> >>> Why did you you choose the 8bit encoding version? I'd prefer that you >>> use the wide version of it because I am forecasting that this will >>> not work for non latin file names, or just use the same macro as >>> what's done in the Qt source. >> >> Does this mean the lyx code is also wrong? > > Yes, or at least outdated. > >> Or is the comment correct? >> "// We can use to_local8bit, since file system encoding and the >> // local 8 bit encoding are identical on windows." > > The comment was correct in a latin world and for pre Win2000 system > (Win9x). AFAIK since Win2000, the filesystem uses utf16 so there is no > such thing as 8bit encoding. Provided that we don't support Win9x I'd > prefer that we switch to the wide version.
Note that we probably do not handle command line arguments properly either. Last time I stumbled over it, argv was already destroyed when main() is entered, and one had to use CommandLineToArgv or such to get unmutilated data. Qt's tools use their own "parser" in src/corelib/kernel/qcorecmdlineargs_p.h (QStringList qCmdLineArgs(int argc, char *argv[]) ) but that's not part of the public API. Andre'
