Does ReactOS have a better and respectable UTF-8 support than Windows?/*
* MSAPI_UTF8: Common API calls using UTF-8 strings
* Compensating for what Microsoft should have done a long long time ago.
* Also see http://utf8everywhere.org/
Here you can discuss ReactOS related topics.
Moderator: Moderator Team
5 posts • Page 1 of 1
Reading from https://github.com/pbatard/rufus/blob/m ... api_utf8.h
When UTF-8 was first promoted in 1993, Microsoft Windows was already almost a decade old. Microsoft Windows XP was released in 2001, two years before UTF-8 was finalized as an international data processing standard. The ReactOS development team aims to support what ReactOS's implementation target (Windows XP) supports. Anything additional will probably have to come from additional code contributors or as a third-party add-on.
Last edited by middings on Fri May 10, 2019 12:58 am, edited 1 time in total.
Well here there is something useful:
[...]Win32 UTF-8 wrapper
Why a wrapper?
This library evolved from the need of the Touhou Community Reliant Automatic Patcher to hack Unicode functionality for the Win32 API into games using the ANSI functions.
By simply including win32_utf8.h and linking to this library, you automatically have Unicode compatibility in applications using the native Win32 APIs, usually without requiring changes to existing code using char strings.
In addition, this library also adds new useful functionality to some original Windows functions.
CreateDirectoryU() works recursively - the function creates all necessary directories to form the given path.
LoadLibraryExU() can be safely and unconditionally used with the search path flags introduced in KB2533623. If this update is not installed on a user's system, these flags are cleared out automatically.
GetModuleFileNameU() returns the necessary length of a buffer to hold the module file name if NULL is passed for nSize or lpFilename, similar to what GetCurrentDirectory() can do by default.
SHBrowseForFolderU() always displays an edit box and shows a resizable window if the active thread's COM settings allow it.
PathRemoveFileSpecU() correctly works as intended for paths containing forward slashes
UTF-8 versions of functions that originally only have UTF-16 versions
LPSTR* WINAPI CommandLineToArgvU(LPCWSTR lpCmdLine, int* pNumArgs)
Splits a UTF-16 command-line string (returned by e.g.GetCommandLineW()) into an UTF-8 argv array, and returns the number of arguments (argc) in pNumArgs. The caller has to free the returned array using LocalFree().
HRESULT WINAPI SHParseDisplayNameU(LPCSTR pszName, IBindCtx *pbc, LPITEMIDLIST *ppidl, SFGAOF sfgaoIn, SFGAOF *psfgaoOut)
Converts a path (pszName) to a ITEMLIST pointer (ppidl), required for a number of shell functions. Unlike the original function, this wrapper also works as expected for paths containing forward slashes.
win32_utf8 it meant to require at least Windows XP - that is, it statically references only Windows functions that were available on XP. Wrappers for functions that were introduced in later Windows versions load their original functions dynamically using GetProcAddress().
Users browsing this forum: Google [Bot] and 9 guests