Exclude Console API code from K95G #301
Draft
Conversation
This file contains 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
This stuff isn't used by k95g.exe so has no reason to be compiled for k95g.exe. Reduces executable size by around 16K
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.
K95G.EXE (the GUI version of K95) still includes a reasonable chunk of code for updating a text-mode console window as used by K95.EXE.
Most of this code is never called so all its doing is bloating the executable size (and probably memory use). But surprisingly _ some of it is actually still called. I can't imagine any of it is actually doing anything useful in the absence of a console window to work with and I suspect in most cases calling this code is unintentional. Just things missed in the port to a GUI.
In some cases I've just removed the calls, in other cases I've replaced the calls with what should be called, like replacing GetCurPos with VscrnGetCurPos as is done elsewhere where ONETERMUPD is defined.
The result seems ok, but its possible this could introduce subtle bugs. Testing required.