[CMD]: Improvements for the CHCP command.

- Display the informative CP-change message on stdout, using the *output* code page (and not the input CP);

- Correctly update the local codepage cache;

- Display the informative CP-change message when the CP change succeeded;

- Add source comments + informative TODO for what remains to be done.

    • -15
    • +29
    /trunk/reactos/base/shell/cmd/chcp.c
[KERNEL32]: Add/update localized codepage display names.

- Slightly update the description of CP 28599;

- Add descriptions for CPs 28600, 28603, 28604 and 28606;

- Add CP 856 "OEM - Hebrew PC" (which differs from OEM Hebrew CP 862).

Note that while we also have codepages 424, 878 and 1006, I don't add their description because:

- CP 424 is actually CP 20424 "IBM EBCDIC - Hebrew" on Windows (documented in the resource files);

- CP 878 is actually CP 20866 "Russian - KOI8" on Windows (documented in the resource files);

- CP 1006 seems to be "IBM Arabic" according to Wine, but I don't know its corresponding number on Windows.

[KERNEL32]: Little improvements/fixes for GetCPInfoExW and GetGeoInfoW:

- Rework GetLocalisedText helper such that it looks more like LoadStringW. Also, if the string is not found (either because there is no associated string table, or because its resource length is zero), then return zero.

Otherwise we return the correct number of characters copied into the user buffer, not counting the NULL terminator.

This fixes the blank strings showing in the list of codepage user-friendly names in the console properties dialog.

- Simplify the code of NLS_GetGeoFriendlyName: we can directly use the user-provided buffer to retrieve the string.

Addendum to r65157.

CORE-13130 #resolve

[KERNEL32]: Add the Brunei in the list of localized countries.

Translators, please localize the name!

[COMMAND]: Disable COMMAND.COM debugging messages by default.

Disable again this #define if you want to get the dbg messages back.

CORE-10710

    • -1
    • +1
    /trunk/reactos/subsystems/mvdm/dos/command.S
[CONSOLE.CPL]: Simplify some parts of font.c code.

- Use a helper function "AddFontToList" to add font names into the font list;

- Use string-safe functions where needed.

    • -1
    • +3
    /trunk/reactos/dll/cpl/console/console.h
    • -57
    • +49
    /trunk/reactos/dll/cpl/console/font.c
[ACCESS]: Fix french el-typo, noticed by Kyle Katarn. Thanks!

CORE-12482

    • -1
    • +1
    /trunk/reactos/dll/cpl/access/lang/fr-FR.rc
[CONSOLE.CPL]: Addendum to r74397: Fix a cast.
    • -1
    • +1
    /trunk/reactos/dll/cpl/console/options.c
[CONSOLE.CPL]: Add a list of available code pages in the console properties dialog.

Display a list of available code pages, as done on Windows (NT/2k/2k3/Vista/7/8, when a CJK language is selected, and as always done on Windows 10 for all languages).

But contrary to Windows, do not limit this list to only CJK + CP-437 codepages, but list *all* the available CPs, retrieved from the registry. These CPs are also those available when using the "chcp" or "mode con cp" commands.

And contrary to Windows (where this is done only for the general console properties), always allow the user to view or change the code page even from the console properties dialog.

[CONSRV]: Support changing the current code page from the console properties dialog.

CORE-12451

    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/de-DE.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/it-IT.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/ru-RU.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/uk-UA.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/es-ES.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/pl-PL.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/zh-CN.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/bg-BG.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/he-IL.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/no-NO.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/cs-CZ.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/en-US.rc
    • -0
    • +2
    /trunk/reactos/dll/cpl/console/lang/ja-JP.rc
  1. … 11 more files in changeset.
[INPUT.CPL]

- Remove an unneeded header inclusion;

- Fix a sizeof invocation;

- RegEnumKeyExW and RegEnumValueW take their fourth parameter (size of key / value name, resp.) as a size in number of *characters* (and not in number of bytes);

- Add a missing RegCloseKey call in LocaleList_Create.

    • -2
    • +2
    /trunk/reactos/dll/cpl/input/layout_list.c
    • -2
    • +4
    /trunk/reactos/dll/cpl/input/locale_list.c
[CONCFG]: Addendum for r74366: Initialize the console settings information codepage with the current OEM codepage, and read the optional console "CodePage" DWORD registry setting.

CORE-12451

[CONCFG]: Use 'Success' boolean variable instead of an obscure 'RetVal'.
[CONSOLE.CPL]: Paint the text samples using the correct character set (derived from the current code page).

