fix: on Windows use UTF-8 strings instead of system default locale strings

[farfella]

The *A version of Windows API functions (e.g., CreateFileA, CreateEventA, etc.) operate on system locale strings and not UTF-8 strings. Furthermore, projects generated with cmake use multi-byte character set. So, CreateFile is defined as CreateFileA vs CreateFileW. This causes weird display and input issues observable by the end-user and reported as bugs.

In this PR, all these cases in the code (only osquery code and not externs) now call the *W versions of the Windows API functions, e.g., CreateFileW, CreateEventW, respectively, and then narrow them to UTF-8 using osquery's wstringToString.

In some cases, we can safely call the *A functions, so these were kept as is (that is, osquery is choosing the input and this input is correct with the *A functions).

Verified all test-cases passed locally.

[farfella]

Thanks @Smjert for your help with the Chrome extensions test! :)

[Smjert]

Thanks again for this effort!

[Smjert]

Last review round then I think it's good to go!
Please also remember to format the code :).

[farfella]

Last review round then I think it's good to go!
Please also remember to format the code :).

Haha! Thanks. Yeah... I just need to set up style-check validator locally. Relying on IDE works 95% of the time.

[Smjert]

Last review round then I think it's good to go!
Please also remember to format the code :).

Haha! Thanks. Yeah... I just need to set up style-check validator locally. Relying on IDE works 95% of the time.

We also have two CMake targets for this: format_check, which checks the code after everything has been committed and format, to actually format the code, but it has to be either in the stage area or unstaged.

[theopolis]

nitpick, this comment looks like the result of a stray copy-paste

[farfella]

Thanks! Updated.

[sroache]

I was testing with this branch to see if it would fix some unicode issues encountered and it fixed most of them!
However when I queried the file table for a path that contained Chinese characters I did not get the expected path returned
SELECT * FROM fiile WHERE path LIKE "C:\%\cmd.exe
Where I have copied cmd.exe into C:\Test and C:\新建文件夹 only returned the copy in C:\Test.
(Where "新建文件夹" was the "new folder" text after creating a folder on a Chinese machine)

My current guess is that it has something to do with converting from unicode to UTF-8 before checking if the path exists in WindowsFindFile (fileops.cpp). I think we would also probably need to keep the path as a unicode string when checking the constraint/regex.

[farfella]

Thanks for validating @sroache! I will take a look. It should call FindFirstFileW if it isn’t since FindFirstFileA is locale specific— I will check your case.

[farfella]

I confirm what @sroache is seeing: I'd prefer to fix this issue in another PR after this is merged in vs adding more changes to this PR.