Re: Suggested bitmap coords resolve

[Andreas Mohr]

On Sun, Jun 23, 2002 at 06:18:13PM +0300, P. Christeas wrote:
> This patch resolves some trouble with bitmap drawing (DIBs), when the y-axis 
> uses negative mapping (LPtoDP). This makes Aut0CaD r. 14 usable under wine.
> Please note bug #720, which was closed by this patch and note any problems w. 
> the patch.
>
> 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...

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