MSVC refuses to compile otherwise.

Whether things actually work when pyuno is built against the debugging
runtime, but the internal Python (to the best of my knowledge) still
against the normal one, I don't know. But anyway, this makes the build
succeed here.

Take notice of USE_DEBUG_RUNTIME also in set_wntx64.mk.

Don't unset USE_DEBUG_RUNTIME and don't hardcode the non-debugging
msvcprt.lib when building the Explorer extension.

Undefine OSL_DEBUG_LEVEL in its source files that would otherwise drag
in the diagnosing functions from sal. We don't link the Explorer
extension with sal.

As such it might not make much sense to actually *use* a shell
extension built with assertions in the C++ library, against the
debugging C/C++ runtime. You don't want assertions to fire in
Explorer, do you? On the other hand, one could be debugging an
Explorer extension remotely. Maybe even locally, I don't know if some
lower levels of Windows get upset if Explorer is unresponsive due to
being debugged, or something.

But anyway, the main point for now is to make an --enable-dbgutil
build succeed.

Alternatively we could also make sure USE_DEBUG_RUNTIME is unset in
*all* makefiles in shell.

Besides, hardcoding msvcprt.lib breaks a dbgutil build where we use
msvcprtd.lib.

It doesn't make sense to try to use anything else to print on *nix
systems these days

Don't try to start a started frame, don't try to end a not started
frame.

Based on a patch from Andras, this removes a set of un-used
debugging type strings from all lang-pack resource files.

With database document, any contents of the Pictures folder ( afaics only basic dialogs store content here ) is never cleaned up between saves.

This patch turns on sorting in many listboxes containing template or region names in Impress.
Contributed under license LGPLv3+/MPL.