kernel32 + user32: stub GetOEMCP / SetFileApisToOEM / CharToOem* / OemToChar*#119
Draft
HarryR wants to merge 1 commit intodecompals:mainfrom
Draft
kernel32 + user32: stub GetOEMCP / SetFileApisToOEM / CharToOem* / OemToChar*#119HarryR wants to merge 1 commit intodecompals:mainfrom
HarryR wants to merge 1 commit intodecompals:mainfrom
Conversation
…mToChar*
Several NT 3.5-era build tools (MC.EXE message compiler, RC.EXE resource
compiler, CL.EXE legacy front-end) probe the current OEM codepage and
apply ANSI<->OEM translation to argv and message payloads. Under wibo
the relevant stubs were unimplemented, causing "call reached missing
import" aborts on first use.
Add minimal, well-behaved stubs:
kernel32!GetOEMCP - returns 437 (IBM PC US), the canonical
OEM codepage for English locales.
kernel32!SetFileApisToOEM - no-op success (our Ansi<->Oem mappings
are effectively 1:1 for ASCII, which
is what NT build pipelines feed).
user32!CharToOem{A,BuffA} - ASCII-identity conversion; correct for
user32!OemToChar{A,BuffA} filenames/argv which are pure ASCII,
and a safe high-byte passthrough.
These cover the translation paths NT build tools actually exercise
without pulling in any codepage tables.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several NT 3.5-era build tools (MC.EXE message compiler, RC.EXE resource compiler, CL.EXE legacy front-end) probe the current OEM codepage and apply ANSI<->OEM translation to argv and message payloads. Under wibo the relevant stubs were unimplemented, causing "call reached missing import" aborts on first use.
Add minimal, well-behaved stubs:
kernel32!GetOEMCP- returns 437 (IBM PC US), the canonical OEM codepage for English locales.kernel32!SetFileApisToOEM- no-op success (our Ansi<->Oem mappings are effectively 1:1 for ASCII, which is what NT build pipelines feed).user32!CharToOem{A,BuffA}- ASCII-identity conversion; correct for filenames/argv which are pure ASCII, and a safe high-byte passthrough.user32!OemToChar{A,BuffA}These cover the translation paths NT build tools actually exercise without pulling in any codepage tables.