Why ANSI str in _WinAPI_GetDiskFreeSpaceEx, _WinAPI_OemToChar, etc.?

[Norman_Diamond]

Most stuff in AutoIt seems to use wstr which I think is the right way to do it in Windows in this millennium.  A few Windows APIs are stuck with ANSI (multibyte) but most have Unicode versions.

In WinAPIFiles.au3, _WinAPI_GetDiskFreeSpaceEx calls GetDiskFreeSpaceEx with a str parameter.  MSDN says there exist GetDiskFreeSpaceExA and GetDiskFreeSpaceExW. I didn't try looking for plain GetDiskFreeSpaceEx.  Why not call GetDiskFreeSpaceExW with a wstr?

In WinAPIMisc.au3, _WinAPI_CharToOem calls CharToOemW with two wstr parameters.   But _WinAPI_OemToChar calls OemToChar with two str parameters.  Both seem not quite right.  MSDN says that CharToOem and OemToChar both exist as ANSI and Unicode versions (with secret function names so we have to experiment and rely on undocumented behaviour).

CharToOem takes a LPCTSTR source and LPSTR destination.  I think _WinAPI_CharToOem has to call CharToOemW with a wstr source and str destination.  Depending on who uses the result, I have a feeling it might be useful to call MultiByteToWideChar on the result so that a wstr gets translated to another wstr.  In Japanese this would result in an identity transformation but of course the real need for OEM characters is to access old style filenames in some of Microsoft's single-byte ANSI code pages.  Maybe the multibyte str result should be left as a str; I'm not sure.

OemToChar takes a LPCSTR source and LPTSTR destination.  If OemToCharW is called then the source should be str and the result should be wstr.  I haven't looked to see if plain OemToChar is a synonym for OemToCharA, but even if it is, the usage seems counterproductive.  I think callers usually have wstr variables and want OemToCharW to be called.  Again, I'm unsure if callers would want to use two wstr parameters and want _WinAPI_OemToChar to call WideCharToMultiByte before calling OemToCharW.  Again in Japanese this would result in an identify transformation but the real need for OEM characters is to access old style filenames in some of Microsoft's single-byte ANSI code pages.

In WinAPICom.au3, _WinAPI_ReleaseStream calls DispCallFunc with an str parameter at the end.  I can't figure out if it would be safe to make it a wstr parameter instead.

[Norman_Diamond]

I think I finally figured out what a program was trying to do, and probably what most of your users would be trying to do.  I think you aren't fiddling with the binary format of directory entries (folder structures) in FAT32/FAT16/FAT12 partitions.  I think you want to read or write the contents of files.

If a text file is stored in Unicode, which is still a bit unusual, then a program just reads and writes the contents using wstr variables and no conversion is needed.

If a text file is stored in an ANSI code page (multibyte), which is still common for the contents of files in disks, strings being transmitted over local networks, and text user interfaces in command prompt windows, then a program wants to use wstr internally but convert to or from str for I/O.  So the program never wants OEM code pages, it only wants ANSI code pages for text being read or written.  You want to provide functions _WinAPI_MutliByteToWideChar and _WinAPI_WideCharToMultiByte which call the corresponding Windows APIs.  In these APIs, an ANSI code page doesn't really have to be multibyte, it can be single-byte, even though the phrase MultiByte is part of the API name.

I think you should still repair the internals of _WinAPI_CharToOem and _WinAPI_OemToChar to pass parameters correctly, but I don't think any ordinary program should ever call them.  Ordinary programs would want to call _WinAPI_MutliByteToWideChar and _WinAPI_WideCharToMultiByte.

(Windows still forces you to use ANSI strings in stuff like dbghelp as you already know, and GetProcAddress.)