Absolute agony to pass strings around in React Native Windows from JS, to UWP, to Win32, between WinRT and WAPI. Worst part of coding for Windows.
The rest of the Windows runtime, though, is really quite nicely designed and documented, compared to Apple’s last-minute homework.
Windows is silly.
Using the Windows API (WINAPI, historically called WIN32API, to distinguish it from the deprecated WIN16API) has some unusual things. For example, if you want to create a file using the Windows API you use CreateFile
However, if you lookup CreateFile on MSDN (Microsoft Development Network) you'll see there are two versions of CreateFile
- CreateFileA
- CreateFileW
When you code in C/C++ and type "CreateFile", depending on your compiler settings, it will default to either CreateFileA or CreateFileW
Why the FUCK does Windows have CreateFileA/W?
Because things are very silly. CreateFileA means ANSI. CreateFileW means WIDE (Wide character, Unicode support).
Way back in the day, in 16-bit Windows, Windows wanted to implement characters other than the English alphabet (such as Japanese, Mandarin, Russian, etc). They decided to make non-English alphabet stuff in equal size buffers (WIDE, UTF-16).
For backwards compatibility, however, Windows could not simply force UNICODE onto everything because it would break existing applications. Instead they opted to make 2 variants of every function which details with strings (A/W).
Interestingly, if you invoke CreateFileA under the hood Windows will transform the ANSI string into a UNICODE string. In other words, when you invoke CreateFileA the Windows OS turns the ANSI string into a UNICODE string then invokes CreateFileW. The OS then reverts the UNICODE string back to an ANSI string for your application which called CreateFileW
- CreateFileA(FilePath)
-- MultiByteToWideChar(FilePath to UNICODE)
--- CreateFileW(FilePath) (More internal stuff)
-- WideCharToMultiByte(FilePath back to ANSI)
- CreateFileA(FilePath)
Let's get even MORE silly. When dealing with strings on Windows you have
CHAR (ANSI)
WCHAR (UNICODE)
TCHAR (Ambiguous, Transitional CHAR)
When programming on Windows, and you're not sure what the compiler settings are (defaulting to ANSI or UNICODE) developers can use TCHAR. With TCHAR the compiler will resolve to the correct data type.
An example of this silliness can be seen in official Microsoft documentation. Windows has CreateProcessA and CreateProcessW (for reasons described above). In the examples from Microsoft they use LPTSTR (Long Pointer Transitional Character String) when using CreateProcess.
In the example, LPTSTR will resolve to either:
- CHAR* FilePath = 0;
or
- WCHAR* FilePath = 0;
Depending on compiler settings.