[Bug 59127] New: ntdll: manifest activeCodePage Legacy value handling doubts (hardcoding)
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: wine-bugs@list.winehq.org Reporter: andi@rhlx01.fht-esslingen.de 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.
http://bugs.winehq.org/show_bug.cgi?id=59127 Andreas Mohr <andi@rhlx01.fht-esslingen.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |11.0-rc1 Keywords| |localization -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59127 --- Comment #1 from Andreas Mohr <andi@rhlx01.fht-esslingen.de> --- "The activeCodePage manifest element can be used for more than just setting UTF-8 as the active code page" https://devblogs.microsoft.com/oldnewthing/20220531-00/?p=106697 appears to be exactly about describing that behaviour: "If you specify an activeCodePage of Legacy, then you’re saying that your application actively hates UTF-8. It will be given the system default locale, provided a system default local exists and it isn’t UTF-8. In those exceptional cases, you get code page 1252 as a fallback. You can also specify a locale name such as en-US or ja-JP, and the application gets the code page corresponding to that locale. If the locale is not recognized by the system, then you get UTF-8 as a fallback.". So, this: - appears to confirm my writing - most likely is what this implementation ought to do -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59127 --- Comment #2 from Alexandre Julliard <julliard@winehq.org> --- (In reply to Andreas Mohr from comment #1)
So, this: - appears to confirm my writing - most likely is what this implementation ought to do
It's actually what it does. Do you have a real use case where it doesn't work? -- 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.
participants (1)
-
WineHQ Bugzilla