aboutsummaryrefslogtreecommitdiff
path: root/win32/winansi.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* win32: drop workaround for Wine console bufferRon Yorston2024-09-271-7/+0
| | | | | | | | | | | | | | Commit 1ade2225d2 (winansi: allow alternative screen buffer to be disabled) added a workaround for the broken alternative screen buffer in the Wine console. The problem has been fixed in Wine for well over a year: https://bugs.winehq.org/show_bug.cgi?id=54287 Remove the workaround. Saves 80-96 bytes.
* win32: code shrinkRon Yorston2024-08-161-1/+1
| | | | | Add the FAST_FUNC qualifier to several Windows-specific functions. This has no effect in 64-bit builds but saves 336 bytes for 32-bit.
* win32: don't allow BB_TERMINAL_MODE=6Ron Yorston2024-06-281-1/+1
| | | | | | | | The BB_TERMINAL_MODE variable is only documented to work for values between 0 and 5. Due to an oversight it also accepted the value 6. Like other unsupported values 6 is now replaced with the default value configured at build time.
* ash: add title built-inRon Yorston2024-04-091-2/+6
| | | | | | | | | | | | | | Implement a 'title' built-in for ash. It's very simple-minded, performs almost no error checking and is completely non-portable. - With no arguments it prints the current console title. - If arguments are provided the *first only* is set as the console title. Costs 88-116 bytes. (GitHub issue #401)
* win32: ascii-optimize winansi_fputc, winansi_putcharAvi Halachmi (:avih)2024-04-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | Other winansi IO wrappers, like winansi_fputs, optimize by calling the libc API directly if no special handling is needed, e.g. if the input is fully ASCII and without escape sequences - without converting the output codepage or interpreting escapes. Now the fputc and putchar wrappers do that as well. And as a simplification, putchar is now also a wrapper of fputc. Other than possibly minor speedup, this can also help buffered streams remain buffered, because the codepage conversion using writeCon_utf8 is unbuffered and first flushes the stream, so by avoiding the conversion and calling the libc API directly, we also avoid premature flush of a buffered stream. This did happen, as "time" is buffered since commit 54dbf0fa5, so previously it was flushed early when using putchar, while now it remains buffered by default (but can still be flushed early if the -f format string contains non-ASCII chars).
* win32: UTF8_OUTPUT: flush stream before conversionAvi Halachmi (:avih)2024-04-061-1/+3
| | | | | | | | | | | | | | | | | | | | writeCon_utf8 is unbuffered - it writes directly using WriteConsoleW, but some winansi libc IO wrappers, like fputs, use the libc API directly if the content doesn't need any special handling (e.g. all ASCII and no escape sequences), and so if the stream is buffered, and if only some parts of it go through writeCon_utf8, then we can get wrong output order due to some parts being buffered and some not. Case in point, the recent commit 54dbf0fa5 made the output of "time" buffered, and so if only parts of it go through writeCon_utf8, then we get bad output order. This did actually happen, because not all the winasi wrappers have this ASCII-only optimization (e.g. winansi_putchar), and "time" did end up with wrong output order. Even if all the winansi wrappers were ASCII-optimized, "time" could still have unicode output, e.g. with -f. Fix it by flushing the stream before converting using writeCon_utf8.
* win32: UTF8_OUTPUT: recover quicker from bad byteAvi Halachmi (:avih)2024-01-311-12/+19
| | | | | | | | | | | | | | | | | | | | | | When an unexpected value is detected in UTF-8, we should print the placeholder codepoint, and then recover whenever we detect a value which is valid for starting a new UTF-8 codepoint (including ASCII7). However, previously, we only tested recovery at the bytes following the unexpected one, and so if the first unexpected value was also valid for a new codepoint, then didn't rcover it. Now we check for recovery from the first unexpected byte, which, if recoverable, requires both placeholder printout and recovery, so the recovery "unwinding" is modified a bit to allow placeholder. Example of of a sequence which now recovers quicker than before: (where UTF-8 for U+1F600 "😀" is: 0xF0 0x9F 0x98 0x80) printf "\xF0\xF0\x9F\x98\x80A" Previously: ?A Now: ?😀A
* win32: fix clang error/warningRon Yorston2023-12-311-3/+3
| | | | | | | | | | | | Since clang doesn't seem to know about ffs(3) make it use __builtin_ffs() instead. Fix a warning in process_escape() in winansi.c: result of comparison of constant -1 with expression of type 'WORD' (aka 'unsigned short') is always true. Change the error value returned by process_colour() from -1 to 0xffff. Costs 16 bytes.
* win32: avoid terminal weirdness induced by GradleRon Yorston2023-10-241-2/+2
| | | | | | | | | | | | Commit 87a3ddc06 (win32: avoid terminal weirdness induced by Gradle?) correctly diagnosed the problem but got the cure wrong. Reset DISABLE_NEWLINE_AUTO_RETURN in the new mode, not the old one. Otherwise the change isn't applied. Saves 48 bytes. (GitHub issue #372)
* win32: avoid terminal weirdness induced by Gradle?Ron Yorston2023-10-221-0/+2
| | | | | | | | | | | | GitHub issue #372 reports that in certain circumstances (which I've been unable to reproduce) Gradle leaves the terminal in a state where linefeeds seem not to result in a carriage return. This *might* be because Gradle sets DISABLE_NEWLINE_AUTO_RETURN in the terminal mode. Reset DISABLE_NEWLINE_AUTO_RETURN to zero before the shell prompt is issued to see of this makes any difference. Costs 16-32 bytes.
* win32: UTF8_INPUT: fix combining of some surrogates pairsAvi Halachmi (:avih)2023-09-111-1/+1
| | | | | | | | | The construction of a codepoint from a surrogates pair was incorrect when the result should have had the 0x10000 bit unset, due to logical "|" instead of arithmetic "+" of 0x10000 (so the 0x10000 bit was set incorrectly when the result should have been U+[1]{0,2,4...C,E}XXXX). For instance: typing or pasting U+20000 ð €€
* win32: UTF8_OUTPUT: speedup for big outputsAvi Halachmi (:avih)2023-08-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | With the native Windows console, writeCon_utf8 which converts a stream of UTF8 into console output is about 1.4x slower for big unicode writes than the native fwrite (e.g. when the console codepage is UTF8), which is not too bad. However, newer versions of conhost are quicker, e.g. OpenConsole.exe (which is conhost) which ships with the Windows terminal is about 4x faster than the native conhost in processing (unicode?) input. And when conhost can process inputs much quicker, it turned out that fwrite throughput was nearly 3x better than writeCon_utf8. Luckily, this turned out to be mainly due to the internal 256 wide chars buffer which writeCon_utf8 uses, and that with 4096 buffer it becomes only ~ 10% slower than fwrite, which is much better. However, making the console window very small such that it needs to spend very little time on rendering, makes it apparent that there's still a difference - writeCon_utf8 is about 30% slower than fwrite, but that's still not bad, and that's also an uncommon use case. So this commit increases the buffer, and also allocates it dynamically (once) to avoid abusing the stck with additional 8K in one call.
* win32: disable console output conversion with LC_ALL=CAvi Halachmi (:avih)2023-08-031-6/+29
| | | | | | | | | | | | | | | | | | | | Previously, when writing to the console, the non-unicode build always assumed the source data is in the ANSI codepage, and used charToCon to convert it unconditionally to the console CP. Similarly, the unicode build made the same assumption (where ANSI CP is UTF8), and always tried to convert it so that it's printed correctly (at least when FEATURE_UTF8_OUTPUT is enabled - which it is by default at the unicode build). However, there could be cases where this assumption is incorrect, for instance if the data comes from a file encoded for some codepage X, and after the user also changed the console CP to X does 'cat file.X' This commit allows disabling this conversion, using the same env vars which can be used to disable the locale/unicode elsewhere, (LANG, LC_CTYPE, LC_ALL as "C") e.g. 'LC_ALL=C cat file.X' now doesn't convert, and the console renders it according to its own codepage.
* win32: add FEATURE_UTF8_OUTPUT (enabled with unicode)Avi Halachmi (:avih)2023-08-031-0/+96
| | | | | | | | | | | | | | | | | | | | | Previously, the unicode build required console (out) codepage of UTF8 in order for unicode output to be printed correctly - e.g. at the shell command prompt or the output of `ls` for unicode file names. This is inconvenient, because by default it's not UTF8, and so unless the user invoked 'chcp 65001' - by default unicode output didn't work. This feature (which is now enabled for the unicode build) makes it print unicode output correctly regardless of the console CP, by using a new stream-conversion funcion from UTF8 chars to wchar_t, and writing those using WriteConsoleW. If the console CP happens to be UTF8 - this conversion is disabled. We could have instead changed the console CP to UTF8, but that's a slippery slope, and some old program which expect the default CP might get broken, so achieving the same result without touching the console CP is hopefully better.
* win32: unify 'convert and write to console' (no-op)Avi Halachmi (:avih)2023-08-031-17/+44
| | | | | | | | Use one call to do both charToCon and then write it to the console. Technically, this commit only reduces boilerplate code slightly, but it also makes it easier for future modifications to make changes to this sequence in one place.
* win32: UTF8 input: improve missing-key-down hackAvi Halachmi (:avih)2023-07-211-11/+47
| | | | | | | | | | | | | | The UTF8 input code works around an issue when pasting at the windows console (but not terminal) that sometimes we get key-up without a prior matching key-down - at which case it generates down. However, previously it detected this by comparing an up-event to the last down-event, which could result in false-positive in cases like: X-down Y-down X-up Y-up (e.g. when typing quickly). Now it remembers the last 8 key-down events when searching a prior matching key-down, which fixes an issue of incorrect repeated keys (in the example above Y-up was incorrectly changed to Y-down).
* ash: properly echo console input to 'read' built-inRon Yorston2023-07-121-0/+11
| | | | | | | The 'read' shell built-in echoed console input to stdout. Echo directly to the console instead. Costs 124-136 bytes.
* win32: more console input character conversionsRon Yorston2023-07-071-0/+20
| | | | | | | | | | | | | Add wrappers for the following input functions with conversions for console input. Applications suitable for testing these changes are appended in brackets. - getchar (xargs) - fgetc (tac) - getline (shuf) - fgets (rev) Costs 112-120 bytes.
* win32: character conversion for fread(3)Ron Yorston2023-07-061-0/+15
| | | | | | | Some applets use fread(3): dd and od, for example. Perform the necessary conversion when input is coming from the console. Costs 96-112 bytes.
* win32: don't crash the console *and* handle CJK inputRon Yorston2023-07-021-0/+21
| | | | | | | | | | | | The previous commit prevented the console from crashing with a UTF8 input code page on Windows 10/11 in the default configuration. But it broke input in CJK code pages. Again. Handle both cases. Costs 36-72 bytes. (GitHub issue #335)
* win32: revert to previous console input method by defaultRon Yorston2023-07-011-2/+8
| | | | | | | | Although the input method used for euro support is no longer required for that reason it does provide a more lightweight workaround for the problem with ReadConsoleInputA and UTF8. Repurpose FEATURE_EURO_INPUT as FEATURE_UTF8_INPUT.
* win32: code shrink readConsoleInput_utf8Ron Yorston2023-07-011-0/+4
| | | | | | | Move decision about how to read console input from windows_read_key() to readConsoleInput_utf8(). Saves 48-64 bytes.
* win32: remove superfluous euro codeRon Yorston2023-07-011-18/+0
| | | | | | | | | Commit ebe80f3e5 (win32: don't assume console CP equals OEM CP) fixed the incorrect character conversions which required special treatment for the euro symbol. The unnecessary code has been removed. Saves 64-80 bytes.
* win32: UTF8 console input: don't spin the CPUAvi Halachmi (:avih)2023-06-301-3/+5
| | | | | | | | | | | | | | | This is a regression from ec99f03ae which changed Read into Peek in order to keep the record at the console queue. However, it failed to take into account that as a result, if no input is pending, that readConsoleInput_utf8 now returns immediately without waiting for input - unlike ReadConsoleInput. Other than incorrectly returning a FALSE value in such case, it also caused a busy-wait loop of windows_read_key and high CPU usage. Fix that by waiting till there's input before the peek. This should make it just like ReadConsoleInput - which idles till there's input.
* win32: UTF8 input: avoid timeout when delivering UTF8 bytesAvi Halachmi (:avih)2023-06-281-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When windows_read_key - which is the sole consumer of readConsoleInput_utf8 - is called with a timeout value, it uses WaitForSingleObject to test whether the console has pending input. Previously, readConsoleInput_utf8 consumed the input record before it delivered the UTF8 bytes which are generated from it. It's not an issue with ASCII-7 input - because indeed there are no buffered bytes once it's delivered, and, except for console bugs (when only key-up record exists) also not an issue with 2 or 3 bytes UTF8 codepoints - because these are generated from a single wchar_t input record on key-down, and the key-up event is not yet dequeued while delivering the key-down UTF8 bytes. But with a surrogate pair, which consumes two wchar_t records to realize the UTF8 sequence, we previously consumed the records up to and including the key-up event of the 2nd surrogate half. This could result in a timeout if there are no further records at the queue - eventhough some UTF8 bytes are still buffered/pending. Such timeout can result in the shell aborting - windows_read_key returns -1, which is later interpreted as EOF of the shell input, and quits the shell. Now readConsoleInput_utf8 dequeues an input record only once the last byte which was generated from this record is delivered, which we do using PeekConsoleInputW instead of ReadConsoleInputW. This avoid a timeout as long as there are input bytes to deliver.
* win32: the great UTF8 ReadConsoleInput hackAvi Halachmi (:avih)2023-06-281-1/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 597d31ee (EURO_INPUT), ReadConsoleInputA is the default. The main problem with that is that if the console codepage is UTF8, e.g. after "chcp 65001", then typing or pasting can result in a crash of the console itself (the Windows Terminal or cmd.exe window closes). Additionally and regardless of this crash, ReadConsoleInputA is apparently buggy with UTF8 CP also otherwise. For instance, on Windows 7 only ASCII values work - others become '?'. Or sometimes in Windows 10 (cmd.exe console but not Windows terminal) only key-up events arrive for some non-ASCII codepoints (without a prior key-down), and more. So this commit implements readConsoleInput_utf8 which delivers UTF8 Regardless of CP, including of surrogate pairs, and works on win 7/10. Other than fixing the crash and working much better with UTF8 console CP, it also allows a build with the UTF8 manifest to capture correctly arbitrary unicode inputs which are typed or pasted into the console regardless of the console CP. However, it doesn't look OK unless the console CP is set to UTF8 (which we don't do automatically, but the user can chcp 65001), and editing is still lacking due to missing screen-length awareness. To reproduce the crash: start a new console window, 'chcp 65001', run this program (or busybox sh), and paste "ಀ" or "😀" (U+0C80, U+1F600) #include <windows.h> int main() { HANDLE h = GetStdHandle(STD_INPUT_HANDLE); INPUT_RECORD r; DWORD n; while (ReadConsoleInputA(h, &r, 1, &n)) /* NOP */; return 0; }
* win32: don't assume console CP equals OEM CPAvi Halachmi (:avih)2023-06-281-54/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, console input was converted to the ANSI codepage using OemToChar[Buff], and ANSI to console conversion used CharToOem[Buff]. However, while typically true by default, it's not guaranteed that the console CP is the same as the OEM CP. Now the code uses the console input/output CP as appropriate instead of the OEM CP. It uses full wide-char conversion code, which was previously limited to FEATURE_EURO, and now may be used also otherwise. While at it, the code now bypasses the conversion altogether if the src/dst CPs happen to be identical - which can definitely happen. Other than saving some CPU cycles, this also happens to fix an issue with the UTF8 manifest (in both input and output), because apparently the Oem/Char conversion APIs fail to convert one char at a time (which is not a complete UTF8 codepoint sequence) even if both the OEM and the ANSI CPs are UTF8 (as is the case when using UTF8 manifest). Conversion is also skipped: - if the converted output would be longer than the input; - if the input length is 1 and the input is multi-byte.
* win32: reduce impact of euro support (2)Ron Yorston2023-06-231-1/+3
| | | | | | | winansi_OemToCharBuff() needs to call the real OemToCharBuff(), not itself! (GitHub issue #335)
* win32: reduce impact of euro supportRon Yorston2023-06-231-10/+12
| | | | | | | | | | The workaround for euro support in busybox-w32 is only intended to work in the 858 code page. Skip the workaround if any other code page is in use. Costs 8-36 bytes. (GitHub issue #335)
* Fixes for old mingw-w64Ron Yorston2023-06-141-0/+4
| | | | | | | | | | | | | Allow current busybox-w32 to build with the CentOS 6 version of mingw-w64. - Fix declaration of setlinebuf(). (GitLab issue 116) - Define ENABLE_VIRTUAL_TERMINAL_INPUT. (GitLab issue 117) - Define IO_REPARSE_TAG_APPEXECLINK. - Avoid a compiler warning in coreutils/shuf.c.
* win32: fix euro symbol handlingRon Yorston2023-06-021-3/+1
| | | | | | | | | | | | Commit 2b4dbe5fa (libbb: speed up bb_get_chunk_from_file()) speeded up grep by a factor of two. However, it introduced a call to OemToCharBuff() in bb_get_chunk_from_file() which didn't have the fix for the euro symbol from commit 93a63809f9 (win32: add support for the euro currency symbol). Export the fixed version of OemToCharBuff() and use it. Saves 8 bytes (64-bit), adds 28 bytes (32-bit)
* win32: delay adjusting code pageRon Yorston2023-03-171-1/+12
| | | | | | | | | | | Commit 93a63809f9 (win32: add support for the euro currency symbol) caused all invocations of busybox-w32 to change code page 850 to 858. This has been known to cause problems with fonts in PowerShell (GitHub issue #207). Delay changing the code page until an i/o operation is imminent. Instances of PowerShell started by the `drop` applet during ssh login thus no longer have their code page adjusted.
* win32: more changes to console/terminal modesRon Yorston2023-03-071-19/+19
| | | | | | | | | | | | | | | | | | Allowing virtual terminal input mode to be set if available proved to be unhelpful: cmd.exe doesn't understand such newfangled stuff (though PowerShell does). The allowed values of BB_TERMINAL_MODE are changed to: 0 Force console mode. 1 Force virtual terminal mode for output. 2 Force virtual terminal mode for input. 3 Force virtual terminal mode for input and output. 4 Support virtual terminal input if enabled. Don't alter mode. 5 Support virtual terminal input if enabled. Set virtual terminal mode for output, if possible. The default is 5.
* win32: changes to console mode handlingRon Yorston2023-03-051-20/+56
| | | | | | | | | | | | | | | | | | | Add the environment variable BB_TERMINAL_MODE as a more general way of controlling console/terminal mode setting. The default remains unchanged: use virtual terminal mode for output if possible but fall back to the console API with emulated ANSI escape sequences. Currently valid settings are: 0 Force use of console mode 1 Force use of virtual terminal mode for output 5 Prefer virtual terminal mode for output, fall back to console Other values won't do anything useful until code elsewhere has been updated. BB_SKIP_ANSI_EMULATION remains available for backwards compatibility. If both variables are set BB_TERMINAL_MODE takes precedence.
* win32: try to recover from strange console modeRon Yorston2023-02-211-4/+14
| | | | | | | | | | | | | | | | | | | | | | Execute a remote command on a Windows server using ssh: ~$ ssh localhost 'echo hello' rmy@localhost's password: hello If such a command is run from a busybox-w32 shell the console enters a strange mode when the command completes. Attempt to recover by setting the console back to a default mode. - This doesn't work in a legacy console. - The new mode may not be _exactly_ correct, but it's better than how ssh leaves it. Costs 80-96 bytes. (GitHub issue #288)
* win32: shuffle skip_ansi_emulation() codeRon Yorston2023-02-191-6/+8
| | | | | Rearrange code to avoid unnecessary tests when the environment variable BB_SKIP_ANSI_EMULATION is set.
* win32: work around problem with ConEmuRon Yorston2023-02-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | When running the busybox-w32 shell in ConEmu, if: - ANSI emulation is disabled (which it will be, by default) - a non-builtin command is run there is a window of a few seconds after the command completes during which ConEmu is in XTerm mode. During this time any attempt to use the arrows keys will result in [A[B[C[D appearing. This appears to be a common problem: https://github.com/Maximus5/ConEmu/issues/2316 Try to detect if we're running under ConEmu and alter the default behaviour to prefer ANSI emulation. The user can override this preference by setting BB_SKIP_ANSI_EMULATION if desired. By a quirk of fate, old MSYS2 programs (from 2021) which required a workaround in busybox-w32 (commit 54d2ea4b4) are immune to the problem with ConEmu. (GitHib issue #287)
* win32: only change console mode if necessaryRon Yorston2023-02-191-7/+10
| | | | | In skip_ansi_emulation() only call SetConsoleMode() if the new mode differs from the current mode.
* win32: speed up getc(3) wrapperRon Yorston2022-12-301-2/+2
| | | | | | | | The grep applet was found to be rather slow. A major reason for this is the implementation of getc(3). Using _getc_nolock() and inlining is_console_in() speeds things up by a factor of three. (GitHub issue #278)
* ash: export certain variables to the environment immediatelyRon Yorston2022-05-081-1/+1
| | | | | | | | | | | The environment variables BB_OVERRIDE_APPLETS, BB_SKIP_ANSI_EMULATION and BB_SYSTEMROOT affect of the behaviour of the shell itself. Setting them as shell variables is insufficient for them to affect the current shell. When these three variables are exported from the shell they are now placed in the environment immediately. Conversely, when they're unset or unexported they're removed from the environment.
* winansi: detect if running under WineRon Yorston2021-12-221-2/+11
| | | | | | | | | | | | | | Detect if running under Wine by checking for the wine_get_version function in ntdll.dll. This is how the Wine Developer FAQ suggests doing it. If running under Wine and not otherwise configured: - use ANSI emulation; - don't use alternate screen buffer in vi/less. Explicit settings of BB_SKIP_ANSI_EMULATION and BB_ALT_BUFFER will override the Wine defaults.
* winansi: add missing va_end()Ron Yorston2021-07-111-0/+1
|
* winansi: fix ansi emulationRon Yorston2021-03-051-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | The following commands (reported in GitHub issue #201): printf "\033[38;2;255;0;0mX\033[m\n" printf "\033[38;2;255;0;0m;\033[m\n" produce different results. The first correctly displays a red 'X' while the second incorrectly displays a white ';'. The problem is that process_24bit() overruns the extent of the escape sequence. As a result the loop in process_escape() which handles 'ESC[...m' sequences sees the ';' in the text as a continuation of the escape sequence. Fix this by: - reworking process_24bit() so that the overrun is avoided; - changing the test in the loop in process_escape() so that even if an overrun happens it stops processing at the end of the escape sequence. Also, save a few bytes by replacing '++str' with 'str + 1' in a few places.
* winansi: code shrink and improvementsRon Yorston2021-02-171-41/+15
| | | | | | | | | | | | | | | | | | | | Commit b0b7ab792 (winansi: code shrink) noted that combining reverse vidoe escape sequences (e.g. ESC[7;27m) didn't work properly. Make further changes to improve the situation: - revert to keeping the current attributes in a static variable; - when reverse video is enabled switch the intensity as well as the colour components; - move the code from set_console_attr() into its only caller, process_escape(); - use 0xffff instead of 0 as a flag to indicate the attributes haven't been initialised. Saves 44 bytes and seems to work better.
* winansi: don't check return from xmallocRon Yorston2021-02-161-3/+0
|
* winansi: allow alternative screen buffer to be disabledRon Yorston2021-02-151-0/+7
| | | | | | | | The alternative console screen buffer (used by less and vi) doesn't work in Wine. Setting the environment variable BB_ALT_BUFFER to 0 causes a screen reset instead.
* winansi: allow test suite to run on WineRon Yorston2021-02-151-3/+3
| | | | | | | | | | | | Running the test suite on Wine failed because in seq 4 0 8 | head -n 10 'seq' didn't detect the broken pipe when 'head' terminated and carried on forever. Fix this by adding a call to ferror(3) in winansi_vfprintf(). Also, use xstrdup() and xmalloc() in a couple of places.
* winansi: code shrinkRon Yorston2021-02-081-13/+13
| | | | | | Mark floating-point constants as being of type 'float'. Saves 72 bytes.
* winansi: more accurate colour mappingRon Yorston2021-02-071-20/+99
| | | | | | Use a more accurate technique to map RGB colours to standard Windows console colours. Since this costs 648 bytes it's configurable but is enabled by default.
* winansi: code shrinkRon Yorston2021-02-071-90/+71
| | | | | | | | | | | | | | | | | | | Refactor handling of ESC[38...m and ESC[48...m: - At lower levels deal only with the standard console foreground colours. This makes handling of foreground and background colours more similar. - Many '|=' assignments (to combine attribute values) have been replaced by simple assinments. - Use a common routine to convert RGB to console colours; colours in the 8-bit 6x6x6 cube are scaled up to make use of this. - Detect invalid escape sequences to avoid setting incorrect colour values. Saves 296 bytes.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-16 02:21:55 +0000