Repository navigation
Conversation
Add a Wine-compatible system error message table, named FormatMessageA flags, and regression coverage for FORMAT_MESSAGE_FROM_SYSTEM lookups. Insert sequences are not processed; the table's messages contain none.
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
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.
@ethteck @encounter the missing
FormatMessageAseems to be stuck issue. The current version is commented out and has only theFORMAT_MESSAGE_FROM_SYSTEMpath implemented, with system messages coming from the host system rather than true Windows errors, and no tests. With this PR, I tried to keep the change "minimal": the goal was to keep the scope confined toFORMAT_MESSAGE_FROM_SYSTEMflag, but with proper messages so we can test it against Wine. Note that the real FormatMessageA would need more code paths to be useful, but I'm hoping like this we can at least get the issue unstuck, and - if needed - add more functionality later?I would prefer this one over #139 and #120 due to its smaller change surface. But I'm happy to start a discussion what is the preferred way forward.