We used to use a bitfield there, which was restricting the total
number of flags to 32 (unless we switch to uint64, which is suboptimal).
Moreover, with the introduction of the global debug flags, we have
even fewer bits to flip, and this shared nature was restricting
the introduction of more global debug channels.
The goal for the bitfield was to make it possible to put a debug message into
more than one channel. But this feature was practically not used by the engines.
This was removed by the previous commits.
This commit turns the debug channels into a hashmap and puts the global channel
IDs after 100000.
There is no absolute need to renumber the existing debug channels, but
I could follow with an engine or two.
A defaultCommandProcessor let's an engine take over the processing of
commands in the debugger. The Director Engine uses the functionality to
implement a repl for the Lingo language.
Example Usage:
registerDefaultCmd(WRAP_DEFAULTCOMMAND(Debugger, lingoCommandProcessor));
The input will now be handled by lingoCommandProcessor. Other commands
will not work untill control is given back to the debugger.
It's up to the engine to return control to the debugger when done.
To return control, call it with a nullptr:
registerDefaultCmd(nullptr);
When built with enable-text-console and disable-readline, flushing output
immediately after printing the debugger prompt, before waiting for input,
ensures that external tools can spawn ScummVM, detect the prompt, and pipe
in automated responses (e.g., expect scripts).
Explicit flushing was necessary at least on Windows, where support for
automating terminal input is less sophisticated. Otherwise, the prompt
string doesn't make it through the pipe, and both the script and ScummVM
get stuck waiting for input.
strdup is a POSIX API, not an ANSI C API. It is not available with
-std=c++11 on newlib-based systems, and VS 2015 will throw errors
unless it is #defined to alias to _strdup or unless deprecation
warnings are turned off (which is not a good idea in general).
Common::String is a safer and potentially faster (due to small
string optimisation) alternative, so prefer it instead.
stdout may be buffered, in which case debugger messages are
delayed until a newline is written. The same kinds of calls to
OSystem::logMessage are flushed, so this just seems to be a simple
omission on this non-default code branch.
I don't know of any good way of transforming file names to base
file names, so document that "md5mac" expects the base file name.
Even though it currently will accept MacBinary file names.
