Convert Ebr* file apis to use wchar_t instead of char*

[rajsesh]

Currently, we have a stop gap with #1875 to support UTF8 characters, but there is back and forth conversion between UTF8 and UTF16 across the Ebr boundary.

• We can reduce these conversions and get better performance.
• We can finally support long paths (additional work needed).

[edvv]

@rajsesh-msft Can you please inform me about this: Are long paths only available with UTF16 API? I thought long paths was more a function of UWP settings and not a particular file system API.

[rajsesh]

https://msdn.microsoft.com/library/windows/desktop/aa365247.aspx#maxpath - this is new in the anniversary update (1607), we do need to support 1512 update for the immediate future. Also, the ascii version of the apis such as mkdir won't support > MAX_PATH. As such, all the Ebr apis use ascii versions of c runtime file apis, so all bets are off.

[edvv]

Ah. On Unix MAX_PATH is 1024. It appears that MAX_PATH is 260 on Windows - which is a pretty severe limitation. So, are you saying that if I convert to wchar_t API such as using _wmkdir() then I get a max math length of 32767?

That fact (if it is true?) is not mentioned at: https://msdn.microsoft.com/en-us/library/2fkk4dzw.aspx

[rajsesh]

@eddv a small correction - we did convert the path apis to use the _w version. If you set the manifest correctly you should have support for long path, but i haven't actually verified everything would work. This work is to avoid the unnecessary conversions as well as to ensure that long paths indeed works.