There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
Running out of pool is likely at least during kmtest:ExPools.
There is a chance of crashing when dereferencing these null pointers -- but
worse, there's also a chance of overwriting the IVT or BDA if a VDM BIOS
call is in progress, which can lead to crashes in non-obvious places later.
CORE-12671
- The default format is used when no format name is specified: this is
the one we use so far in ReactOS:
<debug_class>:(<file>:<line>) <message>
with "debug_class" being "trace", "warn", "err".
- The "wine" format is the one used by Wine. It can be used when trying
to diff-compare traces for a module with the corresponding one
obtained from a Wine run. It can also be useful because the logging of
Wine-synced code assumes that the function names are automatically
added by the helper macros "FIXME()", "TRACE()", "WARN()" or "ERR()",
and not manually inside the logging string given to these macros:
for example:
FIXME("(%params) message\n", params);
displays:
fixme:<module>:SomeFunc(params) message
- The "extended" (or "ext") format is very noisy and tries to output a
lot of information; it is a hybrid of the previous two formats:
<debug_class>:(<file>:<line>):<channel>:SomeFunc <message>
Support for displaying the current process ID is added in
addition to the already existing support for thread ID.