[Bug 59127] New: ntdll: manifest activeCodePage Legacy value handling doubts (hardcoding)

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59127

            Bug ID: 59127
           Summary: ntdll: manifest activeCodePage Legacy value handling
                    doubts (hardcoding)
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ntdll
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Hi,

filing this from an outside context (simply from observations made with some
app, on _Windows_ - NOT _Wine_) - hrmm "bug writing guidelines"? ;-).

https://gitlab.winehq.org/wine/wine/-/commit/967ef0bf41fc6742398313ebdebd681...
implemented _activeCodePage_ _Legacy_ value handling as such:


`
+        else if (!wcsicmp( locale, L"legacy" ))
+        {
+            if (ansi_cp == CP_UTF8) ansi_cp = 1252;
+            if (oem_cp == CP_UTF8) oem_cp = 437;
+        }
`

_AFAIK_ this does not match actual behaviour, on Windows 10/11.
With manifest `activeCodePage` value `Legacy` config and
ACP UTF-8 config setting state enabled (regional settings UTF-8 Beta checkbox
*checked*)
on a German system (i.e. the manifest properly influencing
app-specifically-scoped state), one will get:
`GetACP()` 1252
`GetOEMCP()` 850

This quite possibly is
because the system (well, _Windows_) in case of _Legacy_ possibly simply
does the sensible/expected thing:
possibly something like grabbing the default locale state, its corresponding
locale map container index, and getting `idefaultansicodepage` and
`idefaultcodepage` state of that container element.

_IOW_, probably very much like `locale_init()`s handling:

    entry = find_lcid_entry( locale_table, system_lcid );
    ansi_cp = get_locale_data( locale_table, entry->idx
)->idefaultansicodepage;
    oem_cp = get_locale_data( locale_table, entry->idx )->idefaultcodepage;

Assigning Severity major since
this seems to be a relatively important/global CORRUPTION-level bug
(all non-CP1252 system configurations - e.g. Asia, Russia, or whatever -
running with an encoding that could be characterized as unexpected/improper
*)).
NOPE, not assigning major (since
this is more limited scope:
only relevant to manifest-enabled applications)

*) while with properly obeyed _ACP_ protocol behaviour (i.e., application
obeying _ACP_ state and properly doing transcoding where it matters), there
shouldn't be raw CORRUPTION occurring, this still is problematic (especially
since legacy encodings very often do not have fully precise and bijective
mapping capabilities when transcoding)

Greetings

Andreas

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.