Add debugstr_rect alias for consistency with other debugging functions.

Dimitrie O. Paun dpaun at
Sun Aug 8 10:30:48 CDT 2004

On Sat, Aug 07, 2004 at 04:00:25PM -0700, Alexandre Julliard wrote:
> Mike Hearn <mike at> writes:
> > The lack of this confused me for a few minutes, might as well stick it in.
> It's missing because it violates namespace rules. The other debugstr
> functions are here for historical reasons but we shouldn't add new ones.

Please let's not do this inside of Wine. Clearly, we want to export
everthing with the WINE_/wine_ prefix, I'm not debating this. I can 
also see that we want to be consistent, and that's a good thing -- 
for all but the debugging API our symbol invokations are far and few
in between, and it actually *helps* to see when we call a non-standard 

However, the exact opposite holds for the debugging API: it is the
most used API in the source, and it doesn't help to know that it's
a Wine API. Having the prefix on every single symbol of this API
would not only greatly clutter the code, but I'd also claim it's not
the style we should promote. People should try to write portable
Win32 code (and here portable is between MS Windows and Wine), and
a wine_ prefix is a big bad warning sign. One should be able to grep
the sources for wine_ to figure out such places. Hiding them inside
mountains of debug calls will not help.

Usage of the debug API should not tie the code to Wine, and the
source should make it clear. We should promote symbol renaming
for Winelib apps (just like we do in Wine today):
#define ERR WINE_ERR

Apart for much cleaner code, it's also useful, as I can see many 
people do:
#ifdef WINE
#    define ERR WINE_ERR
#    define TRACE WINE_TRACE
#    define ERR printf
#    define TRACE printf

I have a sentimental attachment to the Wine's debugging API, as it was
the first project that I undertook in Wine. It was what "hooked" me in.
This may be a small issue, and probably I shouldn't care, but I can't
help it. I truely think requiring the WINE_/wine_ prefix inside of Wine 
for commonly used symbols in the debugging API is not a good direction,
and I really hope we can revisit this decision.


More information about the wine-devel mailing list