[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"

I'm really wondering what these "NULL" pointer values are for.... (especially since it is some hackish value like FFFFFB or so, according to the precomp.h)...

I'm really wondering what these "NULL" pointer values are for.... (especially since it is some hackish value like FFFFFB or so, according to the precomp.h)...

"Failed to allocate..."

"Failed to allocate..."

What's this hack about, exactly?

What's this hack about, exactly?

"Deallocate the report description if we failed". Note also that there's a bug, namely that if we indeed failed, then FDODeviceExtension->ReportDescriptor is going to point to an invalid memory area.

"Deallocate the report description if we failed".
Note also that there's a bug, namely that if we indeed failed, then FDODeviceExtension->ReportDescriptor is going to point to an invalid memory area.

"Save the report descriptor in the device extension".

"Save the report descriptor in the device extension".