Suggested bitmap coords resolve

[P. Christeas]

> > The second patch is a simple suggestion about a NULL handler. IMHO all
> > NULLs coming from external programs-libs should be handled in a prog. In
> > that case, a NULL causes no harm, but I guess my 'early test' may
> > introduce a minor speedup.
>
> "Am I right?"
> No, IMO this is not correct.
> If Windows doesn't handle NULLs, then we shouldn't either.
> How are we supposed to detect problems with our API implementation if all
> we ever do is handle every single problem gracefully ?
> That way we'll never find out about that grave implementation problem of
> ours leading to a NULL value...

Sorry, I wasn't clear about that point. What happens with that fn is that it 
will try to get the object for that handle. Clearly, there can be no object 
for a NULL handle. The returned value will be NULL anyway and that fn would 
return that without my patch. I just short-cutted through the fn (which uses 
wine-specific calls to determine the object - I think) and returned that NULL 
earlier.
I am not sure how M$ does that, but anything other than NULL when we have no 
handle would just result in a SIGSEGV. Most mis-handling of NULLs results to 
that and if M$ would GPF to those, that doesn't mean wine should not exit 
cleanly. In some cases we should just show that our ver is better. 
The debugging difference is that my ver doesn't set the error  (  
seeSetLastError( ERROR_INVALID_HANDLE );  at the end) and there is no 
warning. I did that, because that situation happens often and fills the debug 
log with that warning line.

IMHO the only point where wine must differ from M$ is where M$ leads to crash 
(GPF - our SIGSEGV). We can warn the user that the app would fail there, but 
let him continue in most cases

P. Christeas