Hi Hanzac,
I'm changing the ISO 9660 driver to ignore and propagate any illegal
character in file names, instead of halting the processing with an
error.
About the floppy image you sent me, with file names including Chinese
characters, the problem is due to the internal character set conversion
the FAT driver does. This is an old problem we already discussed, I'm
browsing the list archive. I'm currently assuming that short file names
are stored in CP437 character set (will become a mount parameter). I
always convert everything to widechars for internal processing. Before
returning the short file name to the DOS find APIs, I convert it to the
character set used by the DPMI driver, that is currently assumed to be
UTF-8. This causes any character with code >= 128 to become multibyte,
overflowing the 13-byte buffer of the DOS API and failing with
ENAMETOOLONG.
I tested on a Windows XP machine, and it also converts between the
character set assumed for the FAT file system (CP850 there) and the one
used by the console or application. This applies to the FindFirstFileA
and FindNextFileA Win32 APIs. I can't test what happens when the target
character set causes any character to become longer than in the source
character set because I'm not able to find/set an appropriate target
character set for testing (nice, three rows starting with "character
set" BTW ;-).
If you can test under Windows, please let me know (a screenshot is also
welcome) how a "dir a: /x" is supposed to behave on your system, and
the result of a test program like the following:
>>>
#include <windows.h>
#include <stdio.h>
int main()
{
WIN32_FIND_DATA fd;
UINT a = GetConsoleCP();
UINT b = GetConsoleOutputCP();
BOOL c = AreFileApisANSI();
HANDLE h = FindFirstFile("a:\\*.*", &fd);
while (FindNextFile(h, &fd))
{
printf("\"%s\" \"%s\"\n", fd.cFileName, fd.cAlternateFileName);
for (unsigned k = 0; k < sizeof(fd.cAlternateFileName); k++)
printf("%02X(%c) ",
(unsigned char) fd.cAlternateFileName[k],
fd.cAlternateFileName[k]);
printf("\n");
}
FindClose(h);
system("chcp");
system("pause");
return 0;
}
<<<
In cAlternateFileName I get bytes converted to the Windows ANSI code
page (CP1252 IIRC) apparently using a "best match" algorithm against
the "original" CP850 bytes (e.g. box drawing characters converted to
"+" and "-").
Thanks,
Salvo
--
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
freedos-32-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-32-dev
