UTF-8 and conversions to and from a multitude of other encodings, including UTF-16 and even UTF-7 are fully supported since Windows 2000.<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072%28v=vs.85%29.aspx|title=MultiByteToWideChar function (Windows)|publisher=Microsoft Corporation|accessdate=2015-05-13}}</ref>
Although the locale can be set so the "M" encodings handle ''some'' multi-byte encodings, it is not possible to set them to support [[UTF-8]] (attempts to use the locale id passed to MultiByteToWideChar for UTF-8 are ignored). As many libraries, including the standard C and C++ library, only allow access to files using the "M" api, it is not possible to open all Unicode-named files with them. Thus Unicode is not supported by Windows in software using a portable API.
There are proposals to add api to portable libraries such as [[Boost (C++ libraries)|Boost]] to do the necessary conversion, by adding new functions for opening and renaming files. These functions would pass filenames through unchanged on Unix, but translate them to UTF-16 on Windows.<ref>{{cite web|url=http://cppcms.com/files/nowide/html/|title=Boost.Nowide}}</ref>
Many applications imminently have to support UTF-8 because it is the most used of Unicode encoding schemes in various [[network protocol]]s, including the [[Internet Protocol Suite]]. An application which has to pass UTF-8 to or from a "w" [[Windows API]] should call the functions [[MultiByteToWideChar]] and WideCharToMultiByte.<ref>{{cite web |url=http://stackoverflow.com/questions/166503/utf-8-in-windows |title=UTF-8 in Windows |publisher=[[Stack Overflow]] |accessdate=July 1, 2011}}</ref> To get predictable handling of errors and surrogate halves it is more common for software to implement their own versions of these functions.
