Page 1 of 1

ReactOS full UTF-8 support?

Posted: Mon Feb 25, 2019 10:54 pm
by Quim
Reading from ... api_utf8.h
* MSAPI_UTF8: Common API calls using UTF-8 strings
* Compensating for what Microsoft should have done a long long time ago.
* Also see
Does ReactOS have a better and respectable UTF-8 support than Windows?

Re: ReactOS full UTF-8 support?

Posted: Tue Feb 26, 2019 1:58 pm
by middings
Well-tested code that is well-written and conforms to ReactOS coding standards is the sincerest form of feature request.

Re: ReactOS full UTF-8 support?

Posted: Tue Feb 26, 2019 2:51 pm
by erkinalp
This is GPLv3, ReactOS is GPLv2. We cannot distribute them together.

Re: ReactOS full UTF-8 support?

Posted: Sat Mar 02, 2019 12:43 pm
by middings
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.

Re: ReactOS full UTF-8 support?

Posted: Mon May 06, 2019 7:05 am
by Quim
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.

Extended functionality
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.

OS compatibility
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().