Windows 10's MSVCRT will only work if the Win32 version in the header is
0 or 10. Some PE's use it for something else, so when the DLL is
injected the process fails. Provide custom routines for the C functions
used, so the DLL only depends on KERNEL32.
With the DLL independent of the CRT that would mean the exe would either
also need to be independent, or the source files would need to be built
twice (or just remove a linker warning). Another option is to export
the functions from the DLL and have the exe import them, which turned
out to simplify things quite nicely.
A process that has a really long command line would not log properly, so
double the heap to accommodate it.
If ANSICON_DEF could not be parsed the default attribute would be zero
(black on black). Use 7 or -7 instead.
Prevent loading more libraries than necessary, so load WINMM the first
time the bell is used and use the CRT printf functions to avoid loading
USER32 at all.
I was also going to remove MSVCRT, but that turned out to be more
trouble than it's worth. However, a side-effect that I kept is
replacing bsearch with a dedicated search routine.
Just copying the history from the source:
recognize the standard handle defines in WriteFile;
minor speed improvement by caching GetConsoleMode;
keep track of three handles (ostensibly stdout, stderr and a file);
test a DOS header exists before writing to e_oemid;
more flexible/robust handling of data directories;
files writing to the console will always succeed;
log: use API file functions and a custom printf;
add a blank line between processes;
set function name for MyWriteConsoleA;
scan imports from "kernel32" (without extension);
added dynamic environment variable CLICOLOR;
removed _hwrite (it's the same address as _lwrite);
join multibyte characters split across separate writes;
remove wcstok, avoiding potential interference with the host;
similarly, use a private heap instead of malloc.