This e.g. fixes display for the backslash symbol in CJK languages (that should appear as the Chinese "yuan" / Japanese "yen" currency symbol ¥, or the Korean "won" currency symbol ₩).

CORE-12451

    • -2
    • +3
    /trunk/reactos/dll/cpl/console/options.c
    • -3
    • +3
    /trunk/reactos/dll/cpl/console/layout.c
[CONSOLE.CPL]: Add support for Asian fonts & CJK codepage in the console properties dialog.

Based on a patch by Katayama Hirofumi MZ.

CORE-12451

    • -0
    • +2
    /trunk/reactos/dll/cpl/console/console.h
    • -27
    • +81
    /trunk/reactos/dll/cpl/console/font.c
[CONSOLE.CPL]: Code formatting only (in preparation of a subsequent commit).
    • -5
    • +10
    /trunk/reactos/dll/cpl/console/font.c
  • More
  • CR-112
  • resumed reviewing
(Question related to the one in font.h): aren't "IsTrueType" and "IsVertical" somehow 'characteristics' flags?

(Question related to the one in font.h): aren't "IsTrueType" and "IsVertical" somehow 'characteristics' flags?

Aren't we going to mix wine-style debugging and DPRINT(1)'s?

Aren't we going to mix wine-style debugging and DPRINT(1)'s?

General question: These properties (TrueType, Vertical, ...) are not encoded in the 'Characteristics' field?

General question: These properties (TrueType, Vertical, ...) are not encoded in the 'Characteristics' field?

"IsChirpHandled"? or "HandleChirp" (and then 1 would be TRUE ?)

"IsChirpHandled"? or "HandleChirp" (and then 1 would be TRUE ?)

At least, websites won't look shitty anymore when being viewed from within ReactOS! https://code.reactos.org/static/olpro3/2static/images/wiki/icons/emoticons/biggrin.gif

At least, websites won't look shitty anymore when being viewed from within ReactOS!

Comment formatting https://code.reactos.org/static/olpro3/2static/images/wiki/icons/emoticons/tongue.gif

Comment formatting

A general question about this (not related to the particular problem this patch tries to solve): Is FreeType lib still thread-unsafe?

A general question about this (not related to the particular problem this patch tries to solve): Is FreeType lib still thread-unsafe?

Shouldn't it be added inside the code of GDI_CleanupForProcess ?

Shouldn't it be added inside the code of GDI_CleanupForProcess ?

Don't we need later to know what the size of the Buffer pointed to, is? (if so, a SIZE_T BufferSize; somewhere in this structure would be needed then).

Don't we need later to know what the size of the Buffer pointed to, is? (if so, a SIZE_T BufferSize; somewhere in this structure would be needed then).

When compiling under the DDK/WDK environment (& using MSVC), this environment changes the compiler's default calling convention to __stdcall instead of the default __cdecl. As such, all the functio...

When compiling under the DDK/WDK environment (& using MSVC), this environment changes the compiler's default calling convention to __stdcall instead of the default __cdecl. As such, all the functions of driver code that is compiled under DDK/WDK environment, be they exported or internal to drivers code, use __stdcall.
Now, generally, whether the calling convention of internal functions is __stdcall or __cdecl or whatever else, does not really matter. The actual thing that matters, however, is the calling convention of the exported functions.
Most, if not all functions declared in the DDK/WDK MS headers (and corresponding to exported functions from ntoskrnl, hal, etc...) do not mention explicitely that they are __stdcall , but they are. Therefore it is by pure chance that driver code using these headers compile and actually run fine on Windows, because these headers suppose that they are compiled under the DDK/WDK environment where the __stdcall convention is the default.
Now, if you use these MS WDK/DDK headers in another setup (MSVC with __cdecl by default, or GCC, ...), then you're f*cked up, because you're then using functions that are now declared implicitely in __cdecl, and then your driver would be calling exports with __cdecl convention instead of __stdcall, and therefore kaboom

The UNIMPLEMENTED macro now needs a terminating semi-colon (as every other valid "instruction").

The UNIMPLEMENTED macro now needs a terminating semi-colon (as every other valid "instruction").

Maybe using an enumeration would be better?:Unable to find source-code formatter for language: c. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml typedef enum {...

Maybe using an enumeration would be better?:

Unable to find source-code formatter for language: c. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
typedef enum
{
    STARTING = 1,
    RUNNING,
// etc...
} HIDUSB_STATE;

and then using a HIDUSB_STATE variable in your structure below... What do you think about this?

Use a for-loop instead~~~~

Use a for-loop instead~~~~

"Now allocate the array of HIDCLASS_COLLECTIONs"

"Now allocate the array of HIDCLASS_COLLECTIONs"