With the new (great!) Windows UTF-16 console I/O changes, some minor backcompat issues have been introduced for MSVC builds. (Linking to shell.c from the Fossil project, as I can't find all the sources to generate this file, right now.)

• Calls to SetConsoleMode() with the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag included will fail on older versions of Windows (before Windows 10). This will mostly go unnoticed, as well-behaved shells will always keep the console mode in a reasonable state useful to most programs. Also, I think the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag should only be used for programs to explicitly print VT sequences, otherwise output may look surprising.

C:\...>ver

Microsoft Windows XP [Version 5.1.2600]

C:\...>type sample.c
#include <windows.h>
#ifndef ENABLE_VIRTUAL_TERMINAL_PROCESSING
#define ENABLE_VIRTUAL_TERMINAL_PROCESSING 0x0004
#endif
main(){
  if( !SetConsoleMode(
        GetStdHandle(STD_OUTPUT_HANDLE),
        ENABLE_VIRTUAL_TERMINAL_PROCESSING) ){
    DWORD dwNumberOfCharsWritten;
    WriteConsoleA(
      GetStdHandle(STD_OUTPUT_HANDLE),
      "Failed to set ENABLE_VIRTUAL_TERMINAL_PROCESSING.\n",
      50,
      &dwNumberOfCharsWritten,
      NULL);
  }
}

C:\...>sample.exe
Failed to set ENABLE_VIRTUAL_TERMINAL_PROCESSING.

• The <stdint.h> header is not available for older MSVC compilers, breaking the build. But the header is also not required for the latest MSVC compilers, so I'd like to ask for this include directive to be dropped.

Hm, the addition of <stdint.h> is probably is unrelated to the UTF-16 console I/O changes--I was maybe just folled by the temporal coincidence when updating my Fossil builds.

Calls to SetConsoleMode() with the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag included will fail on older versions of Windows (before Windows 10).

The new console I/O package doe not check the return value from SetConsoleMode() for this reason.

This will mostly go unnoticed, as well-behaved shells will always keep the console mode in a reasonable state useful to most programs.

Part of my thinking about this is that the SQLite CLI, (also a shell, albeit one with limited purposes), will keep the console mode in a state useful to itself, including when it is linked with a line-editing package. This keeping should include both startup and resumption from .shell commands, regardless of how ill-behaved the invoked program is with respect to restoring the console mode upon its exit.

Also, I think the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag should only be used for programs to explicitly print VT sequences, otherwise output may look surprising.

My understanding of the flag differs from that. The flag's effect is to enable interpretation of VT sequences rather than printing them.

I have extremely limited sympathy for those who cause non-printable codes to be sent directly to their console and are then both surprised and willing to complain about it. If they want to discern what codes or bytes are in some datum, the hex() function is available to avoid such surprise and simplify human interpretation.

On backwards compatibility:

Simple patches to accommodate ancient compilers and operating systems will be carefully considered. The objectives for older platforms include basic functionality. But sacrificing utility on modern systems to avoid quirks on obsolete systems may not happen.

It's also much more likely to be needed by other compilers (if the types it defines are, of course).

Yes, I see. I noticed those changes at the same time in the Fossil project, and erroneously concluded they were related.

An even simpler example without any BLOB to TEXT conversion magic:

SELECT char(0x1b,0x5b,0x34,0x37,0x6d)||'Can you read this?';

My opinion is that there may be people who think it's nice to keep colored error message fragments in a SQL table, and the SQLite shell should not be tricked into displaying invisible text when dealing with such cases.

But I also see--as I just noticed--that the Windows builds should be bug-for-bug compatible with the *nix builds, the latter permitting arbitrary VT sequences to mess with SQLite shell output, as well! ;-)