I have always just used the ascii version of functions and never used the unicode versions at all. But I'm wondering if I need to use the unicode version of CreateFile for compatibility? What if the user has created a filename with unicode characters then will CreateFileA not work?
Posted on 2004-02-18 08:53:50 by ENF
The Unicode version of CreateFileA (CreateFileW) can open any file just as it's ANSI couterpart can. The data in the file is unaffected by the API that was used to open it. It just requires that the name of the file be passed in a Unicode string. On systems like Windows 2000 or XP this can save alot of time. If you look at the functions for the ANSI wrappers in NT.DLL you will find that mostly they make a call to MultiByteToWideChar to translate the string to Unicode before every call. By using Unicode directly you can bypass this speeding up things significantly. However, if you are using MASM you should use NaN's unicode macros or better yet switch to an assembler like GoAsm that has Unicode support built in. If you plan on using the application in Win9x many of the functions do not have a Unicode equivalent in those versions but you can use MSLU (Microsoft Layer for Unicode) to provide wrappers so your program will work with them.
Posted on 2004-02-18 12:20:49 by donkey
thanx donkey

so are file names always stored on the hardisk as unicode on 2k/xp systems and ascii on 9x?
Posted on 2004-02-18 13:21:34 by ENF
I am not sure about that, it is just that the primary interface to the Windows API in W2K and XP is Unicode so ansi functions are wrapped and translated to Unicode, the Unicode version of the function is then called. For example if you execute GetStatusTextA this is the first few commands

invoke lstrlenA,[pString]

mov esi,eax
lea eax,[esi*2+2]
invoke LocalAlloc,040h,eax
mov edi,eax
<test for zero>
invoke MultiByteToWideChar,CP_ACP,1,[pString],esi,edi,esi


As you can see there is an extraneous call to MultiByteToWideChar.
Posted on 2004-02-18 13:28:06 by donkey
NTFS supports Unicode file names, but I believe FAT32 does not. Win9x does not support NTFS. However, a Unicode layer for Win9x is now available for download from MS. The Unicode layer replaces the Unicode "stub" code that returns failure (and setting the error code to "not implemented") in Win9x.
Posted on 2004-02-18 20:30:28 by tenkey
AFAIK LFN entries are always UNICODE, on both FAT16 and FAT32.
So the only limitation would be imposed by the API, not the filesystem.
Posted on 2004-02-20 05:00:58 by Hawkuletz